Rajnish Jain 写道: > *Can answerer add new codecs which were not present in offer to answer SDP?* > > Yes. > > *OR * > *Should answerer select codecs only in offer and list formats in the same > relative order they were present in the offer?* > > Not necessarily. It will be answerer's discretion to add whatever media > formats it wants and list them in whatever order it wants as long as > there is atleast one common media format between offer and answer. > So which phase will be the final negotiation result? The ACK but not the 200OK? > Here is a quote from section 6.1 of RFC 3264: > > > For streams marked as recvonly in the answer, the "m=" line MUST > contain at least one media format the answerer is willing to receive > with from amongst those listed in the offer. The stream MAY indicate > additional media formats, not listed in the corresponding stream in > the offer, that the answerer is willing to receive. For streams > marked as sendonly in the answer, the "m=" line MUST contain at least > one media format the answerer is willing to send from amongst those > listed in the offer. For streams marked as sendrecv in the answer, > the "m=" line MUST contain at least one codec the answerer is willing > to both send and receive, from amongst those listed in the offer. > 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 (of course, it will not be able to send them at this > time, since it was not listed in the offer). > > > Rajnish > > > > > >> On 3/11/07, Sumin Seo <[EMAIL PROTECTED]> wrote: >> >>> Hi All, >>> >>> I have a question regarding on SDP offer and answer. >>> One of our engineers interprets rfc 3264 like below. >>> "rfc 3264 doesn't say that answer MUST not include more codecs which are >>> not in offer. >>> rfc 3264 also says that the answerer MAY list the formats in their >>> >> desired >> >>> order of preference. >>> It is RECOMMENDS that the answerer list formats in the same relative >>> >> order >> >>> they were present in the offer. >>> So, Session MUST be established as long as there is one common codec in >>> answer regardless of order of preference or existence of codecs not in >>> answer. " >>> >>> Based on his interpretation, following negotiations should work. >>> Offer Answer Offer Answer >>> ----------> ---------------> >>> (a, b, c) (a, b ,c) >>> <---------- <---------------- >>> (d, b, c, e, f) (b, c, d, e, f) >>> I did some interop tests with several carriers. As long as first codec >>> >> in >> >>> answer is one of codecs in offer, calls are successfully connected. >>> >>> *Can answerer add more codecs which were present in offer?* >>> *OR * >>> *Should answerer select codecs only in offer and list formats in the >>> >> same >> >>> relative order they were present in the offer?* >>> >>> >>> Thanks in advance. >>> -Sumin. >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> 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
