CUCM, MTP service list of features?

lexxa7777 · ‎07-22-2010

Hello

There 3 types of MTP

1) CCM software ( Media Streaming App)

2) IOS software

3) IOS hardware

I have some clients who use SIP trunk (w req. MTP) from CUCM to Service Provider and MGCP controlled FXS ports

hint: Service provider uses NON CISCO equpment, and for some reasons client doesn't use CUBE!

thera are a lot of problems with fax & modems.

I do some tests and get a some positive results only when switched off all fax/modem feature t.38/fax-pass/modem-pass and use g711 codec.

standard t.38 won't work

Is there a document which describes features that supported on SIP/H.323 trunk with MTP ( ability to use fax t.38, pass thru, modem passthru, dtmf-relay) with non Cisco devices on the SP side?

/lexxa

Steven Holl · ‎07-28-2010

Lexxa,

I don't have a link to an all-incvlusive document, but I can try and answer your questions here.

1) CCM software ( Media Streaming App)
2) IOS software
3) IOS hardware

Technically, you forgot Transcoders. They essentially serve a different function than an IOS hardware MTP.

CM Software MTP- Only supports g.711ulaw streams.

IOS Software MTP- Codec has to be the same on both sides. Does not use DSPs. Can be used for RTP-NTE to other OOB DTMF conversions. Supports T.38 passthru. Cannot pass NSE-based switchovers. This is what most people end up using for MTPs in a SIP trunk design.

IOS Hardware MTP- Codec has to be the same on both sides. Uses DSPs. Does everything the software MTP can do, but is typically used when the media needs to be re-packetized.

IOS Transcoder- Main function is to allow for different codecs to talk to each other. Codec needs to be g.711ulaw on one side to any codec on the other side. Can re-packetize, and also peek in the audio stream to insert/pull-out DTMF embedded in the audio stream payload.

I have some clients who use SIP trunk (w req. MTP) from CUCM to Service Provider and MGCP controlled FXS ports

hint: Service provider uses NON CISCO equpment, and for some reasons client doesn't use CUBE!

I can't speak on the specifics of your environment, but if you configure early-offer forced and mid-call signaling pass-thru on a SIP to SIP CUBE, you typically can do calls to almost all SIP providers without needing an MTP required for the call flow.

thera are a lot of problems with fax & modems.

I do some tests and get a some positive results only when switched off all fax/modem feature t.38/fax-pass/modem-pass and use g711 codec.

standard t.38 won't work

It is unclear what you are getting at here. First, you need to be clear if the provider supports t.38 or not. If they don't support T.38, your best bet is to nail up a g.711 call to the provider, and you'll get best-effort faxing which should be fine at low speeds. High speed fax and modems would be sketchy at best across a g.711 call in voice mode. You can use specific device pools/regions/dial-peers to acheive this such that calls from/to the fax numbers always are g711 from the start of the call.

Keep in mind that if you are doing any switchovers via NSE (gw-controlled MGCP, SCCP, or nse-forced) then make sure you aren't invoking the MTP, as MTPs don't pass NSEs properly out the other side. Modem passthrough is Cisco proprietary, so you'll never get that to work with a non-Cisco equipped SP. Furthermore, modem passthrough requires an NSE based switchover, which isn't going to work with the MTP as noted above.

You can invoke an MTP for a T.38 call, as long as 'codec pass-thru' is specified. Obviously, your provider needs to support T.38, though. You need to ensure that you use protocol-based switchovers for this (CA-controlled with MGCP, or via H.323 RM/SIP Re-INVITE messaging.)

Fax pass-through switchover is essentially just an upspeed to g711ulaw once the call is established via the call-control protocol messaging, so you can do this with an MTP.

Whether you are doing SIP or H.323, capabilities are the same on the MTP from a functional perspective, since the MTP is really only speaking SCCP anyway.

As far as DTMF-relay goes, the only thing relevant to talk about is RTP-NTE and in-band audio. All other types of DTMF-relay follow the signaling path, and are irrelevant from the perspective of an MTP (which terminates media). If you need to convert DTMF to-from in-band audio, you need a transcoder. Converting RTP-NTE to another type of DTMF-relay (H245-alpha/signal, SIP notify, etc.) can be done with a software or hardware MTP, as well as a transcoder.

Hope this helps. If you can be more specific about your SIP provider's requirements and what you are trying to fax from, we can get into more specific design.

lexxa7777 · ‎08-03-2010

Hello Steven!

Thanks for you reply

I've got a third-party SIP device (Addpac ap200b and do some tests)

1) cheapest sip trunking scheme (without CUBE)
FAX<-->AP200(FXS)<-->SIP_trunk_to_CUCM<-->CUCM(7.1.3b)<-->2811(MGCP,FXS)<-->FAX

i try to use
1) CM soft MTP (Media streaming app)
2) IOS soft MTP
3) IOS dsp MTP

results:

1) CM soft MTP (Media streaming app) can negotiate not only 711ulaw but also rtp-nte
2) faxing on top of 711u works fine
3) T.38 fails with any type MTP оr MTP is off ( no MTP in MRG )
i observe sip reinvite after fax detectioт but switching cannot complete

I realaize that I test only one device
______________

1) classic sip trunking scheme (with CUBE)
FAX<-->AP200(FXS)<-->SIP_trunk_to_CUBE<-->CUBE<-->UCM(7.1.3b)<-->2811(MGCP,FXS)<-->FAX

results:

1) MTP no longer require/used (seen in wireshark)
2) T.38 works! ( with the same config on CUCM)

after that I change FXS signalig from MGCP to SCCP and test.

T.38 doesn't work i look thru docs and find that SCCP controlled FXS ports use T38 NSE switchover.
soI think it is not compatible with addpac ( because CUBE does not support convertion t38 <-->t38 nse)

(no reinvites observed).

Steven, do you have any real info why Cisco doen't want to support outbound SIP INFO?

/lexxa

Steven Holl · ‎08-03-2010

3) T.38 fails with any type MTP оr MTP is off ( no MTP in MRG )
i observe sip reinvite after fax detectioт but switching cannot complete

That should work as long as you have 'codec pass-through' under the MTP. You're doing something wrong, and you'd need to see where the re-invite for t.38 isn't being passed through or responded to. Note that you need to use an IOS MTP with T.38--the CM software MTP will not work.

You are correct that when you go to SCCP, it only can do an NSE based switchover. That's Cisco proprietary, and your third party SIP device isn't going to switch-over. Essentially, you can't use SCCP-controlled fax devices if interoperating with non-Cisco devices. You need to do h323, mgcp, or sccp and use a protocol based switchover to t.38 or g.711 (fax pass-through).

CUBE supports the passing of Info messages for DTMF, but to my knowledge we don't have any devices that generate it. In my experience, SIP Info for DTMF is pretty rare--95% of people these days are doing RTP-NTE for DTMF anyway.

/steve

gfremgen · ‎03-29-2013

I know this post is old but you may be hitting a bug. I know I am hitting this bug, take a look and let me know if this is your problem.

CSCta96039 Bug Details

Chris Deren · ‎03-29-2013

If you want to see a full list of what MTPs are needed for that is very well documented in CUCM SRND under the media resources section.

HTH,

Chris

Giovanni Sciotti · ‎09-04-2013

Hello,

have you solved this issue? i have the same problem.

Thank you.

Giovanni