Hi Daniel,
Since, you are receiving the unreliable provisional response, the below
excerpts from RFC 3311 are applicable to your senario -
<excerpts start>
4 Determining Support for this Extension
:
......An unreliable provisional response MAY contain an Allow header
field
listing the UPDATE method, and a 2xx response SHOULD contain an Allow
header field listing the UPDATE method.
:
:
If the response contains an Allow header field containing the value
"UPDATE", the UAC knows that the callee supports UPDATE, and the UAC
is allowed to follow the procedures of Section 5.1.
5.2 Receiving an UPDATE
:
:
A UAS that receives an UPDATE before it has generated a final
response to a previous UPDATE on the same dialog MUST return a 500
response to the new UPDATE, and MUST include a Retry-After header
field with a randomly chosen value between 0 and 10 seconds.
<excerpts end>
Though UAS has sent 183 with SDP, but since it was NOT reliable, this
was NOT the final response, even though you might be receiving the Allow
header listing UPDATE, in my views UAS is complying to RFC 3311 (5.2
Receiving an UPDATE).
Regards
Abhishek
Message: 4 Date: Wed, 26 Feb 2014 07:16:23 -0500 From: Brett Tate
<br...@broadsoft.com> Subject: Re: [Sip-implementors] UPDATE w/ Offer ||
RFC 3311 To: Daniel Pagan <dpa...@fidelus.com>,
sip-implementors@lists.cs.columbia.edu Message-ID:
<8df3692520fcc3e7212b67533eafa...@mail.gmail.com> Content-Type:
text/plain; charset=US-ASCII
>> >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.
> >From an offer/answer perspective, the answer must be sent reliably. If
> offer sent within INVITE, an SDP within 18x response is not an "answer"
> SDP unless sent reliably by using 100rel per RFC 3262.
>
> RFC 3261 section 13.2.1:
>
> "If the initial offer is in an INVITE, the answer MUST be in a
> reliable non-failure message from UAS back to UAC which is
> correlated to that INVITE. For this specification, that is
> only the final 2xx response to that INVITE."
>
> RFC 3262 section 5:
>
> "RFC 3261 describes guidelines for the sets of messages in which
> offers and answers [3] can appear. Based on those guidelines, this
> extension provides additional opportunities for offer/answer
> exchanges.
>
> If the INVITE contained an offer, the UAS MAY generate an answer in a
> reliable provisional response (assuming these are supported by the
> UAC)."
>
> -- This email is intended solely for the person or entity to which it
> is addressed and may contain confidential and/or privileged
> information. If you are not the intended recipient and have received
> this email in error, please notify BroadSoft, Inc. immediately by
> replying to this message, and destroy all copies of this message,
> along with any attachment, prior to reading, distributing or copying
> it. ------------------------------
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
