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

Advertisements
Tagged , , , , , , , , , , , , , , ,

Accessing the jabber-config.xml Jabber Configuration File

Often when working on Cisco Jabber installations, you will be required to edit an existing jabber-config.xml file to change client parameters or support new functionality, or simply as part of an audit or system assessment want to have a look at what customization is being used for Jabber already.

There are several ways to access the jabber-config.xml file from your CUCM/TFTP server or Jabber client PC.

When troubleshooting, it is often helpful to know the methods to view from both the TFTP server and the Jabber client PC.  Discrepancies can be a good starting point for troubleshooting.

Method 1 – CUOS

From CUOS, run the following command:

admin:file view tftp jabber-config.xml

 

Method 2 – Browser

From your browser, enter the following:

http://X.X.X.X:6970/jabber-config.xml

where X.X.X.X is the CUCM (i.e. TFTP Server) IP Address

 

Method 3 – TFTP Client

Use a TFTP Client such as Windows TFTP client or TFTPD32 and GET the jabber-config.xml file.

 

Method 4 – Windows Client PC

Fetch this from the following path:

%USERPROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config

You may need to enable showing of hidden files on the Windows desktop to reach this.

 

If you know of more, please let me know!

#dontcalltac

Tagged , , , , , ,

VoIP Bandwidth Calculations

If you’re preparing for a your CCIE Written or Lab exams, or (far more importantly) if you need to perform bandwidth sizing for a VoIP design or implementation, it’s critical to be able to accurately calculate the amount of bandwidth that your precious voice streams are going to need as they traverses your network.

Vik Mahli makes an excellent overview of what this means in terms of a QoS configuration here, but skips the calculation part altogether in order to focus on the LAN QoS config that he wished to cover in his post.  Naturally, this created some confusion which was carried over into the comments section!

I encourage you to read the comments, specifically Mark Holloway’s length post on this topic.  Mark makes an excellent reference here to the QoS SRND, and is well worth a read!  Please see this link and refer to where Mark and Vik use a 93bkps base for G.711 calls from.

Building on some of the discussions there, I’d like to provide some additional detail on how these calculations can be performed in this post.

Finally, please take note that this does not account for signalling bandwidth requirements.  This is a different discussion – ping me and I’ll blog about this too! 🙂

 

Performing VoIP Bandwidth Calculations

 

Calculation Assumptions

Firstly, we will have to make some protocol-related assumptions for sizing purposes:

  • IP – 20 bytes
  • User Datagram Protocol (UDP) – 8 bytes
  • Real-Time Transport Protocol (RTP) – 12 bytes
  • Compressed Real-Time Protocol (cRTP) reduces the IP/UDP/RTP headers to 2 or 4 bytes
  • Multilink Point-to-Point Protocol (MP) – 6 bytes
  • Frame Relay Forum (FRF).12 Layer 2 (L2)– 6 bytes
  • End-of-frame flag on MP and Frame Relay frames – 1 byte
  • Ethernet L2 headers– 18 bytes

 

Codec-Specific Information

Secondly, we need to know some values that are codec-specific:

  • Voice Payload Size
  • Codec Bitrate

Some values worth keeping in mind here are:

  • G711
    • Bit Rate – 64 kbps
    • Default Payload size – 160 bytes
  • G729
    • Bit Rate – 8 kbps
    • Default Payload size – 20 bytes
  • iLBC 20ms
    • Bit Rate – 15.2 kbps
    • Default Payload size – 38 bytes
  • iLBC 30ms
    • Bit Rate – 13.33 kbps
    • Default Payload size – 50 bytes

 

There is a detailed discussion of these values and their explanations here.  I won’t go into more detail in this post.  Please refer to the above document for clarity.

NOTE:

For differing Millesecond Packet Sizes (e.g. G.729 20ms/30ms), the codec bitrate is always constant.  Therefore the payload size can always be scaled as a ratio using the formula of:

codec bit rate = codec sample size / codec sample interval

More on this later in a worked example…

 

Bandwidth Calculation Formulas

From the TAC Online Help, we’re presented with a fairly simple calculation:

