CVP4.1 SIP - Trunk MTP Required ?

Unanswered Question
Apr 19th, 2008
User Badges:

System Components


CVP 4.1

ICM 7.2.2

CUCM 6.1

CUPS 6.1

2821 IOS 12.4-15.T3 AdvIPServices


ICM PG - CUCM

Routing Client - Network Transfer Preferred - Unchecked

Advanced - VRU Type - None


ICM PG - CVP

Routing Client - Network Transfer Preferred - Unchecked

Advanced - VRU Type - 10


ICM Network VRU

Type 10

CVP Routing Client Label - 83000

CUCM Routing Client Label - 84000


ICM Dialled Number

1936 - PSTN callers

1935 - IP originated callers


CUPS - Sip Proxy Static Routes

83000* -> 2821 VXML Gateway

84000* -> CVP CallServer

40* -> CUCM (Agent and IPT extensions)

1936 -> CVP CallServer

818181* -> 2821 VXML Gateway (CVP Ringtone)

828282* -> 2821 VXML Gateway (CVP Error)


CUCM

1935 -> CTI Route Point (Internal IP Calls, Agent Transfers)

84000! -> Route Pattern to Sip Proxy Trunk

Sip Trunk to VXML Gateway

Sip Trunk to CVP CallServer

40XX -> Agent Extensions

MTP is unchecked on all SIP Trunks


2821 VXML Gateway

Sip-ua

Sip-server -> CUPS


Dial-peer voice 4000 voip

Destination-pattern 40..

Session target sip-server


Dial-peer voice 1936 voip

Destination-pattern 1936

Session target sip-server


Dial-peer voice 83000 voip

Incoming Called-Number 83000T

Service bootstrap



Call Flow

1. PSTN Caller


1936 -> Dialpeer 1936 -> Proxy -> CVP -> ICM -> Send to VRU

ICM VRU Label 83000XX - > CVP -> Proxy -> VXMLGateway -> Service Bootstrap


Agent is available at 40XX call routes to agent successfully

Agent is unavailable call is queued until agent is available and call routes successfully

Agent answers call then transfers to script with DN 1935


2. Agent transfer to script


1935 CTI route point -> ICM -> Send to VRU -> ICM VRU Label 84000XX -> CUCM

CUCM Route Pattern 84000! -> SIP Trunk to Proxy -> CVP CallServer


Agent is available at 40XX call routes to agent successfully

Agent is unavailable call is queued until agent is available and call routes successfully


3. Internal IPT caller dials script with DN 1935


1935 CTI route point -> ICM -> Send to VRU -> ICM VRU Label 84000XX -> CUCM

CUCM Route Pattern 84000! -> SIP Trunk to Proxy -> CVP CallServer


Agent is available at 40XX call routes to agent successfully

Agent is unavailable call is queued until agent is available and call routes successfully


4. PSTN Caller to IPT User and transfer to ICM Script DN


400X -> Dialpeer 4000 -> Proxy -> CUCM

Call is answered by IPT User successfully

IPT user transfers to ICM DN 1935


1935 CTI route point -> ICM -> Send to VRU -> ICM VRU Label 84000XX -> CUCM

CUCM Route Pattern 84000! -> SIP Trunk to Proxy -> CVP CallServer


Agent is available at 40XX call routes to agent successfully

Agent is unavailable IPT user that is transferring the call hears the queue music and transfers the PSTN caller. PSTN Caller gets silence and call drops after a few seconds.


External Caller to IPT User and transfer to ICM Script DN - With MTP required checked on SIP Trunk to Proxy


400X -> Dialpeer 4000 -> Proxy -> CUCM

Call is answered by IPT User successfully

IPT user transfers to ICM DN 1935


1935 CTI route point -> ICM -> Send to VRU -> ICM VRU Label 84000XX -> CUCM

CUCM Route Pattern 84000! -> SIP Trunk to Proxy -> CVP CallServer


Agent is available at 40XX call routes to agent successfully

Agent is unavailable call is queued until agent is available and call routes successfully


Issue Description


Throughout the CVP4.1 SRND and Configuration Guide it specifies that for SIP calls you do not need MTP checked on the Trunks. (For H323 IP calls you do)

We have customers on CVP4.1 that take a lot of calls to their reception, IPT Users, and then transfer to an ICM script. We are finding that to facilitate this type of call routing we have to check MTP required on the SIP proxy trunk. This is taking up a large amount of MTP resources on the system.

