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
