Intelligent Proximity (iOS App) for Telepresence Endpoints

Cisco has released the beta Intelligent Proximity app for iOS which allows rudimentary control of a Telepresence (SX, MX, C, EX-series running TC 7.0+ code) endpoint as well as shared content viewing.  When it goes “official,” only the current version of endpoints will be supported (SX20 and newer) due to limitations with scalability on the older endpoints.

http://www.cisco.com/c/en/us/products/collaboration-endpoints/intelligent-proximity.html

A great demo video of the application is here – http://youtu.be/ycpcEtxl7Yk

The application uses “ultrasound” to determine which Telepresence codec is in the same room and then connects to the codec over IP for control or content reception.  (Keep in mind that the iPad/iPhone must have network connectivity to the codec to be able to control it or receive content.)

It’s pretty cool to use to control an endpoint when you don’t have a touchpanel or remote control (ack) available.

Note: Intelligent Proximity is also the term used for Bluetooth pairing of a smartphone to a DX650 (to use the iPhone as a second line on the DX650), which has nothing to do with this Intelligent Proximity.

Advertisements

Jabber for Windows 9.7(0) is available on CCO

NOTE:  Although Jabber 9.7 supports Collab Edge MRA, it will not be officially TAC supported until Expressway 8.1.1 releases in the next few weeks.

 

Grab J4W 9.7 here — http://software.cisco.com/download/release.html?mdfid=284324806&flowid=46406&softwareid=284006014&release=9.7%280%29&relind=AVAILABLE&rellifecycle=&reltype=latest

Release notes are here — http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/JABW_BK_CF8F083D_00_cisco-jabber-for-windows-97.html

Please take a look at the release notes.  While Collab Edge MRA is supported in this client it is not TAC supported until Expressway 8.1.1 releases.  There are some notable feature exceptions to be aware of.

From the release notes:

When using Expressway Mobile and Remote Access to connect to services from outside the corporate firewall, the client does not support:

  • LDAP for contact resolution. Instead, the client must use UDS for contact resolution.
  • File transfer, including screen capture, is not supported with on-premise deployments. File transfer using Expressway Mobile and Remote Access is only supported using WebEx Cloud deployments.
  • Desk phone control mode (CTI), including extension mobility.
  • Extend and Connect. You cannot use the Jabber client to make and receive calls on a non-Cisco IP Phone in the office; to control a non-Cisco IP Phone in the office, such as hold/resume; or control a home or hotel phone when connecting with Expressway Mobile and Remote Access.
  • Dial via Office – Reverse calls.
  • Session persistency. The client cannot recover from disruptions caused by network transitions. For example, if a users start a Cisco Jabber call inside their office and then they walk outside their building and lose Wi-Fi connectivity, the call drops as the client switches to use Expressway Mobile and Remote Access.
  • Cisco WebEx Meetings Server. The client cannot access the Cisco WebEx Meetings Server server, or join or start on-premises Cisco WebEx meetings.
  • Sending problem reports. To work around this issue, users can save the report locally and send the report in another manner.
  • CAPF enrollment.
  • Early Media. Early Media allows the client to exchange data between endpoints before a connection is established. For example, if a user makes a call to a party that is not part of the same organization, and the other party declines or does not answer the call, Early Media ensures that the user hears the busy tone or is sent to voicemail. When using Expressway Mobile and Remote Access, the user does not hear a busy tone if the other party declines or does not answer the call. Instead, the user hears approximately one minute of silence before the call is terminated.
  • Self Care Portal.
  • End-to-end media encryption. Media is not encrypted on the call path between the Cisco VCS Control or Cisco Expressway-C and devices that are registered locally to Cisco Unified Communications Manager. The media path outside of the enterprise is encrypted.

Migrating your PRI gateways from h.323 to SIP

One of the recommendations in the CSR version 10 SRND is to use SIP trunks from CallManager to your IOS voice gateway.

This makes sense for multiple reasons:

  1. Avoid dealing with MGCP’s finicky nature when making changes.
  2. A big step towards moving your PSTN connections to SIP trunks and using CUBE as an SBC.
  3. Gateway call forking for call recording.

CUCM 10 includes the ability to fork calls at the gateway to the call recording server.  This is great news for large deployments where using the phone’s BIB for forking isn’t desirable.  Some information about gateway forking is here.

Migrating from h.323

The conversion process is pretty straightforward for anyone running h.323 as they’ll already have all of the necessary dial-peers built typically and will only need to deal with SIP DTMF issues and SIP SDP Early Offer issues for SCCP phones.

In a recent conversion that I did I did the following:

Modified the GW -> CUCM dial peers to look like this:

dial-peer voice 101 voip
preference 1
destination-pattern 5…$
session protocol sipv2
session target ipv4:192.168.65.10
session transport tcp
voice-class codec 1
dtmf-relay sip-notify

There are several ways to deal with DTMF.  I prefer OOB to In-band (rtp-nte / RFC 2833) personally, so I go with sip-notify.

We must make adjustments to the SIP Trunk Security Profile to Accept unsolicited notification so that the DTMF information will be allowed into CUCM.  I copy the normal Non-secure SIP Trunk Security profile to a new name (e.g. Non-secure SIP Trunk Security Profile — GW) and change this option.  I then apply this security profile to the trunk I create from CUCM to the Gateway.

DTMF becomes a problem for SCCP phones unless you do either an Early Offer SIP trunk, or you provide an MTP to deal with it.  There’s an excellent document here – https://supportforums.cisco.com/blog/154706 that discusses all of the various options.

I don’t really like having to force MTP for every call, especially since SIP phones won’t need it for DTMF, so I opted to create a new SIP Profile that enabled Early Offer support for voice and video calls (insert MTP if needed) and apply it to the trunk.

Converting from MGCP

Converting from MGCP is a more significant undertaking.  The PRI configurations all move from CUCM to the Gateway as dial-peers.  I’ll add more to this post to include a sample build of dial-peers to accomplish this.

 

Jabber Mac 9.6 EAP Build 2 Posted

Head over to the Collaboration Community EAP Space and get the latest build (or sign up to join if you haven’t).  It is reported to have MRA enabled by default.

Version Information
To clarify on the version number change:  Prior to this build the product was going to be called 10.0, but has been rebranded to 9.6.  The reasoning behind the change is to have version numbers aligned with the capabilities of each client across the board (iOS, Windows, Mac, Droid).