[Robert - question here for you]
On 2/10/16 11:20 AM, Alex Balashov wrote:
Thanks, Paul. FWIW, B is strictly a UA, not a part-time proxy.
The implementors of A have traced the problem to P's attachment of a value to
the ;lr parameter in the RR:
Record-Route: <sip:xxx.xxx.xxx.xxx:5060;lr=on>
They say that's the cause of the breakage.
This view is certainly supported by RFC 3261; its grammar clearly states that
this is a value-less parameter.
However--and I'm sure this has been beaten to death over the years--there are
some broken UAs out there that actually _do_ expect an lr= value, to such an
extent that Kamailio/OpenSIPS (P is Kamailio in this case) provide a
configuration directive to enable the assignment of an lr parameter value in
inserted RR headers:
http://kamailio.org/docs/modules/4.3.x/modules/rr.html#idm20528
Our implementation of P had this enabled.
Seems one can't win. There's got to be a reason this option came about.
However, it's been around for a long time, and may date back to the mid 2000s...
Longer. The lr parameter exists in order to support backward
compatibility with RFC2543 (the predecessor of 3261).
AFAIK there was never a draft of 3261 where lr had a parameter. Any such
usage must have come from a defective implementation.
Any empirical knowledge of whether there remain UAs out there nowadays that
don't properly support bareword 'lr'?
I don't. But I don't have knowledge about many implementations.
A person who might know (from SipIt) is Robert Sparks. I'm copying him
on this.
Thanks,
Paul
--- Begin Message ---
On 2/9/16 8:58 PM, Alex Balashov wrote:
Hi,
1. I set up a call between two UAs through a proxy:
UAC A ----> Proxy P1 -----> UAS B
2. P1 inserts a Record-Route header indicating that sequential requests
should be directed through it.
3. UAS B does not follow Record-Route properly and, upon hanging up,
sends a BYE directly to UAC A's Contact URI (remote target), not to P1.
Interestingly enough, this BYE includes the Route set constructed from
the intervening Record-Route headers, but the BYE is sent to UAC A's
Contact directly on the network and transport layer.
4. Clearly, UAS B behaving improperly, but in all known cases, over a
variety of UA implementations, UAC A accepts this BYE and the endpoints
end the dialog properly -- all unbeknownst to P1.
My reading of RFC 3261 doesn't give me clarity as to whether it is
proper for a UA to accept a sequential request that otherwise matches a
known dialog but which does not originate from an intermediate proxy
known by the UA to be in the route set for the dialog.
Assuming no properties of firewall or network preclude doing an end-run
around the proxy, is this legal?
Yes, this is legal.
If you examine section 8 of 3261 you will find that UAS processing of
incoming requests doesn't involve examining Route headers. They will
simply be ignored.
BUT, if B has multiple roles, and might sometimes be a proxy and other
times be a UA, then it gets fuzzier. As a proxy it would examine the
Route headers, and probably forward the request to P1. But as a UAS it
would accept the request. There is no guidance on which processing takes
precedence.
The bigger question is *why* this happened. Is it possible that there is
some screw up in handling strict routing vs. loose routing?
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--- End Message ---
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
