- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2013 09:45 PM - edited 03-16-2019 03:41 PM
I have read so many articles on how to fix this and none resolve my situation. The problem is we recently started to send local traffic to a SIP trunk using Verizon services. When we did that we noticed that any calls forwarded from IP Phones or from the IVR fail. In the debug we see the diversion header is the 4 digit number of the phone or the IVR port.
I opened a ticket with Verizon and they stated the Diversion header info was wrong. When I fixed that on my CUBE calls continue to fail. I opened a case with TAC and they stated it is NOT possible to forward calls to Verizon SIP trunk and maintain the calling party number. I keep reading everywhere how people have successfully did this and I'm confused on how they all have gotten it to work when TAC states it is not possible. Perhaps I'm not reading the articles correctly.
We run UCM 7.1.3 and the CUBE is 12.4(20)T4
Person A calls Person B and person B has their phone forwarded to Person C. I need Person C to see the caller ID of person A. I was under the assumption I could do this by adding this on my cube:
voice service voip
sip
sip-profiles 1
voice class sip-profiles 1
request INVITE sip-header Diversion modify "<sip:(.*)@(.*)>" "<sip:8306265600@**verizon address**>"
When I do that the calls do in fact change the diversion header but continue to fail. I have read that by changing the diversion message Verizon uses the diversion field to authenticate the call so the original caller id remains intact.
Has ANYONE really gotten this to work as described above using Verizon as the provider? I'd love to speak directly or through here on the matter.
Solved! Go to Solution.
- Labels:
-
Unified Communications
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2013 11:05 PM
Hi,
I work for Verizon in the UK and we use the Verizon sip trunk solution. And yes diversion works for us. We use sip profiles to authenticate as well.
From the was you have described your sip profile config, looks like its not correctly configured. The @***address***** should address if your cube, cos call is coming from the cube.
Can you send me full debug ccsip messages, the calling and called number.
Sent from Cisco Technical Support Android App
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2013 11:05 PM
Hi,
I work for Verizon in the UK and we use the Verizon sip trunk solution. And yes diversion works for us. We use sip profiles to authenticate as well.
From the was you have described your sip profile config, looks like its not correctly configured. The @***address***** should address if your cube, cos call is coming from the cube.
Can you send me full debug ccsip messages, the calling and called number.
Sent from Cisco Technical Support Android App
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-13-2013 05:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-13-2013 06:11 AM
I believe we got the issue resolved. I added the cube IP to the diversion modify command and it started working.
THank you Aokanlawon!!
