[sip-comm-dev] Fwd: Re: [sip-comm] DTMP tones supported?

Daniel Castro danicast at cisco.com
Fri Aug 6 17:45:50 CEST 2010


  Hi Emil,

Thanks for the follow up. Raised bug 848 
<https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=848>.
Didn't add much detail to the bug as it's all on this thread, let me 
know if you need me to add anything else to the report.

Thanks,
Daniel.

On 06/08/10 15:46, Emil Ivov wrote:
> Hey Daniel,
>
> На 06.08.10 16:25, Daniel Castro написа:
>>   Hi Emil,
>>
>> I talked to the developers and this is what they replied:
>>
>> RFC3264 permits the use of asymmetric payload type. The paragraph they
>> are quoting applies to the offerer MUST not change the offer once
>> extended. But the answer may have different value. No one can restrict
>> the answer value.
>>
>> Quoting RFC3264 :
>> “For sendrecv RTP streams, the payload type numbers indicate the value
>> of the payload type field the offerer expects to receive, and would
>> prefer to send. However, for sendonly and sendrecv streams, the answer
>> might indicate different payload type numbers for the same codecs, in
>> which case, the offerer MUST send with the payload type numbers from the
>> answer.”
> Ah darn, so much for our beautiful PT negotiation code :). Anyways, this
> is indeed a valid point so we'll need to address it. Could you please
> file an issue in our tracker?
>
>> Is it possible for me to change the payload value to 101 somehow as a
>> workaround?
>>
>> Any plans to let users control this? For example, Twinkle provides the
>> following in the GUI:
> We'll think about it. Ideally I'd prefer us to simply respect the RFC.
> However, enabling our streams to send media with one payload type number
> and receive it with a different one might turn out to be quite a hassle,
> so we might indeed go for that kind of a work around.
>
> Thanks for the suggestion!
>
> Emil
>
>>
>> I don't think I can persuade for a fix/change in MP... can't provide a
>> business case at this stage that will justify the work.
>>
>> Regards,
>> Daniel.
>>
>> On 05/08/10 10:23, Emil Ivov wrote:
>>> Hey all,
>>>
>>> I guess this is indeed the most plausible explanation.
>>>
>>> According to RFC 3264:
>>>
>>>     in the case of RTP, the mapping from a particular dynamic payload type
>>>     number to a particular codec within that media stream MUST NOT change
>>>     for the duration of a session.  For example, if A generates an offer
>>>     with G.711 assigned to dynamic payload type number 46, payload type
>>>     number 46 MUST refer to G.711 from that point forward in any offers
>>>     or answers for that media stream within the session.  However, it is
>>>     acceptable for multiple payload type numbers to be mapped to the same
>>>     codec, so that an updated offer could also use payload type number 72
>>>     for G.711.
>>>
>>> So basically, it is wrong for MeetingPlace to be trying to change our
>>> RTP payload mapping from 100 to 101. Besides, in the exchange that we
>>> are seeing here MeetingPlace is actually trying to redefine the payload
>>> type number for both telephone-event, that we declare as 100, and H.264,
>>> that we declare as 101 (naughty, naughty! :) ).
>>>
>>> Daniel, do you thing this is something that could be repaired in
>>> MeetingPlace?
>>>
>>> Emil
>>>
>>>
>>>
>>> На 05.08.10 10:11, Damian Minkov написа:
>>>> Hi,
>>>>
>>>> I was looking at the dumps. The good dump is using g722 and as I not
>>>> see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
>>>> are send like tones in the audio(inband).
>>>> About the bad dump, I see there the dtmfs and wireshark successfully
>>>> recognize them as rfc2833. But what I notice: we are invited and we
>>>> respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
>>>> "Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
>>>> ACK of our OK we receive "Media Attribute (a):
>>>> rtpmap:101 telephone-event/8000" and at the end we send the dtmf
>>>> events with payload 100 (as in our offer). So here I'm not sure which
>>>> is the correct behaviour, do we have to send the dtmfs with payload
>>>> 101, or the other party must accept our offer and receive them as 100
>>>> not as 101.
>>>>
>>>> Regards
>>>> damencho
>>>>
>>>> On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro<danicast at cisco.com>  wrote:
>>>>>   Hi Emil,
>>>>>
>>>>> Here are the two wireshark dumps. Please let me know if there's anything
>>>>> else I can do.
>>>>>
>>>>> Regards,
>>>>> Daniel.
>>>>>
>>>>> On 03/08/10 19:28, Emil Ivov wrote:
>>>>>> На 03.08.10 17:24, Daniel Castro написа:
>>>>>>>    Hi Emil,
>>>>>>>
>>>>>>> No trouble at all. I'll try to get this done before the end of the week.
>>>>>> Great!
>>>>>>
>>>>>>> What's the process? Do you have a bug tracking system? Should I open a
>>>>>>> bug and attach those logs to it? Please advise.
>>>>>> We generally open bugs once they are confirmed as such and I am thinking
>>>>>> that in this case the issue might be with MeetingPlace. Therefore, could
>>>>>> you please send the traces here?
>>>>>>
>>>>>> Cheers,
>>>>>> Emil
>>>>>>> Thanks,
>>>>>>> Daniel.
>>>>>>>
>>>>>>> On 03/08/10 13:06, Emil Ivov wrote:
>>>>>>>> Hey Daniel
>>>>>>>>
>>>>>>>> На 03.08.10 12:17, Daniel Castro написа:
>>>>>>>>> I checked our documentation and the following tone formats should be
>>>>>>>>> detected:
>>>>>>>>> - In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
>>>>>>>>> - RFC 2833
>>>>>>>> That's the kind you'd be getting from SIP Communicator.
>>>>>>>>
>>>>>>>>> Our VoiceMail server is picking up the tones sent but the MeetingPlace
>>>>>>>>> isn't for some reason. Does this ring any bells?
>>>>>>>> Sounds strange. Would it be too much trouble to ask you for a Wireshark
>>>>>>>> dump that contains DTMF tones sent from an application that works with
>>>>>>>> your MeetingPlace, as well as another one that shows those coming out of
>>>>>>>> SC when you are testing it?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Emil
>>>>>>>>
>>>>>>>>> Any help or pointers appreciated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Daniel Castro
>>>>>>>>>
>>>>>>>>> Software QA Engineer
>>>>>>>>> Unified Communications Business Unit
>>>>>>>>> danicast at cisco.com
>>>>>>>>> Phone: +353 91 38 4778
>>>>>>>>> Mobile: +353 83 318 2058
>>>>>>>>>
>>>>>>>>> Cisco Systems Internetworking (Ireland) Limited
>>>>>>>>> Oranmore Business Park
>>>>>>>>> Oranmore, Galway
>>>>>>>>> Ireland
>>>>>>>>> Cisco.com - http://www.cisco.com/global/UK/
>>>>>>>>>
>>>>>>>>> Cisco Systems Internetworking (Ireland) Limited a private limited
>>>>>>>>> company registered in Ireland under company number 314989 with its
>>>>>>>>> registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland
>>>>>>>>>
>>>>>>>>> For corporate legal information go to:
>>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------- Original Message --------
>>>>>>>>> Subject:        Re: [sip-comm] DTMP tones supported?
>>>>>>>>> Date:   Thu, 29 Jul 2010 21:29:50 +0300
>>>>>>>>> From:   Damian Minkov<damencho at sip-communicator.org>
>>>>>>>>> Reply-To:       users at sip-communicator.dev.java.net
>>>>>>>>> To:     users at sip-communicator.dev.java.net
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Daniel,
>>>>>>>>>
>>>>>>>>> On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast at cisco.com>
>>>>>>>>> wrote:
>>>>>>>>>>    Hi,
>>>>>>>>>>
>>>>>>>>>> I'm now to sip-communicator and new to this list. Excellent
>>>>>>>>>> application btw!
>>>>>>>>> Thanks for the kind words.
>>>>>>>>>> I was just testing it and tried to join a meeting that requires me to
>>>>>>>>>> send
>>>>>>>>>> DTMF codes, but apparently sip-communicator it's not sending them.
>>>>>>>>>> Does anyone know if this is supported or if this is a known issue?
>>>>>>>>> Currently we support two type of DTMFs:- rfc4733(which is compatible
>>>>>>>>> with rfc2833) and sending using SIP (SIP INFO messages). The first one
>>>>>>>>> should be default, maybe if it doesn't work for you, you can try
>>>>>>>>> disabling it by unchecking the option in Configuration form under
>>>>>>>>> Audio, search for "telephone-event/8000". When you uncheck it you will
>>>>>>>>> use the one with sip info messages.
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> damencho
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Daniel Castro
>>>>>>>>>>
>>>>>>>>>> Software QA Engineer
>>>>>>>>>> Unified Communications Business Unit
>>>>>>>>>> danicast at cisco.com
>>>>>>>>>> Phone: +353 91 38 4778
>>>>>>>>>> Mobile: +353 83 318 2058
>>>>>>>>>>
>>>>>>>>>> Cisco Systems Internetworking (Ireland) Limited
>>>>>>>>>> Oranmore Business Park
>>>>>>>>>> Oranmore, Galway
>>>>>>>>>> Ireland
>>>>>>>>>> Cisco.com - http://www.cisco.com/global/UK/
>>>>>>>>>>
>>>>>>>>>> Cisco Systems Internetworking (Ireland) Limited a private limited
>>>>>>>>>> company
>>>>>>>>>> registered in Ireland under company number 314989 with its registered
>>>>>>>>>> office
>>>>>>>>>> at Block 6, Eastpoint Business Park, Dublin 3, Ireland
>>>>>>>>>>
>>>>>>>>>> For corporate legal information go to:
>>>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> users-unsubscribe at sip-communicator.dev.java.net
>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> users-help at sip-communicator.dev.java.net
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe at sip-communicator.dev.java.net
>>>>>>>>> For additional commands, e-mail:
>>>>>>>>> users-help at sip-communicator.dev.java.net
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20100806/2c770a22/attachment.html>


More information about the dev mailing list