[cisco-voip] InterCluster Disconnects

[Wes Sisk]

hold/unhold triggers h.245 communication over the ICT to redirect the 
media.  If this is failing in your script it will likely fail for users 
performing hold, park, conference, and transfer as well.  You may have 
worked around it in the script but the underlying problem is still 
present.  Most likely h.245 TCP communication between the clusters is 
being interrupted.

/Wes

On Wednesday, November 18, 2009 7:17:17 PM, Jim Reed 
<jreed at swiftnews.com> wrote:
> *Just as an FYI in case this issue should affect someone else or they 
> have seen it previously, in an exchange between Anthony Holloway and 
> myself on this issue, he pointed me towards turning on the ENG trace 
> in IPCC.  This lead to the suspicion that it was the Call Hold or Call 
> Unhold steps that were possibly causing the issue for the calls across 
> the intercluster trunk.  Instead of placing the calls in queue on 
> hold, running a thirty (30) second delay during which hold music 
> played, then taking the calls off hold and playing a prompt that 
> allowed the caller to continue to hold or press 1 to leave a message, 
> I replaced the Call Hold step with thirty (30) seconds of music via a 
> prompt set to be interruptible and removed the Call Unhold step 
> completely.  Unfortunately, it was near the end of the day and I could 
> not run as many tests as I would have liked.  After hours calls go 
> directly to voicemail if the caller doesn't know the extension of the 
> person they're trying to contact.  I will test in earnest tomorrow 
> morning and if I can get forty (40) to fifty (50) consecutive calls 
> without a failure, I think it will definitely point a finger at 
> something to do with placing a call on hold that goes across an 
> intercluster trunk.  But, playing the devils advocate, I won't say 
> that's the problem right now until I get those forty (40) or fifty 
> (50) consecutive, successful calls.  If anyone has any thoughts along 
> this line, would greatly appreciate hearing them.
>
> Thank You...
> **--
> Jim Reed
> Technology Wrangler
> Swift Communications, Inc.
> 970-683-5646 (Direct)
> 775-772-7666 (Cell)
>
> /"Not only is it not right.
> It's not even wrong."
> /        The Pauli Proverb
>         Wolfgang Pauli
> *
>
> On 11/17/09 6:10 PM, "Alex Hannah" <alex.hannah at gmail.com> wrote:
>
>     Gather and post the MIVRlogs located at C:\prog
>     files\wfavvid\logs\MIVR on the cluster you are having problems
>     with.  MAKE certain you have a time date and pref an ext that
>     called so myself or others can parse the logs.  Out of curiosity
>     where are your transcoders located?  What codec goes across the trunk?
>
>     Sent from my iPhone
>
>     On Nov 17, 2009, at 7:19 PM, Jim Reed <_jreed at swiftnews.com_> wrote:
>
>         *I will do my best to explain this as clearly as possible.
>          Please advise if additional information is needed.
>
>         We have two (2) separate VoIP systems that communicate via
>         intercluster trunks across an MPLS WAN.  For purposes of this
>         discussion, we'll call them System GPC and System CMNM.
>          System GPC is 4.5-Meg MPLS and system CMNM is 9-Meg MPLS.
>
>         When the contact center number is dialed on System GPC, the
>         calls are forwarded to an extension (aka route point) on
>         System CMNM that puts the caller into the contact center script.
>
>         The caller hears the initial recording with no problem.  That
>         recording instructs the caller to press 2 for option A; press
>         3 for option B; press 4 for option C; etc. etc.
>
>         On somewhat frequent occasions, when the caller makes their
>         selection, the call is disconnected.
>
>         This does not happen on calls that are placed to numbers
>         associated directly with System CMNM.
>
>         System CMNM has a toll free number associated with the contact
>         center.  When I forward the calls from System GPC to that toll
>         free number instead of the route point on System CMNM, there
>         are no disconnects.
>
>         I have reset the intercluster trunks between the two systems.
>          When I look at the call statistics in the router(s), they
>         show the code for normal call clearing.
>
>         Anyone got any thoughts on why the selection of the CSQ option
>         in the script is causing that disconnect?
>
>         I have looked at the T1 controller stats and the serial
>         interface stats associated with that PRI controller and there
>         are no errors.  System GPC has no calling issues locally for
>         calls that come in on those same PRI channels.
>
>         Thank You...
>         **--
>         Jim Reed
>         Technology Wrangler
>         Swift Communications, Inc.
>         970-683-5646 (Direct)
>         775-772-7666 (Cell)
>
>         /"Not only is it not right.
>         It's not even wrong."
>         /        The Pauli Proverb
>                 Wolfgang Pauli
>         *
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20091119/f2d30992/attachment.html>