Call Forward external via Carrier SIP trunks Issue

[BrokenRecord2]

We have carrier SIP trunks at a few of our locations and we are unable to call forward external when going out carrier SIP. We beleive its because the CLID doesn't match the SIP number so the carrier doesn't allow the call to pass.

My questions is does anyone no of a way to have the SIP invite or redirect request to display the SIP trunk CLID so it will allow the call to go through?

Already Checked:
CFXA
Trunk to trunk
CLID table
NRS with a valid E164 format #

Thanks for the help in advance!

 

[NortelGuy1979]

Can you post your SIP DCH capture? Also, a SIPCallTrace would be useful (from the SS).

Matthew - Technical Support Engineer Sr.

http://www.linkedin.com/in/matty79

 

[bizkitchris]

We have the same problem and also we can't blind transfer. Avaya has nailed it down to say yes its definitly the mis-match of the CLID buts its also a SIP packet header issue.

Who is your SIP carrier? Ours is Sprint.

The carriers will tell you not to do it, but an SBC of your own should give you the ability resolve the issue by changing the packets to new calls versus transfers/forwards.

 

[BrokenRecord2]

bizkitchris

We are using Sprint they told us to not use our own SBCs and we also have the blind transfer issue. Did you end up installing and SBC? How long have you had your issue? Was there ever any resolution via Avaya or Sprint? Both of them are pointing fingers at each other.

Thanks!

 

[NortelGuy1979]

There's technical notes with R7.0 (for example) and VZ Business SIP trunking - the CS1K won't sent a REFER; rather, it sends another INVITE. You need to have an SBC to change it to a REFER. See this doc (if the URL resolves):

https://support.avaya.com/css/P8/documents/100129565

If it doesn't, look up:
Application notes for Verizon Business IP Trunking and 1800 inbound communication services System with Avaya™ Communication Server 1000 release 7.0

Having an on-site SBC is a good thing, IMHO.

Matthew - Technical Support Engineer Sr.

http://www.linkedin.com/in/matty79

 

[M1spezi]

I have had the same problem on Rel 6.0. I get a new VTRK SU and it´s working now

Meridian, Callpilot, CCM (Symposium) from Germany

 

[AELMAN]

Has anyone found a solution, we are on Rls 6.0 and we cannot forward to Callpilot CDN over SIP trunks callers get dead air. Avaya and Verizon have been working on this for almost three months now. any help would be greatly appreciated

 

[HUGWideBoy]

AELMAN

I had a dead air issue over SIP trunks this weekend after a rls 5 to rls 7 upgrade.

fixed it by changing the media security setting on the IPTI trunks from MSBT to MSNV

 

[BrokenRecord2]

We have got Sprint to fix the forwarding issue but not the blind transfer issue. The problem with the forwarding issue is that when you have you phone call forwarded the PBX sends the 4 digit extension as the calling number. The problem with that is that the security of the SIP trunk provider won't accept a call from an out of network number i.e. 4 digits. Sprint had to create an HMR on the SBC that would change the number to something they recognize.

I believe the true fix is that Avaya needs to change the way they send out the CLID from 4 digits to what is programmed in the CLID table.

 

[M1spezi]

In Rel 6.0 nortel-cs1000-vtrk-6.00.18.65-89.i386.000 fixed the problem.

Meridian, Callpilot, CCM (Symposium) from Germany

 

[AELMAN]

Changing MSBT to MSNV on the IPTI trunks did not do the JOB, I am also thinking it is a SBC problem.Still trying to get this fixed

 

[AELMAN]

Problem resolved

ANALYSIS : After analyzing the sniffer and SIP Debug traces, what we could understand is proper SDP negotiation is not happening over Verizon SIP trunks.
The INVITE that is coming over Verizon SIP Trunks to CS1k,does not have “100 rel” in SUPPORTED and “UPDATE” in ALLOW header of the SIP INVITE.
So, ideally in this case 183 should be forked multiple times from the CS1k over the SIP trunk. This is required to keep updating the latest DSP resources used for playing the greeting to the user. But, because PI Patch 29422 is enabled ,183 with updated DSP information is not sent.