[cisco-voip] Off net to off net transfer using Verizon SIP Trunk

Bob Zanett (AM) bob.zanett at dimensiondata.com
Thu Feb 9 13:41:12 EST 2012


There you go.  You will need to validate that by allowing the SDP information out, that it does not create other side-affects.

Bob Zanett
Technical Services Architect

From: Nick [mailto:csvoip at googlemail.com]
Sent: Thursday, February 09, 2012 12:15 PM
To: Bob Zanett (AM)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Off net to off net transfer using Verizon SIP Trunk

Thanks Bob, I have just managed to fix it by adding the the following

voice service voip
 sip
  pass-thru content sdp




On 9 February 2012 17:30, Bob Zanett (AM) <bob.zanett at dimensiondata.com<mailto:bob.zanett at dimensiondata.com>> wrote:
Nick,
Run debugs on the gateway to validate that the transfer (re-invite) is getting to your gateway and how it is handling it.   If CUBE, as I recall, it can also block this being sent out.    If it is being routed out, have you validated with your provider that they support this functionality?  And additionally, do they have specific requirements around how they want to see it sent?

Cheers -
Bob Zanett
Technical Services Architect
Dimension Data Americas
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Nick
Sent: Thursday, February 09, 2012 11:26 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] Off net to off net transfer using Verizon SIP Trunk


Hi All

I have an issue when trying to complete an off net to off net transfer for calls using Verizon SIP trunking, the call arrives on the SIP and then gets transfered back out of the SIP to an external destination, I get the message cannot complete transfer on the phone and the transfered part of the call fails but the original call stays on hold.

I have got the Block offnet to offnet transfer set to False on the CUCM, so I think this is definitely the SIP trunks thats denying the call. Does anyone know which part of the SIP header may need manipulating for transfered calls, or anyne come across this scenario before?

Regards

Nick


itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120209/b0ffd33e/attachment.html>


More information about the cisco-voip mailing list