Failure During Switch-Version: ERROR: Acquiring lock failed

Do you really want to switch between versions ?

Enter (yes/no)? yes
Switching Version and Restarting the Appliance …

Switch version duration can vary depending on the database size
and platform configuration. Please continue to monitor the
switchover process from here.
Waiting ……………………………………

Operation failed

ERROR: Acquiring lock failed

Easily solved with a simple reboot, then retry on the switch-version.

If this does fail, next steps would be:

  • Switch-version using Recovery CD
  • TAC case with Remote Account, and TAC to edit GRUB configuration file

 

#dontcalltac

Tagged , , , ,

VMware Tools 10.0 Update Failures Creates Outage – CSCux90747, CSCva09767, CSCuy84075

A friend hit this delightful defect this week:

 

 

There are several workarounds, but ultimately there’s a COP file for this – ciscocm.VMwareTools2016c.cop.sgn.  The attached defects cover several initial install and help-me-its-dead scenarios.

 

It’s a bit of a horror.  Watch out for those VMWare tools updates!

 

#dontcalltac

Tagged , , , , , , , , ,

Adding Self-Signed Certificates to Ubuntu Trust Store

I’ve been testing AXL calls using Python, and encountered the following error:

 

Traceback (most recent call last):
 File "./axl_test.py", line 14, in <module>
 result = client.service.listPhone({'name':'SEP%'},{'name':'','model':''})
 File "/usr/lib/python2.7/dist-packages/suds/client.py", line 566, in __call__
 return client.invoke(args, kwargs)
 File "/usr/lib/python2.7/dist-packages/suds/client.py", line 705, in invoke
 result = self.send(soapenv)
 File "/usr/lib/python2.7/dist-packages/suds/client.py", line 747, in send
 reply = self.options.transport.send(request)
 File "/usr/lib/python2.7/dist-packages/suds/transport/https.py", line 66, in send
 return HttpTransport.send(self, request)
 File "/usr/lib/python2.7/dist-packages/suds/transport/http.py", line 80, in send
 fp = self.u2open(u2request)
 File "/usr/lib/python2.7/dist-packages/suds/transport/http.py", line 127, in u2open
 return url.open(u2request, timeout=tm)
 File "/usr/lib/python2.7/urllib2.py", line 429, in open
 response = self._open(req, data)
 File "/usr/lib/python2.7/urllib2.py", line 447, in _open
 '_open', req)
 File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
 result = func(*args)
 File "/usr/lib/python2.7/urllib2.py", line 1241, in https_open
 context=self._context)
 File "/usr/lib/python2.7/urllib2.py", line 1198, in do_open
 raise URLError(err)
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)>

 

This is an easy one, as I’m connecting from my Ubuntu machine to CUCM that’s has a self-signed certificate.  I need to add this to my Ubuntu trust store.

 

Steps to resolve are:

 

  1. Install mycertifcate.pem to local machine

  2. cp to /usr/local/share/ca-certificates

  3. Rename certificate to mycertificate.crt

  4. sudo update-ca-certificates

 

jonathan@mymachine:/usr/local/share/ca-certificates$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs…
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d…

Adding debian:mycertifcate.pem
done.
done.

 

The certificate will now be concatenated to /etc/ssl/certs/ca-certificates.crt and will be trusted as required.

Tagged , , ,

CSCux67499 – SQL NullPointer Exception causes CUC Subscriber Sync Failures

The later version (11.0 – 11.2) of PCP have a fairly painful caveat when it comes to Unity Connection.  CUC is currently afflicted by a(nother) horrid Informix problem that will cause subscriber sync failures.

 

The defect is below:

 

Unfortunately, there’s no workaround available as per the bug description:

 

Symptom:
User Sync of Unity Connection fails on Prime Collaboration Tool (PCP).
NullPointerException exception is seen in Nice log (PCP).

