Jaqan, Additional codec might be added in sdp answer besides those in sdp offer.
See RFC3264 sec 6.1 The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jagan Mohan Sent: Thursday, September 11, 2008 11:18 PM To: Paul Kyzivat (pkyzivat) Cc: SIP Implementors Subject: Re: [Sip-implementors] Rejection of codec sent in a Re-INVITE On Thu, Sep 11, 2008 at 8:25 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > Jagan Mohan wrote: > >> Hi, >> >> If the codec change requested in a Re-INVITE needs to be rejected >> by UAS, is it mandatory to send a 488 response to the Re-INVITE and >> continue operating with the codec negotiated in the INVITE? >> > > Would be helpful if you showed the specifics of the SDP in the initial > and subsequent o/a. Say, g.711-u law is the only codec negotiated in the initial INVITE transaction and g.729 is the only codec received in the re-INVITE. I have only one media line in all offer/answers. Yes, RFC 3264 clearly tells that atleast one codec received in the offer, should be sent in the answer if the offer needs to be accepted. I just wanted to confirm that sending a 2xx response with g.711-u law codec in the SDP is wrong when only g.729 codec is received in the re-INVITE offer. Thanks for the detailed info. Thanks, Jagan > > If the new offer has multiple codecs, and you object to one of them, > then of course you may answer omitting that one. If there is only one > codec offered in the reinvite, and you don't like it, then you could: > > - reject the reinvite with a 488, continuing with your old codec > - successfully answer, accepting the codec, but in an inoperable way, > such as by specifying a=inactive or c=0.0.0.0 > - answer successfully, but reject the media line, by setting the port > to zero > > Of those, I would think that the 488 would normally be the most useful > alternative. > > From section 14 of RFC 3261, looks like it's not mandatory to send > a 488 >> response and more a implementation specific problem. In that case, is >> it ok to send a 2xx response to the Re-INVITE with the codec >> negotiated in the initial INVITE? >> > > If your answer accepts the stream, then it must mention at least one > of the codecs from the offer. > > You should look at RFC 3264 if you haven't already. > > Thanks, > Paul > > Or is this case addressed in any other standard? >> >> Thanks, >> Jagan >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
