Sunday, 5 February 2012

MGCP DTMF Relay

The current implementations of DTMF relay for MGCP are Cisco proprietary, Named Signaling Event (NSE), NTE-CA, NTE-GW, and out-of-band. Keep in mind that
NSEs are the Cisco-Proprietary version of NTEs. They use different PT value than NTEs which is 100 (fixed value).

MGCP RTP-NTE has two implementations which are Gateway (GW) Controlled and Call Agent (CA) Controlled. In GW-controlled mode, GWs negotiate DTMF transmission and RTP PT values by exchanging capability information in SDP messages. That transmission is transparent to the CA. Both GWs are running MGCP and connected to same CUCM. In CA-controlled mode, CA will negotiate DTMF relay capabilities on behalf of the gateways (SDP messages are sent to CA). This is a must when the other GW/Endpoint is non-MGCP. After negotiation, CA will instruct MGCP gateway to use the agreed RTP-NTE values.

Note: In MGCP, RTP-NTE PT values range from 98-119 which is different that RFC2833 (96-127).

Similar to H323, in case negotiation fails, in-band voice DTMF relay will be used with codec PT values.

In the use of NSE (PT = 100) or Cisco proprietary (PT = 121), DTMF relay mechanism won't be carried in SDP messages and won't be negotiated. Each GW will use its local configuration to make the decision of DTMF relay method and PT value. Thus both ends should be configured with same parameters. Those two methods can't be considered as GW-Controlled or CA-Controlled since negotiation isn't present neither directly nor through CA.

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

NSE
s=DSP d=VoIP payload 0x64 ssrc 0x1F36 sequence 0xBF4 timestamp 0x4A8DADC2
Pt:100    Evt:1       Pkt:03 00 00  >>
s=DSP d=VoIP payload 0x64 ssrc 0x1F36 sequence 0xBF5 timestamp 0x4A8DADC2
Pt:100    Evt:1       Pkt:03 00 00  >>

In OOB method, DTMF events will be signaled to CUCM using MGCP protocol messages. To be more specific MGCP NTFY messages will be sent to CA. Its very important to note that after any digit received by MGCP GW and signaled to CUCM, CUCM will send RQNT message to the GW. This message will ask the GW to monitor the events of DTMF Digits, Fax-Relay (FXR), and T.38 Relay. WHY?? Initially when MGCP GW registers with CUCM, CUCM will send same RQNT. When a DTMF digit (for example) is pressed, GW will signal CUCM and consider that request is completed. Any new DTMF digits received by GW won't be signaled to CUCM because no new requests (RQNT) received. So the idea is that CUCM keeps renewing RQNT to GW after each event to keep GW signaling all events to CUCM.

RTR#debug mgcp packets
NTFY 875084221 S0/SU2/DS1-0/1@HQ MGCP 0.1
N: ca@135.5.100.30:2427
X: 1
O: D/1               *** Note: DTMF digit pressed is '1'
<---

Nov 13 11:39:23.045: MGCP Packet received from 135.5.100.30:2427--->
200 875084221
<---

Nov 13 11:39:23.045: MGCP Packet received from 135.5.100.30:2427--->
RQNT 473 S0/SU2/DS1-0/1@HQ MGCP 0.1
X: 1
R: D/[0-9ABCD*#], FXR/t38
Q: process,loop
<---

Nov 13 11:39:23.049: MGCP Packet sent to 135.5.100.30:2427--->
200 473 OK

Please refer to MGCP Protocol notes in order to see all MGCP SDP representations.

In OOB as well, CUCM reports to MGCP GW DTMF digits using RQNT messages through "S" SDP header.

Nov 14 06:40:04.884: MGCP Packet received from 135.5.100.30:2427--->
RQNT 632 S0/SU2/DS1-0/1@HQ MGCP 0.1
X: 1
R: D/[0-9ABCD*#], FXR/t38
S: D/1     !!!...CUCM informs MGCP GW that Digit '1' is pressed. MGCP GW will generate the tone of DTMF digit '1' to PSTN
Q: process,loop
<---

Nov 14 06:40:04.892: MGCP Packet sent to 135.5.100.30:2427--->
200 632 OK
<---

To configure MGCP DTMF relay, global configuration command should be applied:

RTR(config)#mgcp dtmf-relay voip codec all mode ?
  cisco        Set mgcp dtmf-relay mode to be cisco
  disabled     Set mgcp dtmf-relay mode to be disabled
  nse          Set mgcp dtmf-relay mode to be nse
  nte-ca       Set mgcp dtmf-relay mode to be nte-ca
  nte-gw       Set mgcp dtmf-relay mode to be nte-gw
  out-of-band  Set mgcp dtmf-relay mode to be out-of-band
!
RTR(config)#mgcp package-capability fm-package
!
RTR(config)#mgcp package-capability dtmf-package
!
!!!...To hardcode NSE/NTE values use below HIDDEN command. Same value will be assigned to both using this command
mgcp tse payload <98-119>

MGCP have the ability to enable DTMF relay for low-rate codecs (G729, iLBC, GSM, etc) ONLY. In this case high bit-rate codecs such as G711 will send DTMF digits as in-band voice with PT value of the codec.

RTR(config)#mgcp dtmf-relay voip codec low-bit-rate mode ?
  cisco        Set mgcp dtmf-relay mode to be cisco
  nse          Set mgcp dtmf-relay mode to be nse
  nte-ca       Set mgcp dtmf-relay mode to be nte-ca
  nte-gw       Set mgcp dtmf-relay mode to be nte-gw
  out-of-band  Set mgcp dtmf-relay mode to be out-of-band

As we saw so far, DTMF relay type can be configured at the gateway level. It can be configured as well at CUCM level as below (default is Current GW Config). 


MGCP KNOWN BUGs

1) CSCta69407 Bug Details (When using any type of inband DTMF signaling (RTP-NTE, NSE, or Cisco Proprietary) DSP's aren't turning off OOB dtmf signaling using mgcp packets. There fore duplicate digits will be seen on the terminating GW as one coming from rtp and other coming from CUCM)

DSP isn't told to "turn off" digits with mgcp dtmf-relay nte-gw / nte-ca
Symptom:
When using mgcp dtmf-relay type nte-gw, a sniffer trace will reveal that digits are sent both in-band (within the audio stream) and out-of-band (dtmf-relay). Because of this, double digits can be seen in Unity and MeetingPlace.

Conditions:
GW with PRI/CAS backhaul via MGCP to CUCM and mgcp dtmf-relay configured to use nte-gw.

Workaround:
Use mgcp dtmf-relay type out-of-band.

2) CSCsk15316 Bug Details

CSCsb54207 mgcp package-capability fm-package missing from feature sets
Symptoms: When attempting to configure RFC2833 DTMF inband with an MGCP gateway two commands
are required:

mgcp dtmf-relay voip codec all mode [nte-ca|nte-ga]
mgcp package-capability fm-package

The "mgcp package-capability fm-package" was has been released with Cisco IOS. However, it can only
currently be found in the IP Voice Feature Set (ipvoicek9) in either Cisco IOS Release 12.4 or Cisco IOS
Release12.4T.

Conditions: Customers requiring any of the features found in the higher level images (SP Svcs, Adv IP
Svcs, Enterprise Svcs), that are not found in the IP Voice feature set, are unable to implement RFC2833
DTMF inband due to the lack of "mgcp package-capability fm-package".

Workaround: There is no workaround.

Saturday, 4 February 2012

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.