Total Packet Size = (Media Access Header - Layer 2) + (IP/UDP/RTP Header) + (voice payload)
Voice Packets Per Second (PPS) = codec bit rate / voice payload size
Bandwidth = [ (voice packet size) + 1 byte (frame flag) ] * PPS

Finally, it is best practice to allow for a 5.0% overhead in all calculations.

 

Some Worked Examples

This seems simple enough, so let’s put it into practice in some worked examples!

 

Example 1 : 3 Concurrent G.711 Calls over Ethernet

Total Packet Size = [ (18) + (40) + (160) ] = 218 bytes 

Packets per Second = [ 64 kbps * 1000 bits per kilobit ] / [ 160 bytes (default voice payload) * 8 bits per byte ]  = 50 pps

Bandwidth = [ ( 218 bytes ) + (0 bytes ) ] * 50 pps * 8 bites/byte = 87200 bits/sec = 87.2 kbps

5.0% Overhead87.2 kbps * 1.05 = 91.560 kbps

Concurrent Calls = 3 * 91.560 kbps = 274.68 kbps

 

Example 2 : 5 Concurrent G.729 Calls over PPP with Compressed RTP

Total Packet Size = [ (6) + (2) + (20) ] = 28 bytes 

Packets per Second = [ 8 kbps * 1000 bits per kilobit ] / [ 20 bytes (default voice payload) * 8 bits per byte ]  = 50 pps

Bandwidth = [ ( 28 bytes ) + (1 byte) ] * 50 pps * 8 bites/byte = 87200 bits/sec = 11.6 kbps

5.0% Overhead = 11.6 kbps * 1.05 = 12.18 kbps

Concurrent Calls = 5 * 12.18 kbps = 60.9 kbps

 

Example 3 : 10 Concurrent iLBC Calls over Ethernet using a 20ms bitrate

Total Packet Size = [ (18) + (40) + (38) ] = 96 bytes

Packets per Second =[ 15.2 kbps * 1000 bits per kilobit ]  / [ 38 bytes (default voice payload) * 8 bits per byte ]  = 50 pps

Bandwidth = [ ( 96 bytes ) + (0 bytes ) ] * 50 pps * 8 bites/byte = 38400 bits/sec = 38.4 kbps

5.0% Overhead = 38.4 kbps * 1.05 = 40.32 kbps

Concurrent Calls = 10 * 40.32 kbps = 403.20 kbps

The TAC Tool does not cover iLBC calculations, but we can see that there’s nothing special going on here.  We just needed to know the bitrate values for the codec and the calculations are effectively the same.

 

Example 4 : 5 Concurrent iLBC Calls over Ethernet using a 30ms bitrate

Total Packet Size = [ (18) + (40) + (50) ] = 108 bytes

Packets per Second =[ 13.3 kbps * 1000 bits per kilobit ]  / [ 50 bytes (default voice payload) * 8 bits per byte ]  = 33.3 pps

Bandwidth = [ ( 108 bytes ) + (0 bytes ) ] * 33.3 pps * 8 bites/byte = 28800 bits/sec = 28.8 kbps

5.0% Overhead = 28.8 kbps * 1.05 = 30.24 kbps

Concurrent Calls = 5 * 30.24 kbps = 151.20 kbps

 

Example 5 : 2 Concurrent G.729 Calls over Ethernet using a 40ms bitrate

OK, let’s end it off with a challenge 🙂

As I said above, the bitrate is always a constant for any codec:

codec bit rate = codec sample size / codec sample interval

Therefore, we will need to calculate our new Payload Sample Size for 40ms instead of 20ms:

Codec Sample Size = 8 kbps * 40ms  / (8bits/byte) = 40 bytes

See?  Not so hard!  If you’re following, you can actually see that you could have just used a ratio of:

New Payload Size = Old Payload Size * (New Sampling Interval / Old Sampling Interval)

 

OK, I digress.  Now, carrying on as before:

Total Packet Size = [ (18) + (40) + (40) ] = 98 bytes

Packets per Second =[ 8 kbps * 1000 bits per kilobit ]  / [ 40 bytes (default voice payload) * 8 bits per byte ]  = 25 pps

Bandwidth = [ ( 98 bytes ) + (0 bytes ) ] * 25 pps * 8 bites/byte = 19600 bits/sec = 19.60 kbps

