PDA

View Full Version : Direct Dial IP


v164
03-30-2006, 02:04 PM
I have a SIP VoIP service bundled with my ISP in Japan. This VSP "blocks incoming SIP calls from non-business partner external domains" (as SIP Broker so consisely puts it). The only people who can call me through this VoIP service for free are other subscribers, in Japan, with the same ISP, or one of their business-partners.

(Edited 2007-03-03: Further, for someone to call me for free through this service, they need to know that I have this "IP Phone" service, and they need to know my 050xxxxxxxx phone number.)

My ATA however, will accept incoming calls directly from anywhere on the internet (any IP address). So if the person that wants to call me knows my IP address (and 050 number), they can call my ATA direct, for free (no need to traverse my VSP's proxy).

For example, using the X-Ten lite softphone, if I set "Direct Dial IP" to "Yes" (default is "No"), and then dial,

050xxxxxxxx@xxx.xxx.xxx.xxx

(xxx.xxx.xxx.xxx = my IP address)

the call goes straight to my ATA at home and my home phone rings.


I then went to www.e164.org, and set up an ENUM mapping. Both my home number (+8159xxxxxxx) and my VoIP number (+8150xxxxxxxx) are mapped to the SIP URI,

050xxxxxxxx@xxx.xxx.xxx.xxx

The test call at e164.org works fine, and using OzTell's "External free service" option in WebDialer also works (ie, using OzTell's webdialer, I dial my PSTN number, and the call comes arrives via VoIP). However, I haven't been able to get inbound calls to come in via SIP Broker, either using SIP Broker via VoIP, or using the SIP Broker PSTN gateway numbers.

So what I'm asking is, does SIP Broker / Voxalot work with Direct Dial IP?

Voxalot has a lot of configuration options - I was thinking maybe I could "call forward" my voxalot service to my IP address, or maybe I could setup my IP address as an external provider and transfer all calls there.

PS. It appears that my VSP blocks external SIP traffic at their routers. Hence, I can't register this VSP account to have it used with voxalot / OzTell webdialer etc.

martin
03-30-2006, 08:59 PM
Hi v164,

Dracofelis has written a nice piece on doing exactly this on a Sipura / Linksys ATA. Hopefully there is something in there that might help you:

http://faq.sipbroker.com/tiki-index.php?page=Inbound%20Calls%20Directly%20to%20y our%20LinkSys%20or%20Sipura

DracoFelis
03-30-2006, 11:52 PM
Dracofelis has written a nice piece on doing exactly this on a Sipura / Linksys ATA. Hopefully there is something in there that might help you:

http://faq.sipbroker.com/tiki-index.php?page=Inbound%20Calls%20Directly%20to%20y our%20LinkSys%20or%20Sipura
Agreed.

The OP didn't say what type of adapter was being used. However, the fact that the "test call" worked, means that the techniques used in my Wiki post should also work (but the details may be slightly different, depending upon what adapter the OP is used).

