Monday, December 31, 2018

Cisco Jabber SIP URI dialing

Assuming a single CUCM cluster in generally good call routing health, see below for short list of configuration changes required to enable SIP URI dialing in Cisco Jabber:

  • System | LDAP | LDAP Directory set Directory URI to mail
  • System | Enterprise Parameters set URI Lookup Policy to Case Insensitive
  • System | Enterprise Parameters set Directory URI Alias Partition to a partition accessible by clients
  • System | Service Parameter | Cisco CallManager set URI Dialing Display Preference to URI
  • User Management | End User set users' Primary Extension
  • Device | Device Settings | SIP Profile check Use Fully Qualified Domain Name in SIP Requests in a profile applied to endpoints
  • jabber-config.xml | Policies add true

Saturday, December 29, 2018

Using SIP OPTIONS Ping to monitor groups of carrier servers on Cisco CUBE routers

Implementing multiple CUBEs in separate data centers carrying voice traffic to and from the same group of carrier servers.

Ideally, a single dial peer in CUBE 1 points to all the carrier servers, and a single dial peer in CUBE 2 does the same.

Carrier only authenticates traffic by IP so they want to use OPTIONS Ping to monitor the availability of the CUBEs.

I want to monitor the availability of the carrier servers using OPTIONS Ping as well so I can fail between CUBEs and / or other circuits quickly if necessary.  I also don't want to have to create redundant dial-peers to do it.

Step 1:
Add voice class uri defining carrier servers. I'll use this to (at least) define which inbound dial-peer will answer the SIP OPTIONS ping from the carrier. This will let the carrier know which CUBE to send incoming calls to.

voice class uri 2 sip
   host ipv4:10.7.X.X
   host ipv4:10.7.Y.Y

Step 2:
Add a server group defining carrier servers.  This allow me to both route calls to multiple carrier servers as well as monitor them with OPTIONS Ping with a single dial-peer. If OPTIONS Ping fails in defined intervals, the dial-peer is busied out and calls can be routed elsewhere. 

voice class server-group 2
   ipv4 10.7.X.X preference 1
   ipv4 10.7.Y.Y preference 2
   description SIP Carrier Interfaces

Step 3:
Use a voice class to administer down-intervals, up-intervals and retry intervals in one place rather than on a list of different dial-peers.

voice class sip-options-keepalive 2
   description SIP Carrier Interfaces Keepalive
   down-interval 30
   up-interval 60
   retry 5

Step 4:
Create a dial-peer to respond to the carriers OPTIONS Ping using the voice class uri above.

dial-peer voice 2 voip
   description incoming calls from carrier
   session protocol sipv2
   incoming uri via 2
   voice-class codec 1
   voice-class sip bind control source-interface GigabitEthernet0/0/2
   voice-class sip bind media source-interface GigabitEthernet0/0/2
   dtmf-relay sip-kpml rtp-nte
   no vad

Step 5:
Add the server-group session above to a single outgoing dial-peer. With that you can eliminate redundant dial-peers pointing to individual carrier servers.  Add the sip options-keepalive profile above to the same outgoing dial-peer.  You will then send SIP Options ping to the carrier servers to monitor their statuses.  When SIP OPTIONS Ping fails, this dial-peer will be busied out.

dial-peer voice 10 voip
   description Outgoing calls to carrier
   translation-profile outgoing OutboundPSTN
   destination-pattern +T
   session protocol sipv2
   session server-group 2
   voice-class codec 1
   voice-class sip options-keepalive profile 2
   voice-class sip bind control source-interface GigabitEthernet0/0/2
   voice-class sip bind media source-interface GigabitEthernet0/0/2
   dtmf-relay sip-kpml rtp-nte
   no vad

Now you can use show voice class sip-options-keepalive 2 or show dial-peer voice summary to monitor the status of the individual carrier server and general dial peer status.  Below you see neither carrier server is reachable (Busy) via SIP Options ping / voice class sip-options-keepalive 2 and that dial-peer 10 is in a busyout state:


