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

Daniel Castro danicast at cisco.com
Mon Aug 9 10:23:21 CEST 2010


  Hi Emil,

I wasn't expecting a fix so quick, this is excellent!

I tested it with our MP and it is working fine now.

Thank you very much,
Daniel.

On 06/08/10 22:02, Emil Ivov wrote:
> Hey Daniel,
>
> Could you please try the latest build (2858) and see whether that's
> working better?
>
> As mentioned previously, adding the possibility for a stream to use
> different payload type numbers, for the same payload, when sending and
> receiving, is a too much of a hassle.
>
> Instead, we've implemented the possibility to assign "preferred" dynamic
> payload type numbers to media formats. This way, whenever we try to
> allocate a dynamic payload type to a format, we'll first try that number.
>
> I've seen 101 used for telephone-event in various situations so we've
> decided to hard code it as preferred for the corresponding media format.
> At some point we may also add the possibility to change this from the
> user interface but this didn't seem like something particularly urgent
> at this point.
>
> Please, let us know how this works out for you.
>
> Cheers,
> Emil
>
> На 06.08.10 17:45, Daniel Castro написа:
>>   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
>>>>>>>





More information about the dev mailing list