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 ----Basu Chikkalli On Tue, Jan 19, 2016 at 10:26 AM, ankur bansal <abh.an...@gmail.com> wrote: > Hi Ramesh > > Normally it should be full set of codec capabilities in first reliable > response to REINVITE without SDP , > as this offer SDP might be used to send offer to third person UE-C so > sending negotiated codecs of A-B wont help UE-C. > > Having said that it should be full set of codecs ,still its not always same > as if initial INVITE offer sent by same UE. > You can refer RFC 6337 Section 5.2.2 > > Thanks & regards > Ankur Bansal > > On Tue, Jan 19, 2016 at 2:01 AM, Harald Radke <harry...@gmx.de> wrote: > > > Hi, > > > > hm....I would say for a start that RFC3264 applies (8.3.2): > > " The list of media formats used in the session MAY be changed. To do > > this, the offerer creates a new media description, with the list of > > media formats in the "m=" line different from the corresponding media > > stream in the previous SDP. This list MAY include new formats, and > > MAY remove formats present from the previous SDP." > > > > Since an INVITE with no SDP merely "moves" the offer role to the other > > side, I'd say above still holds, so you are pretty much free to put in > > any codec you want, as long as: > > > > (again RTC3264 8.3.2): > > > > " However, in the > > case of RTP, the mapping from a particular dynamic payload type > > number to a particular codec within that media stream MUST NOT change > > for the duration of a session" > > > > so you can leave out 101 our put in like 97 referring to the same codec > > as 101 did previously but you cannot reassign 101 to another one > > > > My two cents, > > > > Harry > > > > > > Am 18.01.2016 um 21:06 schrieb Ramesh Babu Kuppili: > > > Hello SIP experts, > > > > > > I have a question about codec negotiation when a UA receives re-INVITE > > > with no SDP. > > > > > > Lets say, the codec negotiation between UA and Proxy ended up with G711 > > > and RFC 2833 (m=audio 60146 RTP/AVP 0 101). However after the call > gets > > > established, if the proxy sends re-INVITE with no SDP, what should be > > > the codec list in the "200 OK" response for the reINVITE. My proxy > > > vendor claims that the "200 OK" should contain the list of the codecs > > > supported by the UA. Not the codec list already negotiated in the > > > dialogue. Can someone point me in the right direction for this > scenario > > > as to what the RFC says and if possible a section number in the RFC. > > > > > > UA Proxy > > > -----------------------------------------> > > > (INVITE SDP: codecs 0 18 101) > > > > > > <------------------------------------------ > > > (200 OK SDP: codecs 0 101) > > > > > > --------------------------------------------> > > > ACK (no SDP) > > > > > > > > > <------------------------------------------- > > > (re-INVITE no SDP) > > > > > > ----------------------------------------------> > > > (200 OK SDP: codecs ?????) > > > > > > - ramesh > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@lists.cs.columbia.edu > > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
