[cisco-voip] Forwarded Calls drop after 29 secs

[Jim Skelton]

Hi Joel,  I had a similar issue.  I would see our calls drop after exactly
30 seconds.  It turned out to be an issue with our carrier TimeWarner
telecom and thier Oakland SIP switch.  We repointed to thier North Carolina
SIP switch and everything cleared up.   TW is running Sonus switches.

 Our setup with twtelecom is Carrier---sip---CUBE----h323---CUCM

Hope this helps.



Jim Skelton
Halliburton




On Fri, Jan 22, 2010 at 1:13 PM, Joel Perez <tman701 at gmail.com> wrote:

> Hey Guys,
>
> I have a customer that is experiencing a weird issue.
> Currently some of their forwarded calls are failing after 29 secs. I
> believe it is only happening when the calls are forwarded to 2 specific
> carriers, but cant confirm that yet.
> I have a ticket open with the carrier so that they can take a look at the
> traces we have captured.
> The issue happens the following way. Inbound call to main company DID goes
> to an AA, if no choice is used by the caller then it goes to a live person.
> However afterhours this live person forwards their call to an offsite #.
> When that offsite # receives the forwarded call they are only able to stay
> on for 29 secs then the call dies on both ends.
>
> THe set up is as follows:
> Carrier---sip---CUBE----sip---CUCM---sccp---IPT
> CUCM is 7.0
> Unity is 7.0
> CUBE is 12.4.(20T4)
>
> I have tried capturing debugs on the CUBE but havent been able to see any
> SIP (BYE) messages from either side.
> This only happens when Unity is involved. Normal CFW doesnt have this
> problem.
>
>
> Thanks,
>
> Joel P
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


-- 
“A government big enough to give you everything you want, is
strong enough to take everything you have.” — Thomas Jefferson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100122/1d614340/attachment.html>