System or internal error java.lang.NullPointerException
java.sql.SQLException: System or internal error java.lang.NullPointerException
at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:488)
at com.informix.jdbc.IfxSqli.a(IfxSqli.java:9547)
at com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2634)
at com.informix.jdbc.IfxSqli.a(IfxSqli.java:1830)
at com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1768)
at com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1699)
at com.informix.jdbc.IfxResultSet.a(IfxResultSet.java:210)
at com.informix.jdbc.IfxStatement.executeQueryImpl(IfxStatement.java:1237)
at com.informix.jdbc.IfxPreparedStatement.executeQuery(IfxPreparedStatement.java:382)
at dfc.ipt.cisco.unity.util.UMPUtil.executeQuery(UMPUtil.java:247)

Conditions:
1) PCP User Sync in executed for Unity Connection
2) Having 5K or 20K End Users record in CUC11.x or 10.x

Workaround:
None

 

Please take note of the following, as this does affect planned PCP upgrades:

 

 

Nice work from the technical documentation team in listing out the caveat in the upgrade guide!

 

Before upgrading, you need to install an engineering special in Cisco Unity Connection(10.5.x & 11.0) for successful subscriber synchronization. Contact TAC to obtain the Cisco Unity Connection engineering special for the bug (CSCux67499). If you are using Cisco Unity Connection release below 10.5, then you must upgrade to Cisco Unity Connection version 10.5.x and then apply the engineering special.

 

A call to TAC to request an ES is going to be required (as of the date of this blog post).  Cross-reference the bug “Fixed In” details and check if this has been included in a later Unity Connection SU.  If in doubt, call TAC for  assistance.

 

 

Tagged , , ,

CSCup36072 – CUCM/CUC Patch Upgrade Fails

Hit another horror defect today…  Patch upgrades apparently do not work as of 10.5.x and up!

 

Selection_041

 

The defect is described below:

 

 

The bug details are below – only workaround is to install with a bootable image!

 

Symptom:
When doing a fresh install of a Call Manager node, there is an option to use an upgrade patch option.

For CUCM 10.5, this approach cannot be used. Not even by using the bootable image for 10.0 and upgrade file for 10.5

Conditions:
Installing CUCM 10.5 with bootable image of a lower version and upgrade file of CUCM 10.5

Workaround:
None -> Use Bootable image for CUCM 10.5 itself

 

To resolve, the only “supported” method is to request a bootable image from TAC.

 

Terrible.  Terrible.  Terrible.

Tagged , , , , ,

CSCug20588 – Auto-Reg Failure – “Could not insert new row – duplicate value in a UN”

Had an issue that’s affected multiple deployments that I’ve been working on.  At one of my clients in particular, this reached an escalation level.  Just sharing this to assist others, as we went through 4 TAC Engineers to get a root cause and eventually this was attributed to a hidden Cisco defect in 10.x and above…  The first engineer told us that we needed to rebuild an 18 node CUCM cluster from scratch to fix this!

Just sharing this to assist others, as we went through 4 TAC Engineers to get a root cause and eventually this was attributed to a hidden Cisco defect in 10.x and above…  The first engineer told us that we needed to rebuild an 18 node CUCM cluster from scratch to fix this!  Don’t always believe TAC!

 

Problem Description

 

  • Client complains that auto-registered phones are failing to register
  • Eventually determined that the phone had been previously registered and what subsequently deleted
  • Certain clients say that if they manually configure the phone, it registers
  • Phone logs show a TFTP config error

 

Went on site and noted that there were persistent DB-related syslog alarms being generated.

 

The SDL logs showed the registration failure and a syslog event was logged:

 

