12-02-2009 12:06 PM - edited 03-14-2019 04:56 AM
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
Thanks.
12-03-2009 01:21 AM
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:
Regards,
Geoff
12-03-2009 08:02 AM
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?
12-03-2009 08:41 AM
yshraybman wrote:
It's the SIP trunk between CUBE and CUCM that appears to require it. If I uncheck MTP required, call fails.
What's that SIP trunk for?
Regards,
Geoff
12-03-2009 09:21 AM
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.
12-03-2009 10:17 AM
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.
Regards,
Geoff
12-03-2009 11:38 AM
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.
12-03-2009 01:46 PM
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
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/pbx/interop/notes/668298.pdf
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.
Regards,
Geoff
12-03-2009 02:11 PM
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 []
Anyway, I'll give it a try and let you know if it works or not.
Thanks!
12-03-2009 11:37 PM
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.
Regards,
Geoff
12-04-2009 08:39 AM
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.
12-04-2009 10:20 AM
One more thing to try then.
Drop the codec specification and specify g711 - don't let it down-negotiate. SIP providers often send down three codecs at once, so specify codec g711ulaw and see how that goes.
Regards,
Geoff
12-04-2009 01:37 PM
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...
12-08-2009 01:30 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: