Hi, Your conclusion appears to be a misinterpretation of SHOULD. I mention it because not following the SHOULD can have 3PCC related interoperability limitations.
RFC 2119: "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Basu Chikkalli > Sent: Tuesday, January 19, 2016 12:40 AM > To: ankur bansal > Cc: sip-implementors > Subject: Re: [Sip-implementors] Codec negotiation when incoming re-INVITE > has > no SDP > > We have following two RFC references: > > > > Rfc3261 > > Sect 14.2 UAS Behaviour > > > A UAS providing an offer in a 2xx (because the INVITE did not contain an > offer) SHOULD construct the offer as if the UAS were making a > > brand new call, subject to the constraints of sending an offer that > updates an existing session, as described in [rfc 3264] in the case of > SDP. > > > > ========The significance is use of word “SHOULD” instead of > “MUST”================= > > > > > > Rfc 3264 sect 8 modifying session > > The offer MAY be identical to the last SDP provided to the other party > (which > may have been provided in an offer or an answer), or it > > MAY be different > > > My conclusion is "200-OK will have the codec list already negotiated in > the > dialogue" not the list of codec supported by UA _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
