<div>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.</div>
<div> </div><div>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.</div>
<div> </div><div><br><br> </div><div class="gmail_quote">On 15 December 2011 22:50, Roger Wiklund <span dir="ltr"><<a href="mailto:roger.wiklund@gmail.com">roger.wiklund@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
Even if you only have sites in UK, if you have alot of them, you would<br>
benefit from using multiple SIP-trunks. I don't know if long distance<br>
exists in UK, if so, you can use TEHO very easily. And of course EM<br>
that I mentioned before.<br>
<br>
As Verizon identifies on CLI, they also apply emergency number,<br>
billing etc based on the location, so in the case of TEHO you need to<br>
ensure you present the correct CLI to jump out via the correct place.<br>
<br>
With CM 8.6 you can manipulate Diversion with transformation CSS on<br>
the SIP trunk. With 8.5 you have to use SIP Normalization script.<br>
<span class="HOEnZb"><font color="#888888"><br>
/Roger<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Dec 15, 2011 at 11:42 PM, Roger Wiklund <<a href="mailto:roger.wiklund@gmail.com">roger.wiklund@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> Yeah you need to put it on the SIP-trunk. Device pool or on the phone<br>
> will only work on incoming if I'm not mistaken.<br>
><br>
> You can accomplish the same stuff but on the CUBE.<br>
><br>
> Just setup dial-peers matching on your internal number and change it<br>
> in the CUBE before sending it to Verizon.<br>
><br>
> dial-peer voice 100 voip<br>
> desc To/From CUCM London<br>
> translation-profile incoming <lnd_internal_to_real_cli><br>
> translation-profile outgoing <lnd_real_to_internal_cli><br>
> answer-address <your_internal_cli_here><br>
> destination-pattern <real_cli_here><br>
> session-target ipv4:cucm_ip<br>
><br>
> So on an outbound call from internal ext 44016666 for example, you<br>
> ensure that on the dial-peer you have answer-address 440166.. or<br>
> something<br>
> then you can apply your incoming translation profile and change<br>
> 44016666 to the real Verizon number.<br>
><br>
> On an incoming call you do the same. On your dial-peer 100 you have<br>
> destination-pattern real_cli_range, and then you apply the outgoing<br>
> rule to change that to your 44016666.<br>
><br>
> Then you have your main DP to Verizon.<br>
><br>
> dial-peer voice 200 voip<br>
> desc To Verizon<br>
> destination-pattern .T<br>
><br>
> If you are using extension mobility you cannot use this setup, because<br>
> when the call hits the CUBE you cannot determine if its a regular user<br>
> at "home" or a roaming user. And thus you cannot change a DE user<br>
> roaming in UK to the UK switchboard number, because you have no<br>
> indication he is roaming.<br>
><br>
> For example, when the UK user is at "home" his internal number<br>
> 440112345 should translate to 44xxxxxxxxx12345. When this user is<br>
> roaming and is in DE, he will be on the DE phone and this using the DE<br>
> dial-plan. When he calls out he should present the DE switchboard<br>
> number.<br>
><br>
> There is no way for you to know in the CUBE if he is roaming or nto.<br>
><br>
> You need to do that in the CM, with multiple SIP trunks to the same CUBE<br>
><br>
> /Roger<br>
><br>
> On Thu, Dec 15, 2011 at 10:04 PM, Nick <<a href="mailto:csvoip@googlemail.com">csvoip@googlemail.com</a>> wrote:<br>
>> Hi Roger<br>
>><br>
>> Thanks very much for your reply, in this solution we are only in one<br>
>> country, UK and we have a lareg number of remote sites also in the UK, the<br>
>> main site has a varied DDI range that will be ported into the solution so we<br>
>> may need to provide different CLI requirements for different parts of the<br>
>> business all from the same site.<br>
>><br>
>> I tried the Calling Party Transformation CSS and applied this to both Device<br>
>> Pool and Phones, however neither of these worked, the only way I could get<br>
>> the Transformation to work was if it was applied to the SIP Trunk, but this<br>
>> will not suit my CLI requirements.<br>
>><br>
>> Looks like I need to try your suggestion of multiple trunks per CLI<br>
>> requirement / department.<br>
>><br>
>> Its is just the port on the SIP trunk security profie that needs t change,<br>
>> the port on the SIP trunk is 5060, I take is that stays the same?<br>
>><br>
>> Regards<br>
>><br>
>> Nick<br>
>><br>
>><br>
>><br>
>> On 14 December 2011 15:45, Roger Wiklund <<a href="mailto:roger.wiklund@gmail.com">roger.wiklund@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Nick.<br>
>>><br>
>>> Some stuff to know about the Verizon SIP trunk.<br>
>>><br>
>>> They auth calls on CLI and IP.<br>
>>><br>
>>> So if you have your assigned range I.E 44XXXXXXXXX0 - 44XXXXXXXXX9,<br>
>>> you need to send that number in the exact format you have requested.<br>
>>> If it does not match you get a 604 back from them.<br>
>>><br>
>>> The IP address in the INVITE must also match. This should be your CUBE<br>
>>> IP, if it does not match, 604 back.<br>
>>><br>
>>> To support stuff like originating CLI on call forward etc you can use<br>
>>> different headers. They authenticate in this order:<br>
>>><br>
>>> 1. Diversion<br>
>>> 2. Remote-Party-ID<br>
>>> 3. P-Asserted-ID<br>
>>> 4. FROM<br>
>>><br>
>>> If you read Ciscos SRND for 8.x you will find they always setup just<br>
>>> one single trunk from the CM to a CUBE. This setup will work just fine<br>
>>> if you have a couple of sites in just the same country.<br>
>>><br>
>>> However, often you just have one SIP trunk to your MPLS cloud serving<br>
>>> multiple countries, that's part of the reason you move away from local<br>
>>> PRIs also.<br>
>>><br>
>>> However the configuration style of local gatways is still a must IMO.<br>
>>> With a local gateway for each site you have full control PER<br>
>>> site/gateway on called/calling party transformation. Also with 8.6<br>
>>> diversion transformation.<br>
>>><br>
>>> With this setup you can easally change your internal CLI to the real<br>
>>> CLI and authenticate the call by using calling party transformation<br>
>>> CSS on the GW.<br>
>>><br>
>>> This also fits nice in line with LRG. Also if you have extension<br>
>>> mobility and a user is roaming from lets say UK to DE, you can put a<br>
>>> catch all called-party transformation and change it to the switchboard<br>
>>> number of the DE site. That way you authenticate the call and you get<br>
>>> the correct billing etc.<br>
>>><br>
>>> The problem here is setting up new SIP trunks on the CM. From Verizon<br>
>>> to you CUBE you only have one SIP trunk, but from the CUBE to CM<br>
>>> cluster you have multiple. They way you can setup new SIP-trunks for<br>
>>> each site/country is to change the SIP Security profile and increment<br>
>>> the SIP port.<br>
>>><br>
>>> Example: Site1: 5070, Site2: 5071 etc<br>
>>> This is only between the CM and the CUBE. this config allows you to<br>
>>> setup a new SIP trunk to your CUBE with the exact same IP etc but a<br>
>>> different port.<br>
>>><br>
>>> on the CUBE you need a new dial-peer for each site:<br>
>>><br>
>>> Ex:<br>
>>><br>
>>> dial-peer voice 100 voip<br>
>>> desc UK numbers<br>
>>> destination-pattern 44............<br>
>>> session-target ipv4:cucm-ip:5070<br>
>>><br>
>>> dial-peer voice 110 voip<br>
>>> desc DE numbers<br>
>>> destination-pattern 49............<br>
>>> session-target ipv4:cucm-ip:50701<br>
>>><br>
>>><br>
>>> For incoming calls I usually setup translation-patterns to match on<br>
>>> the real number ranges, then just change it to the internal<br>
>>> extensions.<br>
>>><br>
>>> If you want to have private number you can prepend *67 on the CALLED<br>
>>> number before sending to Verizon. You can also put Calling Line ID<br>
>>> Presentation - Restricted on the route-pattern, just be sure to<br>
>>> activate RPID or PAI sending on the trunk, because then your FROM<br>
>>> field will be anonymous@anonymous, but the RPID or PAI will contain<br>
>>> your number and can authenticate on that.<br>
>>><br>
>>> Basically when you have the old H323 gateway style config in the CM,<br>
>>> using SIP trunks instead and with different ports, you can apply all<br>
>>> your known config with LRG, calling/called transformation, TEHO, AAR,<br>
>>> E164 globalization/normalization etc.<br>
>>><br>
>>> With just one single SIP-trunk serving all sites in different<br>
>>> countries, you are super limited.<br>
>>><br>
>>> /Roger<br>
>>><br>
>>><br>
>>><br>
>>> On Wed, Dec 14, 2011 at 3:31 PM, Nick <<a href="mailto:csvoip@googlemail.com">csvoip@googlemail.com</a>> wrote:<br>
>>> > Hi, I am just deploying Verizon SIP trunks now with CUCM 8.6.2a, as<br>
>>> > Verizon<br>
>>> > needs to see the call coming from a number within the range assigned to<br>
>>> > the<br>
>>> > trunks in the format 44XXXXXXXXXX, I would like to know the best way to<br>
>>> > achieve this, in this situation I need most users to have CLI blocked to<br>
>>> > the<br>
>>> > called party, however I have a number of users that need to be able to<br>
>>> > display a CLI which could be different for a number of departments.<br>
>>> ><br>
>>> > I am using device mobility and standard local route groups, is this best<br>
>>> > to<br>
>>> > be configured from the CUCM or CUBE and how can this be done?<br>
>>> ><br>
>>> > Cheers<br>
>>> ><br>
>>> > Nick<br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > cisco-voip mailing list<br>
>>> > <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>>> > <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
>>> ><br>
>><br>
>><br>
</div></div></blockquote></div><br>