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

Tim Smith thsglobal at gmail.com
Wed Oct 1 08:48:37 EDT 2008


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?
It is CCM 4.1(3) - will it attempt fast start outbound, even if that is not
setup in the trunk configuration?
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.

In terms of resources and codec, plenty of resources, codecs are 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.
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)
Does CCM consider an MTP and HW XCODER equivalent?

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?

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...
>
>    1. Correct - should not require an MTP
>    2. 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.
>    3. 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.
>    4. As expected, see above.
>    5. 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.
>    6. 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:*
>
>    1. Normal CCM to CCM via ICT does not require an MTP resource? (never
>    used on in the past)
>    2. 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)
>     3. 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.
>    4. 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.
>    5. Where should the Media Resources be allocated from? (From the IPCC
>    Express MRGL? or the ICT MRGL?)
>    6. Anyone seen anything like this?
>
> *My next steps..*
> **
>
>    1. Probably a TAC case for one! :)
>    2. The PSTN gateway has been rebooted.. want to try and see what
>    happens without MTP required now.. just for giggles.
>    3. 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/62e89c48/attachment-0001.html>


More information about the cisco-voip mailing list