Showing posts with label IOS XE. Show all posts
Showing posts with label IOS XE. Show all posts

Sunday, April 14, 2019

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
  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 expires 3600
  credentials username 5551212 password 0 5551212 realm
  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.

username 5551212 password 0 5551212 realm retry invite 2
 retry bye 2
 retry cancel 2

 registrar 1 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. 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?

Monday, February 11, 2019

Why can't I enter any voice commands?

So you RMA'd your Cisco 4300 or 4400 ISR Voice Gateway and now it won't take any voice commands.  Here's how to get the voice licensing back on the replacement VG so you can load up your voice config and get back in production.

Update the boot licensing level to uck9 and reboot.
 license boot level uck9

Accept the EULA for SRST 
 license accept end user agreement

Update the srst license to right to use licensing.
 license right-to-use move cme-srst

Update the uck9 license to right to use licensing.
 license right-to-use move uck9

That's it.  Now you can apply you existing configuration back to the RMA replacement voice gateway and get it back in business.

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 pla...