5.0% Overhead =19.60 kbps * 1.05 = 20.58 kbps

Concurrent Calls = 2 * 40.32 kbps = 41.16 kbps

As you can see, the payload size may have doubled, but the packet throughput has halved!

 

Example 6 : 8 Concurrent G.722 Calls over Ethernet using a 10ms bitrate

Building on the ideas presented in the previous example:

New Payload Size = 160 kbps * (10/20) = 80 kbps

Total Packet Size = [ (18) + (40) + (80) ] = 138 bytes

Packets per Second =[ 64 kbps * 1000 bits per kilobit ]  / [ 80 bytes (default voice payload) * 8 bits per byte ]  = 100 pps

Bandwidth = [ ( 138 bytes ) + (0 bytes ) ] * 100 pps * 8 bites/byte = 110400 bits/sec = 110,4 kbps

5.0% Overhead =110.40 kbp * 1.05 = 115.92  kbps

Concurrent Calls = 8 *115.92 kbps = 927,36 kbps

OK, at this point not much more to cover! 🙂

 

A Final Note on Sampling Rates…

I highlighted the PPS value in Example 5 in red to make a final point on this topic.

As you can see, the payload size may have doubled, but the packet throughput has halved.

 

Where does all of this come  into play?  Well, there are two competing considerations here:

  1. Longer Durations (i.e. a lower PPS value) reduces Network Overheads
  2. Increased Packet Sizes decreases the resiliency to Network Errors (such as packet loss)

 

Considerations such as physical hardware capabilities, link stability, available bandwidth, PBX feature sets (and don’t forget that of your Peering Partners!)  etc. can all be considered when deciding on a preferred sampling rate for your VoIP network – a lot for the VoIP designer to think about when making decisions on what codecs (and respective capabilities) to support!

 

Online References

I have managed to find a number of excellent documents to help you.

 

For a detailed breakdown of how to perform these calculations:

 

A TAC tool, and simply the best out there with a nice GUI:

 

Configuring Bandwidth-based CAC for CUBE:

 

For quick and dirty calculations that don’t take into account network overheads:

 

Additional links to various sites that offer similar tools:

 

Hope this helps all you CCIE aspirants and VoIP network designers!

 

#dontcalltac

Tagged , , , , ,

RFC 5411 – And Other Guides to the SIP Galaxy

Given half a chance, I am always open to punt The SIP School as probably the best starting point for learning SIP out there.  I took this course some years ago, and was recently able to convince our management to get our whole voice team to complete the training.  It has really skilled up our team and made us a force to be reckoned within our local market.  If you want to learn SIP, look no further.  I’ve said it loads of times, this was without a doubt the key to my CCIE Collaboration success.  Before you ask, I have no affiliation to the SIP School whatsoever – am just a very, very satisfied customer!

That being said, my main motivation for suggesting this training material is that the course, although covering Core SIP and other topics incredibly well, is, by design, heavily influenced by the IETF standards documentation.  At the time of studying for the SSCA exam, I took the opportunity to do a detailed study of the RFCs that each section referenced.  To me, it is very important as a VoIP Engineer to have a strong understanding of RFC Compliance – particularly for SIP!

 

That being said, I only recently came across RFC 5411.  I can’t believe that in the last 5 years I’ve missed this!  This is absolutely the coolest IETF RFC for VoIP ever.  Unsurprisingly, this was written by Jonathan Rosenburg.

This is really a great starting point for working through the long list of RFCs that cover standard-based SIP (a term that can only ever be used loosely, haha).  Although there have been several key RFCs post-2009, this is an excellent starting point for even a seasoned SIP professional.  I particularly like how Jonathan has broken down this list functionally.  If you’re anything like me, you’ll soon find yourself deep down the rabbit hole!  And it definitely goes deep 🙂

 

I am particularly fond of these as well:

For something more Cisco-centric, this is a great read on how Cisco has recently endeavoured to remain RFC-compliant:

 

Happy reading.  Please ping me to add to this list!

Tagged , , ,

Cisco Support Community Collaboration Videos

Thanks to Java for sharing this – can’t believe I’ve never come across this!

