Folks:
I'm reviewing an issue involving a SIP integration and would like your feedback
on the behavior of the UAS in comparison with RFC 3311. To begin, the call flow
is as follows:
UAC ==== UAS
>>> INVITE w/SDP offer
100 Trying <<<
183 w/ SDP answer <<<
>>> UPDATE w/SDP offer
500 Internal Svr Error <<<
The behavior we're suspicious about is the 500 response to the UAC's UPDATE
request. It's been confirmed that the 500 response was sent because the UAS is
waiting for the UAC to PRACK the 183 w/ SDP answer (this 183 does not contain
Require: 100rel). However, reading the sections "5.1 Sending an UPDATE" and
"5.2 Receiving an UPDATE" in RFC 3311 lead me to believe the 500 response
should not be sent in this call flow, and instead the UAS should accept the
UPDATE offer. I'm looking for some help in clarifying whether or not this is
correct and, if the UAS should accept the UPDATE in this call flow, to provide
vendor developers with some supporting evidence in hopes of getting it
corrected.
The RFC sections I'm referring to:
5.1 Sending an UPDATE
... for the caller:
o If the UPDATE is being sent before completion of the initial INVITE
transaction, and the initial INVITE contained an offer [true], the UPDATE can
contain an offer if the callee generated an answer in a reliable provisional
response [UAS sent 183 w/ SDPanswer?], and the caller has received answers to
any other offers it sent in either PRACK or UPDATE [caller did not send other
offers - does not apply], and has generated answers for any offers it received
in an UPDATE from the callee [no offers were sent from callee].
** The first two conditions appear to be true, and the caller has not sent any
other offers nor received other offers to which it did not answer. Because the
first two conditions apply and the last two aren't applicable, it seems to me
the UPDATE should be accepted by the UAS.
5.2 Receiving an UPDATE
If an UPDATE is received that contains an offer, and the UAS has generated an
offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an
answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an
UPDATE is received that contains an offer, and the UAS has received an offer
(in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer,
the UAS MUST reject the UPDATE with a 500 response, and MUST include a
Retry-After header field with a randomly chosen value between 0 and 10 seconds.
** The resulting 500 response from the UAS does in fact contain a Retry-After
header. However, the condition for sending this 500 response that does not
match our call flow states, "the UAS has received an offer to which it has not
yet generated an answer". In our call-flow, the UAS has indeed answered the
previous offer via 183 w/ SDP, which leads me to believe the 500 response is
not appropriate for this call-flow.
One thing about this call-flow that might go against this theory is the
"reliable provisional" mentioned in the 1st section. Please correct me if I'm
wrong, but the "reliable provisional response" referenced by the first RFC
section above simply refers to our 183 w/SDP provisional message, correct? In
other words, when this RFC specifically mentions "if the callee generated a
reliable provisional response", does it automatically assume 180/183 followed
by PRACK or does it simply refer to a 180/183?
Any assistance and clarification on this would be greatly appreciated. Thanks
ahead of time for reading through this and enjoy your day!
- Daniel
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
