Click Here To Visit SIP Broker  

Go Back   Voxalot / SIP Broker Support Forums > SIP Broker Forums > SIP Broker Support

SIP Broker Support Support for the SIP Broker service.

 
 
Reply
Thread Tools Display Modes
Unread 04-28-2007, 11:18 AM   #1
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default 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 is offline   Reply With Quote
Unread 06-23-2007, 03:43 AM   #2
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default 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)

Last edited by v164; 06-23-2007 at 03:45 AM. Reason: url typo
v164 is offline   Reply With Quote
Unread 07-11-2007, 09:53 AM   #3
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default therefore "Record-Route: " header not necessary

Quote:
Originally Posted by v164 View Post
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.
v164 is offline   Reply With Quote
Unread 07-11-2007, 12:31 PM   #4
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

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.
martin is offline   Reply With Quote
Unread 07-29-2007, 03:28 AM   #5
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default 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.
martin is offline   Reply With Quote
Unread 07-29-2007, 03:04 PM   #6
v164
Member
 
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default sipbroker.com compatibility boost

Quote:
Originally Posted by martin View Post
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.
v164 is offline   Reply With Quote
Unread 09-07-2007, 10:37 PM   #7
910198
Member
 
Join Date: May 2007
Posts: 34
Thanks: 2
Thanked 1 Times in 1 Posts
910198 is on a distinguished road
Send a message via Yahoo to 910198 Send a message via Skype™ to 910198
Default 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
910198 is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT. The time now is 07:11 AM.


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