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

Where's my Caller-ID Calling Name Man? (PRI Inbound Calling Name in subsequent FACILITY)

It's been a long minute since I've run into this particular scenario.  Unfortunately, I didn't have the solution in my notes so I reached out to my old pal google for some inspiration.

We just had a new telco company install a voice PRI with the intention of replacing our existing telco company's PRI at one of our remote sites.  After installing and testing the new voice PRI we realized that the inbound calling name was not displayed on the phones.

In this particular scenario the setup looked something like this:

PRI -----ISDN-----> Cisco ISR-G2 VG -----SIP-----> CUCM -----SCCP-----> Cisco IP Phone

We ran a "debug isdn q931" to troubleshoot the problem.  Upon inspection we found that the calling party name was not being sent in the initial ISDN setup message.  In fact, it indicated that the calling name would be send in a "subsequent FACILITY message".

First, the voice gateway won't process the calling name in a subsequent Facility messages by default. The fix for that is to apply the following to the d channel of the PRI:

interface Serial X/X/X:23
 isdn supp-service name calling

Secondly, there is a problem in this scenario with the voice gateway sending a SIP invite to Communications Manager right after it gets the ISDN setup message.  Since the initial ISDN setup message doesn't have the calling name the SIP invite will also be lacking the calling name. When we tested at this point the phones were showing "From pending" as the calling name. The work around for this issue is to introduce a delay before the voice gateway sends the SIP invite to CUCM. Each scenario may require a different amount of time. One can look at the debugs to find out how long it takes between the time the initial ISDN setup message is received and when the ISDN facility message with the name is received. In this particular case we tuned the delay to 500 milliseconds and it seems to work well. The command to delay the setup for 500 milliseconds is.

sip-ua
 timers buffer-invite 500

For more information, Cisco also has a bug id CSCup91440 that references using a buffer-invite on individual dial peers.

Below are some samples of what the debugs looked like on a typical inbound telco call and the telco that sends the calling name in a later message.

Standard Telco "Before Debug"
(The actual telephone numbers have been changed to protect the innocent.)

507963: Jan 22 09:53:13.269: ISDN Se0/2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x14D4
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98382
                Exclusive, Channel 2
        Facility i = 0x9F8B0100A11702010D020100800F4368696361676F202020202020494C
                Protocol Profile =  Networking Extensions
                0xA11702010D020100800F4368696361676F202020202020494C
                Component = Invoke component
                        Invoke Id = 13
                        Operation = CallingName
                                Name Presentation Allowed Extended
                                Name = Joshua Learn
        Display i = 'Joshua Learn'
        Calling Party Number i = 0x2180, '8005551212'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '8885551212'
                Plan:ISDN, Type:National
507964: Jan 22 09:53:13.269: ISDN Se0/2/0:23 Q931: Received SETUP  callref = 0x94D4 callID = 0x13E4 switch = primary-ni interface = User 


Subsequent Facility Message Telco "After"
(The actual telephone numbers have been changed to protect the innocent.)

040306: Jan 22 07:49:27.801 PST: ISDN Se0/2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x1A22
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Facility i = 0x9F8B0100A10F02016A06072A8648CE1500040A0100
                Protocol Profile =  Networking Extensions
                0xA10F02016A06072A8648CE1500040A0100
                Component = Invoke component
                        Invoke Id = 106
                        Operation = InformationFollowing (calling_name)
                                Name information in subsequent FACILITY message
        Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band info
        Calling Party Number i = 0x2183, '8005551212'
                Plan:ISDN, Type:National
        Called Party Number i = 0xA1, '8885551212'
                Plan:ISDN, Type:National
040307: Jan 22 07:49:27.801 PST: ISDN Se0/2/0:23 Q931: Received SETUP  callref = 0x9A22 callID = 0x1D81 switch = primary-ni interface = User
040308: Jan 22 07:49:27.805 PST: ISDN Se0/2/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x9A22
        Channel ID i = 0xA98381
                Exclusive, Channel 1
040309: Jan 22 07:49:27.848 PST: ISDN Se0/2/0:23 Q931: RX <- FACILITY pd = 8  callref = 0x1A22
        Facility i = 0x9F8B0100A11702016B020100800F332054524143452020202020202020
                Protocol Profile =  Networking Extensions
                0xA11702016B020100800F332054524143452020202020202020
                Component = Invoke component
                        Invoke Id = 107
                        Operation = CallingName
                                Name Presentation Allowed Extended
                                Name = Joshua Learn