Mailing List Archive

Separate cluster for third party SIP clients with SIP/ICT trunk to production
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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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 <x-apple-data-detectors://1/0>
>
> 519-824-4120 Ext. 56354 <tel:519-824-4120;56354> | lelio@uoguelph.ca
> <mailto:lelio@uoguelph.ca>
>
> www.uoguelph.ca/ccs <http://www.uoguelph.ca/ccs> | @UofGCCS on
> Instagram, Twitter and Facebook
>
> University of Guelph Cornerstone with Improve Life tagline
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]



_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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@puck.nether.net> On Behalf Of Lelio Fulgenzi
Sent: Sunday, 29 September 2019 8:07 AM
To: Jeremy Bresley <brez@brezworks.com>
Cc: cisco-voip@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]



_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@enject.com.au<mailto:tim.smith@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@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Sunday, 29 September 2019 8:07 AM
To: Jeremy Bresley <brez@brezworks.com<mailto:brez@brezworks.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]



_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
So no session manager? Or is that in the mix as well?


Kent

> On Sep 28, 2019, at 16:50, Lelio Fulgenzi <lelio@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 | lelio@uoguelph.ca
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>> On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@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@puck.nether.net> On Behalf Of Lelio Fulgenzi
>> Sent: Sunday, 29 September 2019 8:07 AM
>> To: Jeremy Bresley <brez@brezworks.com>
>> Cc: cisco-voip@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 | lelio@uoguelph.ca
>>
>> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>>
>>
>>
>> On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@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 | lelio@uoguelph.ca
>>
>> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>>
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent@fredf.org<mailto:kent@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@uoguelph.ca<mailto:lelio@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@enject.com.au<mailto:tim.smith@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@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Sunday, 29 September 2019 8:07 AM
To: Jeremy Bresley <brez@brezworks.com<mailto:brez@brezworks.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]



_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent@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@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@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@puck.nether.net> *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Sunday, 29 September 2019 8:07 AM
> *To:* Jeremy Bresley <brez@brezworks.com>
> *Cc:* cisco-voip@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
> On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Anthony Holloway <avholloway+cisco-voip@gmail.com>
Sent: Sunday, September 29, 2019 4:17 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca>
Cc: Kent Roberts <kent@fredf.org>; cisco-voip@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook


On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent@fredf.org<mailto:kent@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook


On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@enject.com.au<mailto:tim.smith@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@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Sunday, 29 September 2019 8:07 AM
To: Jeremy Bresley <brez@brezworks.com<mailto:brez@brezworks.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook


On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
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@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@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@gmail.com>
> *Sent:* Sunday, September 29, 2019 4:17 PM
> *To:* Lelio Fulgenzi <lelio@uoguelph.ca>
> *Cc:* Kent Roberts <kent@fredf.org>; cisco-voip@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@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent@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@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@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@puck.nether.net> *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Sunday, 29 September 2019 8:07 AM
> *To:* Jeremy Bresley <brez@brezworks.com>
> *Cc:* cisco-voip@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@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@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
Good info, we’re actually looking at having to do this ourselves to maintain support for an application that doesn’t support TAPI/API past where we are on 11.5, so that we can move the rest of the customers off to 12.5+.

I am also looking at third party SIP device support here but because of the above and a prior incident with a low-security third party device, I’m looking to tackle this a bit differently. Currently working on a service agreement type thing with my customers, which would also restrict the networks these devices can be placed on so they are not on public networks, etc.

I’m stuck on HA capabilities for these third party clients, as a lot of them only support a single proxy/registrar address. Will the UCM accept registration to any of the nodes in the pool to be able to use a DNS round robin? Has anyone looked at SIP registration proxy with an Expressway cluster for this? The interworking may be better, but, you’re still having to set up routing rules and that on the Expressway – and I think this is a different license class for “room systems” unless it doesn’t count when you proxy through Expressway, but I am pretty sure you can do DNS RR on an Expressway C cluster and it would work fine there.

Sorry to hijack this thread, just a point of interest.

Adam