Is there a setting within this setup that allows the above scenario 4 to work without MTP required on the SIP trunk?

Has anyone come across this issue?

Any input would be much appreciated.


Regards


Anthony


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (3 ratings)
Loading.

Anthony, I think a few of us have "across this issue".


In scenario 4, when the IPT user starts the transfer, the caller hears hold music from the Call Manager while the IPT user hears queue music from CVP (the gateway). No MTP required. If they wait for the target agent to answer, no MTP required.


If the IPT user completes the transfer, the caller will be dropped without MTP. As you know.


If you put the MTP on the SIP trunk to the SIP Proxy server, the caller will now hear queue music from CVP. Your analysis is correct.


What the Guide says - on page 375 is:


"When using the Warm Transfer feature for SIP Calls with queuing, call flows must have MTP enabled on the SIP trunk that is associated with the VRU label route pattern in the case where the agent completes consult transfer to caller while the call is still in the queue (VXML Gateway)."


Not that well worded - but the idea is there.


If the IPT user completes the warm transfer and removes themselves from the call, in order to hold the TDM caller in queue you have to set the MTP on the SIP trunk.


You are correct that this uses lots of MTP resources. I see a maximum of three in use when the second agent goes ready and takes the queued call.


If you can persuade the IPT user to always wait for the agent to answer the call in queue, you don't need the MTPs.


If you cannot do this, and the IPT user has to dump the call off, you need to set MTP required on the SIP trunk. Now once you set it, MTPs are used for all calls on the SIP trunk even when they normally are not needed.


I don't think there is any way around this at the moment. You need to set up DSP resources on the voice gateway as MTPs (you don't want to use the 24 software MTPs that come with a Call Manager subscriber).


Regards,

Geoff

Charl,


That's exactly what we want, I think.


I'm not a voice expert so I don't know how to do this. But I imagine you can set up an MTP group in Call Manager that actually uses DSPs on the gateway. The IPT architect is looking at doing this right now on the project I'm on.


Regards,

Geoff

agtmcgarry Mon, 04/21/2008 - 05:26
User Badges:

I Geoff


I have been testing in the lab this morning and the following are the results I have found.


MTP usage with MTP required unchecked on SIP Trunk


1. PSTN to Agent - 0 mtps

2. PSTN to Agent and Agent transfer to CTI RP - 1 mtps

3. IP Caller to CTI RP - 0 mtps

4. IP Caller to CTI RIP and Agent transfer to CTI RP - 1 mtps

5. PSTN to IPT and IPT Transfers to CTI RP (Agent Available and answers then IPT user hits transfer) - 0 mtps

6. PSTN to IPT and IPT Transfers to CTI RP (No Agent Available and call fails) - 1 mtps


MTP usage with MTP required checked on SIP Trunk


1. PSTN to Agent - 1 mtps

2. PSTN to Agent and Agent transfer to CTI RP - 3 mtps

3. IP Caller to CTI RP - 2 mtps

4. IP Caller to CTI RIP and Agent transfer to CTI RP - 4 mtps

5. PSTN to IPT and IPT Transfers to CTI RP (Agent Available) - 3 mtps

6. PSTN to IPT and IPT Transfers to CTI RP (No Agent Available) - 3 mtps


Possible work around to checking mtp required on the SIP trunk


Create a trunk to each CVP Call Server and check MTP required.

Create a route group for each CVP Call Server trunk

Place the two route groups in a route list.

CUCM VRU Type 10 Label 84000! Route pattern points to CVP route list instead of SIP Trunk.

Uncheck MTP required on the SIP Trunk


MTP usage with MTP required checked on CVP Call Server Trunks


1. PSTN to Agent - 0 mtps

2. PSTN to Agent and Agent transfer to CTI RP - 1 mtps

3. IP Caller to CTI RP - 1 mtps

4. IP Caller to CTI RIP and Agent transfer to CTI RP - 2 mtps

5. PSTN to IPT and IPT Transfers to CTI RP (Agent Available) - 1 mtps

6. PSTN to IPT and IPT Transfers to CTI RP (No Agent Available) - 1 mtps


As we can see, by using this work around I can significatly reduce the number of MTPs required for each call.

However I have only tested this in the lab and I am not sure if it is a supported configuration.


