On 12/21/11 3:09 AM, Saul Ibarra Corretge wrote:
> Hi,
>
> On Dec 21, 2011, at 8:00 AM, William Scott wrote:
>
>> On 21 December 2011 17:10, Alex Balashov<abalas...@evaristesys.com> wrote:
>>> Is your concern about the two RR headers, or the double lr parameter?
>>
>> The double lr parameter.
>>
>> When my ATA sends the double lr to a VSP using Asterisk the call continues.
>>
>> When it sends it to a VSP using "Sippy" (as seen in User-Agent: and
>> Server:) I fail to receive a ACK for my 200 OK. Multiple 200 OK are
>> sent then finally a BYE message.
>>
>
> As a general rule, the server should be gentle in what it accepts ;-)
+1
The repeated 'lr' is erroneous.
There are no particular rules for what to do when receiving something
erroneous, especially if its in a response. I don't fully follow exactly
what happened in the case that failed. But its not ok to deny the ACK
because of trouble with the 200.
Presumably the bad R-R is being added to the request by some middle box,
then returned in the response. Anything that detects the R-R as being
malformed in the request has some alternatives:
- preserve it as-is
- canonicalize it: remove one of the 'lr's
- return an error code - probably 400
Middleboxes that detect the R-R as being malformed in the response have
fewer options:
- preserve it as-is
- canonizalize it: remove one of the 'lr's
If the malformed R-R makes it back in a 2xx response to the UAC, then
the UAC can:
- preserve it as-is in the route set
- canonicalize it in the route set
- ACK the response and then kill the call with BYE.
However, the BYE must follow the route set, so it can't avoid making
one of the above choices first.
If the UAC preserves the double 'lr' in the route set, then in-dialog
requests will have double lr in the Route header. That will set off a
similar set of issues in handling of Route.
The thing that is most likely to work well is to canonicalize by
removing the extra 'lr'. Some implementations may find that this falls
out automatically. For others it may be unnatural / difficult.
Ultimately the right thing is to get the ATA fixed.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
