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.
We have a VzB IP Trunk.
One issue I have come across is when an inbound call is placed to a IP handset that is set to CFA to a PSTN or mobile number back out the IP Trunk and the callers CLI is witheld or private.
This results in INVITE messages to the VzB network with the FROM field looking like "Anonymous"
The VzB trunk uses the outbound CLI to authenticate the call and so the calls were rejected with a 604 Does not exist anywhere error.
I resolved the issue using SIP normalisation profiles on the CUBE to modify the P-Asserted-Identity on the outbound dial-peer that points to the VzB trunk.
The however messed up our outbound emergency call CLI presentation but this was solved by creating new RL in CUCM and additional dial-peers on the CUBE.
Is this something you have come across and I'm wondering if this was the best solution to the problem?
What version of CUCM are you running?
You need to enable the outbound diversion header delivery on the SIP Trunk configuration in CUCM.
Starting with CUCM Release 6.1(4) adds the Redirected Dialed Number Identification Service (RDNIS) and diversion header capability for certain calls that use the Cisco Unified Mobility Mobile Connect feature.
Thanks for your reply.
Ah yes should have said - I've got CUCM 22.214.171.12400-11.
I tried checking the Redirecting Diversion Header Delivery - Outbound but it did not seem to improve things - is that what you are talking about?
Yes the Redirecting Diversion Header Delivery - Outbound needs to be checked on the SIP trunk configuration in CUCM.
Are you certain that you are sending PAI?
Can you get a wireshark trace of what is being sent from your CUBE to the VzB network?
This should show you what is actually being sent.
If PAI is not being sent then there maybe a CUBE configuration problem.
If you are sending the appropriate PAI with the diversion header, then this maybe a porblem witht he VzB VoIP provisioning.
We have this working in our lab.
Just a heads up regarding this 604 error.
Just experienced that a day ago and it had to be with our caller ID presentation.
After spending hours debugging SIP traces to spot the problem I found out that it all was a missing digit on our Caller ID due to a bad copy paste, so Verizon was rejecting all calls due to wrong caller ID (main or header DID).
So watch out for the way you guys present your IDs out there so that the SP can recognize and "authenticate" your call.
My working config is:
voice service voip
allow-connections sip to sip
fax protocol cisco
bind control source-interface FastEthernet0/0
bind media source-interface FastEthernet0/0
dial-peer voice 202 voip
description OUTBOUND CALLS FROM CUBE TO PSTN (NGN VERIZON)
translation-profile outgoing OUTBOUND_TO_VERIZON
modem passthrough nse codec g711ulaw
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip dtmf-relay force rtp-nte
voice-class sip early-offer forced
session protocol sipv2
session target ipv4:10.130.132.24:5080
fax protocol pass-through g711ulaw
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
Also Verizon requested us to add a leading 34 as the country prefix to the caller ID, i'm unaware of whether this is usually a requirement to all VZ SIP Trunk customers, so we stuck that prefix via a voice translation rule at the ISR, otherwise we get another 604.
Hope this helps!
I am trying to send an outbound call over a Verizon SIP trunk and hide the CLI. I have been told that I need to send the P-Asserted-Identity field with a number of a DDI that is assigned to the SIP Trunk (presumably to 'authenticate' the call), and set the From field to anonymous@
We also wish to test sending a different CLI that on outbound calls (one that is not part of the DID block) using this method.
Unfortunately it doesn't seem to be working, and the called party received the CLI as the number we have inserted in the P-Asserted-Identity field. I am using SIP Profiles on CUBE to set these fields.
Do you have any ideas what we are doing wrong?
Hello, last year we did a large deployment using the Verizon SIP service and for the most part it's been a success. Currently Verizon has us running IOS ver 12.4.20 and we're running into some apparent bugs with SRST (phones won't register to the router after a period of time). We are now going to push forward with another large Vz SIP implementation and I'd like to know what is the latest and greatest IOS version that is "certified" for use within Verizon's SIP environment.
We're being prodded to use 124-20.T5. Is that as good as it gets?
Any help would be appreciated.
We are just about to turn up or Verizon SIP Trunks and was wondering if you could post a generic CUBE config? CUBE is running a nice new 2921!
Thanks in advance.
I have Verizon SIP trunking with CUCM 6.1.2 and CUBE 12.4(22)T. When an inbound call from the PSTN calls to an internal phone with the call forwarding set to an external number, the originating number is blocked as it is not a Verizon DID on the VZ SIP trunk.
What is the best way to allow the originating PSTN phone number to be displayed to the phone that is receiving the call forwarded call?
It's currently displaying the phones DID that is set for call forwarding, but our users want to see the originating phone number.
I changed the "Calling Party Selection" in the trunk under Outbound calls to Originator, but that is when the number started being rejected as the originating number was sent to Verizon who rejected the call.
Verizon stated using Diversion Headers in CUBE will work, can you confirm that?
The best way to handle forwarded calls from CUCM back out to the Vz IP trunk service is by utilizing Diversion Headers in the CUBE router.
On the CUBE we can add the SIP Diversion header by adding the following configuration to the router config.
1.(add sip-profile) Here you will need to replace the phone number(2145551212) with the customer billing TN. Next you will need to change the IP address (10.10.10.10) with the VZ facing IP address or FQDN that the network is expecting.
voice class sip-profiles 100
request INVITE sip-header Diversion add "Diversion: <>>email@example.com)> <firstname.lastname@example.org)>"
2.(apply the SIP Profiles to the outgoing dialpeer towards the Vz network)
dial-peer voice XXX
voice-class sip profiles 100
We port numerous DIDs from all different NPA and NXXs from around the country into our CUBEs using Verizon SIP. We have a unique P-Asserted ID for each number we port so when we send a call outbound to a specifc number range we set a different PAI depending on what number was dialed. This can result in having to create hundreds of outbound dial-peers paired up with hundreds of voice-class sip-profiles to set the correct PAI. I would much rather prefer to just create a single outbound dial-peer, create a single voice-class sip-profile and then create all my PAI modifications under that profile to match the PAI based on what is in the "To" field in the SIP INVITE or REFER message. I have not found a way to do this yet in CUBE. Any ideas??
Basically, "if the number dialed is XXXXXXXXXX then set the PAI to YYYYYYYYYY" with out creating a unique dial-peer for each.
Thanks for the posts. Just a comment. I had to modify your example as below to get Verizon to take the diversion header. Once it was in, it works like a charm and is very appreciated.
request INVITE sip-header Diversion add "Diversion: <2145551212>"2145551212>
I believe it was the right parentheses in your example that was causing my diversion header to be ignored. They didn't complain about it with your format, it just didn't affect the call and would not allow me to set the caller ID (which appears to be set with the P-Asserted Identity field).
Thanks for the post with edit, that worked for my scenario as well. Oddly enough, it wouldn't work with the IP address though, we had to use the FQDN from verizon.
Although after adding the Diversion header you provided, we were still getting rejections on calls that were being forwarded as well as external numbers on Mobility Connect devices. I had to add another line in the sip profile, so that it looks like this...
voice class sip-profiles #
request INVITE sip-header Diversion add "Diversion: <>>email@example.com>"
request INVITE sip-header Diversion modify "<>" "<>>>firstname.lastname@example.org>"
Hope that helps someone!
Is there a way to modify "screen=no" to "screen=yes" in Remote-Party-ID on the Cisco AS5400XM gateway for either specific dial peer or as a global setting?
I’m running Cisco AS5400XM IOS version c5400-is-mz.124-7g.bin.
I receive the following SIP Invite from the remote SIP media/proxy (IP address of the origin is xxx.xxx.xxx.140, I don’t have ability to modify that INVITE):
INVITE sip:+email@example.com;user=phone SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.140:5060;branch=z9hG4bK135397667
CSeq: 1 INVITE
From: "user_001" <>>firstname.lastname@example.org>;tag=2359100369135397665
User-Agent: Alcatel-Lucent 8460 ACS 8.5.0b5703
Remote-Party-ID: "user_001" <>>
o=user_001 2359100369135397665 1 IN IP4 xxx.xxx.xxx.140
c=IN IP4 xxx.xxx.xxx.140
m=audio 12026 RTP/AVP 0 101
Then I use the following dial peer on AS5400XM to translate and forward this INVITE as follows:
dial-peer voice 8999 voip
description Verizon Testing
session protocol sipv2
session target ipv4:126.96.36.199:5060
So the INVITE from my Cisco AS5400XM to Verizon destination (188.8.131.52:5060) looks like this:
INVITE sip:+email@example.com:5060 SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.143:5060;branch=z9hG4bK1A1FD015E
From: "user_001" <>;tag=B0052C54-164A>
Date: Wed, 09 Nov 2011 05:46:25 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
CSeq: 101 INVITE
Remote-Party-ID: "user_001" <>;party=calling;screen=no;privacy=off>
o=CiscoSystemsSIP-GW-UserAgent 2697 8709 IN IP4 xxx.xxx.xxx.143
c=IN IP4 xxx.xxx.xxx.143
m=audio 17446 RTP/AVP 0 101 19
c=IN IP4 xxx.xxx.xxx.143
Everything works out, besides the field
Remote-Party-ID: "user_001" <>;party=calling;screen=no;privacy=off>
Instead of that, according to Verizon - I need to send:
Remote-Party-ID: "user_001" <>;party=calling;screen=yes;privacy=off>
Only difference is I’m sending "screen=no", but I need to send "screen=yes"
Is there a way to modify "screen=no" to "screen=yes" on the gateway itself for either specific dial peer or as a global setting?
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.