From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Lelio Fulgenzi
Sent: Wednesday, October 2, 2019 10:07 AM
To: Anthony Holloway <avholloway+cisco-voip@gmail.com>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Separate cluster for third party SIP clients with SIP/ICT trunk to production

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@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway+cisco-voip@gmail.com>>
Sent: Sunday, September 29, 2019 4:17 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>
Cc: Kent Roberts <kent@fredf.org<mailto:kent@fredf.org>>; cisco-voip@puck.nether.net<mailto:cisco-voip@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent@fredf.org<mailto:kent@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@enject.com.au<mailto:tim.smith@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@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Sunday, 29 September 2019 8:07 AM
To: Jeremy Bresley <brez@brezworks.com<mailto:brez@brezworks.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook




_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
Not hijacking at all… very good points.

I was thinking about the HA availability (HAA?) on these third party SIP devices as well. From what I recall, they only have one spot to enter the registrar.

I too, would think about the Expressway as the registrar – but I have much less experience with Expressway’s dial plan than CUCM’s dial plan.

The other benefit with sticking with a CUCM cluster is, I’m hoping, that it would be easier to route calls from Webex Calling registered devices (via a border xyZ?).

You also talk about network restrictions – that’s a possibility too. It would, however, require a new TPS (third party SIP device) VLAN for every switch stack we have out there. Quite a bit of work, and it doesn’t allow for “instant” access when they buy the devices without asking us. ????

Again – not a hijack, good thread addition.


---
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@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Pawlowski, Adam <ajp26@buffalo.edu>
Sent: Wednesday, October 2, 2019 10:24 AM
To: Lelio Fulgenzi <lelio@uoguelph.ca>; Anthony Holloway <avholloway+cisco-voip@gmail.com>
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Separate cluster for third party SIP clients with SIP/ICT trunk to production

Good info, we’re actually looking at having to do this ourselves to maintain support for an application that doesn’t support TAPI/API past where we are on 11.5, so that we can move the rest of the customers off to 12.5+.

I am also looking at third party SIP device support here but because of the above and a prior incident with a low-security third party device, I’m looking to tackle this a bit differently. Currently working on a service agreement type thing with my customers, which would also restrict the networks these devices can be placed on so they are not on public networks, etc.

I’m stuck on HA capabilities for these third party clients, as a lot of them only support a single proxy/registrar address. Will the UCM accept registration to any of the nodes in the pool to be able to use a DNS round robin? Has anyone looked at SIP registration proxy with an Expressway cluster for this? The interworking may be better, but, you’re still having to set up routing rules and that on the Expressway – and I think this is a different license class for “room systems” unless it doesn’t count when you proxy through Expressway, but I am pretty sure you can do DNS RR on an Expressway C cluster and it would work fine there.

Sorry to hijack this thread, just a point of interest.

Adam


From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Wednesday, October 2, 2019 10:07 AM
To: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway+cisco-voip@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Separate cluster for third party SIP clients with SIP/ICT trunk to production

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@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway+cisco-voip@gmail.com>>
Sent: Sunday, September 29, 2019 4:17 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>
Cc: Kent Roberts <kent@fredf.org<mailto:kent@fredf.org>>; cisco-voip@puck.nether.net<mailto:cisco-voip@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent@fredf.org<mailto:kent@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@enject.com.au<mailto:tim.smith@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@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Sunday, 29 September 2019 8:07 AM
To: Jeremy Bresley <brez@brezworks.com<mailto:brez@brezworks.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook




_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Separate cluster for third party SIP clients with SIP/ICT trunk to production [ In reply to ]
Ah, so we have some internal VLANs that dispense only private address space, which can be used for printers and dummy devices. The fight with that in the past, was that we did not have the internet call proxy available with Expressway, so third party video systems couldn’t do anything video related and they all wanted to call external URIs and IPs.

These VLANs work great for internal only items, but can also quickly become a cesspool of unpatched devices all trying to “discover” each other – presenting other problems.

It doesn’t really matter that much other than we have a ton of public IP space, and prior to recent border changes you could buy a generic endpoint, get creds from us, and then get hacked (or not change the default password). Sure they can’t register but if they can cause the endpoint to dial (or conference) they can pump traffic. Happened with us.

