[cisco-voip] Call flow for device registered to Hybrid Cloud via local PSTN

Jonathan Charles jonvoip at gmail.com
Thu May 16 12:00:03 EDT 2019


It is for Cisco Webex Boards, Room Kits and some SX80s all registered to
the Webex Hybrid Cloud


Jonathan

On Wed, May 15, 2019 at 7:04 PM Brian Meade <bmeade90 at vt.edu> wrote:

> Be aware that Call Service Connect is being deprecated for anything
> besides Video Endpoints.
>
> If this is for Webex Teams client, they want you to start looking at
> Unified CM calling in Webex Teams.
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/ucmcalling/unified-cm-wbx-teams-deployment-guide/unified-cm-wbx-teams-deployment-guide_chapter_01.html
>
>
> If you need something behind hold/resume for mid-call controls or need
> mobile Teams client to work, Cisco is pushing towards having Teams launch
> Jabber for any phone links which can be configured as well.
>
> Long-term goal is to have Teams calling function very similar to Jabber
> softphone for Desktop and mobile.
>
> On Wed, May 15, 2019 at 7:45 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>
>> Inbound Flow (PSTN user calls user’s DID):
>>
>> GW > CCM > (per userWebex Hybrid CTI Device) > Exp-C > Exp-E > ControlHub
>> > (rings your cloud registered device)
>>
>> Outbound Flow (cloud registered device calls PSTN via CCM or other
>> on-prem device):
>>
>> Cloud registered device (ControlHub) > Exp-E > Exp-C > CCM (interacts
>> with the dialplan for onnet/offnet calling).
>>
>> Basically, it’s a B2B call that gets 15 pieces of flair added to it so it
>> can utilize your on-prem gateway for PSTN access. When you go through the
>> configuration, One of the steps will lead you to creating CTI devices in
>> communications manager which share the users DID (Essentially, and on
>> premise representation of the cloud registered device). The inbound flow is
>> a little unique as it essentially capitalizes on a bastardized form of SNR
>> to ring the cloud device.
>>
>> As far as security goes, you are mostly at the mercy of traditional call
>> policy rules (or more specifically writing search rules for your zones).
>>
>> I have found the following to be two good "reject" policies that tend not
>> to interfere with most deployments (though they could if the internal URIs
>> match the policy). Most organizations have Directory URIs that ultimately
>> have been inherited from the user's email address or other corporate
>> standardizations which these policies tend to avoid and also tend to deny
>> routing to a surprising amount of obvious junk (typically, I apply CPL at
>> the edge):
>>
>>
>>    - ^[0-9,a-z,A-Z]{0,6}@.*
>>       -  The first 0-6 characters are made up of alphanumerics 0-9
>>       and/or upper/lower case letters, “@“ anything
>>          - Example: 123456 at domain.com
>>          - Example: NoAuth at domian.com
>>          - Example: 9999 at domain.com
>>
>>
>>    - ^[0-9,a-z,A-Z]{0,6}$
>>       - The first 0-6 characters are made up of alphanumerics 0-9 and/or
>>       upper/lower case letter and do not exceed the 6th character
>>       - Example: 1000
>>       - Example: 9999
>>       - Example: NoAuth
>>       -
>>
>> Good Luck!
>>
>> -Ryan
>>
>> On May 15, 2019, at 19:30, Jonathan Charles <jonvoip at gmail.com> wrote:
>>
>> Thanks!... looks like I have some more reading to do... so how does it
>> prevent anyone from sending a pstn number to my expressway? How does it
>> authenticate the Webex devices to pass calls to CUCM for?
>>
>> Customer has enterprise licensing, so they should be able to do whatever
>> they want...
>>
>>
>> Jonathan
>>
>>
>>
>> On Wed, May 15, 2019 at 6:16 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>>> You’ll need a specific Webex DNS zone and the traversal trunk really
>>> just needs to support pre-loaded route headers and SIP parameter
>>> preservation (those are the most significant differences over the traversal
>>> / neighbor zone you might have setup for B2B).
>>>
>>> It’s a simple enough configuration, but there are a few more moving
>>> parts than what the marketing may lead one to believe. Here is the
>>> configuration documentation:
>>> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/callservices/cmgt_b_ciscospark-hybrid-call-service-config-guide.html
>>> <https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Fvoice_ip_comm%2FcloudCollaboration%2Fspark%2Fhybridservices%2Fcallservices%2Fcmgt_b_ciscospark-hybrid-call-service-config-guide.html&data=02%7C01%7C%7C7ee4a253802142b2a30f08d6d98d40fe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636935598030629961&sdata=1n%2BPAGaE0G2GZrt3Jq7l2uo41jWG0NYoZh5cUcHFAaw%3D&reserved=0>
>>>
>>> Oh and don’t forget to enable MTLS on the edge and also be aware the
>>> ControlHub now requires CCM 11.5.1SU3 or better (it detects CCM version via
>>> call connector on Exp-C). It wouldn’t allow you to enable hybrid calling on
>>> cloud registered devices otherwise.
>>>
>>> You can technically still get away using Expressway 8.11.4, but that’ll
>>> soon be a deprecated version for hybrid calling (you’ll get an alarm about
>>> it), so might as well go to 12.5.2 and be done with it.
>>>
>>> BTW, if you try to upgrade an 8.x Expressway to 12.5.x, you will
>>> interact with GLO for the 12.x release key (can’t do it from the self
>>> service portal because the existing 8.x virtual license is already
>>> associated to a PAK and GLO has to invalidate that relationship first, then
>>> hash your new keys to 12.5.x).
>>>
>>> Good Luck!
>>>
>>> - Ryan
>>>
>>> On May 15, 2019, at 18:42, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>>>
>>>
>>> Very good question. From what I understand, there’s a special traversal
>>> link built and it’s all “built-in” and uses the CSS of the remote
>>> destination or something like that.
>>>
>>> I’ve read absolutely zero docs about this. This is all based on a quick
>>> convo I had. I had the same worries and if I recall correctly, my worries
>>> were somewhat alleviated.
>>>
>>> However, that being said, there is only one template in control hub, so
>>> if your user needs a different setup on their remote destination (or
>>> something like that) you need to go make a manual change.
>>>
>>> It’s sorta like how there’s only one licensing template in control hub
>>> for new users. We’re gonna struggle with that. We might have to engage
>>> (professional) services which make uses of APIs to assign different
>>> services for different users in webex. But I digress.
>>>
>>> *-sent from mobile device-*
>>>
>>>
>>> *Lelio Fulgenzi, B.A.* | Senior Analyst
>>>
>>> Computing and Communications Services | University of Guelph
>>>
>>> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
>>> N1G 2W1
>>>
>>> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>>>
>>>
>>>
>>> www.uoguelph.ca/ccs
>>> <https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C7ee4a253802142b2a30f08d6d98d40fe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636935598030639969&sdata=rnRA4o7FYEPynK7wGT4D8HPePQV7pDXYc69P5PiURa4%3D&reserved=0> |
>>> @UofGCCS on Instagram, Twitter and Facebook
>>>
>>>
>>>
>>> [image: University of Guelph Cornerstone with Improve Life tagline]
>>>
>>> On May 15, 2019, at 5:20 PM, Jonathan Charles <jonvoip at gmail.com> wrote:
>>>
>>> Enabling Cisco hybrid call and routing calls to the PSTN using local
>>> gateway (via Expressway C/E pair).
>>>
>>> What search rules do we need on the E and C?
>>>
>>> How do we prevent toll fraud if we have E.164 patterns inbound on our
>>> Expressways?
>>>
>>> Am I being paranoid?
>>>
>>>
>>> Jonathan
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> <https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C7ee4a253802142b2a30f08d6d98d40fe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636935598030639969&sdata=sSSIRWnroOXGc9j1XbdMp5%2FZ9xcQ%2FXqV3DmMD5hXBMY%3D&reserved=0>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>>
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C5b817b962f3e419f017508d6d986a8fe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636935569711652307&sdata=UCJB8OKg5UlpRWHaTtp6Y2AJNzpfh6NmVWdejkBYmDI%3D&reserved=0
>>> <https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C7ee4a253802142b2a30f08d6d98d40fe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636935598030649977&sdata=h481tpl5aQI%2BYfdWwiuYXVuQlKvZms3jQlHH6JXmL4U%3D&reserved=0>
>>>
>>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190516/a283674a/attachment.htm>


More information about the cisco-voip mailing list