Voxalot / SIP Broker Support Forums - View Single Post

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/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.

05-28-2006, 05:29 AM	#12
v164 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.