[cisco-voip] Verizon SIP Trunk CLI

Mon Dec 19 06:11:19 EST 2011

Hi, In this design we have 4 CUBES serving the main site and a large amount
of remote sites, the CUBES are split up by Verizon into logical pairs
depending on site, as we are using local route groups the issue I have is
when an extension mobility user logs in at a different site the calls will
route from that sites CUBEs which may not be the CUBES that the their
number is associated with so the call will not route.

I have added another SIP trunk from CUCM to CUBE and modified the CLI on
this trunk to be one of the numbers associated with another CUBE to test,
I then added this as a tertiary to a route group, the call will then route
but with time out delays. This is obviously not a desired option, any ideas
how we could get around this.

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

> Even if you only have sites in UK, if you have alot of them, you would
> benefit from using multiple SIP-trunks. I don't know if long distance
> exists in UK, if so, you can use TEHO very easily. And of course EM
> that I mentioned before.
>
> As Verizon identifies on CLI, they also apply emergency number,
> billing etc based on the location, so in the case of TEHO you need to
> ensure you present the correct CLI to jump out via the correct place.
>
> With CM 8.6 you can manipulate Diversion with transformation CSS on
> the SIP trunk. With 8.5 you have to use SIP Normalization script.
>
> /Roger
>
> On Thu, Dec 15, 2011 at 11:42 PM, Roger Wiklund <roger.wiklund at gmail.com>
> wrote:
> > Hi,
> >
> > Yeah you need to put it on the SIP-trunk. Device pool or on the phone
> > will only work on incoming if I'm not mistaken.
> >
> > You can accomplish the same stuff but on the CUBE.
> >
> > Just setup dial-peers matching on your internal number and change it
> > in the CUBE before sending it to Verizon.
> >
> > dial-peer voice 100 voip
> > desc To/From CUCM London
> > translation-profile incoming <lnd_internal_to_real_cli>
> > translation-profile outgoing <lnd_real_to_internal_cli>
> > answer-address <your_internal_cli_here>
> > destination-pattern <real_cli_here>
> > session-target ipv4:cucm_ip
> >
> > So on an outbound call from internal ext 44016666 for example, you
> > ensure that on the dial-peer you have answer-address 440166.. or
> > something
> > then you can apply your incoming translation profile and change
> > 44016666 to the real Verizon number.
> >
> > On an incoming call you do the same. On your dial-peer 100 you have
> > destination-pattern real_cli_range, and then you apply the outgoing
> > rule to change that to your 44016666.
> >
> > Then you have your main DP to Verizon.
> >
> > dial-peer voice 200 voip
> > desc To Verizon
> > destination-pattern .T
> >
> > If you are using extension mobility you cannot use this setup, because
> > when the call hits the CUBE you cannot determine if its a regular user
> > at "home" or a roaming user. And thus you cannot change a DE user
> > roaming in UK to the UK switchboard number, because you have no
> > indication he is roaming.
> >
> > For example, when the UK user is at "home" his internal number
> > 440112345 should translate to 44xxxxxxxxx12345. When this user is
> > roaming and is in DE, he will be on the DE phone and this using the DE
> > dial-plan. When he calls out he should present the DE switchboard
> > number.
> >
> > There is no way for you to know in the CUBE if he is roaming or nto.
> >
> > You need to do that in the CM, with multiple SIP trunks to the same CUBE
> >
> > /Roger
> >
> > On Thu, Dec 15, 2011 at 10:04 PM, Nick <csvoip at googlemail.com> wrote:
> >> 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/20111219/d704ccf9/attachment.html>