RTP-NTE Payload Type

[Wilson Samuel]

Hi,

For one of my customers on the ITSP < > CUBE < >CUCM, often times there have been intermittent issues regarding DTMF.

Although I have configured on both dial-peers as RTP-NTE, I do see that ITSP often engages in different types of payloads in RTP-NTE.

I thought before reading the RFC, check it out over here, if anyone has any easy to understand explanation about RTP-NTE payload types (I have seen mostly 96 and 101) and whenever they are 101, there are issues.

Regards

[Vivek Batra]

Hi Wilson,

RTP Event (RFC 2833) uses dynamic payload type ranging from 96 to 127 (I think default is 96). It's opposed to some other codecs which use static payload type like G.711Mu (payload 0) and G.711A (payload 8).

Moreover both the end points during SDP negotiation can use different payload type for DTMF. 

For example if UAC sends 96 payload type in SDP offer and UAS sends 101 in SDP answer, both UAC/UAS must entertain the payload type of remote end for sending purpose. So this means that UAC will send DTMF in payload 101 whereas UAS will send in 96.

AFAIK default payload type can be set to any other value under dial-peer.

'debug voip rtp' command can be used to debug the RTP-NTE DTMF events.

HTH

Thanks 

[Wilson Samuel]

Thanks guys (+5), I will run this test and will get back to you on the forum.

Regards

[Ayodeji Okanlawon]

Vivek,

DTMF will not work if both parties transmit it using different payload types. I have worked on several DTMF related issues where CUCM/CUBE was advertising DTMF using payload 101 and the other parties use 97. For DTMF to be reliably sent both parties have to usesame payload to send DTMF.

A case in point is systems built bu Huawei..They always use 97 as the payload for rtp-nte. where CUCM/CUBE defaults to 101. DTMF never works. The only way to make it work is to map CUBE/CUCM payload to 97..

Wilson, you need to look at the sip messages and see what dtmf payload is advertised for failing DTMF events..

[Vivek Batra]

Ayodeji,

Good to know from your expertise. Thanks.

However it may be because of implementation issue or interoperability. As per RFC, payload type is declarative value, this means it's not negotiated and since it's declarative, remote end must entertain the request. It's opposite from codec agreement during SDP offer/answer which is basically a negotiation (not declarative).

Alice -> Bob (SDP offer: PT 96)

Bob -> Alice (SDP answer: PT 101)

In the above case, it's completely normal in RFC adaptive implementation for Alice to accept DTMF in PT 96 and Bob to accept DTMF in 101. Myself has tested our gateways (not Cisco) with many third party gateways in this environment and work very well.

Your might be true in a way how it's implemented in CM/CUBE. I will put some time here to come on your way :)

Thanks

Vivek   

[Ayodeji Okanlawon]

Vivek, 

This issue with RFCs is that they provide a frame work to develop protocols across different platforms but no one adheres strictly to them. 

I have seen cases where RFCs says one thing and the developers do different things and I must sat  Cisco is one of the guilty parties. 

[Vivek Batra]

Ayodeji,

Completely agree with you. Implementation with respect to RFC adaption sometimes is more than pain in the neck and in result, interop becomes one of the major factor (specifically in SIP related).

Thanks 

[Mohammed al Baqari]

Hi,

Just a point I want to add here, CUBE 1.3 and earlier requires the same PT on both call legs in both directions of the call.

Starting from CUBE 1.4 (IOS 15.1.1T), CUBE interworks between different PTs for each call leg.

[Ayodeji Okanlawon]

Thanks Mohammed for the update. That is good. Do you have any documentation to confirm this?

[Wilson Samuel]

Thanks all for the great info (+5). I have seen my ITSP offer 96 as well 101 RTP-NTE Payload type. In most cases the CUBE works without issues, however at times it gives us crazy issues (e.g. DTMF not working whenever there is a CallFWD ALL to PSTN by any user).

Regards

[Mohammed al Baqari]

Hi,

As Vivke mentioned, the PT value will be negotiated during call setup in RFC2833. You can set a default value to be used as start point during call setup as below example.

dial-peer voice 10 voip
 rtp payload-type nte 98

During a faulty call, check the negotiated DTMF method and value using the command

OGW#show call active voice
!
… <Output Omitted>…
!
PeerAddress=5001
!
… <Output Omitted>…
!
tx_DtmfRelay=rtp-nte

If it is RTP-NTE, use the command 'debug voice rtp session named-event' to see if the digits are being exchanged.

[KY_]

Hi Everyone,

I'm getting following error when i want to change dtmf payload type

rtp payload-type nte 97
ERROR: value 97 in use!

Can you please advice ?

Thanks

[TONY SMITH]

If you do "show dial-peer voice" for the dial peer of interest, it will show the current assignments.  For example ...

RTP dynamic payload type values: NTE = 101
        Cisco: NSE=100, fax=96, fax-ack=97, dtmf=121, fax-relay=122
               CAS=123, TTY=119, ClearChan=125, PCM switch over u-law=0,
               A-law=8, GSMAMR-NB=117 iLBC=116, AAC-ld=114, iSAC=124
               MP4A-LATM=111, lmr_tone=0, nte_tone=0
               h263+=118, h264=119
               G726r16 using static payload
               G726r24 using static payload

That's from a CUCM facing dial peer, using 101 for DTMF.

On that CUBE we needed to use 97 on the ITSP side, so had to change "fax-ack" (whatever that is) to use a different type.  

 rtp payload-type cisco-codec-fax-ack 99
 rtp payload-type nte 97