Archive for August, 2012

One of our customer reported an issue with ring back tone when calling their Contact center.

I made a test call and observed that as a caller when you call their main Contact center number all you hear is dead silence and then when agent picks up the phone you could hear them talk. There was no ring back tone and no automated messages before an agent picks up the call.

The call flow was something like this:

PSTN > ISDN30 > H323 Dial-peer > SIP Trunk > 3rd-party Contact Center Equipment

First I thought it could be the third-party equipment which was not sending back the ring back tone so I asked them to confirm this. They came back saying they are definitely sending ring back and there was no issue with their equipment.

Looking at Q931 debugs I could see ALERTING message with payload but wasn’t sure why there was no ring back.

The dial-peers were looking ok as well:

!

dial-peer voice 8500 voip
corlist outgoing CCM
description DC1CCM01
preference 1
destination-pattern 361[01].
progress_ind setup enable 3
progress_ind alert enable 8
session target ipv4:10.1.30.12
dtmf-relay h245-signal h245-alphanumeric
no vad

!

dial-peer voice 8501 voip
corlist outgoing CCM
description DC1CCM02 Cycos Ansage
preference 2
destination-pattern 361[01].
progress_ind setup enable 3
progress_ind alert enable 8
session target ipv4:10.1.30.13
dtmf-relay h245-signal h245-alphanumeric
no vad
!
I then decided to run some debugs to get a complete picture as to what is going wrong. These were the debugs I opened on the gateway:

debug voip ccapi inout
debug cch323 all
debug h225 asn1
debug h245 asn1
debug ip tcp trans
debug ccsip all

Collected debugs in the following manner:

Router(config)# service sequence
Router(config)# service timestamps debug datetime localtime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Note: Please be very careful when you run the above debugs as these are processor intensive and make sure you are not logging monitor and console.

The debugs were massive but this is what I observed:

From Gateway traces I can see RINGBACK has definitely been sent to Gateway –

005302: *Aug 25 23:44:07.256: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type ALERTIND_CHOSEN
005303: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: ====== PI = 0
005304: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: alert ind ie_bit_mask 0x1260, displayInfo
005305: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: delay H245 address in alert
005306: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: Call Manager detected
005307: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_h225_receiver: ALERTIND_CHOSEN: src address = 10.187.10.8; dest address = 10.1.30.12
005308: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/run_h225_sm: Received event H225_EV_ALERT_IND while at state H225_REQ_FS_CALLPROC
005309: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_get_embedded_obj_from_ccb: ccb=0x4715D7A0, tag=18, size=83
005310: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_get_embedded_obj_from_ccb: Extraction FAILED
005311: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_set_called_ccm_detected:
CallInfo(called ccm detected=TRUE ccmVersion 3)
005312: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_set_delay_xport:
CallInfo(delay xport=TRUE)
005313: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_call_alert:
Interface=0x46B2BAA8, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
005314: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_call_alert:
Call Entry(Retry Count=0, Responsed=TRUE)
005315: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_h225_set_new_state: Changing from H225_REQ_FS_CALLPROC state to H225_REQ_FS_ALERT state
005316: *Aug 25 23:44:07.260: //3609/D48C17148501/CCAPI/ccCallAlert:
Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)

Then ALERTING Signal shown in ISDN Q931 debug:

005331: *Aug 25 23:44:07.264: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x803A

But then Observed this:

005332: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/h323_open_rtp_stream: Media In-active notification object not attached to ccb
005333: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_set_dtmf_iw_enabled: negotiated dtmf relay: 0, dtmf_iw_enabled: 0, dtmf_sccp_enabled: 0
005334: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_caps_ind: gw_id=1
005335: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_peer_caps_ind_common: Load DSP with Preferred codec(16) g729r8, Bytes=20
005336: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_peer_caps_ind_common: Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
005337: *Aug 25 23:44:07.396: TCP0: ACK timeout timer expired
005338: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 2 Event 0x1
005339: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x46DA9F30, len=53, msgPtr=0x475C62BC
005340: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.225

I was a bit surprised as to why G729 codec was negotiated when the whole path is G711. Even the SIP trunk was in all-G711 region.

Looking closely at dial-peers I found what was missing!! The VOIP dial-peers were missing the “Voice class codec 1” command which had G711 as priority 1 codec. As the command was not there, the call was matching dial-peer 0 and hence negotiating G729 codec. I added the command and the problem was solved. I can now hear ring back tone as well as all automated messages.

This is how it looks after I made the changes:

005935: *Aug 26 00:15:26.432: //3620/349708E58506/H323/h323_open_rtp_stream: Media In-active notification object not attached to ccb
005936: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_set_dtmf_iw_enabled: negotiated dtmf relay: 0, dtmf_iw_enabled: 0, dtmf_sccp_enabled: 0
005937: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_caps_ind: gw_id=1
005938: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_peer_caps_ind_common: Load DSP with Preferred codec(5) g711ulaw, Bytes=160
005939: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_peer_caps_ind_common: Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
005940: *Aug 26 00:15:26.568: TCP0: ACK timeout timer expired
005941: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 2 Event 0x1
005942: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x46DAB900, len=53, msgPtr=0x475C5200
005943: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.225
005944: *Aug 26 00:15:26.620: H225.0 INCOMING ENCODE BUFFER::= 28501900060008914A0005003497A50DEE3911E19D37B87571A7872310800100
005945: *Aug 26 00:15:26.620:
005946: *Aug 26 00:15:26.620: H225.0 INCOMING PDU ::=

Most of the time problems like these are Codec or MRG related so it’s always a good idea to start checking your codecs first.

Scenario#41 – Mailbox in use

Posted: August 14, 2012 in CUE
Tags: , , , ,

A customer reported an issue regarding a user where if she tried to listen to her voicemail messages she would get “Mailbox is in use”.

This issue normally happens if any TUI session or VoiceView sessions are open in any other phones having access to that GDM or the ports have become stuck or busy.
To resolve the issue, login to CLI of CUE module and issue this command:

voicemail mailbox unlock owner Natasha

OR

voicemail mailbox unlock telephonenumber 6311

 

Customer reported a problem about their UCCX version 8.5.1.11001-35 for CAD Agents.

This is what they say about the problem:

We have a UCCX Agent with a 9951 Cisco Phone with 2 Lines.
First line is the private Line
Second Line is the agent Line.
Agent is logged into CAD with his agent extension.

Contact Center gets a customer call for the agent and the agent accepts the call on Agent Line.
Then the agent wants to ask a colleague or wants to transfer the call and presses the call transfer key (on CAD)
The transferred Call is answered by the colleague and they start talking.
The customer hears Music on hold.
So far everything is normal.

Now a new call comes in on the private Line and hits the CFNA to voicemail, or the caller hangs up.

The issue is that at that point with no interaction of the agent or his colleague the transferred Call from the agent to the colleague gets disconnected.

After the issue occurs the call from the private line is on the voicemail.
And the first call (Contact center) still hears music on hold.

This is the fact on all of our phones when an agent is logged in with CAD.

= = =

Later we found there was a bug CSCts44173 hitting this UCCX Version so we asked customer to upgrade to a fixed Version. Customer upgraded the UCCX to 8.5.1.11003-32 but the issue was there for external calls. Calling internally fixed the issue.

After going through the logs we found that the person who was testing had a “Remote destination” setup for his mobile number and this is why they were facing the issue.

So, when customer is facing this very issue make sure they are not using “remote destination” setup.

You may have come across this that though you are logged into your profile through Extension mobility but when you try to access your “Personal Directory” you will be prompted for a userid and pin. Unfortunately, this is by design and cannot be changed. There is a workaround to escape entering userid and pin which I found after getting several requests from customers. If you are among one of those who is annoyed with this then following is the procedure to get rid of it. You will need Admin rights on Call manager to make these changes.

  1. Create a new phone service for Personal directory named PAB
  2. Use this URL http://server-name-or-ipaddr:8080/ccmpd/login.do?name=#DEVICENAME#&service=​pab​
  3. Add the Parameters “name” “pin” and “userid” with no default value (Case sensitive)
  4. Now go to the phone and Subscribe to “PAB”
  5. In the name field enter Phone MAC address with SEP like SEPAABBCCDD9876
  6. In the pin field enter user pin
  7. In the user id enter user id of that user
  8. Click Subscribe and save
  9. Reset the phone

This will now add a  new service called “PAB” under services so you can go in Service and select “PAB” to go directly into Personal directory and the system will not ask you userid and pin.

You may also add this service to a button on the phone. Just add a Service URL type on your phone from “button template” and then you can access PD from that button.

You may also ask users to subscribe to this service by logging into CCMUSER and then adding this service from Device > Services.

The same procedure applies for FASTDIALS except the following changes:

  1. Name the new Service FastDials
  2. The URL is http://server-name-or-ipaddr:8080/ccmpd/login.do?name=#DEVICENAME#&service=​fd
  3. Add only “pin” and “userid” in Parameters
  4. Subscriber Phone or user to this service

Here are screenshots from my Communicator as how this service will appear: