Voxalot / SIP Broker Support Forums

Voxalot / SIP Broker Support Forums (https://forum.sipbroker.com/index.php)
-   SIP Broker Support (https://forum.sipbroker.com/forumdisplay.php?f=9)
-   -   Record-Route: header - is it really necessary? (https://forum.sipbroker.com/showthread.php?t=1476)

v164 04-28-2007 11:18 AM
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:
In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session...
...
... This capability is frequently used for proxies that are providing mid-call features.

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:
So "lr" will break some UAs, and "lr=on" will break others .... - a situation where it's impossible to please everybody.
http://forum.voxalot.com/voxalot-sup...dial-ip-2.html

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
"lr=on" is somewhat questionable from a specification conformance perspective (although I think it's the default setting in OpenSER).


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.

v164 06-23-2007 03:43 AM
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.173.199 = us.voxalot.com

64.34.162.221 = sipbroker.com

58.158.169.93 = sipix.jp

aaa.bbb.ccc.d = SIP device originating the call)

v164 07-11-2007 09:53 AM
therefore "Record-Route: " header not necessary
 
Quote:
Originally Posted by v164 (Post 9691)
I have tried out Keiichi Honda's "SIP-IX" service, which does a similar numeric-prefix to SIP domain name connection service.

...

The SIP INVITE message shown in the dial-a-spiral test shows that sipix.jp does not add the "Record-Route:" header.
The point being, that this shows that the "Record-Route: " header should not be necessary for sipbroker.com either.

martin 07-11-2007 12:31 PM
Hi v164,

We will take a look at this request after the 16th.
.

martin 07-29-2007 03:28 AM
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.
.

v164 07-29-2007 03:04 PM
sipbroker.com compatibility boost
 
Quote:
Originally Posted by martin (Post 10989)
The record-route processing has now been removed from SIP Broker. Please confirm that the new SIP Broker call handling is working as requested.
Thank you for that, Martin. I'm humbled that my suggestion has been implemented.


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 - - - -
(note the large number of codecs supported by this PSTN gateway)


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 - - - -
( 202.60.75.46 = au.voxalot.com )
( 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
This call would be ignored by the ATA built into the NTT-West SVIII ADSL modem (with the current firmware), because of the “=on” part of the “lr” parameter in the “Record-Route:” header.


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.

910198 09-07-2007 10:37 PM
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


All times are GMT. The time now is 08:34 AM.

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