A really, really awesome resource for a number of Collab-related support topics.  Some excellent videos on topics such as:

  • CUOS certificates
  • Self-Provisioning
  • Conference Now
  • PCD
  • TelePresence
  • VCS
  • Service Discovry and UDS
  • Various phone model factory reset procedures

 

 

Enjoy! 🙂

Tagged , , , , , , , , , ,

CUOS Certificate Expiration Issues and Regeneration

I arrived on site at a remote client picking up a deployment that was done some 18 months ago for additional scope of work.  However, when I arrived to begin, I encountered some strange behaviour that I struggled to attribute to anything obvious.

What I saw was:

 

  • High number of AXL connections on CUCM:

admin:utils diagnose test

Log file: platform/log/diag3.log

Starting diagnostic test(s)
===========================
test – disk_space : Passed (available: 1796 MB, used: 12360 MB)
skip – disk_files : This module must be run directly and off hours
test – service_manager : Passed
test – tomcat : Passed
test – tomcat_deadlocks : Passed
test – tomcat_keystore : Passed
test – tomcat_connectors : Passed
test – tomcat_threads : Passed
test – tomcat_memory : Passed
test – tomcat_sessions : FailedThe following web applications have an unusually large number of active sessions: axl. Please collect all of the Tomcat logs for root cause analysis: file get activelog tomcat/logs/*
skip – tomcat_heapdump : This module must be run directly and off hours
test – validate_network : Passed
test – raid : Passed
test – system_info : Passed (Collected system information in diagnostic log)
test – ntp_reachability : Passed
test – ntp_clock_drift : Passed
test – ntp_stratum : Passed
skip – sdl_fragmentation : This module must be run directly and off hours
skip – sdi_fragmentation : This module must be run directly and off hours

 

  • Backups Failing

 

  • Jabber services listed as” UNKNOWN” from the GUI, even though listed as “STARTED” from Serviceability and from CLI:

 

Selection_006

 

  • Immediate Switch-Version failed after an upgrade due to SELinux failing to upgrade correctly, causing differing behaviour on different servers:
    – Java errors on login to server and CLI scripts unable to run due to permissions issues
    – A Cisco DB service refusing to start!
    – Kicked out of ssh session directly after authentication – SELinux issue

 

 

The SELinux issue actually prevented a switch-back as this could not be initiated from CLI.  To resolve this I had to complete a manual partition switch using the CUCM/CUC Recovery CD as well as a File System Check and Repair!

 

This was all very, very strange!

 

Once back to a “stable” platform after the partition swap and file-system check, I again attempted an upgrade, which this time failed:

04/20/2016 19:46:49 upgrade_install.sh|Started auditd…|<LVL::Info>
04/20/2016 19:46:49 upgrade_install.sh|Started setroubleshoot…|<LVL::Info>
04/20/2016 19:46:49 upgrade_install.sh|Changed selinux mode to enforcing|<LVL::Info>
04/20/2016 19:46:49 upgrade_install.sh|Cleaning up rpm_archive…|<LVL::Info>
04/20/2016 19:46:49 upgrade_install.sh|Removing /common/rpm-archive/10.5.2.12901-1|<LVL::Info>
04/20/2016 19:46:50 upgrade_install.sh|File:/usr/local/bin/base_scripts/upgrade_install.sh:604, Function: main(), Upgrade Failed — (1)|<LVL::Error>
04/20/2016 19:46:50 upgrade_install.sh|Parse argument status=upgrade.stage.error|<LVL::Debug>
04/20/2016 19:46:50 upgrade_install.sh|_set_upgrade_status_attribute: status set to upgrade.stage.error|<LVL::Debug>
04/20/2016 19:46:50 upgrade_install.sh|is_upgrade_lock_available: Upgrade lock is not available.|<LVL::Debug>
04/20/2016 19:46:50 upgrade_install.sh|is_upgrade_in_progress: Already locked by this process (pid: 32606).|<LVL::Debug>
04/20/2016 19:46:50 upgrade_install.sh|release_upgrade_lock: Releasing lock (pid: 32606)|<LVL::Debug>

 

This time, I had selected an immediate switch-version instead of using a 2-stage process after a successful upgrade.  Again, I could confirm a successful upgrade:

 

04/20/2016 19:39:01 post_upgrade|Post Upgrade RTMTFinish|<LVL::Notice>
04/20/2016 19:39:01 post_upgrade|========================= Upgrade complete. Awaiting switch to version. =========================|<LVL::Info>
04/20/2016 19:39:01 upgrade_manager.sh|Post-upgrade processing complete|<LVL::Info>
04/20/2016 19:39:01 upgrade_manager.sh|Application install on inactive partition complete|<LVL::Info>
04/20/2016 19:39:01 upgrade_manager.sh|L2 upgrade… Run selinux_on_inactive_partition|<LVL::Info>

 

So now, I concentrated on the post-upgrade switch-version logging, and picked up on this:

 

04/20/2016 19:46:38 upgrade_manager.sh|(CAPTURE) /sbin/restorecon.orig set context /etc/opt/cisco/elm/client/.security/trust_certs/Cisco_Root_CA_M1.pem->system_u:object_r:cisco_etc_t:s0 failed:’Operation not permitted’|<LVL::Debug>
04/20/2016 19:46:38 upgrade_manager.sh|(CAPTURE) /sbin/restorecon.orig set context /etc/opt/cisco/elm/client/.security/trust_certs/Cisco_Root_CA_M1.der->system_u:object_r:cisco_etc_t:s0 failed:’Operation not permitted’|<LVL::Debug>
04/20/2016 19:46:38 upgrade_manager.sh|(CAPTURE) /sbin/restorecon.orig set context /home/sftpuser/sftp_connect.sh->specialuser_u:object_r:user_home_t:s0 failed:’Operation not permitted’|<LVL::Debug>

 

It was then that I became very confused.  These strange issues together all pointed to **certificate expiration**.  However, the system had been installed less than 18 months ago, so this didn’t make sense!  I checked the certificates and confirmed – all expired.  Then it dawned on me.  When we had installed the system, we had staged the network and voice at the same time.  We’d pointed NTP to the firewall – which must have, prior to go-live, been set as a master by our firewall team … with the wrong date-time! 😦

So, root cause found, but now to resolve?!

 

Certificates are a tricky business in CUCM since the implementation of Security by Default.  I don’t intend to cover this topic here (it’s absolutely huge), but I will say this – changing certificates on CUCM can run the risk of getting you fired.

If you don’t know 100% what you are doing, you could cause an outage that will require serious skill to repair, an emergency TAC engagement,  manual phone intervention or a combination of the 3.

 

So, I now needed to complete Certificate Regeneration on CUCM, CUC and IM&P.

Some notes here:

  • My cluster was not in Mixed Mode – my life just got a whole lot easier!
  • The client didn’t have a Private CA, so we were forced to use Self-Signed.  A major consideration if you have signed certs.
  • I was working on a BE6K – with no redundancy – so for me…  ITL files are going to be an issue.  I must to do a “Pre- 8.0 Rollback” and blank all the ITL files before I start.
  • Multi-App integrations are probably going to require manual certificate download/import between clusters for IM&P

 

Following the above process, I carefully:

  1. Blanked all ITL files, with necessary TVS and TFTP service restarts as required
  2. Stopped TFTP Services
  3. Regenerated all applicable certificates as per the above guide
  4. Manually deleted “-trust” certificates as per the guide – I preferred the GUI to the CLI for this – watch out for related bugs in the above guide.
  5. Restarted all applicable services
  6. Removed Pre-8.0 Rollback Enterprise Parameter ITL blanking
  7. Again, restarted TVS and TFTP services
  8. Imported regenerated certs for intra- and inter-cluster communications

 

An Important Note:

When restart TFTP, always wait 5-10mins for the TFTP files to rebuild on the server.  More haste, Less-Job-Come-Monday.

 

Rebooted IM&P, and immediately saw that all the affected IM&P services were listed correctly:

Selection_010.png

 

Helpful links on SBD (Security by Default) and CUOS Certificates in General:

 

 

Check out the ITLRecovery enhancements in 10.x and above!

 

#dontcalltac

Tagged , , , , , ,

Gathering CUOS Installation Information Prior to Upgrade

It may sound obvious, but prior to any upgrade – prepare for the eventuality of a system rebuild.  I hit an upgrade today that required both a Recovery CD partition swap and file system check on the original Active Partition to recover the system, after SELinux failures occurred after a switch-version.

For a rebuild, collect the following from CLI prior to upgrade:

  1. show network eth0 

  2. show status

  3. show version active

  4. utils ntp config

  5. show web-security

 

This will collect IP/Hostname, DNS, NTP/Timezone, firmware and certificate details(last one is critical!).

This is all negated if you have Answer Files set up to begin with and/or are using PCD.

 

HTH

Tagged , , ,

Active Unassigned DN’s – Updating with SQL

Update to a previous post

Disclaimer :

Provided as is – you break your box all on your own buddy!  Lab this first.

 The offending DNs can be queried using:

select n.dnorpattern from numplan n
left outer join devicenumplanmap m on m.fkdevice = n.pkid
where m.fkdevice is null
and n.tkpatternusage = ‘2’
and n.iscallable = ‘t’

  • m.fkdevice is null assures the Route Plan element is unassigned
  • tkpatternusage = ‘2’ matches DNs only
  • iscallable=’t’ defines the “Active” checkbox on the DN page – and our offending behaviour.

Some help came from here.

Construct your own UPDATE SQL statement to fix it!  As assistance – start here, it’s not too difficult.

#dontcalltac

Tagged , , , , , ,

Prime Collaboration Provisioning and the Unassigned DN

Something to watch out for!

When using Prime Collaboration for auto-provisioning of  users/lines for Self-Provisioning in CUCM, the DNs will be added as “Active” by default.

Active Check Box

The Active check box, which only displays for unassigned directory numbers, determines whether the directory number gets loaded and used by Cisco Unified Communications Manager. By checking the check box, the directory number gets loaded and used by Cisco Unified Communications Manager. For example, the directory number belonged to an employee who left the company. The directory number had certain settings that were configured, such as call forwarding to voice-messaging system. By leaving the directory number active, a call that is intended for the directory number will get forwarded. This eliminates the need to reconfigure another employee to have the same call-forwarding options. If the check box is not checked, the directory number will not get loaded by Cisco Unified Communications Manager, which results in settings that are configured for that DN to not be used (for example, call forward destinations), and callers will not get their call forwarded properly.

Please see the CUCM System Guide.  My links for 8.6, but still 100% relevant.

The impact is that when doing site migrations, sites already deployed onto the new cluster will fail to dial users that, although pre-provisioned in CUCM, have not yet Self-Provisioned their endpoints.  Nice way to create an outage, sending all calls a VM box that hasn’t even been set up!

I haven’t found a Prime-driven solution for this.  Sadly, we’re back to BAT tools to get the working with Export/Import…  Or SQL.

Tagged , , , ,

WebEx in Ubuntu 14.04+ for x64 systems

As per Cisco’s WebEx System Requirements specification, WebEx is only supported in x86 for Linux, and for Ubuntu specifically in 12.x and 14.x with Gnome.

However, most modern machines use the x64 architecture, so this does create a problem.  I had some fun sorting out this one ( I need it for work, so it’s pretty important I guess 🙂 ).  The steps to resolve are fairly well documented, and in summary are as follows:

 

  1. WebEx requires Java.  The WebEx system requirements guide says Java 6, but it works just fine (eventually!) in Java 8.
  2. Regarding browsers, Chrome just doesn’t work – walk away.  Need Firefox here!
  3. Java may require certain security exceptions in certain cases to get this working
  4. Even after initiating a Webex, in-meeting features such as audio, desktop share etc. are not going to work.  At the time of meeting initiation, WebEx will prompt the user to accept the download of a number of shared libraries (.so files)  to the user’s /home directory, that are stored under /home/myuser/.webex/.  These will contain package dependencies that will prevent most features from working, and should be addressed using this process.

 

There is however still a caveat listed here that needs to be taken into consideration.  It’s important to install the correct icedtea plugin to remove any conflicts:

 

sudo apt-get -y remove icedtea-7-plugin:i386 icedtea-netx:i386
sudo apt-get install openjdk-7-jre:i386 libxmu6:i386 icedtea-7-plugin firefox
sudo update-alternatives --auto mozilla-javaplugin.so

 

It definitely doesn’t look too pretty in Ubuntu, but hey, for my purposes (support) I’m happy it’s working!

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.