Click Here To Visit SIP Broker  

Go Back   Voxalot / SIP Broker Support Forums > Voxalot Forums > Voxalot Support

Voxalot Support Support for the Voxalot service.

Thread Tools Display Modes
Unread 03-21-2007, 03:07 AM   #21
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default workaround using udp_echo

Originally Posted by v164 View Post
My new Japanese VSP sends SIP INVITE packets where the final line of the SDP body ends abruptly without a terminating CRLF ( 0x0d 0x0a ) ... . The AT-530 doesn't like that, and rejects the call with "488 Not Acceptable Here". I've sent an email to Atcom asking them to make the firmware more liberal...
No word from Atcom yet, but in the meantime I've created a small program that adds in the missing carriage-return - line-feed pair (CRLF 0x0d 0x0a ) to the end of the SIP INVITE packet, and then sends the packet on to the AT-530.

I did this by slightly modifying Christopher Brewer's "udpserv: A simple UDP echo server" program.

The added bits are:

struct sockaddr_in dest_client;  /* Info about the destination client */


char *buffer_ptr;


dest_client.sin_family = AF_INET;
dest_client.sin_port = htons((unsigned short)6080);
dest_client.sin_addr.s_addr = inet_addr("");

/* Receive bytes from client */

/* Send data back */
/* (after adding 0x0d 0x0a to the end of it */
if( buffer[bytes_received-1] != 0x0d && buffer[bytes_received-1] != 0x0a )
	buffer[bytes_received++] = 0x0d;
	buffer[bytes_received++] = 0x0a;

 * modify port in request uri from 5061 to 6080
if( buffer[0] == 'A' )  /* for ACK */
	buffer_ptr = &buffer[32];
	buffer_ptr = &buffer[35];

*buffer_ptr++ = 0x36;
*buffer_ptr++ = 0x30;
*buffer_ptr++ = 0x38;
*buffer_ptr++ = 0x30;

if (sendto(sd, buffer, bytes_received, 0, (struct sockaddr *)&dest_client, client_length) != bytes_received)
The AT-530, at, is listening for incoming SIP messages on port 6080. I've used a softphone to register with the sip server, quoting port 5061 in the Contact: field (then terminating the softphone before it can deregister) (a more robust solution would put SIP register functionality into the above program). In the AT-530's NAT settings, UDP port 5061 is mapped to (the old windows 98 laptop on my LAN running the above udp echo program).

So when someone calls my 0505536xxxx number (either from the PSTN, or through VoIP), the SIP INVITE packet comes straight through to my windows98 laptop, the above udp echo program adds in the missing CRLF (if necessary), changes the port in the request URI from 5061 to 6080, and then sends it to the AT-530. The AT-530 then handles it as if the correctly formatted packet had arrived straight from the SIP server.

One of the fascinating things about RFC3261 SIP, which allows the above trick to work, is that (correct me if I'm wrong, Martin) the source address and source port from which SIP messages arrive, is never actually used, unless you are doing "extra-RFC3261" things such as "NAT assistance" or using "rport" parameters in Via headers.

Perhaps a similar technique could remove the "=on" from the ";lr" parameter for people using the NTT-West SVIII modem.
v164 is offline   Reply With Quote
The Following User Says Thank You to v164 For This Useful Post:
martin (03-21-2007)
Unread 06-19-2007, 11:51 AM   #22
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough

Originally Posted by v164
However, I seem to have come across yet another SIP incompatibility problem.

VoXaLot successfully registers with the provider at, and the provider appears to correctly use the "Contact: " URI - 660xxx@, however when a call comes in, the SIP INVITE message makes it all the way to my phone (which accepts the call, rings, and if I answer it, it even starts transmitting RTP packets), however the "100 Trying", "180 Ringing" and "200 OK" messages don't seem to make it back to my provider's SIP server.

The symptom is that, although my phone rings, the caller does not hear the ringing tone ("ringback").

The SIP invite packets from my provider arrive from, with a source port in the 30000 - 60000 range (eg. port 37422), however the "Via" header in the SIP INVITE wants the reply to be sent to port 5060. I thought that maybe VoXaLot was sending the "100 Trying", "180 Ringing" and "200 OK" messages back to port 37422 (which would be essential for "NAT Assistance"), and so the responses were being lost, however when I send a similar UDP packet to Voxalot correctly responds to port 5060.

I'm at a loss to explain it. Incoming calls work fine with X-Ten / Firefly SIP softphone, however the 100, 180, and 200 responses seem to go missing when the incoming call is processed through Voxalot. The same thing happens both when answering on my phone that's registered to Voxalot, and when my phone is un-registered, and Voxalot answers the call by voicemail.

Somewhere between and the 100, 180, and 200 SIP responses seem to go missing.

I have a hunch that this might be because of the "lr=on" problem; the responses are getting there, but because of "lr=on", rejects the messages as non-compliant.

I'm thinking that Craig Peacock's "sipdebug" might show what the problem is.
SIP Debug Proxy Server
v164 is offline   Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Dial plan problems with FaktorTel and VoXaLoT Hally Voxalot Support 1 01-06-2007 09:21 AM
dial plan for ** won't get you speed dial d85551 Voxalot Support 0 11-30-2006 12:00 PM
dial plan help please muzzza Voxalot Support 0 09-01-2006 11:38 AM
Dial Plan for Italy wanted!!! moonshiner Voxalot Support 32 08-20-2006 10:26 PM
Voxalot as Provider in Dial Plan vpsaini Voxalot Support 2 06-27-2006 09:36 AM

All times are GMT. The time now is 03:16 PM.

Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.