Hi,
We've encountered an issue where we think we're setting the Request URI for
the ACK during an re-INVITE but this causes a problem for the remote end.
I'd be happy to hear if our interpretation is correct or if we are missing
something somewhere.
Here's the message flow, showing an incoming INVITE which succeeds followed
by a re-INVITE sent by us which doesn't.
Local Remote
==================
INVITE sip:[email protected]
Via: SIP/2.0/UDP 192.168.254.43:5060
;branch=z9hG4bKa0f46fe9041c02f28
Via: SIP/2.0/UDP 192.168.254.43:5060
;branch=z9hG4bKa0f46fe9041c02f28;received=192.168.1.203
Record-Route: <sip:192.168.1.203>
Contact: 54321 <sip:[email protected];user=phone>
100 Trying
180 Ringing
200 Ok
ACK sip:[email protected]
Via: SIP/2.0/UDP 192.168.1.203:5060
;branch=z9hG4bK3ceca34da83ae1e
Via: SIP/2.0/UDP 192.168.1.203:5060
;branch=z9hG4bK3ceca34da83ae1e;received=192.168.1.203
Record-Route: <sip:192.168.1.203>
[re-INVITE]
INVITE sip:192.168.1.203
Route: 54321 <sip:[email protected];user=phone>
100 Trying
200 Ok
Record-Route: <sip:192.168.1.203>
Contact: 54321 <sip:[email protected]>
ACK sip:192.168.1.203
Route: 54321 <sip:[email protected]>
...something goes wrong
... re-transmission of 200 OK
... re-transmission of ACK
For the INVITE and ACK we follow RFC 3261
http://tools.ietf.org/html/rfc3261#section-12.2.1.1
which seems straightforward enough
<http://tools.ietf.org/html/rfc3261#section-12.2.1.1>"If the route set is
not empty, and its first URI does not contain the
lr parameter, the UAC MUST place the first URI from the route set
into the Request-URI, stripping any parameters that are not allowed
in a Request-URI. The UAC MUST add a Route header field containing
the remainder of the route set values in order, including all
parameters. The UAC MUST then place the remote target URI into the
Route header field as the last value."
Our customer is adamant that because we do this and not use the URI from
the Contact header the ACK is ignored.
We say we can't use the Contact URI because of the lack of the "lr"
parameter.
We're fairly sure we are doing things correctly. Is there something we've
missed?
Thanks in advance
Neil
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
