Satya T, I agree with you. This is what I want to know and what I want to push the community to clarify.
Thanks Regards, -Rockson -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of T Satyanarayana-A12694 Sent: Saturday, August 15, 2009 11:35 PM To: Paul Kyzivat (pkyzivat); Dale Worley Cc: [email protected] Subject: Re: [Sip-implementors] Can EP send media only peer supports Additional round trips should be made optional (only for implementations having concurrent codecs limitation). Additionally, why can't the spec be modified (or place in a BCP): 1. to allow only a sub-set (of what is present in the offer) in the answer (or even just one codec) 2. to place a restrion on the offerer to only use one of the codecs listed in the intersection of answer & offer. There are other mechanisms any way that describe capailities (the declaration part). Regards Satya T -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Kyzivat Sent: Saturday, August 15, 2009 5:24 AM To: Dale Worley Cc: [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 _______________________________________________ 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
