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

Daniel Castro danicast at cisco.com
Fri Aug 6 16:25:44 CEST 2010


  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.”

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:


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/354fa2e8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot1.png
Type: image/png
Size: 102156 bytes
Desc: not available
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20100806/354fa2e8/attachment.png>


More information about the dev mailing list