[cisco-voip] Cisco IOS Enhanced Software Media Termination Point, DTMF and SIP
Keith Klevenski
KKlevenski at cstcorp.net
Fri Sep 11 11:08:55 EDT 2009
Nick,
'wait for far-end H245 TCS' is checked and I see CM receiving the TCS from the gateway first in the traces.
I receive the following from Asterisk when it responds to CM's INVITE with its 200 OK ack:
v=0
o=root 9674 9674 IN IP4 10.1.100.254
s=session
c=IN IP4 10.1.100.254
t=0 0
m=audio 17200 RTP/AVP 18 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
But when CM ACKs back I only see this:
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.1.101.11
s=SIP Call
c=IN IP4 10.1.101.2
t=0 0
m=audio 18866 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
I see nothing about 2833 from CM.
It seems like the issue is CM is not negotiating 2833 with Asterisk or the h323 gateway for some reason. I see it advertised in the TCS from the gateway to CM, but nothing back from CM and the same with Asterisk.
Everything looks like it should as far as I can tell, but it just isn't happening. I'm guessing g729 has something to do with it so I've gone back to g711 to Asterisk and a transcoder and everything works. If the transcoder doesn't release a session like it was doing before I'll just troubleshoot that instead. I thought it would be nice and clean to run one codec and avoid transcoders if possible, but I'm at a loss trying to get it to work.
Although I'd love to get it to work with only g729 and get rid of the transocder I just don't know what to do at this point. Since its g729 I guess I need a transcoder anyway to use as an MTP for 2833, but I've tried that and when I do all calls fail. May as well just transcode to g711 anyway.
Regardless, I appreciate you and Ryan's help because I've learned a lot in the process. We you have to really dig into something that you don't deal with regularly it is always an opportunity to learn and I have.
Thank you.
-keith
-----Original Message-----
From: matthn at gmail.com [mailto:matthn at gmail.com] On Behalf Of Nick Matthews
Sent: Thursday, September 10, 2009 7:49 PM
To: Keith Klevenski
Cc: Ryan Ratliff; cisco-voip at puck.nether.net Voice
Subject: Re: [cisco-voip] Cisco IOS Enhanced Software Media Termination Point, DTMF and SIP
If CCM isn't sending the RFC 2833 capabilities in the TCS, then it
won't be negotiated.
You could try checking 'wait for far-end H245 TCS'. CUCM may not
advertise it unless the gateway advertises it first, although this is
the default.
As well, you could turn on the SIP messaging debugs ( or get a
sniffer) and see what the SDP from the SIP endpoint looks like.
You should see something similar to this in the SDP from the endpoint:
INVITE ...
From:...
......
m=audio 16428 0 101
a=fmtp:101 1-16
Something to that effect, advertising NTE on PT 101 for events 1-16,
sometimes 1-15.
-nick
On Thu, Sep 10, 2009 at 4:32 PM, Keith Klevenski<KKlevenski at cstcorp.net> wrote:
> Hence the name... lol.
>
> Thanks!
>
>
> -----Original Message-----
> From: Ryan Ratliff [mailto:rratliff at cisco.com]
> Sent: Thursday, September 10, 2009 3:31 PM
> To: Keith Klevenski
> Cc: Nick Matthews; cisco-voip at puck.nether.net Voice
> Subject: Re: [cisco-voip] Cisco IOS Enhanced Software Media Termination Point, DTMF and SIP
>
> Sep 10 20:05:34.368: H245 MSC OUTGOING ENCODE BUFFER::= 6D40012A
> Sep 10 20:05:34.368:
> Sep 10 20:05:36.148: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "0"
>
>
> That is the H.245-alpha dtmf 0 sent from the gw to CUCM.
>
> -Ryan
>
> On Sep 10, 2009, at 4:28 PM, Keith Klevenski wrote:
>
> Ryan,
>
> What exactly is it that means I'm sending OOB DTMF? These?
>
>
>
> Sep 10 20:05:34.368: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "*"
>
>
>
> I'm assuming so because when I removed h245-alpha and only left rtp-
> nte I did not see these messages when running 'deb h245 asn1'. I just
> wanted to confirm if that is correct. Even so 'deb voip rtp session
> named' still didn't show any output when sending DTMF. Sigh.
>
> I'm slowly catching on... ;)
>
> -keith
>
>
> -----Original Message-----
> From: Ryan Ratliff [mailto:rratliff at cisco.com]
> Sent: Thursday, September 10, 2009 3:19 PM
> To: Keith Klevenski
> Cc: Nick Matthews; cisco-voip at puck.nether.net Voice
> Subject: Re: [cisco-voip] Cisco IOS Enhanced Software Media
> Termination Point, DTMF and SIP
>
> That means your DTMF from the gateway to CUCM is set up as h245-alpha,
> which is OOB. Look at detailed CCM traces and you'll see that same
> message come in and then something sent to the other side, whether to
> an MTP or via SIP (if it's doing SIP oob).
>
> -Ryan
>
> On Sep 10, 2009, at 4:15 PM, Keith Klevenski wrote:
>
> Ryan/Nick,
>
> I set up the dial-peer as you guys suggested:
>
> dial-peer voice 24 voip
> description ## Test for Keith ##
> destination-pattern 8325317449$
> progress_ind setup enable 3
> voice-class h323 1
> session target ipv4:10.1.101.11
> dtmf-relay h245-alphanumeric rtp-nte
> playout-delay nominal 130
> playout-delay mode fixed
> fax-relay ecm disable
> fax rate 9600
> fax nsf 000000
> fax protocol cisco
> no vad
>
> When I do a 'deb h245 asn1' I see the TCS sent from the PSTN gateway:
>
> capabilityTableEntryNumber 34
> capability receiveRTPAudioTelephonyEventCapability :
> {
> dynamicRTPPayloadType 101
> audioTelephoneEvent "0-16"
>
> But the TCS I receive from CM I see none of this. Also when I do a
> 'deb voip rtp session named-event' I get no output when I send DTMF
> from the PSTN. Ryan, you mentioned that if I don't see the gateway
> sending 2833 packets with payload type I need to look at h323 and SIP
> signalling. I'm just not sure what to look for. Incoming/outgoing
> calls work fine from from the h323 PSTN gateway to internal phones.
> Voicemail can be accessed and DTMF sent no problem from inside though
> the SIP trunk to Asterisk. Obviously there is some problem with the
> 2833 packets not being sent from the gateway, but I'm not sure where
> to go from there. This all works fine when using a transcoder and
> configuring the SIP trunk for g711, but calls seem to get hung on the
> transcoder as I described before and I'd rather just run one codec
> anyway. All h323 and SIP configuration is the same in that scenario
> with the exception of g711 on the SIP trunk and a transcoder so I
> would think the signalling should be ok.
>
> I did notice when doing 'deb h245 asn1' that after the call was
> connected to Asterisk, when I pressed DTMF I saw the following:
>
> Sep 10 20:05:34.368: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "*"
>
>
>
> Sep 10 20:05:34.368: H245 MSC OUTGOING ENCODE BUFFER::= 6D40012A
> Sep 10 20:05:34.368:
> Sep 10 20:05:36.148: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "0"
>
>
>
> Sep 10 20:05:36.148: H245 MSC OUTGOING ENCODE BUFFER::= 6D400130
> Sep 10 20:05:36.148:
> Sep 10 20:05:37.848: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "#"
>
>
>
> Sep 10 20:05:37.848: H245 MSC OUTGOING ENCODE BUFFER::= 6D400123
> Sep 10 20:05:37.848:
> Sep 10 20:05:39.468: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "7"
>
>
>
> Sep 10 20:05:39.468: H245 MSC OUTGOING ENCODE BUFFER::= 6D400137
> Sep 10 20:05:39.468:
> Sep 10 20:05:40.388: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "8"
>
>
>
> Sep 10 20:05:40.388: H245 MSC OUTGOING ENCODE BUFFER::= 6D400138
> Sep 10 20:05:40.388:
> Sep 10 20:05:41.200: H245 MSC OUTGOING PDU ::=
>
> value MultimediaSystemControlMessage ::= indication : userInput :
> alphanumeric : "9"
>
>
> I'll keep playing with it and I appreciate any suggestions you may
> have at this point. I am really looking forward to truly
> understanding what is taking place here.
>
>
> Thanks!
>
> -keith
>
>
> -----Original Message-----
> From: Ryan Ratliff [mailto:rratliff at cisco.com]
> Sent: Thursday, September 10, 2009 8:55 AM
> To: Keith Klevenski
> Cc: Nick Matthews; cisco-voip at puck.nether.net Voice
> Subject: Re: [cisco-voip] Cisco IOS Enhanced Software Media
> Termination Point, DTMF and SIP
>
> You mentioned that all your calls are using g.729 codec. In this case
> in order for an MTP to be allocated it would have to invoke a
> transcoder to convert between g.711 and g.729. Both the CUCM software
> MTP and the IOS MTP (from the config in your first email) only support
> g.711.
>
> The fact that the 'show voip rtp conn' command shows you the Asterix'
> IP address means no MTP is being invoked. You can do the same command
> on whatever device is hosting the sccp controlled FXS ports or if you
> have a physical IP phone get a call up to Asterix, browse to the
> phone's IP address and look at Streaming Statisics 1 for the remote IP
> address. Physical IP phones support both g.729 and RFC 2833 DTMF so
> there is no need for an MTP.
>
> I think you're hung up on the MTP thing when you really don't need
> one. Set up your dial-peer like Nick and I suggested with both H245-
> alpha and rtp-nte. Get a call up and turn on 'debug voip rtp session
> named-event'. Now test the DTMF and you should see it sending 2833
> packets (with payload type). If not then you need to look at the H.
> 323 and SIP signaling.
>
> If you see the gateway sending DTMF but it's not being recognized by
> Asterix then I'd start with a packet capture at the Asterix server to
> make sure it is receiving the 2833 packets and go from there.
>
> -Ryan
>
> On Sep 10, 2009, at 12:37 AM, Nick Matthews wrote:
>
> If your software MTP is the same router it's not quite as
> straightforward. You can use 'show call active voice brief' to
> determine which IP addresses are used in each call leg. If you see
> calls with ID 0: that's usually indicative of a software MTP. If the
> MTP is on a different router / CUCM, then if you see that IP address
> in 'show voip rtp connections' you aren't using an MTP. You could
> also use RTMT to track MTP usage and see if the call goes up when you
> place it - may be more straightforward.
>
> If you would like to look deeper you can do a 'debug h245 asn1' and
> look at the terminalCapabilitySet the router sends and receives for
> the call. You should see something like Telephone Event 101 and
> Events 1-16 somewhere in the TCS. This would show for sure if it's
> being negotiated. As well, 'debug voip rtp session named' will show
> you debugs for when RFC 2833 is sent or received.
>
>
> -nick
>
> On Thu, Sep 10, 2009 at 12:14 AM, Keith
> Klevenski<KKlevenski at cstcorp.net> wrote:
>> Nick,
>>
>> Thanks for the info. This is exactly how I have it configured and
>> DTMF is still not being passed from the PSTN. The payload type is
>> 101 which is the default for rtp-nte so that was fine. Great
>> explanation as to why the SRND says CM doesn't support RFC 2833.
>> Good to know.
>>
>> Well, I am stumped. Everything you and Ryan said makes sense, but I
>> can't seem to get it working. I did use the 'show voip rtp
>> connections' command and saw the Asterisk server's IP address, but
>> how does this show that an MTP is being invoked? I must say I've
>> parsed out this command before, but I've never really used it for
>> troubleshooting. If a make a call to a phone and use this command I
>> see the IP address of the SCCP gateway, but does this have anything
>> to do with MTPs?
>>
>> So the kicker here is that DTMF works fine internally. Using SCCP
>> controlled FXS ports with analog phones. So that means my SCCP
>> phone is sending DTMF OOB which requires an MTP to be sent RFC 2833
>> to Asterisk over the SIP trunk. In old Windows version of CCM it
>> was easy to pull up perfmon and instantly see in real time when a
>> resource was being used, but it is not so easy anymore. I pull up
>> the MTPs in RTMT, but don't ever see any being used. It would only
>> be used when DTMF tones are being sent I would assume so maybe it's
>> hard to see? Plus I thought the SW IOS MTP was required for OOB
>> DTMF to RFC 2833, but Ryan mentioned the SW MTPs in CM could as
>> well. I am using g729 everywhere here so that may be a factor.
>>
>> If I could at least know for sure when an MTP is required (OOB DTMF
>> to RFC 2833 right?) so I could go monitor all MTPs and find out
>> where it is being used would be helpful. So far since I can't seem
>> to prove any MTPs are being used even though I'm in a working
>> scenario (internal DTMF from SCCP phones works) that requires MTPs.
>>
>> I'm sure I'll get to the bottom of this and I'm looking forward to
>> feeling very satisfied once it is fixed.
>>
>> Thanks a ton to you guys!
>>
>> -k
>>
>> -----Original Message-----
>> From: matthn at gmail.com [mailto:matthn at gmail.com] On Behalf Of Nick
>> Matthews
>> Sent: Wednesday, September 09, 2009 9:35 PM
>> To: Keith Klevenski
>> Cc: Ryan Ratliff; cisco-voip at puck.nether.net
>> Subject: Re: [cisco-voip] Cisco IOS Enhanced Software Media
>> Termination Point, DTMF and SIP
>>
>> This would be my opinion:
>>
>> -Configure CUCM to do rtp-nte to Asterisk
>> -Look at the SDP coming for Asterisk to check the payload type they're
>> using for DTMF
>> -Configure the outgoing dial peer from your PRI gateway to cucm as
>> 'h245-alpha rtp-nte'
>> -Use 'rtp payload-type nte <x>' as needed from the SDP from Asterisk
>>
>> This should remove the need for the MTP altogether, which is a good
>> design choice. The reason the SRND states that RFC 2833 isn't
>> supported is because CUCM will only allow RFC 2833 if at least one leg
>> of the call is SIP (I have no explanation for this, minus some
>> targeted speculation). In this case you have a SIP trunk so you're
>> fine. You would only have problems H323-H323 and you were only doing
>> RFC 2833. But, with 'h245-alpha rtp-nte', you will still prefer
>> h245-alpha and you don't have this problem.
>>
>> A quick way to check if MTP is being invoked is 'show voip rtp
>> connections'. Check if you see the IP of your Asterisk or not.
>>
>> -nick
>>
>>
>>
>> On Wed, Sep 9, 2009 at 6:03 PM, Keith
>> Klevenski<KKlevenski at cstcorp.net> wrote:
>>> I tried rtp-nte in the past and it did not work. In the CUCM 7.x
>>> SRDN I read that you should not use nte on h323 gateways because CM
>>> doesn't support it on h323 gateways: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/media.html#wp1056938
>>> I will certainly try it again as it was a few weeks ago when I was
>>> messing with it.
>>>
>>> All the voip dial-peers to CM are configured with h245-signal so
>>> I'm not sure how the gateway and Asterisk could have matching DTMF
>>> capabilities, but either they do or an MTP is being invoked and I
>>> am not detecting it. Even internal SCCP calls to Asterisk should
>>> be invoking an MTP for DTMF right? SCCP device calls Asterisk,
>>> media is up, SCCP device presses a digit and DTMF is sent OOB to
>>> CM, CM invokes MTP, MTP sends RFC2833 digit to Asterisk. However I
>>> don't see any MTP's being invoked when I do this and it works fine
>>> and all devices only have access to an IOS SW MTP in which I can
>>> see no activity with a 'deb sccp packet' which should definitely
>>> give me something if it is being invoked.
>>>
>>> The combination of SIP, g729, MTPs and DTMF is boggling to me.
>>> Does the fact that all calls are g729 a factor? All devices are in
>>> a g729 region. I read in CM help that 'To configure G.79 codecs
>>> for use with a SIP trunk, you must use a hardware MTP or transcoder
>>> that supports the G.79 codec' however I do not need one as it is
>>> working just fine wihtout it internally. I check MTP required, but
>>> one doesn't get invoked that I can tell yet internal DTMF works and
>>> all devices only have access to one device which is the IOS SW
>>> MTP. Which doesn't show any sign of being invoked...
>>>
>>> I wish they would just buy Unity. :P
>>>
>>> Thanks for your help Ryan. I'll play around with it some more and
>>> report back.
>>>
>>> -k
>>>
>>>
>>> -----Original Message-----
>>> From: Ryan Ratliff [mailto:rratliff at cisco.com]
>>> Sent: Wednesday, September 09, 2009 4:32 PM
>>> To: Keith Klevenski
>>> Cc: cisco-voip at puck.nether.net
>>> Subject: Re: [cisco-voip] Cisco IOS Enhanced Software Media
>>> Termination Point, DTMF and SIP
>>>
>>> Why require the MTP at all? You can configure more than 1 dtmf type
>>> on the dial-peer going to CUCM. Add rtp-nte to the dtmf payload
>>> types
>>> (in addition to h245-alpha) and you shouldn't need an MTP at all.
>>> Since you mentioned h245-alpha I assume your gateway is H.323.
>>>
>>> The CUCM software MTP can also convert from oob to 2833 DTMF so it
>>> may
>>> be using that one as well. The only difference in the IOS one is the
>>> codec support. If CUCM really isn't invoking an MTP then it's
>>> because
>>> the gateway and Asterix have matching dtmf capabilities.
>>>
>>> One thing you'll want to check is the payloadType for the 2833 DTMF.
>>> IOS gateways don't support dynamic payload types currently and I
>>> think
>>> use 101 by default. If Asterix is using something else you'll want
>>> to
>>> change it on the dial-peer with the command 'rtp payload-type nte
>>> <97-127>' where the number matches whatever Asterix is using. It may
>>> be that both sides think they can do 2833 but the gateway is
>>> sending a
>>> payloadType Asterix isn't looking for.
>>>
>>> -Ryan
>>>
>>> On Sep 9, 2009, at 5:02 PM, Keith Klevenski wrote:
>>>
>>> All,
>>>
>>> Trying to get DTMF to pass to an Asterisk VM server from the PSTN
>>> with
>>> no love. Using H323 PSTN gateways running 12.4(24)T1, ISDN PRI's,
>>> CUCM 7.02, with a SIP trunk to Asterisk. This is all g729 as
>>> well. I
>>> can dial into Asterisk internally and DTMF works fine, but I can't
>>> get
>>> it to pass DTMF from the PSTN. The call goes though to Asterisk fine
>>> from the PSTN, but doesn't seem to be passing DTMF.
>>>
>>> sccp ccm group 1
>>> associate ccm 1 priority 1
>>> associate ccm 2 priority 2
>>> associate profile 1 register softmtp2
>>> !
>>> dspfarm profile 1 mtp
>>> codec g711ulaw
>>> maximum sessions software 50
>>> associate application SCCP
>>>
>>> sh sccp
>>>
>>> SCCP Admin State: UP
>>> Gateway Local Interface: GigabitEthernet0/0.101
>>> IPv4 Address: 10.1.101.3
>>> Port Number: 2000
>>> IP Precedence: 5
>>> User Masked Codec list: None
>>> Call Manager: 10.1.101.11, Port Number: 2000
>>> Priority: 1, Version: 7.0, Identifier: 1
>>> Call Manager: 10.1.101.10, Port Number: 2000
>>> Priority: 2, Version: 7.0, Identifier: 2
>>>
>>> MTP Oper State: ACTIVE - Cause Code: NONE
>>> Active Call Manager: 10.1.101.11, Port Number: 2000
>>> TCP Link Status: CONNECTED, Profile Identifier: 1
>>> Reported Max Streams: 100, Reported Max OOS Streams: 0
>>> Supported Codec: g711ulaw, Maximum Packetization Period: 30
>>> Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
>>> Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
>>> Supported Codec: inband-dtmf to rfc2833 conversion, Maximum
>>> Packetization Period: 30
>>>
>>> From what I understand the IOS software MTP should be what I need to
>>> allow RFC2833 and h245-signal (tried h245-alphanumeric as well) to
>>> communicate, even with g729. The IOS SW MTP is registered and
>>> configured, but DTMF is still not being passed. The IOS software MTP
>>> is in the MRG/MRGL for all device pools for all devices. I've even
>>> put all the other media resources in a temp MRG to ensure only the
>>> software MTP is able to be invoked (it's all g729 satellite sccp
>>> analog phones so no moh/annunciator or anything). I do a 'deb sccp
>>> packet' on the gateway with the IOS MTP, but I get nothing when
>>> sending DTMF. In RTM I don't see any MTP resources being used on the
>>> IOS MTP. I've had the SIP trunk configured with MTP required checked
>>> and unchecked (although CM should still dynamically allocate and MTP
>>> for DTMF if needed even if it is not checked), RFC2833 set as the
>>> DTMF
>>> type and G729/G729a as the codec on the trunk. It seems like the MTP
>>> is not being invoked at all, but I'm not sure why or how to
>>> absolutely
>>> prove that it is or isn't. So far I don't see any attempts being
>>> made
>>> to invoke it by looking at RTM or 'deb sccp packet'. I don't have
>>> access to the Asterisk box (and wouldn't know what to do if I did),
>>> but it works fine internally so I'm pretty sure the problem is with
>>> two DTFM types needing an MTP.
>>>
>>> Any suggestions or insight?
>>>
>>> Thanks!
>>>
>>> Keith
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>
>
>
>
More information about the cisco-voip
mailing list