00024541.012 |07:28:21.243 |AppInfo |SIPStationD(269) - checkDNsReceived: TotalCount=0
00024541.013 |07:28:21.243 |AppInfo |SIPStationD(269) - sendLineRegisterReq: DN match failed for AUTO-REG
00024541.014 |07:28:21.243 |AppInfo |SIPStationD(269) - sendLineRegisterReq: Phone is autoregistering...sending 200OK followed by a restart request
00024541.015 |07:28:21.243 |AppInfo |SIPStationD(269) - buildServiceControl: Sending callid from mPrimaryLineNum 0: 0UTqUn-9I4FebBfs1swQbo.GQ78HIxyf
00024541.016 |07:28:21.243 |AppInfo |SIPStationD(269) - sendServiceControlNotify: starting servicecontrol NOTIFY timer
00024541.017 |07:28:21.243 |AppInfo |SIPStationD(269) - sendServiceControlNotify: sending service-control NOTIFY
00024541.018 |07:28:21.243 |AppInfo |EndPointTransientConnection - An endpoint attempted to register but did not complete registration Connecting Port:5060 Device name:SEPAAAABBBBCCCC Device IP address:192.168.100.123 Device type:592 Reason Code:7 Protocol:SIP Device MAC address:AAAABBBBCCCC IPAddressAttributes:0 LastSignalReceived:SIPRegisterInd StationState:auto_register App ID:Cisco CallManager Cluster ID:MYCUCM Node ID:mycucmhostame
00024541.019 |07:28:21.243 |AlarmErr |AlarmClass: CallManager, AlarmName: EndPointTransientConnection, AlarmSeverity: Error, AlarmMessage: , AlarmDescription: An endpoint attempted to register but did not complete registration, AlarmParameters: ConnectingPort:5060, DeviceName:SEPAAAABBBBCCCC, IPAddress:192.168.100.123, DeviceType:592, Reason:7, Protocol:SIP, MACAddress:AAAABBBBCCCC, IPAddrAttributes:0, LastSignalReceived:SIPRegisterInd, StationState:auto_register, AppID:Cisco CallManager, ClusterID:MYCUCM, NodeID:mycucmhostame,
00024542.000 |07:28:21.243 |AppInfo |-->RISCMAccess::DeviceTransientConnection(...)
00024543.000 |07:28:21.243 |AppInfo |Device Transient deviceName : SEPAAAABBBBCCCC, IPAddress : 192.168.100.123, IPv6Address : not shown, IPv4Attribute :0, IPv6Attribute :0, Protocol : 2
00024544.000 |07:28:21.243 |AppInfo |DebugMsg deviceName : SEPAAAABBBBCCCC, DeviceType : 592, risClass: 1
00024545.000 |07:28:21.243 |AppInfo |<--RISCMAccess::DeviceTransientConnection(...)
00024541.020 |07:28:21.243 |AppInfo |SIPStationD(269) - Received register from Cisco phone for unconfigured line AUTO-REG; shutting down
00024541.021 |07:28:21.243 |AppInfo |StationTracking::updateMismatchCount: deviceId=SEPAAAABBBBCCCC, mismatchCount=174
00024541.022 |07:28:21.243 |AppInfo |SIPStationD(269) - processVersionStampMismatch: VersionStampMismatch detected, count = 174
00024541.023 |07:28:21.243 |AppInfo |SIPStationD(269) - DevStat-StopClose: LineRegisterReq send failure

 

 

And later we in the same trace see that CUCM sends a NOTIFY for the above:

 

NOTIFY sip:AUTO-REG@192.168.100.123:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK2b1379d1903
From: <sip:192.168.1.100>;tag=789090571
To: <sip:AUTO-REG@192.168.100.123>
Call-ID: bb580e00-6df1b475-27b-247410ac@192.168.1.100
CSeq: 101 NOTIFY
Max-Forwards: 70
Date: Wed, 09 Mar 2016 05:28:21 GMT
User-Agent: Cisco-CUCM11.0
Event: service-control
Subscription-State: active
Contact: <sip:192.168.1.100:5060>
Content-Type: text/plain
Content-Length: 67

action=restart
RegisterCallId={0UTqUn-9I4FebBfs1swQbo.GQ78HIxyf}

 

I traced through the logs and saw that  soon after the NOTIFY was placed on the wire, the following was logged in SDL that highlighted the problem:

 

 

