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
