[cisco-voip] CallManager ICT and IPCC Express transfer issues

[Ryan Ratliff]

Inline in red below...

-Ryan

On Oct 1, 2008, at 8:48 AM, Tim Smith wrote:

Hi Ryan,

Thanks for the response!

 From what I can see IPCC Express is answering, checking time of day,  
and then transferring.
I can see the CTI port answer, and then it tries the transfer. Does  
that rule out faststart?
Faststart is only applicable to the H.323 call leg.  What this  
indicates is that media will be set up to the CTI port and if the  
codec to be used is g.729 then a hardware transcoder is required.
It is CCM 4.1(3) - will it attempt fast start outbound, even if that  
is not setup in the trunk configuration?  No
If the call comes from a remote 6.1(2) cluster into the 4.1(3) and  
then to the IPCC express, is that actually considered an inbound or  
outbound call on the ICT? I was thinking inbound. Outbound on the 6.1  
cluster, inbound on 4.1.

In terms of resources and codec, plenty of resources, codecs are ok.  
How specifically are your codecs "ok"?
There is only usually 1 call in progress using resources when I was  
testing.

The strange part is that the results are inconsistent.
I unchecked MTP required on the 4.1 trunk. I got 2 succesful calls  
and then the third, fourth, fifth failed.  Are all of these calls up  
at the same time or are you dropping the current call before  
proceeding to the next one?
After a reset, I get the same results. A couple of succesful and then  
failures. (this behaviour is consistent)

When I check MTP required all calls seem to be succesful.
They never actually use an MTP though (RTMT and traces, confirm that  
SW MTP is never invoked)
The hardware XCODER is invoked instead. (It is first in the MRGL for  
the CTI Port, but it is after the SW MTP's on the ICT MRGL)
As I mentioned before it is the device that requires the MTP whose  
MRGL is used.  When you tick "MTP required" then the ICT's MRGL will  
be used.  If not and CUCM determines a transcoder is required because  
of incompatible capabilities then it will be the device that does not  
support the required codec who's MRGL will be used, in this case the  
CTI port.
Does CCM consider an MTP and HW XCODER equivalent?  They can provide  
some of the same functionality but an MTP can support only one  
codec.  In the case of a software MTP this is g.711.  A software MTP  
will never be allocated for a g.729 call.  To actually transcode, ie  
convert one codec to another, a transcoder is required.

Without MTP Required. I get the failures.
Why would MTP required make a difference? Especially since we dont  
think it actually requires an MTP for what it is doing?
If you are setting up g.729 RTP to IPCC configured for g.711 then you  
will always require a transcoder.

Cheers,

Tim.

On Thu, Sep 25, 2008 at 7:54 PM, Ryan Ratliff <rratliff at cisco.com>  
wrote:
Quick and dirty response to your questions...
Correct - should not require an MTP
Most often MTP is required for early media (h323 faststart).  With  
CUCM we can do inbound faststart without MTP but for outbound we do  
require one.  In this case if IPCC did not set up any audio (ie  
redirect without ever answering the call) then the xcoder should not  
be required, assuming the far-end H.323 gateway supports g.729.
You have a G.729 trunk that is going to be talking to a G.711 only  
IPCC.  You require a hardware transcoder, not MTP.
As expected, see above.
The resources come from the device that doesn't support the required  
codec.  In this case CUCM is trying to use G.729 for the call.  The  
calling device's caps will get sent to the 4.1 CUCM by the 6.1  
server.  If for some reason the calling device did not support G.729  
you'd see the 6.1 CUCM allocating an xcoder.  On the 4.1 side if the  
called party is IPCC then it does not support G.729 so it will look  
at the CTI port's MRGL to allocate an xcoder.
Many, many times :)
Remember a hardware MTP can act as an MTP (in most cases)  but an MTP  
cannot do any transcoding (except between variants of the same codec).
To see why the call is failing you need to look at the xcoder.  Is it  
out of resources?  Is it not configured to support the particular  
variant CUCM is asking it to use?

-Ryan

On Sep 25, 2008, at 5:28 AM, Tim Smith wrote:

Hi Guys,

Apologies for the length of this, difficult to give a simple  
overview, as there are lots of components and factors at play.
I havent posted the traces, debugs etc, as there is too many :) -  
trying to narrow down the exact theory first!
I suspect a bug.. I am trying to narrow down where exactly still.
I have found some pretty close bugs - but I am not sure they should  
apply - bug desc is a bit light on.

Quick and dirty overview

Site A - CUCM 6.1(2) (call this local)
Site B - CCM 4.1(3)sr3a (call this the remote)
Site B - IPCC Express also (G711) 4.0(4)SR1
Site B - Voice Gateway - H323 IOS gateway (ISR router)
Site B - Xcoder + Conf Bridge - SCCP on IOS GW (ISR) - no HW MTP
Site B - Software MTP on CCM

ICT between Site A and Site B
ICT is configured properly in terms of CCM group, CCM IP's, MRGL's.
MTP required is not ticked at either end.

Problem

Call flow looks like this:
Local IP phone > CUCM 6.1(2) > ICT (G729) > CCM 4.1(3) > IPCC Express  
 > redirected to mobile phone via 3800 IOS H323 Gateway (12.4(9)T1)

Translation pattern in Site A - translates called party to CTI RP  
number in Site B (Across the ICT)
CTI RP goes to IPCC Express application - for simplicity the test app  
uses a re-direct to an external number (my mobile)
Have tested with an agent, and it works fine. It is to the external  
number that is a problem.
Call is routed to H323 gateway
Call rings on my mobile number. Either I answer within about 2 rings  
and then I get fast busy at both ends
Or I dont answer and again within about 2 rings it stops ringing my  
mobile and I get fast busy at the calling phone
Q931 shows a "Temp fail" or sometimes possibly a "Resource  
Unvailable" I saw Temp fail on most of my attempts.

On a failed call I see an SCCP setup request on the xcoder gateway -  
it fails (does not setup either leg of the xcode session)
In the setup I see the local IP address, but no remote IP address  
(0.0.0.0)
Also in the debugs I see an RTP and RTCP error (no packet received)

Wierd things

Not all calls fail - I have received some succesful calls (using the  
same flow as above) - not many though.
I usually have a couple of succesful calls after an ICT reset (on the  
remote Site B)
Normal phone to phone calls are perfectly fine.. never have a problem.
Normal calls to IPCC express that invoke transcoder, and end up at an  
agent in Site B are fine.. never had a problem.

Couple of things I wanted to confirm really:
Normal CCM to CCM via ICT does not require an MTP resource? (never  
used on in the past)
With the IPCC express app - docco states MTP is required if the CTI  
RP has first party control of the call. Since the script answers on  
the CTI port first. Is this true? should it always require MTP? (I  
have to dig up this reference again)
I never trust RTMT completely. But looking at it, it does not seem to  
be using a software MTP for any of the calls across the trunk, even  
though MTP required is ticked.
I also checked the CCM traces - i see the call, I dont see it ask for  
MTP, I do see it ask for xcoder though.
Where should the Media Resources be allocated from? (From the IPCC  
Express MRGL? or the ICT MRGL?)
Anyone seen anything like this?
My next steps..

Probably a TAC case for one! :)
The PSTN gateway has been rebooted.. want to try and see what happens  
without MTP required now.. just for giggles.
Also wanted to try a hardware MTP - From design perspective - if an  
MTP is required - we should use HW so it can XCODE as well, and not  
invoke 2 x media resources!
Cheers,

Tim





_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20081001/a6ed7f71/attachment-0001.html>