[VoiceOps] Malformed ACKs/sequential request lines

[Alex Balashov]

[For anyone on Sip-Implementors, sorry for crossposting this here. 
However, it occurred to me that viewed in a certain light, this could 
be seen as more of an operational issue than a theoretical one, and I 
wonder if any of you have encountered it too.]

Hi everyone,

I am faced with what strikes me as a genuine mystery.  In the last few 
days, I have encountered several completely unrelated commercial SIP 
UAC implementations that all exhibit the same erroneous behaviour. 
This behaviour, while certainly incorrect as far as I can tell, is 
consistent across three or four completely unrelated stacks, leading 
me to wonder what I am missing.

The scenario is that UAC A places call to UAS B through stateful proxy P:

    A ---> P ---> B

P inserts Record-Route header on the initial INVITE in order to stay
in the loop on sequential requests.  Nothing eccentric in that
inherently.

When final 200 OK response to the initial INVITE transaction is
relayed from P back to A, it contains a normal Contact URI which
should be used as the remote target URI for sequential requests
(absent any requests that would refresh it):

    Contact: <sip:xxx at a.b.c.d:5060>

It also contains a Record-Route header which has been copied into the
reply by B, of course, which looks something like this:

    Record-Route: <sip:ip.of.proxy.p;lr;param1=blah1;param2=blah2>

But bizarrely, the end-to-end ACK sent by A to this 2xx response has a
request line formed not from the Contact in the 2xx reply, but from
the content of the Record-Route header:

    ACK sip:ip.of.proxy.p;lr;param1=blah1;param2=blah2 SIP/2.0

Naturally, the proxy is quite bewildered and does not propogate this.

3261 scripture seems quite clear--at least, to me--on why this would
be wrong.  12.2.1.1 ("Generating the [in-dialog] Request") says:

    If the route set is not empty, and the first URI in the route
    set contains the lr parameter (see Section 19.1.1), the UAC
    MUST place the remote target URI into the Request-URI and
    MUST include a Route header field containing the route set
    values in order, including all parameters.

Other parts of the spec make quite clear that this kind of ACK is an
in-dialog request, and that the Contact in the 2xx response
establishes the "remote target URI" aforementioned.  In other words,
pretty commonsensical stuff.  I think anyone can agree the request
line of the ACK should be:

    ACK sip:xxx at a.b.c.d:5060 SIP/2.0

However, the fact that I have encountered this in completely unrelated 
situations with an improbable frequency leads me to believe that there 
must be some element of this I am failing to grasp.  Is it some sort 
of legacy behaviour and/or RFC 2543 backward compatibility mode that 
is causing this, or perhaps something else?

Thanks,

-- 
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/