Hi Daniel,
In my previous message, I put the wrong reference. Please find the correct
references from RFC 3311 which are actually related to your senario:
5.2 <https://tools.ietf.org/html/rfc3311#section-5.2> Receiving an
UPDATE
...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.
>>>here though you have received 183 with SDP, but it will NOT be considered as
>>>answer as 183 was NOT reliable. So, the UAS is compliant to above RFC 3311.
5.1 <https://tools.ietf.org/html/rfc3311#section-5.1> Sending an UPDATE
:
The rules for inclusion of offers and answers in SIP messages as
defined inSection 13.2.1 of RFC 3261
<https://tools.ietf.org/html/rfc3261#section-13.2.1> still apply. These rules
exist
to guarantee a consistent view of the session state. This means
that, for the caller:
o If the UPDATE is being sent before completion of the initial
INVITE transaction, and the initial INVITE contained an offer,
the UPDATE can contain an offer if the callee generated an
answer in a reliable provisional response, ...
>>>here it is very clear that UPDATE must only be sent after the reception of
>>>reliable provisional response/reliable response containing the answer.
So, in your case you should NOT send the UPDATE, until the previous answer has
been received in the reliable message.
Regards
Abhishek
------------------------------
Message: 4
Date: Thu, 27 Feb 2014 13:10:04 +0530
From: Abhishek Jain<[email protected]>
Subject: Re: [Sip-implementors] UPDATE w/ Offer || RFC 3311
To: Daniel Pagan<[email protected]>
Cc:[email protected]
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
<[email protected]> Subject: Re: [Sip-implementors] UPDATE w/ Offer ||
RFC 3311 To: Daniel Pagan<[email protected]>,
[email protected] Message-ID:
<[email protected]> 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
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
