Direct Dial IP

[v164]

Originally Posted by v164

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.
http://www.gomorgan89.com/winsock/udpserv.html

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("192.168.11.1");


...
/* 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];
else
	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 192.168.11.1, 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 192.168.11.45 (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]

Originally Posted by v164

However, I seem to have come across yet another SIP incompatibility problem.

VoXaLot successfully registers with the provider at ph2.so-net.ne.jp, and the provider appears to correctly use the "Contact: " URI - 660xxx@64.34.173.199:5061, 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 202.238.94.166, 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 64.34.173.199:5061 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 64.34.173.199:5061 and 202.238.94.166:5060 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", 202.238.94.166 rejects the messages as non-compliant.

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