[cisco-voip] Separate cluster for third party SIP clients with SIP/ICT trunk to production

Wed Oct 2 10:18:20 EDT 2019

Actually I don't know that it doesn't exist, I was just saying I had not
heard of it before.  I am curious if it is, and no one has addressed it yet.

Also, I realize I have a type on this line:

*National Pattern strips + prefixes *#*02 and routes to SIP trunk
(*#*13055551212) *

It should include the two-digit prefix

*National Pattern strips + prefixes *#*02 and routes to SIP trunk
(*#*0213055551212) *

On Wed, Oct 2, 2019 at 9:07 AM Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

> Thanks for this great information Anthony. Back to work after a few days
> off…
>
>
>
>
>
> As for my harping on the CSS mapping feature, you know, it could have just
> been me making that up in my mind. Although, when I think of it, it could
> be a PBX feature that exists (ROLM -> HICOM) over digital trunks that I
> asked about 15 years ago and faintly recall that it was a feature that
> would be available. Maybe just wishful thinking. Darn.
>
>
>
> I really like your solution for CSS mapping though, using translations. I
> think with a little bit of thought, that could be easily implemented in our
> scenario.
>
>
>
> I was also thinking of extending the solution on the remote cluster such
> that there are two partitions, TPS_Dialable_PT and TPS_NonDialable_PT, and
> the community has the decision to have their third party endpoints be
> dialable or not.
>
>
>
>
>
> ---
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 | lelio at uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
>
> *From:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Sent:* Sunday, September 29, 2019 4:17 PM
> *To:* Lelio Fulgenzi <lelio at uoguelph.ca>
> *Cc:* Kent Roberts <kent at fredf.org>; cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] Separate cluster for third party SIP clients
> with SIP/ICT trunk to production
>
>
>
> What is this pass and map CSS info thing you've mentioned twice now?
> That's not something I've ever heard of.  Have you seen that done before,
> or maybe read it somewhere?  I know here are times where more data can be
> transmitted over a SIP/ICT trunk; like in GeoLocation or Anti Tromboning,
> but I've just never heard of this with CSS/Partitions.
>
>
>
> Let's just say it's not possible for sake of argument.  Then, you could
> pass a prefix to the called number, and using translation patterns on the
> terminating cluster, you could switch the CSS.
>
>
>
> E.g., On Net Remote Cluster
>
>
>
> Originating Cluster
>
> Phone CSS is Whatever
>
> Phone dials On Net Pattern e.g., 4000
>
> On Net Pattern prefixes *#*00 and routes to SIP trunk (*#*004000)
>
>
>
> Terminating Cluster
>
> CSS on SIP trunk matches *#*00.! xlate
>
> Xlate strips *#*00 and sets CSS to On Net (4000)
>
> Correct pattern now gets matched as if phone was local to this cluster
>
>
>
> E.g., Local
>
>
>
> Originating Cluster
>
> Phone CSS is Local
>
> Phone dials Local Pattern e.g., \+16125551212
>
> Local Pattern strips + and prefixes *#*01 and routes to SIP trunk
> (*#*0116125551212)
>
>
>
> Terminating Cluster
>
> CSS on SIP trunk matches *#*01.! xlate
>
> Xlate strips *#*01, adds plus, and sets CSS to Local (+16125551212)
>
> Correct pattern now gets matched as if phone was local to this cluster
>
>
>
> E.g., National
>
>
>
> Originating Cluster
>
> Phone CSS is National
>
> Phone dials National Pattern e.g., \+13055551212
>
> National Pattern strips + prefixes *#*02 and routes to SIP trunk
> (*#*13055551212)
>
>
>
> Terminating Cluster
>
> CSS on SIP trunk matches *#*02.! xlate
>
> Xlate strips *#*02, adds plus, and sets CSS to National (+13055551212)
>
> Correct pattern now gets matched as if phone was local to this cluster
>
>
>
> And I think that illustrates the point, barring any typos I might have
> made.
>
>
>
> You would then be able to support 100 CSS mappings with this model..
> Choose a prefix which makes sense for you, but if the SIP CSS on the
> terminating Cluster only can access prefixed patterns, then it could
> literally be anything you want.
>
>
>
> On the topic of the BE6K, just like others have stated, it's the same
> level of effort as "normal" CUCM...because it is a normal CUCM.  A BE6KS is
> too, for what that's worth, however a BE4K is completely different and
> cloud managed like a meraki device.  You might find that the implementation
> of the BE6K is easier for two reasons: 1) Your expectations for it to
> perform for you are lower than your production cluster, 2) Managing the
> VMware side of it might be easier because it's more of an appliance, and
> less of a datacenter object. (E.g., no UCS manager, and no vCenter
> requirements).
>
>
>
> On the topic of just looking at this as a "good idea" I do think that it
> is a good idea.  In fact, this idea is very similar to what UCCE
> deployments are typically like, where the entire UCCE environment gets its
> own  CUCM cluster, separate from the non- Contact Center users and
> devices.  Or how you might have an entire VCS/Expressway cluster for
> registering your video devices.  Or heck, what's starting to become popular
> and cloud register all of your video devices, so you can get rid of
> on-premise telepresence all together.  I think this plan of yours falls
> right inline with those other scenarios.
>
>
>
> On Sat, Sep 28, 2019 at 7:25 PM Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>
>
>
> I don’t see it being needed in this case. Just two clusters. All off-perm
> resources (if required) would be routed through the main cluster. That
> being said, I’m not up to speed on what the session managers give you. But
> I’d like to avoid additional components.
>
>
>
> I envision the simplest of configs. Two partitions. One CSS. (Maybe more
> if there’s a way to pass and map css information across trunks.) one route
> pattern for offnet calls. One route pattern for extensions on the main
> cluster.
>
>
>
>
>
> *-sent from mobile device-*
>
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent at fredf.org> wrote:
>
> So no session manager?  Or is that in the mix as well?
>
>
>
> Kent
>
>
>
> On Sep 28, 2019, at 16:50, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>
> 
>
>
>
> Yup. That’s the plan. I was just wondering if be6k was more “user
> friendly” with fewer configurable options. More like a key system or
> something.
>
>
>
> It’s looking more and more like just another cluster. I may even consider
> recommending we “outsource” that.
>
> *-sent from mobile device-*
>
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith at enject.com.au> wrote:
>
> What version are you running?
>
> Should be able to just spin up a new cluster and point it at same ELM /
> PLM / Smart Licensing account I think?
>
> Share/pool your licensing
>
>
>
> Cheers,
>
>
>
> Tim
>
>
>
> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Sunday, 29 September 2019 8:07 AM
> *To:* Jeremy Bresley <brez at brezworks.com>
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] Separate cluster for third party SIP clients
> with SIP/ICT trunk to production
>
>
>
>
>
> The primary goal for the separate cluster would be to remove all
> networking restrictions. SIP devices could (attempt to) register from any
> on-premise network.
>
>
>
> Secondary goal would be to be ready for a cloud service migration.
>
> *-sent from mobile device-*
>
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez at brezworks.com> wrote:
>
> BE6K is exactly the same software, just a different way to buy bundled
> hardware and Cisco/Vmware licensing.  You have the opportunity when you buy
> the hardware to get a discounted package of 35 UCL/CUWL standard/CUWL
> Meetings licenses.
>
> Ordering guide has more information:
>
> https://www.cisco.com/c/en/us/products/collateral/unified-communications/business-edition-6000/guide-c07-739442.html?dtid=osscdc000283
>
> Is your goal of a separate cluster that it's going to be managed under a
> separate administrative domain, or to restrict calls to/from certain
> devices?
>
> Jeremy
>
> On 9/28/2019 5:46 PM, Lelio Fulgenzi wrote:
>
>
>
> I was thinking about the possibility of spinning up a separate cluster for
> third party SIP device registration and then setting up a trunk (either SIP
> or ICT) to the production.
>
>
>
> Is BE6000 any “simpler” than a full fledged CUCM install? Or is it the
> exact same?
>
>
>
> Does ICT (still) allow for CSS mapping per device? So whatever CSS it had
> on one cluster, it will be mapped to the other?
>
>
>
> I want to be able to offer up third party sip registration, but without
> having to open up access to the production cluster.
>
>
>
> This would be namely devices used by other departments for security, etc.
>
>
>
> Benefit of this second cluster would be if we do decide to migrate calling
> to the cloud, we’d maintain the small cluster and build a route path to the
> cloud via whatever option is available.
>
>
>
> Thoughts?
>
> *-sent from mobile device-*
>
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip at puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> 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/20191002/14228f41/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1297 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191002/14228f41/attachment.png>