00024556.000 |07:28:21.385 |SdlSig |StationClose |wait |SIPHandler(1,100,80,1) |SIPStationInit(1,100,73,1) |1,100,10,1.591^192.168.100.123^* |[T:N-H:0,N:0,L:0,V:0,Z:0,D:0] CloseStationReason = 0 StationId = SEPAAAABBBBCCCC
00024546.004 |07:28:21.428 |AppInfo |DB: odbc::SQLException(Error fetching data from datasource: [Informix][Informix ODBC Driver][Informix]Could not insert new row - duplicate value in a UNIQUE INDEX column (Unique Index:assign).)
00024546.005 |07:28:21.429 |AppInfo |DBLException - An error occurred while performing database activities ErrorCode:-239 ExceptionString:Error fetching data from datasource: [Informix][Informix ODBC Driver][Informix]Could not insert new row - duplicate value in a UN App ID:Cisco CallManager Cluster ID:MYCUCM Node ID:mycucmhostame
00024546.006 |07:28:21.429 |AlarmErr |AlarmClass: CallManager, AlarmName: DBLException, AlarmSeverity: Alert, AlarmMessage: , AlarmDescription: An error occurred while performing database activities, AlarmParameters: ErrorCode:-239, ExceptionString:Error fetching data from datasource: [Informix][Informix ODBC Driver][Informix]Could not insert new row - duplicate value in a UN, AppID:Cisco CallManager, ClusterID:MYCUCM, NodeID:mycucmhostame,
00024546.007 |07:28:21.429 |AppInfo |dBProcs - ERROR odbc::SQLException addDevice()
00024546.008 |07:28:21.429 |AppInfo |ProcessDb - ERROR initializing_DbStationAutoRegisterReq - addDevice failed

 

So my initial thought was a bug with orphaned data.  Had to be something along this line as the SDL error was referencing a duplicate.  So , I relunctantly decided to go straight to  TAC for analysis.   I sent this off to TAC and got crickets…  The assigned engineer eventually told me this was an NTP issue which didn’t make sense at all.

Another colleague logged a similar case that we had at another client.  2 re-queues later we got a great engineer who identified  CSCug20588 as the cause of our problem.  It’s a hidden TAC case.

 

The fix?  Well, a RIDICULOUS bug!

 

When auto-registering a phone in 10.x the Auto-Reg config uses a UDT/ULT.  This results in a phone-specific Phone Button Template being created when a phone is inserted into the Informix database, of the form:

 

SEP<MAC-ADDRESS>-SIP-Individual Template

 

The damn PBT was causing the phone not to register!  This obvoiusly remained in the list of PBT’s when the phone was deleted from CUCM.  When it came to AUTO-REG the phone, CUCM clearly does not look to delete/re-add the PBT or simply use the existing one.  Thus the DB insertion error, and the problematic behaviour.

I deleted the PBT and immediately the phone registered.

There’s no fix for this in 10.x and we’re waiting on the BU to confirm an official 11.x SU that will contain the fix for this.  One to watch out for!

 

Tagged , , , ,

Interpreting MGCP Debug Parameters

I manage a number of deployments that still feature ISDN extensively, so debug mgcp packet is something that I’m reading off IOS CLI on a fairly routine basis at the moment.

There are a lot of blog posts that cover reading MGCP debugs pretty well, but one thing that I struggled with for a while was being able to quickly interpret the  debug parameters and what they stood for in each respective MGCP message.  Often these are fairly intuitive, but sometimes a quick point of reference is needed.

I looked around on Cisco forums etc., and really there just isn’t anything that covers this well.  Eventually I resorted to the RFC, and was pleasantly unsurprised that all the parameters were well tabulated and easily reference-able.

I’ve included the list below for reference, but as always it is best to go straight to RFC 3435 to get this information!

 


3.2.2 Parameter Lines

