[cisco-voip] Verizon SIP Trunk CLI

[Roger Wiklund]

Hi Nick.

Some stuff to know about the Verizon SIP trunk.

They auth calls on CLI and IP.

So if you have your assigned range I.E 44XXXXXXXXX0 - 44XXXXXXXXX9,
you need to send that number in the exact format you have requested.
If it does not match you get a 604 back from them.

The IP address in the INVITE must also match. This should be your CUBE
IP, if it does not match, 604 back.

To support stuff like originating CLI on call forward etc you can use
different headers. They authenticate in this order:

1. Diversion
2. Remote-Party-ID
3. P-Asserted-ID
4. FROM

If you read Ciscos SRND for 8.x you will find they always setup just
one single trunk from the CM to a CUBE. This setup will work just fine
if you have a couple of sites in just the same country.

However, often you just have one SIP trunk to your MPLS cloud serving
multiple countries, that's part of the reason you move away from local
PRIs also.

However the configuration style of local gatways is still a must IMO.
With a local gateway for each site you have full control PER
site/gateway on called/calling party transformation. Also with 8.6
diversion transformation.

With this setup you can easally change your internal CLI to the real
CLI and authenticate the call by using calling party transformation
CSS on the GW.

This also fits nice in line with LRG. Also if you have extension
mobility and a user is roaming from lets say UK to DE, you can put a
catch all called-party transformation and change it to the switchboard
number of the DE site. That way you authenticate the call and you get
the correct billing etc.

The problem here is setting up new SIP trunks on the CM. From Verizon
to you CUBE you only have one SIP trunk, but from the CUBE to CM
cluster you have multiple. They way you can setup new SIP-trunks for
each site/country is to change the SIP Security profile and increment
the SIP port.

Example: Site1: 5070, Site2: 5071 etc
This is only between the CM and the CUBE. this config allows you to
setup a new SIP trunk to your CUBE with the exact same IP etc but a
different port.

on the CUBE you need a new dial-peer for each site:

Ex:

dial-peer voice 100 voip
desc UK numbers
destination-pattern 44............
session-target ipv4:cucm-ip:5070

dial-peer voice 110 voip
desc DE numbers
destination-pattern 49............
session-target ipv4:cucm-ip:50701


For incoming calls I usually setup translation-patterns to match on
the real number ranges, then just change it to the internal
extensions.

If you want to have private number you can prepend *67 on the CALLED
number before sending to Verizon. You can also put Calling Line ID
Presentation - Restricted on the route-pattern, just be sure to
activate RPID or PAI sending on the trunk, because then your FROM
field will be anonymous at anonymous, but the RPID or PAI will contain
your number and can authenticate on that.

Basically when you have the old H323 gateway style config in the CM,
using SIP trunks instead and with different ports, you can apply all
your known config with LRG, calling/called transformation, TEHO, AAR,
E164 globalization/normalization etc.

With just one single SIP-trunk serving all sites in different
countries, you are super limited.

/Roger



On Wed, Dec 14, 2011 at 3:31 PM, Nick <csvoip at googlemail.com> wrote:
> 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 configured from the CUCM or CUBE and how can this be done?
>
> Cheers
>
> Nick
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>