Paul, I haven't seen SIPit collecting stats at this level (it is usually at feature level). But, it will be a good exercise to collect this at next SIPit or even solicit implementor opinion on this mailing list.
Regards Satya T -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Kyzivat Sent: Monday, August 17, 2009 9:23 PM To: Rockson Li (zhengyli) Cc: [email protected] Subject: Re: [Sip-implementors] Can EP send media only peer supports Rockson Li (zhengyli) wrote: > Paul, > > If I catch you clearly, do you mean this is a real bug in RFC3264? IMO this is unclear. It might be that what is written is not exactly what the original authors intended. Or maybe it is as intended but isn't what people now wish had been written. Either way it isn't necessarily a bug if what is written can be implemented, which seems to be the case. > Do we have some formal doc/draft to clarify usage here? I don't think so. At this point any change in the specs is likely to disrupt somebody's implementation, so things must be done carefully. If it is considered that there is ambiguity about how this should be implemented, then a clarification would be a good thing. But it will then take some work to decide which of the possible interpretations should be blessed. I'd be interested to hear what is implemented in practice - perhaps stats from SipIt. Thanks, Paul > 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
