- 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
Diary of technical happenstance, simple Internet accessible scratchpad, and brain dump to save myself later
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:
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
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
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
Subscribe to:
Posts (Atom)