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

Emil Ivov emcho at sip-communicator.org
Fri Aug 6 16:46:31 CEST 2010


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

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
emcho at sip-communicator.org                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31


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