Parameter lines are composed of a parameter name, which in most cases
   is composed of one or two characters, followed by a colon, optional
   white space(s) and the parameter value.  The parameters that can be
   present in commands are defined in the following table:


    ------------------------------------------------------------------
   |Parameter name        | Code |  Parameter value                   |
   |----------------------|------|------------------------------------|
   |BearerInformation     |   B  |  See description (3.2.2.1).        |
   |CallId                |   C  |  See description (3.2.2.2).        |
   |Capabilities          |   A  |  See description (3.2.2.3).        |
   |ConnectionId          |   I  |  See description (3.2.2.5).        |
   |ConnectionMode        |   M  |  See description (3.2.2.6).        |
   |ConnectionParameters  |   P  |  See description (3.2.2.7).        |
   |DetectEvents          |   T  |  See description (3.2.2.8).        |
   |DigitMap              |   D  |  A text encoding of a digit map.   |
   |EventStates           |   ES |  See description (3.2.2.9).        |
   |LocalConnectionOptions|   L  |  See description (3.2.2.10).       |
   |MaxMGCPDatagram       |   MD |  See description (3.2.2.11).       |
   |NotifiedEntity        |   N  |  An identifier, in RFC 821 format, |
   |                      |      |  composed of an arbitrary string   |
   |                      |      |  and of the domain name of the     |
   |                      |      |  requesting entity, possibly com-  |
   |                      |      |  pleted by a port number, as in:   |
   |                      |      |    Call-agent@ca.example.net:5234  |
   |                      |      |  See also Section 3.2.1.3.         |
   |ObservedEvents        |   O  |  See description (3.2.2.12).       |
   |PackageList           |   PL |  See description (3.2.2.13).       |
   |QuarantineHandling    |   Q  |  See description (3.2.2.14).       |
   |ReasonCode            |   E  |  A string with a 3 digit integer   |
   |                      |      |  optionally followed by a set of   |
   |                      |      |  arbitrary characters (3.2.2.15).  |
   |RequestedEvents       |   R  |  See description (3.2.2.16).       |
   |RequestedInfo         |   F  |  See description (3.2.2.17).       |
   |RequestIdentifier     |   X  |  See description (3.2.2.18).       |
   |ResponseAck           |   K  |  See description (3.2.2.19).       |
   |RestartDelay          |   RD |  A number of seconds, encoded as   |
   |                      |      |  a decimal number.                 |
   |RestartMethod         |   RM |  See description (3.2.2.20).       |
   |SecondConnectionId    |   I2 |  Connection Id.                    |
   |SecondEndpointId      |   Z2 |  Endpoint Id.                      |
   |SignalRequests        |   S  |  See description (3.2.2.21).       |
   |SpecificEndPointId    |   Z  |  An identifier, in RFC 821 format, |
   |                      |      |  composed of an arbitrary string,  |
   |                      |      |  followed by an "@" followed by    |
   |                      |      |  the domain name of the gateway to |
   |                      |      |  which this endpoint is attached.  |
   |                      |      |  See also Section 3.2.1.3.         |
   |RemoteConnection-     |   RC |  Session Description.              |
   |         Descriptor   |      |                                    |
   |LocalConnection-      |   LC |  Session Description.              |
   |         Descriptor   |      |                                    |
    ------------------------------------------------------------------

   The parameters are not necessarily present in all commands.  The
   following table provides the association between parameters and
   commands.  The letter M stands for mandatory, O for optional and F
   for forbidden.  Unless otherwise specified, a parameter MUST NOT be
   present more than once.

This table is great as I can simply look up the parameter code in my MGCP packet debug and do a quick interpretation.  I also find this very handy when reading off MGCP Connection ID’s and other call-specific tracing that can be cross-referenced in SDL!


 

For example, in a simple AUEP (Audit Endpoint), we see:

 

*Jul 17 11:14:18.332: MGCP Packet received from 192.168.123.213:2427—>
AUEP 31 S0/SU2/DS1-0/1@RTR1.uc.lab MGCP 0.1
F: X, A, I
<—

