Hi T Satyanarayana-A12694, I am not sure that I understand this issue correctly.
Assuming the following case, UE-A does not have enough CPU power to encode and decode G723 at the same time, but it has the only enough one to encode or decode. Then, UE-A offer m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 UE-B can use the both codec and answer m=audio 49170 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 then UE-A send G723 and UE-B send G711. This is the best result for each other. But IMO, what is the problem is that the both UE can NOT negotiate this result explicitly. SDP can NOT describe the different direction of a each codec in one media description. Regards, Shinji "T Satyanarayana-A12694" <[email protected]> > >Even in scenario I, if A sends DTMF as TE (even though he didn't declare >it in offer), B is expected to receive it since he declared it in the >answer. However, B MUST not send DTMF as TE since A didn't declare it in >offer. Do it sends it in-band (i.e. in G711Mu). This results in >asymetric DTMF operation (send in one more and receive in one mode). >Most client implementations (due to underlying DSP arch) will have >difficult with this since they mostly have one setting for DTMF mode. > >Currently, RFC3264 says: > >For streams marked as sendrecv in the answer: >1. 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. >2. 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). > >To help achieve symmetric modes, I still feel restricting the answer to >a sub-set will help. i.e. with a SHOULD clause in addition to the >current MUST and MAY clauses as below. > >3. The stream SHOULD contain a sub-set of media formats listed in the >offer. > >Regards >Satya T > >-----Original Message----- >From: Rockson Li (zhengyli) [mailto:[email protected]] >Sent: Wednesday, August 19, 2009 12:42 PM >To: T Satyanarayana-A12694; Paul Kyzivat (pkyzivat) >Cc: [email protected] >Subject: RE: [Sip-implementors] Can EP send media only peer supports > >What comes to my mind is UA sometimes has preference in conveying DTMF >in signaling path (INFO, NOTIFY) or telephone-event in media path. > >So suppose A and B is in talk, > >If A does not prefer convey DTMF in telephone-event, it send offer as >follows, > > m=audio 49170 RTP/AVP 0 4 > a=rtpmap:0 PCMU/8000 > a=rtpmap:4 G723/8000 > >B gets this offer, it prefer to receive DTMF as telephone-event, so >advertises it in answer. > > m=audio 6678 RTP/AVP 0 4 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:4 G723/8000 > a=rtpmap:110 telephone-events/8000 > >So A knows and rfc3264 allows, dtmf can be sent to as telephone-event to >B. > >However, if the dtmf preference reverses, the issues arises. > >If A does prefer receive DTMF in telephone-event, it send offer as >follows, > > m=audio 49170 RTP/AVP 0 4 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:4 G723/8000 > a=rtpmap:110 telephone-events/8000 > >B gets this offer, it does NOT prefer to receive DTMF as >telephone-event, it answers as > > m=audio 6678 RTP/AVP 0 4 > a=rtpmap:0 PCMU/8000 > a=rtpmap:4 G723/8000 > >However, it cannot send dtmf as telephone-event to A. >Even worse if A does not indicate DTMF support in signaling, A cannot >get any DTMF signal, which is a big service impact in real world. > >Thanks >Regards, >-Rockson >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of T >Satyanarayana-A12694 >Sent: Wednesday, August 19, 2009 1:50 AM >To: Paul Kyzivat (pkyzivat) >Cc: [email protected] >Subject: Re: [Sip-implementors] Can EP send media only peer supports > > >Sorry, I meant "Even if the answerer is prepared to receive".. > >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of T >Satyanarayana-A12694 >Sent: Tuesday, August 18, 2009 11:07 PM >To: Paul Kyzivat >Cc: [email protected] >Subject: Re: [Sip-implementors] Can EP send media only peer supports > > >Yes, I do agree that implementations have done a good job of working >with this ambiguity so far. And, it is not as much an issue. > >However, I am having a difficulty to visualize a use case where the >offerer may use this "addl codec" to send media. Even if the offerer is >prepared to receive, the offerer would probably never use it (if he >could, he would have declared it in offer anyway). > >So, wouldn't it help if we can add a qualifying statement to the spec: >"The answerer may add additional codecs in the answer. However, at the >time of writing this spec, there are no known use cases warranting this >condition." > >Regards >Satya T > >-----Original Message----- >From: Paul Kyzivat [mailto:[email protected]] >Sent: Tuesday, August 18, 2009 7:53 PM >To: T Satyanarayana-A12694 >Cc: Dale Worley; [email protected] >Subject: Re: [Sip-implementors] Can EP send media only peer supports > >The more I think about this "issue" the less I understand why it should >be an issue. > >The answerer is under no obligation to include codecs that were not >present in the offer. And if it does so, there is no guarantee of >circumstances under which they might be used. And the offerer is >certainly free to ignore them. > >So the only question is: > >*If* the answer includes codecs that were not included in the offer, may >the offerer use them to encode media? And that is only an issue if the >answerer is *not* expecting them to be used. > >So, if you are constructing an answer, don't include any codecs that you >aren't prepared to receive now. (If it hurts, don't do it.) > >All we could possibly do by tightening up the wording is ensure that >even if mentioned, such codecs would not be used. What purpose would >that serve? And such restriction would only apply if both parties adhere >to it. > > Thanks, > Paul > >T Satyanarayana-A12694 wrote: >> >> >> -----Original Message----- >> From: Dale Worley [mailto:[email protected]] >> Sent: Tuesday, August 18, 2009 1:37 AM >> To: T Satyanarayana-A12694 >> Cc: Paul Kyzivat; [email protected] >> Subject: RE: [Sip-implementors] Can EP send media only peer supports >> >> On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote: >>> 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) >> >>>> If you mean, "Is it allowed to put in the answer only a subset of >>>> the >> codecs that are in the offer", that is allowed now. >> >> No, I mean "Answerer must include only a sub-set of codecs present in >> the offer". Or "Answerer must not include any codec not present in the > >> offer". >> >>> 2. to place a restrion on the offerer to only use one of the codecs >>> listed in the intersection of answer & offer. >> >> Some implementations use more than one codec, so that would have to be > >> considered a BCP. >> >> Dale >> >> >> > >_______________________________________________ >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 ___________________________________________________________ 奥村 伸二 (株)ソフトフロント 第3事業部 〒060-0009 北9条西15丁目28-196 http://www.softfront.co.jp tel:+81-11-623-1119 mailto:[email protected] fax:+81-11-623-1002 sip:[email protected] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
