[cisco-voip] Verizon SIP Trunk CLI

[Nick]

Hi Roger

Thanks very much for your reply, in this solution we are only in one
country, UK and we have a lareg number of remote sites also in the UK, the
main site has a varied DDI range that will be ported into the solution so
we may need to provide different CLI requirements for different parts of
the business all from the same site.

I tried the Calling Party Transformation CSS and applied this to both
Device Pool and Phones, however neither of these worked, the only way I
could get the Transformation to work was if it was applied to the SIP
Trunk, but this will not suit my CLI requirements.

Looks like I need to try your suggestion of multiple trunks per CLI
requirement / department.

Its is just the port on the SIP trunk security profie that needs t change,
the port on the SIP trunk is 5060, I take is that stays the same?

Regards

Nick



On 14 December 2011 15:45, Roger Wiklund <roger.wiklund at gmail.com> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20111215/2cce396a/attachment.html>