myCUBE1#show voice class sip-options-keepalive 2
Voice class sip-options-keepalive: 2 AdminStat: Up
 Description: Carrier Interfaces Keepalive
 Transport: system Sip Profiles: 0
 Interval(seconds) Up: 60 Down: 30
 Retry: 5

  Peer Tag    Server GroupOOD SessID  OOD Stat    IfIndex   
  --------    ----------------------  --------    -------   
  10          2                       Busy        16         

  Server Group: 2 OOD Stat: Busy
   OOD SessID  OOD Stat   
   ----------  --------   
   5           Busy       
   6           Busy       

 OOD SessID: 5            OOD Stat: Busy
  Target: ipv4:10.7.X.X
  Transport: system       Sip Profiles: 0

 OOD SessID: 6            OOD Stat: Busy
  Target: ipv4:10.7.Y.Y
  Transport: system       Sip Profiles: 0

------------------------------------------------------

csb-dc-s0-vg1#show dial-peer voice summary
dial-peer hunt 0
             AD                                    PRE PASS                OUT
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE    VRF
2      voip  up   up                                0  syst                          NA                 
10     voip  up   up             +T            0  syst                               busyout    NA                 


See related official Cisco documentation here:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_sip/configuration/15-mt/cube-sip-15-mt-book/oodo-ping-group.pdf



Wednesday, December 26, 2018

QSIG PRI between CUCM and NEC 8500 hold and resume issues

Call flow was basically:
Cisco 8841 -> SIP -> CUCM -> SIP -> CUBE -> QSIG PRI -> NEC 8500

When making calls from CUCM to NEC endpoints, placing a call on hold on the Cisco endpoint and resuming resulted in disconnecting the call on the CUCM side.  The NEC system did not release the call.

Found a SIP UPDATE message being sent from CUCM to CUBE when resuming the call resulted in an ISDN NOTIFY message between CUBE and the NEC system.  Either the NOTIFY message, or maybe just the fact it included a caller name in ISDN Display format was not supported by NEC.  The result was the call would drop on the CUCM side.

Although you can remove the name in the ISDN SETUP message via "no isdn outgoing display-ie", there was no way I could find to eliminate the name from the ISDN NOTIFY message.  The work around was to prevent caller ID from being updated on the SIP trunk side via SIP | no update-callerid in the CUBE configuration.  This eliminated the entire ISDN NOTIFY message as a result.

This is a sample message sent to NEC when resuming held calls and the disconnect:

Dec 21 18:51:49.701: ISDN Se0/1/1:23 Q931: TX -> NOTIFY pd = 8  callref = 0x00C8
        Notification Ind i = 0x8300
        Display i = 'Ray Maslanka'
        Calling Party Number i = 0x0081, '78898'
                Plan:Unknown, Type:Unknown
        Cause i = 0x85E328 - Information element not implemented
        Call State i = 0x00
Dec 21 18:51:49.774: %ISDN-6-DISCONNECT: Interface Serial0/1/1:0  disconnected from 23999 , call lasted 19 seconds

This is relevant snippets of the CUBE configuration:

voice service voip
 ip address trusted list
  ipv4 X.X.X.X 255.255.255.0
 mode border-element license capacity 200
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 fax protocol t38 version 0 ls-redundancy 1 hs-redundancy 1 fallback none
 modem passthrough nse codec g711ulaw
 h323
 sip
  bind control source-interface Port-channel1
  bind media source-interface Port-channel1
  ! This eliminates the SIP UPDATE message
  ! that in turn eliminates the ISDN NOTIFY message
  no update-callerid 
  early-offer forced

controller T1 0/1/0
 framing esf
 clock source network
 linecode b8zs
 cablelength long 0db
 pri-group timeslots 1-24
 trunk-group PSTN timeslots 1-24 preference 1

interface Serial0/1/0:23
 encapsulation hdlc
 no cdp enable
 isdn switch-type primary-qsig
 isdn protocol-emulate network
 isdn incoming-voice voice
 ! This eliminates name display in ISDN SETUP messages.
 ! This DOES NOT eliminate name display in ISDN NOTIFY messages 
 ! when resuming from hold.
 no isdn outgoing display-ie