[cisco-voip] DTMF Method 0

Fri May 24 14:15:53 EDT 2013

I hear you there.  We do use IOS software based MTPs.  Thanks for the
feedback.

On Fri, May 24, 2013 at 11:57 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>wrote:

> I have noticed loss of DTMF among other issues when using CM based MTP.  I
> usually use IOS based software MTP.
>
>
> On Fri, May 24, 2013 at 11:12 AM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> Thanks for the clarification.  In fact, I have other PG's set to g711,
>> therefore an MTP is used, and the problem still exists in that scenario.
>>
>>
>> On Fri, May 24, 2013 at 9:15 AM, Nick Matthews <matthnick at gmail.com>wrote:
>>
>>> A transcoder is an MTP with additional features, so that should be fine.
>>>
>>> -nick
>>>
>>>
>>> On Thu, May 23, 2013 at 11:54 PM, Anthony Holloway <
>>> avholloway+cisco-voip at gmail.com> wrote:
>>>
>>>> Just to clarify, what if it were a transcoder and not an MTP?  See, the
>>>> PG is set to g729 (mistake) and the ACME SBC is set to g711 only (call
>>>> recording), therefore a transcoder is what gets used.
>>>>
>>>>
>>>> On Thu, May 23, 2013 at 10:41 PM, Nick Matthews <matthnick at gmail.com>wrote:
>>>>
>>>>> Having some experience troubleshooting Mobile Agent issues I know at
>>>>> least in 8.0 MTP is required for the official UCCE Mobile Agent feature.  A
>>>>> lack of MTP for this type of call flow could cause DTMF problems.
>>>>>
>>>>> -nick
>>>>>
>>>>>
>>>>> On Thu, May 23, 2013 at 11:11 AM, Chris Ward (chrward) <
>>>>> chrward at cisco.com> wrote:
>>>>>
>>>>>>  According to the bug that is the defect, that DTMF input is trying
>>>>>> to be processed while the method is still undecided… The defect does have
>>>>>> some conditions that are different than what is presented here but it is
>>>>>> still pretty close.****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> Having the DTMF preference selected as RFC2833 is supposed to be a
>>>>>> workaround but it either was applied without rebooting the trunk, there is
>>>>>> another caveat, or this is not the bug.****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> The other thing you could try, IF this is the defect it should only
>>>>>> occur if Early Offer is enabled. Disabling Early Offer should work around
>>>>>> it.****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> This defect, as it stands now, is only going to be fixed in 9.1(2)
>>>>>> and 10.0(1) so if you wanted it in an 8.6(2) ES you would need to open a
>>>>>> TAC case and request the fix be ported to the ES.****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> +Chris****
>>>>>>
>>>>>> Unity Connection TME****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> *From:* Ryan Ratliff (rratliff)
>>>>>> *Sent:* Thursday, May 23, 2013 10:53 AM
>>>>>> *To:* Anthony Holloway
>>>>>> *Cc:* Cisco VoIP Group; Chris Ward (chrward)
>>>>>>
>>>>>> *Subject:* Re: [cisco-voip] DTMF Method 0****
>>>>>>
>>>>>>  ** **
>>>>>>
>>>>>> Bugs aside, from what I can tell if you wee this then we haven't
>>>>>> settled on a DTMF capability yet.  That would also explain why you miss the
>>>>>> first digit, if something is getting delayed.****
>>>>>>
>>>>>>
>>>>>>
>>>>>> ****
>>>>>>
>>>>>> |//SIP/SIPCdpc(8,74,1872820)/ci=146637572/ccbId=85511580/scbId=0/star_CcUserInfoReq:
>>>>>> Outbound DTMF method not supported ****
>>>>>>
>>>>>>
>>>>>>
>>>>>> ****
>>>>>>
>>>>>>
>>>>>>
>>>>>> ****
>>>>>>
>>>>>> -Ryan ****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> On May 23, 2013, at 9:58 AM, Chris Ward (chrward) <chrward at cisco.com>
>>>>>> wrote:****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> Should have noted, the defect has to do with negotiating OOB and 2833
>>>>>> in the same call with a SIP trunk that has “no preference” selected as its
>>>>>> DTMF method. You could try and select a preference and see if it resolved
>>>>>> it. But again, we need your version to confirm.****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> +Chris****
>>>>>>
>>>>>> Unity Connection TME****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On
>>>>>> Behalf Of *Chris Ward (chrward)
>>>>>> *Sent:* Thursday, May 23, 2013 9:50 AM
>>>>>> *To:* Anthony Holloway; Cisco VoIP Group
>>>>>> *Subject:* Re: [cisco-voip] DTMF Method 0****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> Anthony,****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> For issues like these, the call flow and devices involved in the call
>>>>>> flow are crucial. On a quick internal search, I found CSCuc80321 with the
>>>>>> same error/warning. We would need your version too.****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> +Chris****
>>>>>>
>>>>>> Unity Connection TME****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at puck.nether.net>
>>>>>> ] *On Behalf Of *Anthony Holloway
>>>>>> *Sent:* Thursday, May 23, 2013 12:26 AM
>>>>>> *To:* Cisco VoIP Group
>>>>>> *Subject:* [cisco-voip] DTMF Method 0****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> All,****
>>>>>>
>>>>>> *The smaller picture*****
>>>>>>
>>>>>>
>>>>>> I have the following two lines from a CCM trace I pulled:****
>>>>>>
>>>>>> 00:06:11.643
>>>>>> |//SIP/SIPCdpc(8,74,1872820)/ci=146637572/ccbId=85511580/scbId=0/star_CcUserInfoReq:
>>>>>> Outbound DTMF method selected is 0. Digit=1 and
>>>>>> isMTPPassingThru2833=0|5,200,21,1.12763334^[REDACTED]^RCP5143F0107
>>>>>> 00:06:11.643
>>>>>> |//SIP/SIPCdpc(8,74,1872820)/ci=146637572/ccbId=85511580/scbId=0/star_CcUserInfoReq:
>>>>>> Outbound DTMF method not supported
>>>>>> (0)|5,200,21,1.12763334^[REDACTED]^RCP5143F0107****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> The log states that this method is not supported, but what is the
>>>>>> method exactly?****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> *The bigger picture*****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> My Mobile Agent Connect Tone feature is half working, and I can see
>>>>>> DTMF digits 1 and 2 being sent in the Agent's direction, however, the Agent
>>>>>> is only hearing the second tone.  I have confirmed this with the above
>>>>>> trace lines showing that the first tone fails due to unsupported reasons,
>>>>>> also the below additional trace lines showing the second tone being sent
>>>>>> via a different method and succeeding, and finally, a wireshark capture
>>>>>> which only shows the digit 2 hitting the wire as RTP-NTE (not shared).
>>>>>> ****
>>>>>>
>>>>>> 00:06:11.905
>>>>>> |//SIP/SIPCdpc(8,74,1872820)/ci=146637572/ccbId=85511580/scbId=0/star_CcUserInfoReq:
>>>>>> Outbound DTMF method selected is 2. Digit=2 and
>>>>>> isMTPPassingThru2833=0|5,200,21,1.12763334^[REDACTED]^RCP5143F0107
>>>>>> 00:06:11.905
>>>>>> |//SIP/SIPCdpc(8,74,1872820)/ci=146637572/ccbId=85511580/scbId=0/sendDtmfVia2833:
>>>>>> sending sipOutgoingDTMFTone Tone 2 for digit
>>>>>> 2.|5,200,21,1.12763334^[REDACTED]^RCP5143F0107****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> If I could figure out the method number to name mapping, that would
>>>>>> help me understand why method 0 is not supported while method 2 is.
>>>>>>
>>>>>> Thanks for your help.****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> Anthony Holloway****
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip****
>>>>>>
>>>>>> ** **
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130524/ea3b1985/attachment.html>