So it's clear that the UAC is violating the "MUST ignore".
I think this also makes it clear that the UAS is violating RFC.
RFC 6337 section 2.2.
Note that an offer/answer exchange initiated by an INVITE request
must follow exactly one of the Patterns 1, 2, 3, 4. When an initial
INVITE causes multiple dialogs due to forking, an offer/answer
exchange is carried out independently in each distinct dialog. When
an INVITE request contains no offer, only Pattern 2 or Pattern 4
apply. According to Section 13.2.1 of [RFC3261], 'The first reliable
non-failure message' must have an offer if there is no offer in the
INVITE request. This means that the User Agent (UA) that receives
the INVITE request without an offer must include an offer in the
first reliable response with 100rel extension. If no reliable
provisional response has been sent, the User Agent Server (UAS) must
include an offer when sending 2xx response.
In Pattern 3, the first reliable provisional response may or may not
have an answer. When a reliable provisional response contains a
session description, and is the first to do so, then that session
description is the answer to the offer in the INVITE request. The
answer cannot be updated, and a new offer cannot be sent in a
subsequent reliable response for the same INVITE transaction.
In Pattern 5, a Provisional Response ACKnowledgement (PRACK) request
can contain an offer only if the reliable response that it
acknowledges contains an answer to the previous offer/answer exchange.
— snip
-------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N
2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N
5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y
Table 1: Summary of SIP Usage of the Offer/Answer Model
The violation is:
"When a reliable provisional response contains a
session description, and is the first to do so, then that session
description is the answer to the offer in the INVITE request. The
answer cannot be updated, and a new offer cannot be sent in a
subsequent reliable response for the same INVITE transaction."
The only thing left to interpretation IMO is if version increment with
no SDP change is considered an update.
Thoughts on this?
/Roger
On Thu, Sep 17, 2015 at 10:06 PM, Roger Wiklund <roger.wikl...@gmail.com> wrote:
> Thanks, makes sense!
>
> On Thu, Sep 17, 2015 at 10:02 PM, Brett Tate <br...@broadsoft.com> wrote:
>> Hi,
>>
>> The UAC is violating the "MUST ignore". It is an SDP which MUST be ignored.
>> Thus it is irrelevant what the UAS sends unless interacting with devices
>> that ignore the "MUST ignore". However for interoperability reasons, the
>> UAS can change their behavior. If I remember correctly, RFC 6337 might even
>> recommend not including an SDP in that situation.
>>
>>
>>> -----Original Message-----
>>> From: Roger Wiklund [mailto:roger.wikl...@gmail.com]
>>> Sent: Thursday, September 17, 2015 3:29 PM
>>> To: Brett Tate
>>> Cc: sip-implementors@lists.cs.columbia.edu
>>> Subject: Re: [Sip-implementors] SDP version increment without SDP change
>>> in
>>> early dialog
>>>
>>> Hi
>>>
>>> Correct I forgot to mention that the initial INVITE contains SDP and it's
>>> a
>>> single dialog.
>>>
>>> RFC3261 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.
>>> That
>>> same exact answer MAY also be placed in any provisional responses sent
>>> prior
>>> to the answer. The UAC MUST treat the first session description it
>>> receives
>>> as the answer, and MUST ignore any session descriptions in subsequent
>>> responses to the initial INVITE.
>>>
>>> "That same exact answer MAY also be placed in any provisional responses
>>> sent
>>> prior to the answer."
>>>
>>> You MAY place it in subsequent responses but the key is "that same exact
>>> answer" So if you increment the version number it's not the exact same
>>> answer.
>>>
>>> Is that not a violation?
>>>
>>> /Roger
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 17, 2015 at 8:26 PM, Brett Tate <br...@broadsoft.com> wrote:
>>> > Hi,
>>> >
>>> > I assume that the INVITE contained an SDP and your example truly
>>> > reflects a single dialog (i.e. 18x/2xx To tags are the same).
>>> >
>>> > According to RFC 3261 section 13.2.1, the SDP modification must be
>>> > ignored. Thus it shouldn't cause the call to be released. With that
>>> > said, some devices have configuration options to violate that
>>> > statement and treat as an updated answer SDP (or a new offer SDP).
>>> >
>>> > RFC 3261 section 13.2.1: "The UAC MUST treat the first session
>>> > description it receives as the answer, and MUST ignore any session
>>> > descriptions in subsequent responses to the initial INVITE."
>>> >
>>> > More inline.
>>> >
>>> >> -----Original Message-----
>>> >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>>> >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger
>>> >> Wiklund
>>> >> Sent: Thursday, September 17, 2015 1:47 PM
>>> >> To: sip-implementors@lists.cs.columbia.edu
>>> >> Subject: [Sip-implementors] SDP version increment without SDP change
>>> >> in
>>> > early
>>> >> dialog
>>> >>
>>> >> Hi list
>>> >>
>>> >> I'm seeing the following behavior from an Aastra 400 PBX.
>>> >>
>>> >> Flow below is ITSP to PBX
>>> >>
>>> >> INVITE>
>>> >> <100Trying
>>> >> <183 w/SDP
>>> >> PRACK>
>>> >> <200OK (PRACK)
>>> >> <180 w/SDP
>>> >> >PRACK
>>> >> <200OK (PRACK)
>>> >> <200OK (INVITE)w/SDP
>>> >> ACK>
>>> >> BYE>
>>> >> <200OK (BYE)
>>> >>
>>> >> Each time the PBX sends an SDP, the version number is incremented
>>> >> even
>>> > though
>>> >> nothing is changed.
>>> >>
>>> >> ITSP does not like this and sends the BYE.
>>> >>
>>> >> I'm trying to wrap my head around this and to figure out who's at
>>> >> fault
>>> > here.
>>> >>
>>> >> According to RFC6337 section 3.2
>>> >>
>>> >> When both UAs support the 100rel extension, they can update the
>>> >> session
>>> > in
>>> >> the early dialog once the first offer/answer exchange has been
>>> > completed.
>>> >>
>>> >> To me that means that the UAS can send many provisional responses
>>> >> each
>>> > with
>>> >> different SDP, each one updates the early dialog as long as PRACK is
>>> > used.
>>> >
>>> > RFC6337 section 2.2 (and RFC 3261) only allows 1 offer/answer for a
>>> > dialog's INVITE/response/ACK. After the INVITE's offer/answer
>>> > completes; PRACK and UPDATE can be used for new offer/answer exchanges
>>> > before the INVITE transaction completes.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
