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