What has remote side requested information on?

 

Firstly, the side has requested information in a comma-separated list:

|RequestedInfo         |   F  |

 

The list contains the following:

|RequestIdentifier     |   X  |
|Capabilities          |   A  |
|ConnectionId          |   I  |

 

Simple stuff.

 

#dontcalltac

Tagged , , , , , , ,

Cisco Meraki Managed Communciations MC74 IP Phone Released

Cisco Meraki have released a new cloud-managed phone.

mc-front

Gotta say I love the look of the elegant slim-line design.

The key to this deployment model’s appeal can be seen in the finer details of the datasheet.  Just a few highlights that piqued my interest below.

 


Hardware Specs:

  • High definition color 7” IPS backlit touchscreen display (1280×800)
  • Integrated GbE switch with passthrough port
  • Rear and side USB headset ports
  • Ambient light sensor

 

Phone Features:

  • Hold Transfer
  • Ad hoc conferencing
  • Mute
  • Visual voicemail
  • Directory
  • Interactive Voice Response
  • History
  • Extension to extension calling

Pretty standard stuff.

 

Zero Touch:

  • Meraki Communications phones benefit from zero-touch deployment. With only a serial number the network admin can remotely configure the phone for a user or meeting room. Once online it will connect to the cloud, pull down its configuration and within seconds be ready to make calls.

Very interesting!

 

Codec Support:

  • Wideband audio G.722 internal calling (G.711 for PSTN calling)

Was surprised that the datasheet appears quite limited in codec support.  Honestly, was hoping to see Opus on that list…

 

Security:

  • VoIP Fully encrypted voice and SIP signaling (TLS/SRTP)

 

Looking forward to following its mainstream adoption…  Interesting times ahead!

 

 

 

 

Tagged , , , , ,

CUBE URI-based Routing and Multiple Via Headers

Cisco introduced some pretty cool URI enhancements for CUBE from 15.4(1)T that have added some great extensions to the CUBE feature set, and specifically include some fine-grained SIP routing control.  These have been long overdue as IOS-based VoIP routing has been heavily dependent on numerical pattern matching due to Cisco’s ongoing support for H.323-style legacy configuration.

These enhancements are covered in a lovely Cisco doc here.  I’ve also blogged previously on a similar topic on how to utilize these and other new CUBE SIP features to provide Loop Prevention on CUBE.

 

To start, the basic configuration for URI dial-peer matching is somewhat trivial:

!
voice class uri voice-class-uri-tag sip|tel
    host hostname-pattern
    host ipv4:ipv4-address
    host ipv6:ipv6-address
    host dns:dns-address
    pattern uri-pattern
    user-id username-pattern
!
dial-peer voice tag voip
 session protocol sipv2
 incoming uri { from | request | to | via } voice-class-uri-tag
!

Here we see that incoming called-number is dropped and is instead routing using incoming uri.  Typically, we’d match the URI on a via header, with our voice class uri container applying a match on our preferred IP Address / DNS address.

I am referring to RFC compliant behaviour for the Via header from RFC 3261:

8.1.1.7 Via

   The Via header field indicates the transport used for the transaction
   and identifies the location where the response is to be sent.  A Via
   header field value is added only after the transport that will be
   used to reach the next hop has been selected (which may involve the
   usage of the procedures in [4]).

   When the UAC creates a request, it MUST insert a Via into that
   request.  The protocol name and protocol version in the header field
   MUST be SIP and 2.0, respectively.  The Via header field value MUST
   contain a branch parameter.  This parameter is used to identify the
   transaction created by that request.  This parameter is used by both
   the client and the server.

Here we note that a SIP Request can contain multiple Via headers.  This is used as a loop prevention mechanism for SIP Routing.  This becomes incredibly import when multiple SIP Proxies forward requests.  This is well described here for the SIP initiate.

 