NOTE: I highly recommend the OP get a free SIP Broker alias (sign up here: http://www.sipbroker.com ), and point that "alias" at the dynamic DNS entry pointing to the OP's IP dialing address. Once that is done, it is trivial for the OP to be dialed via their SIP Broker alias (that now points directly to their adapter). For example, SIP Broker aliases can easily be dialed by: 1) Any Voxalot user (*011 alias), 2) any SIP Broker user (*011 alias), 3) any user of the free SIP Broker PSTN dialin numbers (*011 alias), 4) any user of a VoIP service that "peers" with SIP Broker (peer_code *011 alias), 5) and even anyone who can dial SIP URIs directly (*011alias@sipbroker.com).

hwittenb
03-31-2006, 04:13 AM
I highly recommend the OP get a free SIP Broker alias (sign up here: http://www.sipbroker.com ).
I don't see where you click to get the alias on the sipbroker.com page.

martin
03-31-2006, 06:06 AM
Hi,

Just register with sipbroker.com and when you login you should see the "Member Details" page. Scroll down and you will see a section where you can set-up an alias.
The alias maps to the URI that you used to register with SIP Broker.

Hope that helps

v164
03-31-2006, 04:42 PM
Thank you Martin and DracoFelis for that info. I'll try those ideas on the weekend.

However, it is confusing for me, that with my PSTN number mapped to 050xxxxxxxx@xxx.xxx.xxx.xxx, e164.org can call me via ENUM (test), OzTell can can call me via ENUM (WebDialer), but Sip Broker can't seem to call me via ENUM.

The ATA I'm using is the "ADSL Modem SV III", provided by NTT-West. This appears to be the standard ADSL modem they supply for their "Flets ADSL" service. It has a built-in SIP-compliant ATA (supports G.711 u-law codec only).
http://www.ntt-west.co.jp/kiki/consumer/flets/modemsv3/index.html
(in Japanese)

http://asahi-net.jp/en/support/guide/ip-f-sv.html
(an abridged guide in English)

The ATA is not locked - you can set it to use any SIP provider - however it is designed specifically for the bundled / packaged "IP Phone" service provided by Japanese ISPs using NTT's "ADSL Flets" connection. The dial plan is hard coded, and calls are dialed out in Japanese-domestic format.

The most flexible solution for me, would be to run Asterisk on an internal computer, have the ATA register with my Asterisk server, and then get the Asterisk server to take care of everything. However, I'm trying to see if there is a solution that would require no additional hardware, so that many other subscribers in my situation can take advantage of ENUM and VoIP peering.


edited: spelling correction

Ron
04-01-2006, 07:39 AM
The most flexible solution for me, would be to run Asterisk on an internal computer, have the ATA register with my Asterisk server, and then get the Asterisk server to take care of everything. However, I'm trying to see if there is a solution that would require no additional hardware, so that many other subscribers in my situation can take advantage of ENUM and VoIP peering.

I long to play with Asterisk myself, but don't currently have the time and resources to devote to it. I don't have a clear picture of your needs and what all you're dealing with, but I was able to pull most of my VoIP loose ends together using VoXaLot:

I have two DID's and an FWD number that I point to xxxxxx@voxalot.com.

I have four outbound providers for PSTN termination (one is default, the other three require dialing a prefix of #n to access them). I have StanaPhone set up as a provider so I can call other StanaPhone users. I have FWD set up as a provider to I can direct toll-free calls there.

Now, with one PAP2 registered on VoXaLot and only one phone line which is wired to all the phones in the house, I can make and receive calls to almost anywhere using the lowest cost route.

The only loose ends I have left are Gizmo Project and StanaPhone incoming calls as neither of these allow forwarding to a URI.

I'm not sure this picture will necessarily help with your situation, but like you, I hope it will give other users some food for thought.

Ron

v164
04-02-2006, 12:42 PM
I still can't receive an ENUM call via SipBroker. However, I noticed the modem light flashing, showing the UDP packet arriving. For some reason, my ATA was not accepting the call. To get to the bottom of the matter, I captured some of these packets and analysed the contents. Below are the SIP "INVITE" messages that arrived.


050xxxxxxxx is my 050 phone number
xxx.xxx.xxx.xxx is my public IP address
6173305xxxx is my PSTN number, which is mapped to

sip:050xxxxxxxx@xxx.xxx.xxx.xxx

at e164.org


Here are the SIP "INVITE" messages that arrived...

<< test call via e164.org - this works >>

INVITE sip:050xxxxxxxx@xxx.xxx.xxx.xxx SIP/2.0
Via: SIP/2.0/UDP 204.50.80.11:5060;branch=z9hG4bK042cc19c
From: "6044845289" <sip:6044845289@204.50.80.11>;tag=as056c135d
To: <sip:050xxxxxxxx@xxx.xxx.xxx.xxx>
Contact: <sip:6044845289@204.50.80.11>
Call-ID: 5d6...edited.out...48@204.50.80.11
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Sun, 02 Apr 2006 11:45:49 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 289


I then used Voxalot Web Callback to get an incoming call via SIP Broker. For "Your Number", I entered 6173305xxxx, via SIP Broker, and for "Number to Dial", I entered 15166875089 (an ENUM test number), via SIP Broker.

<< call using SIP broker. My ATA ignores this; it doesn't ring >>

INVITE sip:050xxxxxxxx@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:24.196.79.163;ftag=as6e3737c3;lr=on>
Via: SIP/2.0/UDP 24.196.79.163;branch=z9hG4bK2618.863f3e15.0
Via: SIP/2.0/UDP 71.13.117.133:5061;branch=z9hG4bK3ad516b5;rport=50 61
From: "<my 6-digit Voxalot user ID>" <sip:blah@sipbroker.com>;tag=as6e3737c3
To: <sip:*0136173305xxxx@sipbroker.com>
Contact: <sip:blah@71.13.117.133:5061>
Call-ID: 0e3...edited.out...61d@sipbroker.com
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 16
Date: Sun, 02 Apr 2006 12:09:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 338



The key difference seems to be in the "To: " line.

(Edited 2006-05-28: the problem is actually the "lr=on" part of the Record-Route header - see subsequent post for details)

Test call from e164.org:

To: <sip:050xxxxxxxx@xxx.xxx.xxx.xxx>


Test call from SIPBroker:

To: <sip:*0136173305xxxx@sipbroker.com>


It seems that my ATA looks at the "To: " line, says to itself "I'm not *0136173305xxxx@sipbroker.com", and ignores it.

So that seems to be the cause of the problem. But is the fault with SIP Broker, or with my ATA?

martin
04-07-2006, 05:01 PM
Hi,

The problem you mention is working as designed. In the RFC look for the section

4.1.2 Request-URI

The Request-URI field is a SIP URL as described in Section 2 or a
general URI. It indicates the user or service that this request is
being addressed to. Unlike the To field, the Request-URI field may
be re-written by proxies.


Another link describes it as "bad practice"

http://www.archivum.info/serusers@iptel.org/2005-04/msg00535.html

v164
04-08-2006, 02:11 PM
Thanks martin, ron, et al for your comments.

ron,

Voxalot would tie everything up nicely, except for the fact that my VSP-ISP's SIP server blocks/ignores SIP traffic from outside.

I think I'm going to have to either use Asterisk / Asterisk@Home / SER, or perhaps setup some kind of UDP proxy to pass Voxalot's signalling traffic through on the way to my VSP. Probably may as well just use Asterisk.

Although with one Asterisk box, I should be able to organise seemless ENUM lookups and/or peering for other people connected to the same ISP - kind of like replicating Voxalot's setup, but within the ISP's domain (so their SIP servers will talk to us).

evilbunny
04-09-2006, 09:13 AM
I setup an asterisk c&p setup site a long time ago... http://www.asterisk.net.au

v164
05-28-2006, 05:29 AM
I've done some more thorough black-box testing on my ATA, and I've found that the problem is not in the "To: " line, but is actually in the "lr=on" parameter of the "Record-Route: " line added by SipBroker.

The SIP INVITE message from SipBroker arrives at my ATA like this:

INVITE sip:050xxxxxxxx@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:24.196.79.163;ftag=as6e3737c3;lr=on>
...

My ATA completely ignores this SIP message - it doesn't even respond with an error.


However, if I remove the three characters "=on", so as to make this:

INVITE sip:050xxxxxxxx@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:24.196.79.163;ftag=as6e3737c3;lr>
...

my ATA accepts the call and my phone rings.



This problem is described further in this discussion:

https://lists.cs.columbia.edu/pipermail/sip-implementors/2003-October/005528.html


Arguably, lr-param = "lr", as on page 222 of RFC3261 is correct, however some ATAs will not work with this. Among the SER documentation is the comment,

"add value to ;lr param to make some broken UAs happy"


So "lr" will break some UAs, and "lr=on" will break others (like mine) - a situation where it's impossible to please everybody.

Does SipBroker need to stay in the (SIP signalling) loop after the call is established? If not, you could just stop putting the "Record-Route: " header in the INVITE messages.

I could perhaps petition the manufactuer of my ATA to make their ATA more accepting of the "lr" parameter in the next firmware upgrade.

Perhaps the most flexible thing would be for SipBroker to try "lr" first (as per RFC3261), and then if the UA doesn't like it, try "lr=on" (or perhaps try these in the reverse order). This would try to please everybody, but would require, I imagine, a fair bit of re-coding of SipBroker's system.

v164
03-05-2007, 10:09 AM
An update on this situation:

A "workaround" of sorts is explained here:
http://forum.voxalot.com/showthread.php?t=721


However I no longer have this ATA. The one-year discount period with this ISP (which included free rental of the ADSL modem with built-in ATA that rejects "lr=on") has ended, and I have switched to Sofbank's "Yahoo BB" ADSL.

(This is the ISP famous for their large number of VoIP users on their bundled "BBPhone" service (perhaps one of the largest "walled gardens" in the world of VoIP).)

However, I've chosen their budget plan that does not include the "BBPhone" service, and for my VoIP calls I've purchased the Atcom AT-530 IP Phone.
http://www.voip-info.org/wiki/view/AT-530

(which I'm hoping will work with "lr=on")

The AT-530 can use 2 SIP accounts (with the option for different accounts for incoming and outgoing calls), plus an IAX2 account, and has a built-in NAT router (so I'll be putting this on my public IP address).

The "IP Phone" service with the 050 xxxx xxxx number that I had with the previous ISP is gone, however I now have a SIP VoIP service (with 050 xxxx xxxx) number from a separate VSP, which is not linked to any particular ISP.

Looking forward to taking full advantage of Voxalot dial plans and ENUM.

RDP
03-05-2007, 12:27 PM
Could you tell me who is providing you with that SIP number?

I have Flet's ADSL Type 2 service but havent found a place to get a local DID yet.

Thanks,
RDP

v164
03-05-2007, 12:53 PM
Could you tell me who is providing you with that SIP number?


Fusion Communications. It's a trial service at the moment, with no monthly charges. This gives you an 050 xxxx xxxx number for incoming calls and caller ID on outgoing calls.

http://phonep.fusioncom.co.jp/index.html
(in Japanese)

and you need the unofficial instructions here to setup a standard SIP device:
http://wiki.tomocha.net/?memo%2FFUSION%20IP%C5%C5%CF%C3%A5%B5%A1%BC%A5%D3% A5%B9
(in Japanese)

(Also, set your SIP register interval to 3600 seconds, or else the server will refuse saying "interval too short").



I have Flet's ADSL Type 2 service but havent found a place to get a local DID yet.


Type 2 - that's where you have ADSL but no phone service over the copper line.

v164
03-05-2007, 01:06 PM
I have Flet's ADSL Type 2 service but havent found a place to get a local DID yet.


This place seems to be offering a SIP VoIP service with a Tokyo DID ( 03 xxxx xxxx ) for 500yen per month, which seems to be about the market price at the moment.

http://cybergate.planex.co.jp/

RDP
03-06-2007, 09:56 AM
Thanks for all the good info.

v164
03-17-2007, 06:57 AM
...for my VoIP calls I've purchased the Atcom AT-530 IP Phone.
http://www.voip-info.org/wiki/view/AT-530

(which I'm hoping will work with "lr=on")


I've confirmed that the Atcom AT-530 does work with ";lr=on" (as well as the strictly-RFC 3261 ";lr"), so it works fine with Voxalot / SipBroker.

However I've now encountered another SIP-incompatibility problem. My new Japanese VSP sends SIP INVITE packets where the final line of the SDP body ends abruptly without a terminating CRLF ( 0x0d 0x0a ) (I wonder if that's included in the "SIP torture test"). The AT-530 doesn't like that, and rejects the call with 488. I've sent an email to Atcom asking them to make the firmware more liberal. I'm hopeful that they'll do that.

v164
03-19-2007, 01:40 PM
However I've now encountered another SIP-incompatibility problem. 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.

"488 Not Acceptable Here"

In the meantime, a possible workaround would be to use VoXaLot's "Provider Registrations" feature to receive incoming calls from this VSP. Unlike the AT-530's current firmware, Voxalot's server doesn't seem to mind the SDP body with missing CRLF. Voxalot's server then forwards a properly-formatted SDP body to my phone in the SIP INVITE message (with a wider choice of codecs - although hopefully transcoding can be avoided).

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.

affinity
03-19-2007, 02:07 PM
488 meant incorrect CODEC for one of my providers until they adjusted the account on their server to accept the CODEC that I wanted to use.

v164
03-21-2007, 03:07 AM
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
06-19-2007, 11:51 AM
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 (http://www.beyondlogic.org/solutions/sipdebug/sipdebug.htm)