RSS

Category Archives: 8841

New codec on the block – recording failures and CUCM 11.x

The inspiration for this post comes from spending way too much time trying to solve an issue that would have taken only minutes had I been aware of the key information I’m generously bestowing upon my fine readers today.

The problem started with reports that just 8841 phones weren’t successfully recording. I happened to have a spare 8841 phone, so I set up a line, configured recording parameters, and began testing. Sure enough – the recording failed on the spare phone.  I also happened to have a 7942 phone, set up an extension and the recording worked just fine.  Note that I had previously examined the endpoint configurations like recording server profile, Built in Bridge enabled, recording calling search space, and recording server setup for the extension.

Thinking this might be related to a SIP versus SCCP issue, I employed the RTMT to see if the audio for the SIP calls was being forked and sent to the recording server. I was able to drill into the SIP call placed to the recording server, check out the Call Flow Diagram, and confirm the recording server was invited to the party.  If you’ve not done this before, just need to log into the RTMT and navigate to Real Time Monitoring Tool -> Voice/Video -> Session Trace Log View -> Real Time Data. While snooping around all the SIP calls to the recording server, I noticed some successes belonging to 8841 phones.  Intrigued that my problem might not be model dependent, I hopped over to the recording server to see which extensions on 8841 phones *did* record successfully.  Which is where things began to make even less sense – only intermittent failures on some 8841 phones in question, others never recorded at all.

Using my any-excuse-for-a-packet-capture philosophy, I setup two 8841 phone endpoints to allow spanning to PC port and fired up Wireshark.  My test recording failed, but my packet analysis hit pay dirt.  When filtering for RTP, I saw PT=OPUS in the Info column.  Immediately, I had my answer.

I was vaguely aware the Opus codec was a thing, but I previously had no idea that 8841 phones supported the OPUS codec and that CUCM 11.X enabled the OPUS codec automagically (thanks?) – all information I gleaned from this link.

Knowing that recording servers historically hate anything that isn’t g.711 or maybe g.729, I immediately proceeded to follow the instructions from the aforementioned link to find and disable Opus for recorded phones. I previously did this for g.722 many years ago, which is why this solution stung a little, my not being aware there was a new codec on the block and to have preemptively avoided this issue entirely.

While looking at the Opus parameter, I couldn’t help but notice iSAC was new to me as well.  Sifting through my packet captures, I found RTP streams using that codec as well and so disabled it for recorded phones, too.

Below are a couple of screen shots of what you can expect to see in the SIP/SDP packets if you are experiencing this same issue. Hopefully this saves you a bit of leg work should you have some recording failures after an 11.x upgrade.

Feel free to send thanks in the form of flowers, coffee, and cheesecake.

Published 10/18/2018

Advertisements
 

Tags: , , , , , , , , , , ,

8841s and line selection woes…

Just a quick post in case there is at least one other person in the world that didn’t know this particular trick for the 8800* series phones that always go off hook on the last line used.  In case you weren’t aware that these phones had this behavior, don’t worry, as soon as you deploy one to a receptionist that handles more than a single phone line, you WILL be made aware. You may not survive the encounter, but you will know…

Should the user let you live long enough to research a solution, you will find that TAC doesn’t offer you any hope in restoring the requisite amount of receptionist happiness to keep oxygen flowing to your lungs. TAC will politely inform you that the phone is operating as designed and that you might want to buy the receptionist some flowers instead.  Okay, maybe that last part was my idea…

Technically TAC is right, you cannot force the phone back to selecting the primary line after hanging up a call that was answered or placed on any of the other lines. However, as my awesomely brilliant coworker discovered, you can change the behavior of the phone so that when calls come in they are DISPLAYED on the primary line.

This way, when the user hangs ups, the phone still has the primary line selected, even if the last call received was for one of the other lines on the phone. This mimics a behavior users have come to know and love of the older generation of phones, a behavior users who manage multiple lines desperately want back.

You can set this option on the phone configuration page, just search for Show All Calls and change the feature to Enabled.

Show All Calls on Primary Line

This won’t make the remembering-the-last-line-selected-for-off-hook behavior go away, but it does make its impact far less noticeable to end users who might otherwise want to plot your demise.

* In this case we were working with 8841 phones, but my coworker has used this trick in the past on 9971 phones, so I’d be inclined to believe this would work on pretty much any SIP phone that has this behavior. 

Published 04/11/2016

 

Tags: , , , , , ,