With this in mind, I came across an interesting scenario recently where a call route through an ITSP’s SIP Proxy network changed without my knowledge, meaning that the Via header ordered list in the inbound INVITE changed.  This resulted in not matching my voice class uri configuration.  This stymied me at first until I noted the following for this feature:

In a scenario where multiple SIP hops are involved in a call, there would 
be multiple via headers involved, and the topmost via header of an 
incoming SIP invite represents the last hop that forwarded the SIP 
request, and the bottom-most via header would represent the originator 
of the SIP request. This feature supports matching by the last hop that 
forwarded the request (neighboringSIPentity), which is the topmost via 
header.

 

From the PDF link’s worked examples, we can see the matching will use the following behaviour:

INVITE sip:123@1.2.3.4:5060 SIP/2.0

Via: SIP/2.0/TCP 10.10.10.1:5093;branch=z9hG4bK-17716-1-0

Via: SIP/2.0/TCP 10.10.14.20:5093;branch=z9hG4bK-28280-1-0

 

In my situation, I’d been using a voice class uri that looked something like this:

!
voice class uri ITSP sip
    host ipv4:10.10.14.20
!
dial-peer voice tag voip
 session protocol sipv2
 incoming uri via ITSP
!
I would have expected the feature to consider the ordered list in decreasing priority, but the dial-peer never matched…  As per the feature description, only the “neighboringSIPentity” is considered.
Just something to note when deploying this feature in future.
#dontcalltac
Tagged , , , , , ,

CUCM Video Codec Preferences Support – CSCuw53802

Colleague called me for assistance with a video call that wouldn’t set up when dialling in to a VC bridge.

The call flow was from a Polycom endpoint to the new Conductor-managed vTS bridge that I’d installed a week before.  The endpoint could dial into the Rendezvous VC bridge, but calls only had audio.  Some additional testing showed that this wasn’t working for point-to-point calls to Jabber as well, which helped us rule out the bridge completely.

My colleague pulled a Wireshark from Jabber, and the signalling confirmed a codec support issue on the Polycom:

Jabber INVITE with H.264:

Selection_035

However, the response clearly showed that our Polycom unit didn’t like this, and marked the video streams as inactive:

Selection_036

My colleague did some reading up on our somewhat outdated Polycom unit, and we ultimately found that some release keys and a firmware upgrade would be needed.  Customer not too happy, but nothing to do here other than upgrade…

However, my colleague did post a question to me:

Can we not just set some video codec preferences for this call, or at least for the call into the VC bridge?

Well, the answer is… no!

 

As of 11.0 this is not supported.  However, thankfully this does appear to have been considered in the roadmap for CUCM 11.5:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw53802/

Selection_037

 

This is good news, as the CUCM-based video architecture is now quite mature, having gone through several iterations since it’s inception from CUCM 9.x.

As the market for Skype for Business grows, H.265 begins to create more and more headaches due to patent licensing problems, and Cisco subsequently begins to punt Thor as a potential future video standard, this new feature should hopefully solve some problems down the line.

 

#dontcalltac

Tagged , , , , , , , , , , , , , , ,
Collaboration Engineer

All things Collaboration - Posts to save for when you need them

Gerry Keleghan's Blog

A Blog about Cisco Unified Communications

ccieme

my personal journey to ccie collaboration

Striving for greatness

Thoughts on emerging tech, open source, and life

Network Experts Blog

“Knowledge comes by eyes always open and working hands.”

SIP Adventures

A unified communications blog by Andrew Prokop

The Cloverhound Blog

Cloverhound Employees Talk Unified Communications and Contact Center

Warcop

Fog navigator. Get out of the clouds. Down to earth solutions. @Warcop

Cisco Collab Engineering Tips

Michael White - CCIE #26626

Darkroomstory

Photography by Manos,

afterthenumber

Thoughts and experiences of a Cisco Collaboration engineer after clearing the CCIE lab...

Longreads

The best longform stories on the web

The Daily Post

The Art and Craft of Blogging

The WordPress.com Blog

The latest news on WordPress.com and the WordPress community.