Verizon IP Trunking

Unanswered Question
Jan 28th, 2010

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.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (1 ratings)
greemewat Tue, 03/02/2010 - 12:08

Hi there,

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" or .

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?


cdemaret Tue, 03/02/2010 - 14:04

What version of CUCM are you running?

You need to enable the outbound diversion header delivery on the SIP Trunk configuration in CUCM.

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

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.

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}


greemewat Wed, 03/03/2010 - 00:03

Thanks for your reply.

Ah yes should have said - I've got CUCM

I tried checking the Redirecting Diversion Header Delivery - Outbound but it did not seem to improve things - is that what you are talking about?


cdemaret Thu, 03/04/2010 - 08:02

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.


JORGE FERNANDEZ... Thu, 07/19/2012 - 03:03

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


dtmf-interworking rtp-nte

allow-connections sip to sip

fax protocol cisco


  bind control source-interface FastEthernet0/0

  bind media source-interface FastEthernet0/0

  header-passing error-passthru

  midcall-signaling passthru

  sip-profiles 1

dial-peer voice 202 voip


translation-profile outgoing OUTBOUND_TO_VERIZON

destination-pattern 0T

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:

dtmf-relay rtp-nte

fax protocol pass-through g711ulaw

no vad

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!

Peter Cresswell Fri, 04/09/2010 - 02:56

Hi Charles,

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@ address>.

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?

I have the P-Asserted-Identity set to: P-Asserted-Identity: (real number is one of our DDI's assigned to SIP Trunk for inbound routing)
And the From field set to: From:



john.kensmoe@co... Tue, 09/28/2010 - 06:46

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.

cbelcher Mon, 11/15/2010 - 19:56

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.

bahuston1 Thu, 07/28/2011 - 14:14


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?

cdemaret Fri, 07/29/2011 - 06:41


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 ( 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: 2145551212@> <2145551212@>"

2.(apply the SIP Profiles to the outgoing dialpeer towards the Vz network)
dial-peer voice XXX
  voice-class sip profiles 100

Kelly McCoy Thu, 09/15/2011 - 14:23

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.

phampson Sat, 10/29/2011 - 05:17


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: "

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 again,


kdotten36 Fri, 06/07/2013 - 08:27

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:>"

request INVITE sip-header Diversion modify "" ">"

Hope that helps someone! Thu, 11/10/2011 - 15:41

Hi Charles,

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, I don’t have ability to modify that INVITE):


INVITE;user=phone SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK135397667



From: "user_001">;tag=2359100369135397665



User-Agent: Alcatel-Lucent 8460 ACS 8.5.0b5703

Max-Forwards: 70

P-Charging-Vector: icid-value=8165bb7afd93697f1d6433a60d767968


Allow-Events: edial-service-info

Supported: timer

X-owner-phone: true

Remote-Party-ID: "user_001"


Content-Length: 208

Content-type: application/sdp


o=user_001 2359100369135397665 1 IN IP4


c=IN IP4

t=0 0

m=audio 12026 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000/1

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

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

destination-pattern +15556661212

session protocol sipv2

session target ipv4:

dtmf-relay rtp-nte

codec g711ulaw

So the INVITE from my Cisco AS5400XM to Verizon destination ( looks like this:

INVITE sip:+15556661212@ SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK1A1FD015E

From: "user_001" ;tag=B0052C54-164A


Date: Wed, 09 Nov 2011 05:46:25 GMT


Supported: 100rel,timer,replaces

Min-SE:  1800

Cisco-Guid: 4280823408-164368865-3125598130-2410715365

User-Agent: Cisco-SIPGateway/IOS-12.x


CSeq: 101 INVITE

Max-Forwards: 70

Remote-Party-ID: "user_001" ;party=calling;screen=no;privacy=off

Timestamp: 1320817585


Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 274


o=CiscoSystemsSIP-GW-UserAgent 2697 8709 IN IP4

s=SIP Call

c=IN IP4

t=0 0

m=audio 17446 RTP/AVP 0 101 19

c=IN IP4

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000


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?   

Thanks you! Thu, 11/10/2011 - 19:51

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.

nickkassel Wed, 12/14/2011 - 06:28

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?



Eric Ingram Tue, 04/08/2014 - 15:48


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

Scenario 1:
Call goes out Cube 1 (primary for DN per Vzb) matching the port 5075 and call is good.

Scenario 2:
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.  


ALI HYDER Fri, 04/11/2014 - 09:54



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.



kdotten36 Fri, 04/11/2014 - 11:12

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.



This Discussion

Related Content