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