04-09-2006, 09:13 AM | #11 |
Senior Member
Join Date: Feb 2006
Posts: 176
Thanks: 0 Thanked 14 Times in 10 Posts |
I setup an asterisk c&p setup site a long time ago... http://www.asterisk.net.au
|
05-28-2006, 05:29 AM | #12 |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
Record-Route "lr" parameter
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/piperm...er/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. |
03-05-2007, 10:09 AM | #13 |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
update
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. |
03-05-2007, 12:27 PM | #14 |
Member
Join Date: Oct 2006
Posts: 30
Thanks: 0 Thanked 1 Times in 1 Posts |
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 |
03-05-2007, 12:53 PM | #15 |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
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%2FFUSI...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"). Type 2 - that's where you have ADSL but no phone service over the copper line. |
03-05-2007, 01:06 PM | #16 | |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
Quote:
http://cybergate.planex.co.jp/ |
|
03-06-2007, 09:56 AM | #17 |
Member
Join Date: Oct 2006
Posts: 30
Thanks: 0 Thanked 1 Times in 1 Posts |
Thanks for all the good info.
|
03-17-2007, 06:57 AM | #18 | |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
Quote:
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. |
|
03-19-2007, 01:40 PM | #19 | |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
SIP responses missing in action
Quote:
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. |
|
03-19-2007, 02:07 PM | #20 |
Join Date: Apr 2006
Posts: 799
Thanks: 66 Thanked 61 Times in 44 Posts |
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.
|
|
|
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 |