|
SIP Broker Support Support for the SIP Broker service. |
Thread Tools | Display Modes |
04-28-2007, 11:18 AM | #1 | ||
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
Record-Route: header - is it really necessary?
The optional "Record-Route" header, as explained in RFC 3261, is inserted by SIP proxies that wish to remain in the signalling path for the duration of the dialogue:
Quote:
I do not understand why (apart from, perhaps collecting statistics on call minutes) it is useful for sipbroker.com to remain in the signalling path after the call is established. I am not aware of any "mid-call features" that the sipbroker.com proxy is providing. I had originally thought that the "Record-Route:" header was somewhat essential for "NAT traversal", however I now understand that that is taken care of with the "Via: " headers, and use of the "rport" parameter, etc. The problem with sipbroker.com adding the "Record-Route:" header is that it then requires sipbroker.com to add the loose-routing parameter: "lr", which causes incompatibilities: Quote:
Although RFC 3261 explains the "lr" parameter as just ";lr", in order to "make some broken UAs happy", sipbroker.com adds "=on" to the "lr" parameter: Code:
INVITE sip:050xxxxxxxx@xxx.xxx.xxx.xxx:5060 SIP/2.0 Record-Route: <sip:64.34.162.221;lr=on;ftag=as570b93cc> Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bK3ade.c5e555e3.0 Via: SIP/2.0/UDP 64.34.173.199:5061;branch=z9hG4bK00a2f0d9;rport=5061 It would seem to me that, if sipbroker.com simply did away with inserting the "Record-Route:" header, thereby avoiding having to use the "lr" parameter, it would please everybody, improve compatibility (interoperability), and improve conformance to RFC 3261. |
||
06-23-2007, 03:43 AM | #2 |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
SIP-IX does not use "Record-Route:" header
I have tried out Keiichi Honda's "SIP-IX" service, which does a similar numeric-prefix to SIP domain name connection service.
SIP IX - The SIP INVITE message shown in the dial-a-spiral test shows that sipix.jp does not add the "Record-Route:" header. The SIP-IX service therefore avoids potential problems caused by "lr=on" / "lr". "Dial-a-spiral" test: http://forum.voxalot.com/sip-broker-....html#post9690 Code:
INVITE sip:050xxxxxxxx@xxx.xxx.xxx.xxx:5060 SIP/2.0 Record-Route: <sip:64.34.173.199;lr=on;ftag=2568014107> Record-Route: <sip:64.34.162.221;lr=on;ftag=2568014107> Record-Route: <sip:64.34.162.221;lr=on;ftag=2568014107> Via: SIP/2.0/UDP 64.34.173.199;branch=z9hG4bKd728.14ebdfe4.0 Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bKd728.bbb7b4e1.0 Via: SIP/2.0/UDP 58.158.169.93;branch=z9hG4bKd728.db54b947.0 Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bKd728.abb7b4e1.0 Via: SIP/2.0/UDP aaa.bbb.ccc.d:6080;branch=z9hG4bK24374553867812144 ... 64.34.162.221 = sipbroker.com 58.158.169.93 = sipix.jp aaa.bbb.ccc.d = SIP device originating the call) Last edited by v164; 06-23-2007 at 03:45 AM. Reason: url typo |
07-11-2007, 09:53 AM | #3 |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
therefore "Record-Route: " header not necessary
The point being, that this shows that the "Record-Route: " header should not be necessary for sipbroker.com either.
|
07-11-2007, 12:31 PM | #4 |
Join Date: Feb 2006
Posts: 2,930
Thanks: 528 Thanked 646 Times in 340 Posts |
Hi v164,
We will take a look at this request after the 16th. .
__________________
Martin Please post support questions on the forum. Do not send PMs unless requested. |
07-29-2007, 03:28 AM | #5 |
Join Date: Feb 2006
Posts: 2,930
Thanks: 528 Thanked 646 Times in 340 Posts |
Now Removed
The record-route processing has now been removed from SIP Broker. Please confirm that the new SIP Broker call handling is working as requested.
Thanks. .
__________________
Martin Please post support questions on the forum. Do not send PMs unless requested. |
07-29-2007, 03:04 PM | #6 | |
Member
Join Date: Mar 2006
Posts: 96
Thanks: 8 Thanked 26 Times in 19 Posts |
sipbroker.com compatibility boost
Quote:
Here are the SIP INVITE messages that arrived at my SIP phone when calling via SIP Broker using various methods: (My PSTN number +8150xxxxxxxx is mapped to the SIP URI 050xxxxxxxx@221.xx.xx.yyy at e164.org) 1. Ordinary SIP call to 8150xxxxxxxx@sipbroker.com (dialing from my Atcom AT-530 at 221.xx.xx.xx) RECEIVE << 64.34.162.221:5060 ( 64.34.162.221 = sipbroker.com ) Code:
INVITE sip:050xxxxxxxx@221.xx.xx.xx.yyy SIP/2.0 Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bKaf6.6f14e895.0 Via: SIP/2.0/UDP 221.xx.xx.xx.xx:6080;branch=zh4K088716000 From: 6173xxxxxxx <sip:6173xxxxxxx@sip.pennytel.com>;tag=2267814189 To: "8150xxxxxxxx" <sip:8150xxxxxxxx@sipbroker.com:5060> Call-ID: 07108322702@221.xx.xx.xx.xx CSeq: 1 INVITE Contact: <sip:6173xxxxxxx@221.xx.xx.xx.xx:6080> max-forwards: 69 supported: replaces, 100rel user-agent: Voip Phone 1.0 Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE Content-Type: application/sdp Content-Length: 342 v=0 o=sdp_admin 28694149 31133503 IN IP4 221.xx.xx.xx.xx s=A conversation c=IN IP4 221.xx.xx.xx.xx t=0 0 m=audio 10026 RTP/AVP 0 4 4 18 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:4 G723high/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv 2. Calling via the Brisbane (Australia) SIP Broker PSTN gateway ( +61 7 3018 2881 ) RECEIVE << 64.34.162.221:5060 Code:
INVITE sip:050xxxxxxxx@221.xx.xx.xx.yyy SIP/2.0 Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bK0e1e.9be19477.0 Via: SIP/2.0/UDP 204.11.194.10:5070;branch=z9hG4bK10d4f0a6 From: "6173xxxxxxx" <sip:6173xxxxxxx@204.11.194.10:5070>;tag=as3707e432 To: <sip:*0138150xxxxxxxx#@sipbroker.com> Contact: <sip:6173xxxxxxx@204.11.194.10:5070> Call-ID: e1cce9171ea3df@204.11.194.10 CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 69 Date: Sun, 29 Jul 2007 13:42:53 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 393 v=0 o=root 25390 25390 IN IP4 204.11.194.10 s=session c=IN IP4 204.11.194.10 t=0 0 m=audio 18512 RTP/AVP 0 18 8 111 97 3 4 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:111 G726-32/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:3 GSM/8000 a=rtpmap:4 G723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 3. “spiral” test, via Keiichi HONDA's SIP-IX service. Caller -> sipix.jp -> sipbroker.com -> sipix.jp -> sipbroker.com -> destination ( 58.158.169.93 = sipix.jp ) RECEIVE << 64.34.162.221:5060 Code:
INVITE sip:050xxxxxxxx@221.xx.xx.xx.yyy SIP/2.0 Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bKc62d.99f92f84.0 Via: SIP/2.0/UDP 58.158.169.93;branch=z9hG4bKc62d.b740e301.0 Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bKc62d.89f92f84.0 Via: SIP/2.0/UDP 58.158.169.93;branch=z9hG4bKc62d.a740e301.0 Via: SIP/2.0/UDP 221.xx.xx.xx.xx:6080;branch=z9hG4bK463813099308327117 From: 6173xxxxxxx <sip:6173xxxxxxx@sip.pennytel.com>;tag=2254816291 To: "0101*809601018150xxxxxxxx" <sip:0101*809601018150xxxxxxxx@sipix.jp:5060> Call-ID: 421904227@221.xx.xx.xx.xx CSeq: 1 INVITE Contact: <sip:6173xxxxxxx@221.xx.xx.xx.xx:6080> max-forwards: 13 supported: replaces, 100rel user-agent: Voip Phone 1.0 Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE Content-Type: application/sdp Content-Length: 341 v=0 o=sdp_admin 14392964 7747828 IN IP4 221.xx.xx.xx.xx s=A conversation c=IN IP4 221.xx.xx.xx.xx t=0 0 m=audio 10034 RTP/AVP 0 4 4 18 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:4 G723high/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv 4. Using Web Callback (WebCall), as explained here: http://forum.voxalot.com/e164-org-su...html#post10967 RECEIVE << 64.34.162.221:5060 Code:
INVITE sip:050xxxxxxxx@221.xx.xx.yyy SIP/2.0 Via: SIP/2.0/UDP 64.34.162.221;branch=z9hG4bKef2e.ac94e9e1.0 Via: SIP/2.0/UDP 202.60.75.46:5061;branch=z9hG4bK058f6bf3;rport=5061 From: "Voxalot" <sip:82xxxx@202.60.75.46:5061>;tag=as7b280933 To: <sip:*0138150xxxxxxxx@sipbroker.com> Contact: <sip:82xxxx@202.60.75.46:5061> Call-ID: 58b13e4741a6167018277cbe11707d72@202.60.75.46 CSeq: 102 INVITE User-Agent: voxaLot Max-Forwards: 69 Date: Sun, 29 Jul 2007 14:11:17 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY P-src-ip: 221.xx.xx.xx.yyy Content-Type: application/sdp Content-Length: 336 v=0 o=root 19704 19704 IN IP4 202.60.75.46 s=session c=IN IP4 202.60.75.46 t=0 0 m=audio 15482 RTP/AVP 18 97 3 0 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:97 iLBC/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - ( 82xxxx = six-digit VoXaLot number ) The “Record-Route:” header, together with “lr=on” is now gone from the calls routed via SIP Broker. All of the above calls should now work with SIP devices that are fussy about “lr” / “lr=on”, including the NTT-West SVIII ADSL modem, which I was using last year. I think this is an important improvement in interoperability. The SVIII modem is representative of the most widely used unlocked SIP ATA in Japan – those provided for use with the bundled “IP Phone” services provided by Japanese ISPs using NTT-West / NTT-East “Flets” ADSL connection. I intend to write in more detail about this at a later date, because supporting these SIP devices would be, at this point in time, the most effective way to drive adoption of ENUM and VoIP peering among Japanese VoIP users. As a final example, number (5) doesn't use the sipbroker.com SIP proxy – VoXaLot does the ENUM lookup and routes the call (note the different IP address from which the SIP INVITE arrived). 5. Using VoXaLot (ENUM match in dial plan) RECEIVE << 64.34.173.199:5060 ( 64.34.173.199 = us.voxalot.com ) Code:
INVITE sip:050xxxxxxxx@221.xx.xx.xx.yyy SIP/2.0 Record-Route: <sip:64.34.173.199;lr=on;ftag=66638464> Via: SIP/2.0/UDP 64.34.173.199;branch=z9hG4bKd10a.9fba7631.0 Via: SIP/2.0/UDP 221.xx.xx.xx.xx:6080;branch=z9hG4bK2746116113766423988 From: 82xxxx <sip:82xxxx@us.voxalot.com>;tag=66638464 To: "8150xxxxxxxx" <sip:8150xxxxxxxx@us.voxalot.com> Call-ID: 2180323145-342329725256@221.xx.xx.xx.xx CSeq: 2 INVITE Contact: <sip:82xxxx@221.xx.xx.xx.xx:6080> max-forwards: 69 supported: replaces, 100rel user-agent: Voip Phone 1.0 Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE Content-Type: application/sdp Content-Length: 342 P-hint: outbound P-src-ip: 221.xx.xx.xx.xx v=0 o=sdp_admin 31805841 18160206 IN IP4 221.xx.xx.xx.xx s=A conversation c=IN IP4 221.xx.xx.xx.xx t=0 0 m=audio 10036 RTP/AVP 0 4 4 18 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:4 G723high/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv Edited: I don't have the SVIII modem myself anymore, but I know some people who do, so I'll test that when I can. |
|
09-07-2007, 10:37 PM | #7 |
Member
|
Techincal X Functional
Hello folks,
I appreciate the willingness of SipBroker to be faithful to the RFC 3261. But we should be aware that the law exists to serve men, and not the opposite. The technical matters must match, first of all, the functional matters (real needs) of the users. Since this implemtentation (July) I and many users now have problems when receiving incoming calls from PSTN. This issue is described in details on http://forum.voxalot.com/sip-broker-...-not-work.html I would like to to ask to SipBroker team to kindly analyze this issue and, hopefully, returns to the original configuration. Thank you to hear me. Best regards, André Silveira |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Dead route information stored in e164.org | evilbunny | e164.org Support | 13 | 07-25-2007 10:02 AM |
A question about voice stream route using web callback? | hust | Voxalot Support | 1 | 05-02-2007 08:03 AM |
Track record for FWD and VoipStunt | isolve | Voxalot Support | 2 | 10-27-2006 05:50 PM |
Can't get Dialplan to route properly | pmerrill | Voxalot Support | 3 | 06-04-2006 03:36 AM |
Premium call route option now available | evilbunny | e164.org Support | 0 | 03-29-2006 11:46 PM |