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

[Tim Smith]

Forgot 1 important detail :) (Very important actually)

On Site B - on the ICT - If I turn on MTP required.
I have success everytime. (again I dont see a SW MTP in use in RTMT though)

Cheers,

Tim.

On Thu, Sep 25, 2008 at 11:28 AM, Tim Smith <thsglobal at gmail.com> 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
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20080925/a4effa36/attachment.html>