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?

B-channel selection for PRIs in a trunk group.

Why doesn't the ISDN B-channel selection configuration work on my Cisco Voice Gateway?

I had the PRIs in a trunk group and had the IOS configuration setup to perform channel selection on the serial interfaces corresponding with our PRIs.  However, the PRIs ignored the channel selection commands.  How strange, I would have thought that the serial interface would be the most specific configuration option to define the hunting scheme.  Well wouldn't you know, all of the hunt scheme magic is performed at the trunk group level.  (I didn't know)  The commands bellow illustrate how to configure the PRIs to hunt in a descending order which is typically my preference as carriers usually hunt in an ascending order. 

router(config-trunk-group)#trunk group PRI
router(config-trunk-group)#hunt-scheme ?
  sequential    The interface with highest preference is selected

router(config-trunk-group)#hunt-scheme sequential ?
  both  Select from all available timeslots

router(config-trunk-group)#hunt-scheme sequential both ?
  down  Timeslots are selected in the descending order 

router(config-trunk-group)#hunt-scheme sequential both down

Why's the mainline forwarded to a cell phone!?! (Cellphone Carrier plays error after 60 seconds)

Here's a "fun" one.

Symptom:
I received intermittent reports/questions about the main line, "being forwarded to a cell phone".  I know there's no reason why I would have forwarded the mainline to a cell phone.

Troubleshooting:
I checked Cisco Communications Manager and confirmed the main line wasn't forwarded to another number.  Then I began to call the mainline from a land line & a cell phone but could not to reproduce the reported problem.  During the tests when an operator wasn't available after 90 seconds my call was routed to the auto attendant as designed.  I checked the logs for the reported problem call and found a normal call clearing from the PSTN.  Sadly, I wasn't any closer to finding where the end user's disconnect was.

Luckily, one of the reporting persons then sent me a video of an example problem call to the main line on her mobile phone.  Her  mobile phone rang for right around 60 seconds and then played the following message.

"
Welcome to Verizon wireless.  The wireless customer you called is not available at this time  Please try your call again later.  Announcement 1 switch [redacted]
"

This helped explain the confusion around why users were reporting the main line was being forwarded to a cell phone.  The Verizon error states that the "wireless customer" is not available.

I validated that the reporting user was indeed using a Verizon mobile phone.  Armed with that information I repeated the test from a couple of other Verizon mobile phones and was able to consistently recreate the issue.

Issue:
Verizon Wireless pulled back the call at 60 seconds and played the following error message:

"
Welcome to Verizon wireless.  The wireless customer you called is not available at this time  Please try your call again later.  Announcement 1 switch [redacted]
"

Work Around:
Modified the timers on the Cisco Communications Manager.  Previously the system was configured to route calls to the auto attendant after 90 seconds.  I discussed the issue with the customer and we decided to change the value to 30 seconds.  Now, when an operator doesn't pick up the call within 30 seconds, the call is routed to the auto-attendant instead of being disconnected by our friends at Verizon.