[cisco-voip] Verizon SIP Trunk CLI

[Roger Wiklund]

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