Of course now that I’ve built all of that no one wants room systems any more.

Regarding routing in, I’m not sure how that would work as I assume you’re going to have the same SIP domain for all of these things. ILS will sync URIs, and so the call should just flow over the trunk to that other cluster? The Expressway should answer for self-registered endpoints, and I guess if proxy registration worked then it would be registered to the UCM and thus a single cluster, so calling inbound it would ring like anything else.

If you registered right to the Expressway that… I don’t know. I can see that becoming a mess if you have to hairpin around. Beyond me but something to add to my list of things to futz around with in a lab if we have time.

Adam




From: Lelio Fulgenzi <lelio@uoguelph.ca>
Sent: Wednesday, October 2, 2019 10:32 AM
To: Pawlowski, Adam <ajp26@buffalo.edu>; Anthony Holloway <avholloway+cisco-voip@gmail.com>
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Separate cluster for third party SIP clients with SIP/ICT trunk to production

Not hijacking at all… very good points.

I was thinking about the HA availability (HAA?) on these third party SIP devices as well. From what I recall, they only have one spot to enter the registrar.

I too, would think about the Expressway as the registrar – but I have much less experience with Expressway’s dial plan than CUCM’s dial plan.

The other benefit with sticking with a CUCM cluster is, I’m hoping, that it would be easier to route calls from Webex Calling registered devices (via a border xyZ?).

You also talk about network restrictions – that’s a possibility too. It would, however, require a new TPS (third party SIP device) VLAN for every switch stack we have out there. Quite a bit of work, and it doesn’t allow for “instant” access when they buy the devices without asking us. ????

Again – not a hijack, good thread addition.


---
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@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Pawlowski, Adam <ajp26@buffalo.edu>
Sent: Wednesday, October 2, 2019 10:24 AM
To: Lelio Fulgenzi <lelio@uoguelph.ca>; Anthony Holloway <avholloway+cisco-voip@gmail.com>
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Separate cluster for third party SIP clients with SIP/ICT trunk to production

Good info, we’re actually looking at having to do this ourselves to maintain support for an application that doesn’t support TAPI/API past where we are on 11.5, so that we can move the rest of the customers off to 12.5+.

I am also looking at third party SIP device support here but because of the above and a prior incident with a low-security third party device, I’m looking to tackle this a bit differently. Currently working on a service agreement type thing with my customers, which would also restrict the networks these devices can be placed on so they are not on public networks, etc.

I’m stuck on HA capabilities for these third party clients, as a lot of them only support a single proxy/registrar address. Will the UCM accept registration to any of the nodes in the pool to be able to use a DNS round robin? Has anyone looked at SIP registration proxy with an Expressway cluster for this? The interworking may be better, but, you’re still having to set up routing rules and that on the Expressway – and I think this is a different license class for “room systems” unless it doesn’t count when you proxy through Expressway, but I am pretty sure you can do DNS RR on an Expressway C cluster and it would work fine there.

Sorry to hijack this thread, just a point of interest.

Adam


From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Wednesday, October 2, 2019 10:07 AM
To: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway+cisco-voip@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Separate cluster for third party SIP clients with SIP/ICT trunk to production

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@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway+cisco-voip@gmail.com>>
Sent: Sunday, September 29, 2019 4:17 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>
Cc: Kent Roberts <kent@fredf.org<mailto:kent@fredf.org>>; cisco-voip@puck.nether.net<mailto:cisco-voip@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 8:05 PM, Kent Roberts <kent@fredf.org<mailto:kent@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@uoguelph.ca<mailto:lelio@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 6:46 PM, Tim Smith <tim.smith@enject.com.au<mailto:tim.smith@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@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Sunday, 29 September 2019 8:07 AM
To: Jeremy Bresley <brez@brezworks.com<mailto:brez@brezworks.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook



On Sep 28, 2019, at 6:00 PM, Jeremy Bresley <brez@brezworks.com<mailto:brez@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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook




_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip