Mar 30

Session Line Mode vs Enhance Line Mode – 8800 Series

Enable Enhanced line mode to use the buttons on both sides of the phone screen as line keys. Predictive dialing and Actionable incoming call alerts are enabled by default in Enhanced line mode.

You must create a new, customized phone button template.

Step 1 In Cisco Unified Communications Manager Administration, select Device > Phone.
Step 2 Locate the phone that you need to set up.
Step 3 Navigate to the Product Specific Configuration area and set the Line Mode field to Enhanced Line Mode.
Step 4 Navigate to the Device Information area and set the Phone Button Template field to a customized template.
Step 5 Select Apply Config.
Step 6 Select Save.
Step 7 Restart the phone.

Features Available in Enhanced Line Mode

Enhanced line mode supports most but not all features. Enabling a feature does not imply support. Read the following table to confirm that a feature is supported.

Feature Supported by Firmware Release 11.5(1) Notes
Answer Yes
Automatically Answer Calls Yes
Barge/cBarge Yes
Bluetooth Smartphone integration Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Bluetooth USB Headsets Yes
Call Back Yes
Call Chaperone Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Call Forward All Yes
Call Park Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Call Park Line Status Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Call Pickup Yes
Call Pickup Line Status Yes
CFWA on multiple calls Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Cisco Extension Mobility Cross Cluster Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Cisco IP Manager Assistant (IPMA) Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Cisco Unified Communications Manager Express Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Conference Yes
Computer Telephony Integration (CTI) applications Yes
Decline Yes
Device Invoked Recording Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Directed BLF Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Do Not Disturb Yes
Enhanced SRST Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Extension Mobility Yes
Group Pickup Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Hold Yes
Hunt Groups Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Incoming Call Alert with configurable timer Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Intercom Yes
Key Expansion Module Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Malicious Call Identification (MCID) Yes
Meet Me Yes
Mobile Connect Yes
Multilevel Precedence and Preemption Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Mute Yes
Programmable Line Key (PLK) Support for Queue Status Yes
Privacy Yes
Queue Status Yes
Quality Reporting Tool (QRT) Yes
Right to Left locale support Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Redial Yes
Silent Monitoring and Recording Not supported by Firmware Release 11.5(1) This feature is being considered for future releases.
Speed Dial Yes
Survivable Remote Site Telephony (SRST) Yes
Transfer Yes
Uniform Resource Identifier (URI) Dialing Yes
Video Calls Yes
Visual Voicemail Yes
Voicemail Yes

Cisco IP Phone 8800 Series Administration Guide

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8800-series/english/adminguide/P881_BK_C136782F_00_cisco-ip-phone-8800_series/P881_BK_C136782F_00_cisco-ip-phone-8811-8841_chapter_01011.html#task_99EA577B0C5DA470C3075195494F789C

Mar 25

Poor Voice Quality. Is it My problem or the Telco’s?

Quite often in the voice world we are pointed at and told that our system doesn’t work, call quality is poor, the caller’s voice drops out, calls are being disconnected randomly etc. Then we have to go and decipher what is really going on and isolate the issue so we can determine where the fault lies within the network… or perhaps outside the network.

Rcvr Lost counter on an IP Phone simply states that the phone expected to receive x amount of packets and only receive y amount of packets, the difference being the RCVR Lost counter. How does the phone know what to expect? Well RTP is a stream of organised sequential packets, each packet has a sequential number associated to it.. If RTP packet number 1002 was lost along the way, then the phone would receive RTP packet 1001 and then 1003… the phone would be asking.. Hey where was RTP packet 1002? And then notch up the RCVR Lost counter. With enough packets lost in a RTP stream.. The callers now start to experience poor quality with words dropping out etc.

Of course this is our problem until proven otherwise, Telcos never want to investigate into the problem first.. I’ve outlined the process of what I undertook to essentially clear the phone system of any wrong doing and force the Telco to take a closer look at the issue.

First of all, this is a SIP ITSP connection.. I have a Cisco 2901 ISR acting as a CUBE, with CUCM sitting behind the CUBE.

1. Enable web access to the phone. View the phone from the web and select stream 1. This is the primary conversation. There will be a few counters in here.. But we interested in RCVR Lost counter and the customer is complaining about not being able to hear callers, as their voice drops in and out, hence we look at the incoming stream. If the RCVR Lost counter has any number higher then ’1′ then we have a potential issue.

2. Now lets log into the CUBE. We are looking for packets received and packets sent for the call conversation. These should exactly match the phone. Use the following command on the CUBE to view packets in / out. HOSTNAME# show call active voice brief

call_active_voice_bri
In the above output, you can see between the Inbound and outbound call legs (same Call IDs), the rx (received) packet count on the inbound call leg exactly matches the tx (transceive) packet count on the outbound call leg. (The yellow highlight represents the call flow inbound and the Red underline represents the call flow outbound.

When the rx and tx are matching, this indicates the CUBE is not dropping any packets in the RTP stream. So we must look further out to the Telco.

4. Also check the Switching interfaces for lost packets, this is quite rare, but worth verifying to ensure switch ports or QoS are not dropping packets etc.

5. Lets take a packet capture on the outside interface of the CUBE. We want to do this to explicitly identify if the any RTP packets have been lost before arriving at the CUBE. We can also playback the RTP stream in wireshark to listen for the defect in the voice.

6. To capture packets on the CUBE follow the below. There is also a great article, which I have linked below that expands on capturing packets.

(config)# monitor capture buffer BUF size 2048 max-size 1518 linear

(config)# ip access-list extended RTP
(config-ext-nacl)# permit udp any any range 16384 32767
(config-ext-nacl)# permit tcp any any eq 5060
(config-ext-nacl)# permit udp any any eq 5060

(config)# monitor capture buffer BUF filter access-list RTP

Select the interface of the capture point. Also select the switching plan.. Which should be cef and not process.

(config)# monitor capture point ip cef POINT gigabitethernet 0/1 both

(config)# monitor capture point associate POINT BUF

(config)# monitor capture point start POINT

(config)# monitor capture point stop POINT

(config)# monitor capture buffer BUF export tftp://10.1.1.1/BUF.pcap

Delete capture point and capture buffer

(config)# no monitor capture point ip cef POINT fastEthernet 0 both
(config)# no monitor capture buffer BUF

7. Now we can open the stream in wireshark. If the stream is g711u/alaw then wireshark will have no problems analysing the RTP stream and playing it back to you. If the stream is G729 however, I’ll add a note onto the bottom of this blog to take you through decoding g729, actually I’ll add this is as a separate blog entry.

8. Open the PCAP file in wireshark. Navigate to Telephony -> RTP -> RTP Streams. This will display the captured RTP Streams.

rtp_streams_wireshark

We can also see from here that the inbound call leg for the external facing interface is displaying lost packets and a high jitter number. These lost packets are known because the RTP stream is sequential.. Hence the CUBE knows how many packets it should have received vs the packets is has received. In this case we can send this result to the Telco as this definitively states the issue lies before the one-premise CUBE processes the RTP Stream.

We can also play the stream to hear for any missing voice etc. Select the ‘Analyze’ button. This will display a window with more statistics for the RTP Stream.

rtp_streams_analyze

No select Play Stream. This will playback the stream.

rtp_streams_play

Link to capturing packets on Cisco IOS Router.
www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-embedded-packet-capture/116045-productconfig-epc-00.html

Mar 23

SIP Calls Disconnecting After 30 Minutes – ITSP

Having issues with calls being disconnected after the Min Session Timer expires, which by default on a Cisco UC system is 30 minutes. I found the Session-Expires SIP header was not being passed through by the Cisco CUBE. Therefore the 200 OK Message also did not contain the Session-Expires SIP Header back to the ITSP. As the ITSP did not receive the Session-Expires SIP Header the return 200 OK message, the call will be torn down (by the ITSP) after the Session_Expires timer expires (that was a mouth full).

Summary of what Users will see.

Call ends 29:59sec, the remote device (PSTN) will disconnect, however the Jabber Client (in my case) remained established, however obviously not connected to anything. The User then had to hangup the call.

To resolve this and allow the CUBE to effectively be transparent in SIP session timer refreshing process, we need to add the following command to the Voice Services VOIP -> SIP menu or to the Dial-Peer.

*** Global ***

geneaic2vg001(config)#voice service voip
geneaic2vg001(conf-voi-serv)#sip
geneaic2vg001(conf-serv-sip)#session refresh

*** Dial-Peer ***

geneaic2vg001(config)#dial-peer voice 1
geneaic2vg001(config-dial-peer)#voice-class sip session refresh

****** BEFORE THE CHANGE *******

Mar 23 10:31:45.248: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:0232282750@192.168.240.20:5060 SIP/2.0
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bKhee5hq103g3h299jm431cmsp90n13.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1640860859-1490224603520-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=66B126F4-1974
Call-ID: BW101643520230317-1846521292@210.193.202.4
CSeq: 1009217731 UPDATE
Contact: <sip:0428842486@210.193.202.100:5060;transport=udp>
Supported: timer
Min-SE: 1800
Session-Expires: 1800;refresher=uac
Max-Forwards: 29
Content-Length: 0

Mar 23 10:31:45.252: //1258857/7263E0D597B2/SIP/Msg/ccsipDisplayMsg:
Sent:
UPDATE sip:0232282750@192.168.240.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.240.20:5060;branch=z9hG4bKA2A101A89
From: <sip:+61428842486@macquarietelecom.com>;tag=66B126B8-570
To: <sip:0232282750@192.168.240.10>;tag=9418806~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28985743
Date: Wed, 22 Mar 2017 23:16:43 GMT
Call-ID: 726519BD-E8C11E7-97B8AB1C-AE5BD661@192.168.240.20
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Max-Forwards: 70
Supported: timer,resource-priority,replaces,sdp-anat
Timestamp: 1490225505
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 UPDATE
Contact: <sip:+61428842486@192.168.240.20:5060>
Min-SE: 1800
Content-Length: 0

Mar 23 10:31:45.252: //1258856/7263E0D597B2/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bKhee5hq103g3h299jm431cmsp90n13.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1640860859-1490224603520-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=66B126F4-1974
Date: Wed, 22 Mar 2017 23:31:45 GMT
Call-ID: BW101643520230317-1846521292@210.193.202.4
Server: Cisco-SIPGateway/IOS-15.5.1.T2
CSeq: 1009217731 UPDATE
Allow-Events: telephone-event
Contact: <sip:0232282750@192.168.240.20:5060>
Supported: timer
Content-Length: 0

Mar 23 10:31:45.256: //1258857/7263E0D597B2/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.240.20:5060;branch=z9hG4bKA2A101A89
From: <sip:+61428842486@macquarietelecom.com>;tag=66B126B8-570
To: <sip:0232282750@192.168.240.10>;tag=9418806~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28985743
Date: Wed, 22 Mar 2017 23:31:45 GMT
Call-ID: 726519BD-E8C11E7-97B8AB1C-AE5BD661@192.168.240.20
Server: Cisco-CUCM11.5
CSeq: 102 UPDATE
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-ID: 000066cd00105000a00000059a3c7800;remote=24d15a06715421e863228f8ab9418806
P-Asserted-Identity: “Ben Morgan” <sip:2750@192.168.240.10>
Remote-Party-ID: “Ben Morgan” <sip:2750@192.168.240.10>;party=called;screen=yes;privacy=off
Contact: <sip:0232282750@192.168.240.10:5060>;+u.sip!devicename.ccm.cisco.com=”CSFBENMORGAN”;video;bfcp
Content-Length: 0

****** AFTER THE CHANGE *******

Mar 23 01:08:37.492: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:0232282750@192.168.241.20:5060 SIP/2.0
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bK13p7q400b01053t5s670cms1eq4b3.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1132754884-1490226813863-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=5C0C230-1AB1
Call-ID: BW105333863230317-1887904559@210.193.202.4
CSeq: 1010322902 UPDATE
Contact: <sip:0428842486@210.193.202.100:5060;transport=udp>
Supported: timer
Min-SE: 1800
Session-Expires: 1800;refresher=uac
Max-Forwards: 29
Content-Length: 0

Mar 23 01:08:37.492: //667358/97DC18C3A58D/SIP/Msg/ccsipDisplayMsg:
Sent:
UPDATE sip:0232282750@192.168.240.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.241.20:5060;branch=z9hG4bK892821863
From: <sip:+61428842486@macquarietelecom.com>;tag=5C0C20C-15FA
To: <sip:0232282750@192.168.240.10>;tag=9427326~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28987887
Date: Wed, 22 Mar 2017 23:53:33 GMT
Call-ID: 97DD5113-E9111E7-A593BCA3-13A15289@192.168.241.20
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Max-Forwards: 70
Supported: timer,resource-priority,replaces,sdp-anat
Timestamp: 1490227717
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 UPDATE
Contact: <sip:+61428842486@192.168.241.20:5060>
Min-SE: 1800
Session-Expires: 1800;refresher=uac
Content-Length: 0

Mar 23 01:08:37.496: //667357/97DC18C3A58D/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bK13p7q400b01053t5s670cms1eq4b3.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1132754884-1490226813863-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=5C0C230-1AB1
Date: Thu, 23 Mar 2017 00:08:37 GMT
Call-ID: BW105333863230317-1887904559@210.193.202.4
Server: Cisco-SIPGateway/IOS-15.5.1.T2
CSeq: 1010322902 UPDATE
Allow-Events: telephone-event
Contact: <sip:0232282750@192.168.241.20:5060>
Session-Expires: 1800;refresher=uac
Require: timer
Supported: timer
Content-Length: 0

Mar 23 01:08:37.500: //667358/97DC18C3A58D/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.241.20:5060;branch=z9hG4bK892821863
From: <sip:+61428842486@macquarietelecom.com>;tag=5C0C20C-15FA
To: <sip:0232282750@192.168.240.10>;tag=9427326~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28987887
Date: Thu, 23 Mar 2017 00:08:37 GMT
Call-ID: 97DD5113-E9111E7-A593BCA3-13A15289@192.168.241.20
Server: Cisco-CUCM11.5
CSeq: 102 UPDATE
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
Require: timer
Session-ID: 0000190000105000a00000059a3c7800;remote=3062c55c0330af1676d56a3ab9427326
P-Asserted-Identity: “Ben Morgan” <sip:2750@192.168.240.10>
Remote-Party-ID: “Ben Morgan” <sip:2750@192.168.240.10>;party=called;screen=yes;privacy=off
Contact: <sip:0232282750@192.168.240.10:5060>;+u.sip!devicename.ccm.cisco.com=”CSFBENMORGAN”;video;bfcp
Content-Length: 0

As we can now see the CUBE passes the Session-Expires SIP Header through to the CUCM Server. The call can now keep refreshing and remain up long past 30 mins.

Mar 22

Upgrading the Expressway Cluster from v8.7 to v8.9 – Take Note

Quick note on the upgrade process from Expressway Cluster v8.7 and below to v8.8 and above. The database synchronisation/replication ports have changed slightly. 8.7 and previous uses UDP 500 (IKE) and AH 51. DB traffic is encapsulated in this header. As from 8.8 no more encapsulation with AH. TCP ports 4371 – 4372 are used as direct synchronisation/replication. Ensure these ports open on any firewall between the cluster peers.

Mar 20

Cisco Unity Connection – Saving Voice Messages

Cisco Unity Connection Administration.

Ensure the ‘Web Inbox’ permissions are enabled in the relevant Class of Service. The Class of Service is found in Unity Connection under ‘Class of Service -> Class of Service’ then selecting the relevant Class of Service for the user.

Cisco Unity Connection Web Inbox

Web Inbox

To access the web Inbox use the URL https://ciscounityserver/inbox

Once logged in select the Voice Message to download

Cisco Unity Connection Web Inbox

Right-click ‘message.wav’ and select Save Link As. Select the appropriate destination folder and select Save.

Cisco Unity Connection Web Inbox

Can now play voice message using PC/laptop installed media player.

Cisco Unity Connection Web Inbox

Dec 05

Cisco MRA Jabber – Cannot Communicate with Server – Reverse DNS

Another “Cannot Communicate with Server” error when logging into Cisco Jabber. This error can lead to many possibilities of where the actual error lies. You will need to do some digging. I come across a doozy and have documented below. But this relates to the newer version on Expressway 8.8+ which now also queries reverse DNS zones to confirm operations. If PTR records are missing or mis-configured you will know about it..

The symptoms I received were as follows:

- I could resolve the SRV record and A records
- I could log into Jabber from within the Corporate LAN
- If I typed an incorrect password, I would receive “Username or Password is incorrect” message
- If I typed in the correct password, I would receive the infamous “Cannot Communication with Server” error.

Versions I’m running:

- CUCM/IMP version 11.0.1.21900
- Expressway version 8.8.1

Processes and Solution (to this particular scenario):

- Expressway-E Event Log showing Service Unavailable – 503 error.
MRA Jabber- Set the ‘network’, ‘network tcp’ and ‘network sip’ diagnostic logging to DEBUG.
- Attempted to log into Jabber. Captured and Downloaded logs.
- Analysed log file and found this line. “Detail=Certificate verification failed for host=X.X.X.X, additional info: Invalid Hostname cor8-ppp2557.per.dsl.connect.net.au”
- Discovered a PTR record for my exact Expressway-E’s A Record had been created somewhere on the Web, and when the Expressway-C was actioning a Reverse DNS Lookup Query, this PTR record was being found. What are the chances hey??
- I had to create a Reverse Lookup Zoen for the Expressway-E Public IP Address, add the correct PTR record. Once I flushed DNS.. Everything started to work fine and I could log into Jabber remote.

**Leaving Thoughts.. As I’ve also found in CUCM version 11.5, reverse DNS plays a very important role now.. Make sure all A records have PTR records and only one!

Nov 25

DNS Unreachable Warning – CUCM Version 11.x

Recently upgraded a UC environement from 10.5 to 11.5. After the upgrade was complete, the CUCM Publisher server displayed a “DNS Unreachable” error upon logging into the Administration webpage.

cucm-dns-warning-1

This warning message only appeared on the CUCM Publisher and not the subscriber etc. I confirmed DNS had been configured identically for both the publisher and subscriber. I read that CUCM Version 11.x no does a couple of more network tests that have a direct impact on warning/error messages being displayed on the GUI. One of these tests is against the DNS Reverse Lookup Zone. Pre 11.x versions.. The CUCM server would check to see if a PTR record existed for the hostname, in fact this is required for CUCM installation process to succeed. In version 11.x the CUCM now also continuously checks against the Reverse Lookup Zone for mismatches and displays a warning message on the GUI. In my case, the customer had created an additional A Record for user friendly purposes called myphone.domain.com.au, this automatically created a PTR record. So when CUCM ran checks against the Reverse Lookup Zone, the results displayed a mismatch. Hence the warning was raised and displayed. (Although DNS was functioning perfectly)

Removing this PTR Record resolved the issue with the warning message.

I ran the command “utils diagnose test” to pin point the issue.

cucm-dns-warning-2

Nov 20

Forward Voicemail Messages with Jabber 11.8+

From Cisco Jabber 11.8+, users can forward voice messages to other user mailboxes. One very good feature is Cisco Jabber also allows the user to record a header message that gets attached to the original voice message. This is also available for Jabber on mobile devices.

In Cisco Jabber navigate to the Voice Messages tab, then right click the voice message and select ‘Forward Voice Message’

cisco-voicemail-forward-1

A window now opens, which allows you to record a message. You can then playback the recorded message, re-record etc.

cisco-voicemail-forward-2

Once happy with the recorded voice message, search for users in the directory. (NOTE: users must have a voice mailbox). You can also select multiple recipients.

cisco-voicemail-forward-3

Nov 05

Cisco Mediasense 11.5(1) – Role Based Access for Finesse Agents

Mediasense 11.5(1) has introduced the long awaited role based access for Finesse Agent and Supervisors. Finesse Supervisors can monitor the recordings of only their assigned Teams, while Finesse Agents can only view their own recordings. Recordings include active recordings, associated recordings and archived recordings.

For the above to work, the Finesse AgentInfo gadget is required to be active for both Agents and Supervisors. This feature only applies to Finesse Integrated Contact Centres.

To reference additional 11.5(1) features for Mediasense, please use the below link.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_11_5/release/guide/RCCT_BK_U98D7FB5_00_uccx-solution-release-notes-115/RCCT_BK_U98D7FB5_00_uccx-solution-release-notes-115_chapter_0101.html