H323 DTMF Relay

H323 endpoints support four types of DTMF relay methods which are:

1. Cisco Proprietary

In this method DTMF signals are carried in RTP stream with PT 121. This PT value won't be negotiated during call setup and thus both ends should be configured to use same method. OGW will send RTP PT 121 without verifying if TGW supports this or not.

RTR#debug voice rtp session named-event

s=DSP d=VoIP payload 0x79 ssrc 0x1F1E sequence 0xE93 timestamp 0xB437938A

Pt:121    Evt:1       Pkt:01 03 20  >>

s=DSP d=VoIP payload 0x79 ssrc 0x1F1E sequence 0xE94 timestamp 0xB437942A

Pt:121    Evt:1       Pkt:02 03 20  >>

*** Note: DTMF digit pressed is '1'

2. H.245 Alphanumeric

In this method DTMF signals are carried as H.245 messages (OOB). However, this method can't provide the duration of DTMF digit, i.e. for how long this digit was pressed. It always assume that the duration is 500 msec.

RTR#debug h245 asn1

value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1"

During call setup phase h245-alphanumeric negotiation can be verified as follow,

OGW#debug h245 asn1

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

    {

…

…

      capabilityTable

      {

…

…

        {

          capabilityTableEntryNumber 27

          capability receiveUserInputCapability : basicString : NULL

3. H.245 Signal

This method overcomes the problem of H.245 alphanumeric by carrying tone length info.

RTR#debug h245 asn1

value MultimediaSystemControlMessage ::= indication : userInput : signalUpdate :

    {

      duration 100

      rtp

      {

        logicalChannelNumber 1

      }

    }

During call setup phase h245-signal negotiation can be verified as follow,

OGW#debug h245 asn1

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

    {

…

…

      capabilityTable

      {

…

…

        {

          capabilityTableEntryNumber 30

          capability receiveUserInputCapability : dtmf : NULL

        },

4. RTP-NTE or RFC2833

In this method DTMF tones are transported in RTP streams based on RFC2833. The use of this method and PT value will be negotiated between both ends during call setup through H245 Terminal Capability Set (TCS) messages (unlike Cisco Proprietary method where the method and PT value won't be negotiated).

During call setup phased RTP-NTE negotiation can be verified as follow,

OGW#debug h245 asn1

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

    {

…

…

      capabilityTable

      {

        {

          capabilityTableEntryNumber 34

          capability receiveRTPAudioTelephonyEventCapability :

          {

            dynamicRTPPayloadType 101

            audioTelephoneEvent "0-16"

          }

        },

        {

…

…

During RTP session, whenever DTMF digit is pressed it can verified as follow,

OGW#debug voice rtp session named-event

*Dec 14 21:21:10.150:          s=DSP d=VoIP payload 0x65 ssrc 0x50142FE sequence 0x28FD timestamp 0x82EAC004

*Dec 14 21:21:10.150:          Pt:101    Evt:1       Pkt:04 00 00  >>

TGW#debug voice rtp session named-event

*Dec 14 21:21:10.150:          s=VoIP d=DSP payload 0x65 ssrc 0x50142FE sequence 0x28FD timestamp 0x82EAC004

*Dec 14 21:21:10.150:  << Pt:101    Evt:1       Pkt:04 00 00

Here is a sample configuration for DTMF relay in H323 Gateway,

dial-peer voice 10 voip

 destination-pattern 11000

 session target ipv4:135.5.100.30

 !!!...In case you want to hardcode PT value

 rtp payload-type nte 98

 dtmf-relay rtp-nte h245-signal h245-alphanumeric cisco-rtp

 codec g711ulaw

As you see, we can apply all DTMF methods at the same time. Now based on negotiation any of them will be selected. In case non of the configured methods is matched between both ends, DTMF relay method will fall back to voice in-band signaling. The RTP PT value will be used same as codec PT value.

*** For full list of RTP PT values refer to VoIP Protocols notes

To verify the used DTMF relay method during RTP session,

OGW#show call active voice

!

…

…

!

PeerAddress=5001

!

…

…

!

tx_DtmfRelay=rtp-nte

Tricky Question: In DTMF Relay mode RTP-NTE, DTMF digits are transmitted using G711 or G729 codecs?? Non of them, it's using speical codec based on RFC2833 to transmit DTMF digits. This is also confirmed based on PT value. For G711 PT = 0 and for G729 PT = 18, but for RTP-NTE PT value range from 96-127, i.e. it's not matching any of the codecs. The only exception as we said earlier is that when negotiation for all DTMF Relay modes fail, then DTMF Relay will fallback to voice in-band signaling with RTP PT value same as codec PT value, i.e. DTMF signaling is sent as audio RTP stream using the configured codec. Also, those DTMF RTP packets won't be seen using "debug voice rtp session named-event" since they are audio packets now and not events.

The difference between RTP-NTE and DTMF Fallback to in-band can be also distinguished using IOS:

tx_DtmfRelay=rtp-nte

Or

tx_DtmfRelay=inband-voice

TIP on RTP-NTE

As you each digit is represented by 7 RTP NTE packets … WHY?? Why not 1 RTP NTE packets?

s=DSP d=VoIP payload 0x65 ssrc 0x41F42FE sequence 0x1A4F timestamp 0x8276446C

Pt:101    Evt:1       Pkt:04 00 00  >>

s=DSP d=VoIP payload 0x65 ssrc 0x41F42FE sequence 0x1A50 timestamp 0x8276446C

Pt:101    Evt:1       Pkt:04 00 00  >>

s=DSP d=VoIP payload 0x65 ssrc 0x41F42FE sequence 0x1A51 timestamp 0x8276446C

Pt:101    Evt:1       Pkt:04 00 00  >>

s=DSP d=VoIP payload 0x65 ssrc 0x41F42FE sequence 0x1A52 timestamp 0x8276446C

Pt:101    Evt:1       Pkt:04 01 90  >>

s=DSP d=VoIP payload 0x65 ssrc 0x41F42FE sequence 0x1A53 timestamp 0x8276446C

Pt:101    Evt:1       Pkt:84 03 20  >>

s=DSP d=VoIP payload 0x65 ssrc 0x41F42FE sequence 0x1A54 timestamp 0x8276446C

Pt:101    Evt:1       Pkt:84 03 20  >>

s=DSP d=VoIP payload 0x65 ssrc 0x41F42FE sequence 0x1A55 timestamp 0x8276446C

Pt:101    Evt:1       Pkt:84 03 20  >>

• The first packet says that it is the start of a new NTE digit because it does not have the endbit set  (Pkt:04 00 00)
• The second and third packets are repeats of the first packet for redundancy.
• The fourth packet is a refresh packet with a duration of 50ms (0×0190 = 400 samples * 1sec / 8000 samples).
• The fifth packet is the endbit packet (84) with a duration of 100ms (0×0320 = 800 samples * 1sec / 8000 samples) (Pkt:84 03 20)
• The sixth and seventh packets are redundant packets for packet five.