Tuesday, July 29, 2014

How to configure Call monitoring for UCCX

Hi Guys!

UCCX is a great contact center. The supervisor desktop, which I always dismissed as not being that good, actually has some great new features that we will cover off later. For now I am going to talk about how to configure UCCX Call monitoring.

Call monitoring allows you to listen in on an agents conversation, it plays through your PC speakers. The call does NOT have to be an ACD calls because it basically works via SPAN.

The way it works is that the agent software sends the RTP stream to the supervisors PC, it does this because the phone has "SPAN to PC" option configured.

This is found under the phone itself:

Next, you simply select an recording server for the user. This is found under the Desktop administration drop box in the corner of UCCX (top right hand corner)

On the side menu, expand out multiline, monitoring and recording and select VoIP monitoring device

We are done! Setup is ready to go, you will need to relogin to the agent and supervsior and don't forget to reset the phone.

From here you simply go to the supervisor desktop, highlight the user and click "voice monitor"
That's it! Easy as that

Friday, July 25, 2014

Retrieve MOH files


  1. Connect (using SSH) to the CUCM node that has the MoH audio server role or the publisher node.
  2. To list the music files use the command: file list activelog mohprep.
  3. You will see a list of MoH files in various formats (ulaw, alaw, g729, etc.). Identify the file(s) you would like to download.
  4. Retrieve the file using the command: file get activelog mohprep/
    1. You can use specific filename: e.g. mohprep/mymohfile.ulaw.wav
    2. You can use a mask: e.g. mohprep/*.ulaw.wav

Thursday, July 24, 2014

Disabling specific log messages on the ASA to help troubleshoot

The ASA logging gives you lots of great info but it tends to have loads of info coming up all at once. I tend to do a trick where I know the IP address I am looking for, so I constantly type:

show log | inc

then I try and generate the traffic and capture the entry in the log.

However, someone else has a great way to disable specific logs


Great stuff!

Wednesday, July 16, 2014

Good looking CDR reporting tool for CUCM

Hi Guys

I just saw this CDR reporting tool for CUCM and it actually looks really good

Also please find below a really good Erlang B calculator for working out trunk sizes

Sunday, July 13, 2014

Mini UCS is finally here

Mini UCS is finally here, it has been long rumoured but has finally arrived. Data sheet does a better job of explaining it than me


Tuesday, July 8, 2014

JTAPI Testing

Hi Guys

Super useful app is available from cisco to test JTAPI and make sure that your JTAPI setup username/password etc is 100 percent correct. It's available here:


Monday, July 7, 2014

(Random collection) Random collection of bugs I uncovered during an upgrade from 8.5 to 10.5

- WORKFLOW does not get copied over with a DRS (no reason codes etc)
- Bug with headsets and 79XX handsets means transfers will not work correctly
- ITL will have issues  (show itl in the console)
-  watch out for JTAPI IPv6 issues causing problems with RMCM logging in
- there is an issue when doing UCCX switch version from 8.5 to 10.5
(shared memory on UCS server look for bug with that mentioned)
- CUIC login fails
- database sync has failed when going from SU3 to SU4 for 8.5

Cisco Workflow for Cisco Agent Desktop (CAD) does not get copied during DRS restore or upgrade with UCCX

Hi Guys

as per the post title, Cisco Workflow information does not get copied across with a DRS restore or a UCCX Upgrade, totally crap so be careful when your doing a UCCX upgrade

Hit this bug during a UCCX upgrade from 8.5 to 10.5


Basically you need to be sure when using JTAPI that your common device phone profile does not have IPv6 Addressing enabled, otherwise JTAPI will try and use IPv6 by default. This can cause error messages such as:

"Login failed due to a configuration error. Please ask your system administrator to associate your phone with the RM JTAPI Provider user ID according to the instructions in the administrators guide"

Another thing that can cause this issue is extension mobility, so if your sure your phone is associated to the user etc, check your common device profile for IPv6 addressing mode as well as checking for Extension mobility

Full shoutout to Amy Engineer Blog

Great Blog!


Friday, July 4, 2014

Tuesday, July 1, 2014

SIP: The (hopefully) fairly definitive Post



A lot of people seemed to like my Definitive Jumbo Frames blog entry so I was inspired to do another blog post on SIP and try and be as exhaustive on the topic as I can. SIP trunks are becoming more and more important. So here is my attempt to be thorough and document it.


We have already spoken earlier about the importance of SDP and why it plays such a crucial role in SIP, but an SDP datagram contains a particular IP address that is very important:

The connection address controls what address other end will attempt to connect to, as you can see in this output the IP address is a private address. This is often caused by the use of NAT obviously and can lead to many problems, the most common is one way audio. 
There are several ways that we can overcome this.

Client-Server Methods


STUN, which stands for Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators was one of the earlier methods to resolve some of these issues, it is useful in some scenarios.

The client will attempt to discover a STUN server that will help it determine it's outside IP address so that the client is then smart enough to change the SDP packet that it sends out to reflect the true IP address. Simple and elegant.

The great thing about STUN too is that the server or VOIP provider your using for VOIP doesn't necesseraily have to be your STUN server. A STUN server is an optional part of SIP and does not have to be implemented, CUCM does not implement it for example.

There are several STUN servers available out on the internet, stun.counterpath.com for example, which we will configure to show how STUN works below:


Router Methods (Interception Methods)


So, what are we going to try and cover in this post.. Pretty much everything.

We will start by talking about SIP theory and going through SIP theory in great detail, This will involve quite a few wireshark and packet capture outputs, we will dissect common SIP call flows as well as SIP registrations.

We will clear up SIP terminology to make our lives easier.

Next, we will look at DTMF digits, Redirects and other things

Then, we will start getting into more Cisco-Specific things like:
  • What is CUBE?
  • Why do I need it?
  • When can I get away without CUBE and just have a SIP trunk straight from CUCM? Why would I want/Not Want to do that?
  • When do I need an MTP
  • SIP Normalization 
  • SIP Profiles/SIP Trunks
  • Explore Voice gateway SIP config options and see what they can do for us.
OK let's go over some of the tools

I am going to assume you already have wireshark or your favorite packet capture utility, so that's all good, next you will want a SIP soft phone that registers directly to a SIP provider and/or SIP trunk itself for the purpose of our testing.

A good one that exists for both Mac and Windows is X-lite, it's an absolute pain to find the correct download link as there is two versions, one is a free version and one is a paid product. I am sure the paid product has lots of great features that might be useful but in this example I only use the free one.


Next, we need to get a SIP trunk to test with. I am convinced that if your going to implement SIP for the first time, your better off trying it out in a test environment first to make sure your comfortable with the configuration. I looked for a SIP provider who was sort of like "pre-paid" were I didn't have to sign up and pay a monthly fee.

I found net2phone and I am quite happy with them (disclaimer: I was given absolutely NO incentive from net2phone to say this, I'm just a happy customer) but please replace net2phone with whoever you would prefer to use.


SIP Theory

(Please note, much of this content is paraphrased and collected from other great great sites with great information, a List of reference sites will be included)

( Site Links:



SIP Failover/Redundancy



How to show DTMF:

show call active voice | inc tx_DtmfRelay

Troubleshooting command to check out:

#show sip-ua calls

PeterCCIE18371#show sip-ua statistics
SIP Response Statistics (Inbound/Outbound)
Trying 121/283, Ringing 116/109,
Forwarded 0/0, Queued 0/0,
SessionProgress 3/3
OkInvite 100/255, OkBye 88/61,
OkCancel 31/42, OkOptions 0/0,
OkPrack 2/2, OkRegister 0/408
OkSubscribe 82/157, OkNotify 2059/180, OkPublish 0/0
OkInfo 0/0, OkUpdate 6/14,
202Accepted 0/0, OkOptions 0/0
Redirection (Inbound only except for MovedTemp(Inbound/Outbound)) :
MultipleChoice 2, MovedPermanently 0,
MovedTemporarily 20/11, UseProxy 0,
AlternateService 0
Client Error:
BadRequest 0/0, Unauthorized 0/39366,
PaymentRequired 0/0, Forbidden 0/0,
NotFound 4/1331, MethodNotAllowed 0/0,
NotAcceptable 0/0, ProxyAuthReqd 0/0,
ReqTimeout 0/0, Conflict 0/0, Gone 0/0,
ConditionalRequestFailed 0/0,
ReqEntityTooLarge 0/0, ReqURITooLarge 0/0,
UnsupportedMediaType 0/0, UnsupportedURIScheme 0/0,
BadExtension 0/0, IntervalTooBrief 0/0,
TempNotAvailable 0/0, CallLegNonExistent 3389/77,
LoopDetected 0/0, TooManyHops 0/0,
AddrIncomplete 0/0, Ambiguous 0/0,
BusyHere 0/2, RequestCancel 32/42,
NotAcceptableMedia 0/0, BadEvent 0/5,
SETooSmall 0/0, , RequestPending 0/0
UnsupportedResourcePriority 0/0
Server Error:
InternalError 0/3, NotImplemented 0/0,
BadGateway 0/0, ServiceUnavail 5/2,
GatewayTimeout 0/0, BadSipVer 0/0,
PreCondFailure 0/0
Global Failure:
BusyEverywhere 0/0, Decline 0/0,
NotExistAnywhere 0/0, NotAcceptable 0/0
Miscellaneous counters:
RedirectRspMappedToClientErr 0

SIP Total Traffic Statistics (Inbound/Outbound)
Invite 283/160, Ack 290/159, Bye 62/89,
Cancel 45/32, Options 0/0,
Prack 2/2, Update 14/6,
Subscribe 1738/3684, Notify 257/27750, Publish 0/0
Refer 0/0, Info 0/0,
Register 41203/0

Retry Statistics
Invite 8, Bye 1, Cancel 1, Response 45,
Prack 0, Reliable1xx 0, Notify 24177, Info 0
Register 0 Subscribe 202 Update 0 Options 0
Publish 0

Right now i am studying SIP, and it is talking about DTMF-Relay.

To cut a long story short: DTMF-Relay for SIP dial-peers is RTPE-NTE, RTP-NTE is in-band signalling, meaning it is part of the RTP stream, the problem is that SCCP Phones don't understand RTP-NTE! So they cannot send or receive the DTMF tones correctly.

The way to resolve this is to either:

1. Run an MTP and enable this for the trunk for CUCM (this is your only option in CUCM 4)
2. Change the dtmf-relay method on the dial-peer using

#dial-peer voice 999 voip

Now, the thing is, when i tried thsi with my SIP provider it failed miserably, that is because the SIP provider is expecting the digits as SIP-NOTIFY, the cisco routers have a solution to this too..

for gateways running CCME with SIP trunks, you need to configure RTP-NTE. This will convert the signalling received from the SCCP phones to Named Telephony Event (Which is an RFC supported by most SIP providers.)

Here is some more info i found:

The last blog entry covered DTMF relay. This blog entry will focus on Cisco IP Phone and Cisco SIP Trunk DTMF relay support. Cisco’s first generation of IP phones do not support RFC2833 DTMF-Relay. All digits are sent out of band in either SCCP or SIP signaling packets depending on the phone load. Cisco first generation phones are referred to as Type A phones in the Cisco Unified Communications Manager 6.x SRND (Solution Reference Network Design) guide available at www.cisco.com/go/srnd. Type A phones include the following phones:
• 7902
• 7905
• 7910
• 7912
• 7940
• 7960
Cisco’s second generation phones support RFC2833 DTMF Relay when registered with Cisco Unified Call Manager versions 5.0 and later. These phones include the following:
• 7906
• 7911
• 7941
• 7942
• 7945
• 7961
• 7962
• 7965
• 7970
• 7971
• 7975

Source; http://www.networkworld.com/community/node/30207

# ---- Opinion Section ----#
SIP is yet another topic that does my head in, a "standard" that no one seems to implement in the same way, meant to be our engine for voice, video and IM until XMPP came on the scene, ridiculous restrictions from Telcos with SIP such as this idea of "Concurrent call" pricing, as if it's an ISDN line where each physical line actually costs them money. They could very easily give you as many channels as you had bandwidth but they LOVE the concurrent call business model even if they can't justify it technically (a lot like SMS: costs them literally nothing to send but they still charge for it.)

But, there is no getting around it that SIP is here to stay. Almost all new PSTN connections in the united states now are SIP based. 

SIP also offers some exciting concepts such as URI dialing, I am absolutely positive that eventually we will do away with the antiquated notion of telephone numbers and instead will start to rely on URI dialling heavily, It wouldn't be terribly difficult for someone like apple to say "Guess what! You don't have to remember peoples telephone numbers, if you know they have an IPhone you can ring them at their App Store registered email address." 

Maybe it will be some other system, but I am convinced telephone numbers are going to go away at some point.

# ---- Opinion Section ----#