CallManager has a choice of MTPs available. It’s not always clear the difference between the types or why you might need one.
Reasons to use an MTP
MTPs can be required for any of the following reasons:
- To provide Early Offer support for SIP call. (Although since CUCM 10.0 this may not be true)
- To provide DTMF transcoding. (But this may not actually be true of all MTPs)
- To act as an RSVP agent for calls.
- To act as a trusted relay point for calls.
- To provide IPv4/IPv6 conversion for RTP streams.
- Repacketisation of a stream. (e.g, convert between 10ms & 20ms packetisation)
- Act as a fixed point in the media stream when one endpoint in the call doesn’t support mid-call media changes. (e.g. Transfers)
MTPs do not convert between codecs. Well, not always…
When not to use an MTP
- When the call might involve video. Standard MTPs do not pass video.
- When you need to convert between codecs. In this case you need a transcoder. However, a transcoder can also perform all the functions of an MTP.
There are three different types of MTPs in CallManager and they have differing capabilities.
This is the simplest MTP available. It is built into the CallManager software. Each node in a CallManager cluster can only run one instance of an MTP. Each MTP instance can only support a maximum of 48 concurrent calls. It also cannot make any changes to the media (e.g. DTMF conversion). Cisco’s latest recommendation is to only have this as a last resort and use one of the other types instead.
IOS Software MTP
The IOS software MTP runs on a Cisco IOS (or IOS-XE) router with the voice feature set. It is similar to the CUCM MTP but can handle up to 500 concurrent calls. (The maximum number of calls is dependent on the router hardware)
IOS Hardware MTP
This type of MTP requires DSP resources being allocated on the router. So the maximum number of calls is dependant on the available DSP resources.
This MTP can:
- Change DTMF formats. e.g. “read” the audio stream and extract DTMF signals and generate out-of-band signalling.
- Re-packetise the audio. e.g. Convert between 10ms & 20ms packetisation
Whilst MTPs cannot convert between codecs, Cisco’s docs claim a hardware MTP can convert between G.711 a-Law and G.711 u-Law.
Configuring IOS MTPs
Both software & hardware IOS MTPs register to CUCM via SCCP.
IOS Software MTPs
!Change to the appropriate value voice-card XX/XX/XX !Assign the DSPs to being in a dspfarm. dsp services dspfarm ! !Adjust based on which CUCM servers this device is supposed to be registering to sccp ccm 192.168.0.1 identifier 1 priority 3 version 7.0 sccp ccm 192.168.0.2 identifier 2 priority 2 version 7.0 ! !Activate SCCP sccp ! dspfarm profile 1 mtp maximum sessions software 500 associate application SCCP no shutdown ! sccp ccm group 1 associate ccm 1 priority 1 associate ccm 2 priority 2 !Change the name to something appropriate. e.g. MTP_HW_GW-1. !Note that CUCM has a limit as to the length of this name !The profile number is that specified in the dspfarm profile command. associate profile 1 register XXXX
IOS Hardware MTPs
Hardware MTPs are configured almost the same as a software MTP. However, instead of:
dspfarm profile 1 mtp maximum sessions software 500
dspfarm profile 1 mtp maximum sessions hardware X
Where X is the number of DSP resources you want assigned to the hardware MTP.
Hardware and Software MTPs
Having hardware MTPs configured does not preclude having software MTPs configured on the same IOS device. Just make sure they are configured as separate dspfarm profiles and both are listed in the SCCP CCM GROUP section:
dspfarm profile 1 mtp maximum sessions software 500 ... ! dspfarm profile 2 mtp maximum sessions hardware 4 ... ! sccp ccm group 1 ... associate profile 1 register IOS-SW-MTP associate profile 2 register IOS-HW-MTP
Note that if you’re in Europe and use G.711 a-Law, you need to add the following two lines to the dspfarm profile command as it defaults to G.711 u-Law:
dspfarm profile 1 mtp ! !IOS Defaults to G7.11 u-Law no codec g711ulaw codec g711alaw
Regardless of type, MTPs are assigned to devices (phones, SIP Trunks, Gateways, etc) via Media Resource Group Lists.
Unfortunately, CUCM is not clever enough to know what type of MTP is required for each call scenario. As IOS Hardware MTPs are generally quite limited resources compared to the two software MTPs, the sysadmin as to be prudent in how they are assigned. This will mean configuring differing MRGLs containing the different MTP types.
If there are insufficient (or incorrect types of) MTPs to support a call, the call may progress but without the (correct) MTP. This will result in the call progressing but with errors in the media. In the best case, the callers may not notice anything. In the worst, the call will establish but have no audio, or audio will drop during hold, transfers, or have one-way audio, or have DTMF events fail, etc.