01-28-2010 08:40 AM
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
03-02-2010 12:08 PM
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"
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
03-02-2010 02:04 PM
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
03-03-2010 12:03 AM
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
03-04-2010 08:02 AM
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
07-19-2012 03:03 AM
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!
04-09-2010 02:56 AM
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@
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?
Thanks,
Peter
09-28-2010 06:46 AM
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.
11-15-2010 07:56 PM
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.
07-28-2011 02:14 PM
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?
07-29-2011 06:41 AM
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
09-15-2011 02:23 PM
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.
10-29-2011 05:17 AM
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>"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.
06-07-2013 08:27 AM
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!
11-10-2011 03:41 PM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide