Unanswered Question
Dec 2nd, 2009

Call Flow: SIP Provider-CUBE-CUPS-CVP-ICM

I managed to get inbound calls working by checking MTP required on the SIP trunk between CUBE and CUCM.

Is there a way to make it work without MTPs?

CUBE 1.3, CUPS 6.0, CVP4.1, CUCM6.12


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

Yes there is.

I'm not sure it will work with CVP 4.0(2), but it certainly works with CVP 7.0(2) - preferably ES 7.

If “midcall-signaling passthru” is not set, MTPs are required on the SIP trunk to CUPS. Do you have this configured in your CUBE?

If you do have it set, then the only solution for you is to go to CVP 7. There are many subtle and not so subtle SIP fixes in CVP7 - strongly suggest going there.

Our test bed is:

  • UCCE 7.5
  • CVP 7.0(2) ES7
  • CUCM 6.1(3a)
  • CUPS 6.0(2)
  • IOS on ingress gateway – 12.4(22)T1 (CUBE 1.2)
  • IOS on VXML gateway – 12.4(15)T8
  • AT&T IP Toll Free Service



yshraybman Thu, 12/03/2009 - 08:02

Thanks for the reply.

SIP trunks to CUPS are set without MTP required.

It's the SIP trunk between CUBE and CUCM that appears to require it.  If I uncheck MTP required, call fails.

I do have midcall-signaling passthru configured.

Is there something else I'm missing?

yshraybman Thu, 12/03/2009 - 09:21

This is getting interesting...

So we mostly use PSTN/vxml gateways and trying to test SIP ingress.

There is SIP trunk between PSTN gateways and CUCM for the very last call leg ( I assume).  So I figured I would need one between CUBE and CUCM.  Obviously it is using it somehow because it works (with MTP only).

Are you saying I do not need CUBE-CUCM trunk for ICM calls?  And use existing CUPS-CUCM trunks instead?

Well, existing CUPS-CUCM trunks do not have MTP checked and I would think MTP is not required there as PSTN -originated calls work OK.

Is there some special configuration required for mixed environment of PSTN-originated calls and SIP-originated calls?  I was under assumption that core configuration for PSTN calls would be the same as for the SIP calls.

CVP does not need the SIP trunk between the CUCM and the voice gateway, but non-CVP will probably need it for inbound and you may need it for outbound. The mixing of these two is sometimes tricky.

You should see if you can get all your agent based ICM-CVP system working first. There should be no labels on the CUCM routing client at all - just on CVP RCs.



yshraybman Thu, 12/03/2009 - 11:38

After I removed CUCM label it worked without MTP checked.

But it is still using CUBE-CUCM trunk.  I know that because if i change CUBE-CUCM trunk inboud sig digits to 1, the call to agent fails.  If I set it to the same digits as Agent extension then it works.

So the question is should I leave it the way it is or should I investigate further why it is using CUBE-CUCM trunk?

Collect Digits not working as well, using rtp-nte for dtmf relay.

yshraybman wrote:

Collect Digits not working as well, using rtp-nte for dtmf relay.

It's absolutely vital that you follow the instructions in what I regard as the primary reference "AT&T IP Toll-Free: Connecting Cisco Unified Communications Manager 6.1(1a) via the Cisco Unified Border Element using SIP". The link that used to work for me is

The settings for the payload are

rtp payload-type cisco-codec-fax-ind 98
rtp payload-type nte 96
dtmf-relay rtp-nte

Even if you set this on the incoming dial peer, it is MANDATORY to ensure you also set these  on the dial peer for the Network VRU Transfer label (typically 8111111111) that catches the switch leg on the VXML gateway and starts the bootstrap. If you don't do this, DTMF will fail.

Make sure this is aligned.



yshraybman Thu, 12/03/2009 - 14:11

Very good point.  I'll definitely give it a try.

It's just I do not comprehend why do we need to change payload type.  From the Networkers presentation:  By Default Cisco IOS Uses Payload-Type 96 for fax and 101 for RFC2833.  Why suddenly it needs to be 96?

Or is it one of those things if it works be happy it works, don't ask any more questions

In the ICM script it fails at Run Ext script (GD microapp).  The same script works OK for PSTN call.

VXML gateway does not appear to see entered digit

Dec  3 22:07:18.545: //3529442//AFW_:/vapp_digit_collection_done: digits [], status [18], pattern []

: name=ERROR_CODE expr=17

Anyway, I'll give it a try and let you know if it works or not.


yshraybman wrote:

Or is it one of those things if it works be happy it works, don't ask any more questions

Like you, I hate those sort of situations. As you said, for DTMF digit passing using RFC2833 the default for rtp-nte (network telephone-events DTMF) is 101. This needs to be changed to 96. Wish I knew why.

Once you have this working, I would not mind getting back to the SIP trunk discussion.



yshraybman Fri, 12/04/2009 - 08:39

I still can't get it to work.  Failing at GD microapp.

VXML gateway dial peer

dial-peer voice 114 voip
translation-profile incoming block
service vru-leg
rtp payload-type cisco-codec-fax-ind 98
rtp payload-type nte 96
voice-class codec 1
incoming called-number 48111111111....
dtmf-relay rtp-nte
no vad 

CUBE dial-peers dtmfs are the same.

I'll try engaging TAC and see what happens.

I'll post the results.

Thanks again for your help.

yshraybman Fri, 12/04/2009 - 13:37

So, we have two providers, Verizon and ATT, connected to the same CUBE.

Verizon:  for both G.711 and G.729 calls it plays the message (GD) but never gets DTMFs, I suspect the issue is with Verizon SIP.

ATT: G.711 calls work OK with the same script, DTMFs are working.  But it does not work with G.729.  It never plays the message (in GD).

But it plays with Verizon G.729 call, and the dial-peers are almost identical on the same CUBE and the same VXML gw!!  Go figure...

yshraybman Tue, 12/08/2009 - 13:30

I finally got DTMFs working.

For Verizon SIP service it works with dtmf-relay rtp-nte digit-drop and default payload type.

It even works with G729 all the way.

For ATT SIP serivce, just like you suggested, dtmf-relay rtp-nte and payload type 96.

But PM and GD do not work with G729, only with G711 using the same VXML gw as Verizon service (different dial peers of course).

It would be nice to make ATT work with G729 but it just does not like it at this moment.

CUBE 12.4(22)YB4, VXML 12.4(15)T8


This Discussion