[cisco-voip] Verizon SIP Trunk CLI

Mon Dec 19 08:33:46 EST 2011

On Mon, Dec 19, 2011 at 12:11 PM, Nick <csvoip at googlemail.com> wrote:
> 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.

When your EM user logs in to a different site, it will use that sites
CUBE to dial out. What you need to do here is to apply a calling
number transformation pattern on that specific SIP trunk on the
Callmanager.

Basically a catch all rule that modifys the calling number to the main
number of that site.

Here is our setup:

UK SIP Trunk in CM:

Match internal directory number UK site phones, keep the last 4 digits
and prepend the real number to authenticate with Verizon
Match * replace entire number with UK site switchboard number

DE SIP Trunk in CM:
Match internal directory number of DE site phones, keep last 4 digits
and prepend the real numer to authenticate with Verizon
Match * replace with entire number with DE site switchboard number

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

If you do it like that you are using TEHO. Even if its within UK.
Example: Site A is in London, Site B is Manchester.

If your London user logs in to Manchester site, and you want him to
still authenticate on his London number, then you are invoking TEHO.
because its not only authentication, its also that this user is
applied with London billing, london dial-plan etc.

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