Integrating WebEx Calling and Communications Manager Express 2/2

This is the second post in the two post series. It will go into more detail on the configuration of the solutions and workarounds put in place.

 

• The Communications Manager Express (WebEx local gateway / CUBE) requires a security license. There's not much else to add. Make sure it has one so the CUBE will accept the TLS commands.

 

• The CME phone directory numbers will by default register to the WebEx Control Hub. According to TAC this can confuse the Webex Control Hub and cause issues. The symptom of the phones trying to register with Webex is evident with a “show sip-ua register status”. It will show the directory numbers of all the CME phones trying to register to Webex. TAC explained that it should only show the SIP trunk trying to register to Webex. (It’s also normal to see registration for a SIP IP Telephony Service Provider too if it's configured for authentication) TAC offered a configuration sample to prevent the SIP devices from registering with Webex and I looked up how to prevent the SCCP devices and POTS device ports. Please see the following three configuration samples.

 

• SIP phones on the CME will need their directory numbers configured as “no-reg”

    voice register dn <>

    no-reg

 

• SCCP phones on CME will need their directory numbers configured for “no-reg”

                   ephone-dn <>

        number <> no-reg primary

• Analog phones connected to CME will need to have their pots dial-peer configured not to “sip-register” it's destination-pattern

        dial-peer voice <> pots

         destination-pattern <>

         port <>/<>/<>

         no sip-register

            Note: In my case, I had to reboot the CUBE before the configuration changes took full effect.

After configuring the system to not pass the phone registration along to Webex I still have two registration attempts listed. The first one is to the IP Telephony Service Provider for the CME phones and the second is to Webex for the integration. The following CLI sample output is similar to my registration CLI output now.

ExampleCME#show sip-ua register status

Tenant:  10

--------------------- Registrar-Index  1 ---------------------

Line                             peer      expires(sec) reg survival  P-Associ-URI

================================ ========= ============ === ========  ============

5555551212                       -1         239          yes normal

Tenant:  200

--------------------- Registrar-Index  1 ---------------------

Line                             peer      expires(sec) reg survival  P-Associ-URI

================================ ========= ============ === ========  ============

ExampleCME.Trunk1234_LGU         -1         39           yes normal

ExampleCME#

• The CME location in the WebEx Control Hub needs to have the main phone number associated with it. This is kind of an interesting step because the CME is not hosting Webex Calling phones but rather it's hosting its own CME phones. However, Webex won’t pass calls without the main phone number configured. I chose an unused DID the customer owns, added it to the control hub, and associated it to the location the trunk is tied to.

 

• The CME dial-peers directed at the WebEx cloud didn't present the SIP signaling in a way that the WebEx cloud expected to see it. According to Cisco TAC their configuration guide was designed for the CUBE to front end a Communications Manager or other PBX device. Cisco TAC suggested hair-pinning the dial peers to obfuscate CME from WebEx Calling. TAC also helped me do a little bit of dial-plan manipulation prefixing digits so that the CUBE didn't drop the calls as a "loop". Technically TAC said CME isn't explicitly listed as being supported however, this workaround presented the SIP signaling to the Webex cloud in the Webex expects to see it. Please see the following information on how the dial-peers and translations were configured:

 

Inbound calls from WxC to CME

The "Configure Local Gateway on IOS-XE for Webex Calling" guide from Cisco includes dial-peers without any dial-plan numbers tied to them. In their example, they show dial-peer 200201 matching inbound calls from Webex Calling and then sending it along to dial-peer group 300.

 

Example of a portion of the reference configuration in the "Configure Local Gateway on IOS-XE for Webex Calling" guide from Cisco:

dial-peer voice 200201 voip

 description Inbound/Outbound Webex Calling

 destination dpg 300

 

I took Cisco’s example config and modified the dial-peer group so that it passed the calls to my dial-peer 444001 below. This dial-peer hairpins the calls back onto the CME and prefixes a 444 so the CUBE doesn't drop the call as a duplicate.

dial-peer voice 4440001 voip

 description Inbound calls from WxC to CME - Prefix 444 and loop via CUBE

 translation-profile outgoing add444

 destination-pattern 8040..$

 session protocol sipv2

 session target ipv4: <CME IP Address>

 voice-class sip early-offer forced

 voice-class sip bind control source-interface Loopback0

 voice-class sip bind media source-interface Loopback0

 dtmf-relay rtp-nte sip-kpml sip-notify

 codec g711ulaw

 no vad

 

This inbound dial-peer matches the call with the 444 prefix and strips it off. Then the CME phone will match the outbound leg.

dial-peer voice 4440002 voip

 description Inbound calls from WxC to CME - Strip 777 Webex Calling Strip 777 - WxC Side

 translation-profile incoming strip444

 session protocol sipv2

 session target sip-server

 incoming called-number 444T

 voice-class sip early-offer forced

 voice-class sip bind control source-interface Loopback0

 voice-class sip bind media source-interface Loopback0

 dtmf-relay rtp-nte sip-kpml sip-notify

 codec g711ulaw

 no vad

 

Outbound Calls from CME to WxC

This outbound dial-peer matches the directory number of phones on WxC, then prefixes a 777, and then loops the call back through the CUBE.

 

     dial-peer voice 7770001 voip

      description Outbound calls to WxC - Prefix 777 and loop via CUBE

      translation-profile outgoing add777

      destination-pattern 8070..$

      session protocol sipv2

      session target ipv4:<CME IP Address>

      voice-class sip early-offer forced

      voice-class sip bind control source-interface Loopback0

      voice-class sip bind media source-interface Loopback0

      dtmf-relay rtp-nte sip-kpml sip-notify

      codec g711ulaw

      no vad

 

This dial-peer matches the inbound call leg for calls routed to the 777 prefix.

dial-peer voice 7770002 voip

 session protocol sipv2

 session target sip-server

 incoming called-number 777T

 voice-class sip early-offer forced

 voice-class sip bind control source-interface Loopback0

 voice-class sip bind media source-interface Loopback0

 dtmf-relay rtp-nte sip-kpml sip-notify

 codec g711ulaw

 no vad

 

This dial-peer matches the outbound call leg for calls with the 777 prefix. Strips off the prefix and the routes the call out to Webex Calling

 

dial-peer voice 7770003 voip

 description Outbound calls to Webex Calling Strip 777 - WxC Side

 translation-profile outgoing strip777

 max-conn 150

 destination-pattern 7778070..$

 session protocol sipv2

 session target sip-server

 destination dpg 300

 voice-class codec 99 

 voice-class stun-usage 200

 no voice-class sip localhost

 voice-class sip tenant 2000

 dtmf-relay rtp-nte

 srtp

 no vad

 

The information below shows the translations config: 

voice translation-rule 4441

 rule 1 /\(......\)/ /444\1/

 

voice translation-rule 4442

 rule 1 /^444\(......$\)/ /\1/

 

voice translation-rule 7771

 rule 1 /\(......\)/ /777\1/

voice translation-rule 7772

 rule 1 /^777\(......$\)/ /\1/

 

voice translation-profile add444

 translate called 4441

 

voice translation-profile strip444

 translate called 4442

 

voice translation-profile add777

 translate called 7771

 

voice translation-profile strip777

 translate called 7772

Integrating Webex Calling and Communications Manager Express 1/2

 Cisco now supports WebEx Calling locations that use Cloud Connected PSTN to also integrate with a local gateway (CUBE) for on-net dialing to a PBX. The new trunk, route group, and dial plan configuration options in the WebEx Control Hub facilitate this. Cisco has guides published that reference the configuration to support Communications Manager as that PBX specifically. These two posts will take it in a slightly different direction and explore integrating with Communications Manager Express. While not explicitly called out as supported by Cisco I've had success with the integration with a little assistance from Cisco TAC. This integration may help folks migrating off of existing CME deployments and onto WebEx Calling.

This first post will call out some caveats I ran into at a high level. The second post of two will go into more detail about how I addressed the caveats.

Gotchas

• The Communications Manager Express (WebEx local gateway / CUBE) requires a security license. While this makes sense now it wasn't explicitly called out in the documentation and I missed this requirement initially. The documentation does say, "The trunk between the local gateway and the Webex cloud is always secured using SIP TLS transport and SRTP for media between the local gateway and the Webex Calling Access SBC". Read, get a security license on that CUBE. (along with the CUBE licensing that is stated as required in the documentation)

• The CME phone directory numbers will by default register to the WebEx Control Hub. This can cause confusion/issues with the trunk authentication between the CUBE and the WebEx Control Hub. The first time I integrated a CME it didn't present as an issue but the 2nd time I integrated one the trunk wouldn't authenticate. Cisco TAC requested that I removed the registration from the CME phone directory numbers to the WebEx Control Hub.

• The WebEx Calling location in the WebEx Control Hub needs to have a main phone number associated with it. "You will not be able to make or receive calls until this number is added" Even though this location will not host phones in the WebEx Control Hub the WebEx Calling location must have a main number defined or the location will not process calls. 

• The CME dial-peers directed at the WebEx cloud didn't present the SIP signaling in a way that the WebEx cloud expected to see it. Cisco TAC suggested hair-pinning the dial peers to obfuscate CME from WebEx Calling. We also needed to do a little bit of dial-plan manipulation prefixing digits so that the CUBE didn't drop the calls as a "loop". Technically TAC said CME isn't specially called out as being supported however, this workaround allowed the SIP signaling to present to the WebEx cloud in the way they typically expect to see it.

SIP Bindings on CME with an authenticatied SIP Trunk

Let's say there is a Communications Manager Express and a PSTN SIP trunk to the telco that requires authentication.  How does CME bind SIP messaging to the telco from a Northbound interface (E.G. GigibitEthernet 0/0/0) while binding it's local SIP traffic to a loopback address?

I'll start with the second part of that.  If I want all SIP traffic bound to an interface I bind it globally under the "voice service voip" portion of the configuration.  The section below shows how one might bind SIP traffic to a loopback interface.

!
voice service voip
 allow-connections sip to sip
 sip
  bind control source-interface Loopback0
  bind media source-interface Loopback0
!

The example above works well for local SIP traffic that should be bound to the loopback address.  However, the registration to the Telco Provider would likely fail assuming that they are expecting the IP address of the Northbound interface of the CUBE.  (e.g. GigabitEthernet 0/0/0).

It's seems to me that the tenant feature in CUBE is helpful for sourcing the registration message to the telco from an interface and in fact overrides the global SIP binding.  Here is an example of what a tenant configuration might look like with the traffic bound to Gi0/0/0.

!        
voice class tenant 1
  registrar 1 dns:example.telcosbc.com expires 3600
  credentials username 5551212 password 0 5551212 realm example.telcosbc.com
  timers buffer-invite 5000
  bind control source-interface GigabitEthernet0/0/0
  no pass-thru content custom-sdp
  no outbound-proxy
!

The example above calls out the interface to bind the registration messages,  the registrar destination, the credentials and the realm.  In order for this work in production I had to duplicate the registrar configuration and add an authentication statement (that matched the credentials in the tenant) under the sip-ua section.  The following is an example of what that sip-ua section might look like.

!
sip-ua
 authentication username 5551212 password 0 5551212 realm example.telcosbc.com retry invite 2
 retry bye 2
 retry cancel 2
 registrar 1 dns:example.telcosbc.com expires 3600
!

After entering that configuration we typically find that the "show sip register status" returns back a yes for the username.  In this case it would look something like.

cme-cube.example.com#show sip register status
--------------------- Registrar-Index  1 ---------------------

Line                             peer       expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
5551212                         -1         1663         yes normal

For whatever reason we have run into scenarios where we had to reboot the CME-CUBE before we received back a response from the telco SBC.

I won't go into the dial-peers in detail in this blog.  However, we did also have dial-peers with bindings on them.  Inbound and outbound calls use the bindings on the dial-peers as apposed to the global SIP binding or the tenant SIP binding.

(The following configuration example was from a Cisco ISR 4300 series ISR running Cisco IOS XE Software, Version 16.05.02)


Has anyone else tried this method or another method to bind the traffic to the telco SIP SBC from a specific interface?

How do I enable the line selection features for the Cisco 8800 phones on Communications Manager Express (CME)?

Many of us who have deployed the Cisco 88XX phones have run across 2 features that are life savers when working with multi-line phones connected to CUCM. Those features are "Show ALL Calls On Primary Line" and "Revert All Calls". For those who haven't used those features before I recommend checking out Amy Engineer's blog on why they are helpful and how they work with CUCM.

https://amyengineer.com/tag/8841/

While these 88XX line selection options have existed in the full Unified Communications Manager offering for a while. These options are not officially available in CME at the time of this writing. Luckily, since the phones have the functionality in firmware, there is a bit of a dirty hack to invoke these features in CME.

The following configuration will enable the "Show ALL Calls On Primary Line" feature on ALL phones.

telephony-service
service phone allCallsOnPrimary 1

The following configuration will enabled the "Revert All Calls" feature on ALL phones.

telephony-service
service phone revertToAllCalls 1

After those features have been enabled the phone profiles (config files) need to be re-created.  The following commands can be used to recreate the profiles.

voice register global
 no create profile
 create profile

Then we can validate the configs or skip this part and just reboot the phones and test.  Here's a sample scenario to check the config file.  Assuming CME is writing the config files to a directory called "its" and there is a phone with a name of "SEP101010101010", the following cli commands would show if the new configuration options are written to the config file.

more bootflash:/its/SEP101010101010.cnf.xml | i allCallsOnPrimary
and
more bootflash:/its/SEP101010101010.cnf.xml | i revertToAllCalls

After validating the the new addition to the configuration the phones will need to be rebooted and then voilà the new features are active!