<div>Hi Roger</div><div> </div><div>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.</div>
<div> </div><div>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.</div>
<div> </div><div>Looks like I need to try your suggestion of multiple trunks per CLI requirement / department.</div><div> </div><div>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?</div>
<div> </div><div>Regards</div><div> </div><div>Nick</div><div><br><br> </div><div class="gmail_quote">On 14 December 2011 15:45, 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">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>
<div><div class="h5"><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 Verizon<br>
> needs to see the call coming from a number within the range assigned to 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 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 to<br>
> be configured from the CUCM or CUBE and how can this be done?<br>
><br>
> Cheers<br>
><br>
> Nick<br>
><br>
><br>
</div></div>> _______________________________________________<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>
</blockquote></div><br>