Would you have any concerns about using this call flow.


Thanks for your post.


Anthony

I have the same issue and after a ton of troubleshooting and config settings we found out that no matter what that software mtp's get used first. SO I defined 450 software MTP's in my gateway.. I have the same setup... I created Hardware MTP's and in the MRGL the hardware MTP's came first in in all cases we used the software MTP's first.

We also had to check use MTP on the sip trunk definition.

At this point all is well at my site but this whole MTP thing was a mess.

So I started no matter what just define the max software MTP's in the gateway.

Just my two cents

agtmcgarry Tue, 05/06/2008 - 11:45
User Badges:

Hey,

yes I also performed lots of troubleshooting and the work around above, for inbound calls, still has holes in it as it works for the first warm transfer but subsequent transfers and the agent losses cti control of the call.

Bottom line is that, for now, you need mtp checked on all sip trunks and lots of mtp resources.


Jason Aarons Mon, 06/23/2008 - 14:18
User Badges:
  • Bronze, 100 points or more

The SRND needs a MTP calculator.


We have a site with similar issue, they are getting intermittent Resource not Available errors and some poor voice quality using H323.


I guess I have do worst case 4 MTPs per call, this is a large call center, those MTPs are expensive.


Why is the MTP required? I thought MTP was for older H323v1 or devices that can't advertise ECS, etc. What would it take for Cisco to remove the MTP requirements?

pantinor Tue, 06/24/2008 - 05:28
User Badges:

Hi Anthony,


Geoff is right about your case number 4. If the agent completes the transfer to caller while still in queue, it causes the mid call media change for the voice browser on the VXML gateway, which is not something they support right now. Unforunately we have to live with this MTP situation for the time being, until they are able to support this.


You can mitigate the MTP usage by putting the CVP SIP Trunk with MTP checked, and then put the 84000! route pattern on the CVP SIP Trunk. This will allow you to only use MTP allocation on the warm transfers with queueing.

If you dont want to do it that way, then you could create a duplicate SIP Trunk to the proxy with MTP checked, and apply the 8400! route pattern to it.


A general note about MTP with the SIP Trunks which you might already know about, is that MTP can automatically be allocated if a DTMF mismatch is encountered, even if you have MTP unchecked. It will need it if it needs to convert the out of band digits to the in band rfc2833 or vice versa.


I think you should indicate the dtmf-relay on your dial peers. Why do you exclude them?


hope that helps,


Paul

Chad Stachowicz Wed, 06/25/2008 - 13:52
User Badges:
  • Silver, 250 points or more

If I were going to do this for a remote branch I would create my DSP local on my remote router. Now in CM the phones, they are in a device pool.


This device pool has a media resource group list.


Under the media resource group list is a list of media resource groups.


Under this media resource group you define the remote branch MTP Resources. Now define this DP to the SIP Trunk and The phones at the branch and you should be good to go on local MTP.


BR 1 Phone

-> DP_RemoteSite1

->MRGL_RemoteSite1

->MRG_RemoteSite1

-> HW Voice Gateway DSP

SIP TRUNK

-> DP_RemoteSite1

->MRGL_RemoteSite1

->MRG_RemoteSite1

-> HW Voice Gateway DSP



Check MTP Required..



HTH,


Chad

pantinor Fri, 06/27/2008 - 05:51
User Badges:

Its up to you how much MTP you think the call volume can deal with. If you want MTP on all the calls, then Chad's configuration is fine. Otherwise, you can set up 2 trunks (to destination CVP or CUPS) one with MTP required and one without (both on your same dp/mrgl). Put the VRU label route pattern on the MTP trunk for the outgoing calls. And then you have all the inbound calls avoiding MTP allocation. I know its a crappy workaround but we have to live with it for now.

Thanks to pantinor for advice on having two SIP trunks from CUCM to the SIP Proxy. I did exactly that - MTP required on one and that has the pattern for the VRU label on the CUCM routing client for the warm transfer. This worked better than I thought - though I'm still trying to figure out why. Not only are MTPs not used on normal calls, I am not seeing any MTP usage at all on the Call Manager MTPs - monitored using RTMT - during warm transfers.


With the previous configuration with a single SIP trunk to the CUPS I could see the media being tracked back to the head office from the branch router - using "show voip rtp connections". Now I don't see that on normal calls, as expected. But neither do I see it when MTPs are used on the SIP warm transfer.


