Verizon IP Trunking

[cdemaret]

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.

Thanks,

Charles

[greemewat]

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?

Thanks

[cdemaret]

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.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/6_1_4/cucm-rel_note-614.html#wp854592

-Charles

[greemewat]

Thanks for your reply.

Ah yes should have said - I've got CUCM 7.1.3.10000-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?

Thanks

[cdemaret]

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.

-Charles

[Jorge F]

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

address-hiding

dtmf-interworking rtp-nte

allow-connections sip to sip

fax protocol cisco

sip

  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

description OUTBOUND CALLS FROM CUBE TO PSTN (NGN VERIZON)

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:10.130.132.24:5080

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]

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: <442030000000> (real number is one of our DDI's assigned to SIP Trunk for inbound routing)

And the From field set to: From:

Thanks,

Peter

[john.kensmoe]

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]

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]

Charles,

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]

Brent,

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

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

[Kelly McCoy]

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]

Charles,

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

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,

Pat.

[kdotten36]

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: <>4105551212@company.globalipcom.com>"

request INVITE sip-header Diversion modify "<>" "<>4105551212@company.globalipcom.com>"

Hope that helps someone!

[dmitry]

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

Received:

INVITE sip:+15556661212@xxx.xxx.xxx.143;user=phone SIP/2.0

Via: SIP/2.0/UDP xxx.xxx.xxx.140:5060;branch=z9hG4bK135397667

Call-ID: 490546034@xxx.xxx.xxx.140

CSeq: 1 INVITE

From: "user_001" <>user_001@ring2.com>;tag=2359100369135397665

To: sip:+15556661212@xxx.xxx.xxx.143;user=phone

Contact: sip:user_001@xxx.xxx.xxx.140:5060

User-Agent: Alcatel-Lucent 8460 ACS 8.5.0b5703

Max-Forwards: 70

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

P-Asserted-Identity: <>

Allow-Events: edial-service-info

Supported: timer

X-owner-phone: true

Remote-Party-ID: "user_001" <>

Allow: ACK,BYE,CANCEL,INFO,REFER,MESSAGE,INVITE,NOTIFY

Content-Length: 208

Content-type: application/sdp

v=0

o=user_001 2359100369135397665 1 IN IP4 xxx.xxx.xxx.140

s=phone-call

c=IN IP4 xxx.xxx.xxx.140

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:63.79.178.193:5060

dtmf-relay rtp-nte

codec g711ulaw

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

INVITE sip:+15556661212@63.79.178.193:5060 SIP/2.0

Via: SIP/2.0/UDP  xxx.xxx.xxx.143:5060;branch=z9hG4bK1A1FD015E

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

To: <>

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

Call-ID: FF28CA98-9CC11E1-BA4ED7B2-8FB098E5@xxx.xxx.xxx.143

Supported: 100rel,timer,replaces

Min-SE:  1800

Cisco-Guid: 4280823408-164368865-3125598130-2410715365

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

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER

CSeq: 101 INVITE

Max-Forwards: 70

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

Timestamp: 1320817585

Contact: <>

Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 274

v=0

o=CiscoSystemsSIP-GW-UserAgent 2697 8709 IN IP4 xxx.xxx.xxx.143

s=SIP Call

c=IN IP4 xxx.xxx.xxx.143

t=0 0

m=audio 17446 RTP/AVP 0 101 19

c=IN IP4 xxx.xxx.xxx.143

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

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!