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
