I am starting this discussion area to help answer any questions related to Verizon's IP Trunking services for Cisco VoIP products.
I work with the Verizon engieering teams to help with Interop issues between Cisco and Verizon's VoIP network.
Please feel free to ask any questions related to design, implementation, and trobleshooting a Cisco deployment using Vz IP Trunking.
Found the solution by upgrading IOS to 124-22.YB8 that supports
voice class sip-profiles xxx
request INVITE sip-header Remote-Party-ID modify "screen=no" "screen=yes"
Applied this to the dial-peer - works fine now.
Hi, I am just deploying Verizon SIP trunks now with CUCM 8.6.2a, as Verizon needs to see the call coming from a number within the range assigned to the trunks in the format 44XXXXXXXXXX, I would like to know the best way to achieve this, in this situation I need most users to have CLI blocked to the called party, however I have a number of users that need to be able to display a CLI which could be different for a number of departments.
I am using device mobility and standard local route groups, is this best to be done from the CUCM or CUBE and how cn this be done?
My issue I believe is related to Verizon provisioning. So we have two cubes, one in each data center with SIP trunks to Verizon respectively.
Data center 1 Cube 1 x.x.x.101 Vzb provisioned to port 5075
Data center 2 Cube 2 x.x.x.102 Vzb provisioned to port 5076
Call goes out Cube 1 (primary for DN per Vzb) matching the port 5075 and call is good.
Force call to go Cube 2 using css with RL to Cube 2 and call fails using port 5076. Vzb says DN is provisioned to use 5075 and can we send port 5075.
How can we accomplish this or should the port for each SRV be the same from a Verizon provisioning? We have 6000 numbers and I don't see how we can configure all these number to use different ports. Adding dial-peers for each number does not scale.
Hopefully I explained this to make sense. Any help is much appreciated.
We are running into an issue with fail-over SIP connection to Verizon. We have a distributed SIP connection model with each remote site having its own Cube connecting to Verizon. In case the remote site Cube fails, the SME which is at our central site routes outbound calls over the Corp Cube that connects to Verizon. We recently experienced a real outage at the remote site and discovered that Outbound calls that we sent over to the Corp Cube were being rejected by Verizon with a 408 request timeout error. Verizon is saying that we are missing diversion header that's why the call is being rejected. Inbound calls worked fine.
My question is do I need to create a SIP profile and add diversion header for 1500 DID numbers to be able to make outbound calls over the Corp SIP gateway? I thought diversion header is for call forwarding, and in our case we are not forwarding the call but rather sending out over the backup trunk.
This is probably happening because the two sites have different circuits. When using SIP, Verizon will reject any call that does not originate from a number that belongs on that circuit, hence why your rerouted calls are blocked.
The diversion header is basically spoofing a number that belongs there in the header while still allowing you to send whatever you wanted to send with your outbound mask.
You can use it for all outbound calls, but be sure to have Unscreened ANI enabled by Verizon as well.
How did you fix your issue? I have a similar issue 100+ sites with 9000 DIDs going through single centralized CUBE to Verizon SIP. Customers wants to send out ANI which is not a part of Verizon DID range. Verizon has enabled unscreened ANI (STN). Question is can we fix ths with single SIP profile diversion header? I am trying to avoid per site dial peer which is not a scalable solution
Any help would be much appreciated!
I'm a few years removed from this issue and no longer a Verizon customer but you shouldn't need per site dialpeers. The diversion header would pass all outbound calls to Verizon using a number local to that site regardless from where they originate. The Unscreened ANI feature then permits the mask applied in your voice network (i.e. CUCM) to replace that local number without rejecting the call. So for example, you'd have a global outbound dialpeer for each site, looking something like this...
dial-peer voice 100 voip
description Outgoing Calls to Verizon Trunk
voice-class sip profiles 1
#other requirements specific to your environment
The sip profile inserted in the dialpeer is configured like so...
voice class sip-profiles 1
request INVITE sip-header Diversion add "Diversion:<sip:firstname.lastname@example.org>"
...where 2025551212 is a local number assigned to that site's circuit (preferably not a user's number), and the fqdn is whatever Verizon has established (for our circuit, it was company.globalipcom.com)
If you're also receiving calls to remote sites (i.e. user co-locates with Extension Mobility) you might need to modify the diversion header on your incoming dialpeer...
voice class sip-profiles 2
request INVITE sip-header Diversion modify "<sip:(.*)@(.*)>" "<sip:email@example.com>"
Reference that on the inbound dialpeer by adding "voice class sip-profiles 2"
You'd copy that to the next site, replacing 2025551212 with whatever number is local to that one, and so on. Just make sure you know the fqdn of each site if it's different.
That's two global dialpeers that covers outgoing and inbound calls for each site. Again, I've since left Verizon and went to a provider without such strict requirements (TW Telecom, now Level 3), so there may be something I'm overlooking or their process may have slightly changed in the past few years, but no better way to find out than to give it a try!
Thanks for your detailed response! In the first line you said you shoudln't need per site dialpeers but then your example indicates that we need sip profile and dial peer per site specifying the STN in the diversion header allocated by Verizon for that site? Problem is I have 107 sites going through a single CUBE (pretty crazy I know) so creating 107 sip profiles and dialpeers would be a nightmare on a single CUBE.
We tested with single sip profile as mentioned in your first example and it worked fine initially but then we were seeing some of the calls getting rejected by Verizon. It seemed like there was a ceiling on Verizon side that they would not allow more than x amount of calls from a single STN. Customer asked us to un-do the change but we will test again with Verizon in the next change window!
You may need to contact Verizon to check what the concurrent call or burst is configured for the voip location associated w/ the STN. If you are using a STN from a VoIP location that has a limit of 50 calls as an example, all calls that use that particular STN will count against that limit.
I see. I didn't realize you were funneling all sites through a single CUBE. I thought you were positioning each CUBE for failover, so I meant you didn't need a dialpeer for Site A, Site B, and Site C to make outbound calls through Site Z's CUBE, just a single global outbound peer as you implemented and tested. As for volume, I can't speak for that. Probably something Verizon has in place for security purposes, but since you have a legitimate need, maybe they can remove it.
Alternatively, you could create a group of ten dialpeers to split it up, using a different local number for each peer and sip profile. So instead of a global argument .T, you could match 2......... , 3........ , 4......... , and so on, or define a separate prefixed code for each site, so if your outside access code is 9, you could tell CUCM to prefix NY calls with 1, Kansas with 2, Los Angeles with 3, then create dialpeers 19 29 39. Even if you have a ton of sites, it's not much work from a configuration perspective since you can copy and paste it in Notepad, it just looks ugly to have a hundred dialpeers from a management point of view.
You can use a single STN in the diversion header for all sites. But one thing to be aware of is that Verizon may bill all calls w/ this diversion header to the VoIP location associated to the STN.
You may also need to consider whether your environment will have off-net redirects and if there is a requirements to convey the proper redirect # in the diversion header.
You may also want to check what your E911 requirements are as well. Normally customers use STN's from the voip location that has the same physical location as the person making the call so that when the PSAP gets the call the proper physical address shows up.
I just have a question about VoIP.
We have Cisco Network equipment. We are looking at getting off of our PBX system and moving to VoIP. Is there a way to configure Verizon VoIP, or any other VoIP system, work with the Voice VLAN feature on Cisco switches? I am obviously inexperienced with setting this up. I helped managed an existing Cisco VoIP system where I used to work, and would like to know if it is possible to use other VoIP products in a similar way?