Paul, If I catch you clearly, do you mean this is a real bug in RFC3264? Do we have some formal doc/draft to clarify usage here?
Thanks Regards, -Rockson -----Original Message----- From: Paul Kyzivat (pkyzivat) Sent: Saturday, August 15, 2009 7:54 AM To: Dale Worley Cc: Rockson Li (zhengyli); [email protected] Subject: Re: [Sip-implementors] Can EP send media only peer supports comment at end. Dale Worley wrote: > On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote: >> I think answerer can add additional codec G729 here per sec 6.1 of >> rfc3264 >> >> <snip> >> 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 >> </snip> >> >> However, here comes the inconsistency. >> >> When answerer send media, it cannot send G723 packets to offerer per >> sec >> 6.1 of RFC3264 >> >> <snip> >> The answerer MUST send using a media format in the offer >> that is also listed in the answer, </snip> >> >> Whereas RFC3264 does not forbid offerer to send G729 packets to >> answerer per sec 7 >> >> <snip> >> It MUST send using a media format listed in the answer, and it >> ***SHOULD*** use the first media format listed in the answer when it >> does send. >> </snip> > > I think you've found a mistake in the wording of the RFC. The writers > assumed that if the offerer was willing to send G729, then it would > have offered to do so. Clearly, the intention is that both the > offerer and answerer must use only codecs that have been listed in > both the offer and the answer. I think there was some inconsistency in thinking about whether this is a *negotiation* or a *declaration*. Note that the answerer is permitted to begin sending media to the offerer as soon as the offer is received. So at that point this is being considered a declaration, not a negotiation. While the answerer is obligated to list the codecs it is sending to in the answer, the offerer doesn't necessarily have the answer when packets arrive. But requiring the answer to list the packets the answerer will send to does turn it into an after-the-fact negotiation. Allowing the answer to have new codecs, and the offerer to send to them is simply symmetry with the answerer being able to use any of the codecs in the offer. My impression is that when this was first done there was a lot of concern in reducing round trips, so it was only a 2-way handshake rather than 3-way. In retrospect, it seems that few implement the way it was apparently intended. Many apparently can't support multiple concurrent codecs and so need a negotiation to settle on one before media can flow. Others have different kinds of restrictions. So it seems a *negotiation* is really needed, even if it takes more round trips. Thanks, Paul _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
