Record-Route: header - is it really necessary?

[v164]

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:

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:

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:

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.