I do have a MRGL on this with a MRG that contains MOH media resources set up for multicast MOH from the gateways, and although that does not work with SIP, perhaps the MOH resource on the gateway is being used for SIP warm transfers.


I need to look at this further - but at this stage I cannot see any MTPs on CUCM subscribers being used nor can I see the RTP being sent down from the branch to the head office from the gateway. It's working better than I expected - but I don't know why.


As Lewis Carroll wrote - "curiouser and curiouser".


Regards,

Geoff

pantinor Tue, 07/01/2008 - 11:22
User Badges:

hey Geoff,


Thats great you are not seeing MTP allocation, but you really should be seeing it for warm xfer with **queuing**.


The key is if you do a warm transfer with no queuing (ie no vru label + corr id) then you wont have the second call out from the trunk to cvp. You will only see the SIP reinvite to the caller on the transfer completion. The MTP outbound call is only made when EAPIM VRU label is routed out the trunk to CVP, ie the outbound call.


Are you monitoring the RTMT tool peformance counters for real time MTP usage, on all your nodes?


BTW, I am still trying to understand what it is about SIP and IVR (Symposium voice browser) on the gateway, because evidently H323 can handle this call flow without MTP. I think there is something about the H323 protocol handling in the gateway that allows them to move the RTP from agent1 to the caller when the agent completes while still in queue.


Thanks,


Paul

Thanks for getting back Paul.


Agreed - I should be seeing the MTP used. I was looking at all MTPs on the cluster - all nodes, all MTPs.


I do have some MTPs for RSVP configured as DSPs on the gateway. These may be being used.


I do the warm transfer and dump the call off to the queue, and while it's queued and I'm hearing music from my CVP wav files, I looked at "debug voip rtp packet" and the only IP address I see is the gateway.


Lines like:



433066: Jul 2 01:15:07 UTC: RTP(30008): fs rx s=10.101.254.97(18606), d=10.101.254.97(17684), pt=0, ts=58ECC09E, ssrc=2376FE61


.97 is the gateway.


Regards,

Geoff



pantinor Tue, 07/01/2008 - 13:07
User Badges:

one more thing.


Can you grab logs on the VXML gateway with these traces:


debug ccsip messages

debug voip rtp packet


It will allow you to see the SIP mid call media renegotiations


Do this with low traffic as its a hog and will impact performance on gw.


It could help your tracking of the RTP.

Jason Aarons Tue, 07/01/2008 - 17:59
User Badges:
  • Bronze, 100 points or more

From a knowledgeable co-worker;


"CVP has nothing to do with being able to place a caller on hold. It is true that CVP was once coded such that is required a CallManager MTP resource to do warm transfers from one agent to another, but that was resolved with 4.0(2) ES1. As long as that is applied, there is no need for an MTP on the gatekeeper trunks in UCM, and these should NOT have the MTP option checked.

For all intents and purposes, once a caller is connected to an Agent, that call is between the IOS gateway and the IP Phone, and any MTP or MOH resources are entirely within that realm."


Trying to find a bug id or release notes about 4.0(2)ES1


pantinor Wed, 07/02/2008 - 08:22
User Badges:

Geoff,


I just retested this in the lab and forgot one important configuration that is required.


You need to create an alternate SIP Trunk Security Profile, apart from the default one "non secure sip securty profile". Use all the same settings as the default one, just change the Listen Port to something else, like 5065.


Now on your second trunk that has the MTP, apply this security profile, and reset it.


Thats all.


The reason for this is because you cannot create 2 duplicate sip trunks in CUCM with the same host/ip and listen port.


Again, you are never using this trunk for inbound calls, so you never need to make a static route from CUPS/CVP to port 5065 for example. Just use 5060 that is associated on the other non-MTP trunk.


Also, if you are going to have other DNs for the IP originated callers, not the warm transfer with queuing calls, then use the non-MTP trunk on that route pattern.


thanks,


Paul



pantinor Wed, 07/02/2008 - 09:57
User Badges:

I mean yes, you can create them, but underneath, Call Mgr will only register one of them. Probably the one that you created last.

Jason Aarons Wed, 07/02/2008 - 08:54
User Badges:
  • Bronze, 100 points or more

So with the 4.x ES I referenced is MTP required with h323 trunks? We want to remove MTP checkbox for CVP/ICM.

Actions

This Discussion