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.
