One of the issues that you may come upon with Intelligent Proximity is knowing if your endpoint is emitting the ultrasound required to pair with your device. There may be a number a number or reasons for this, including if your using a third party screen with a integrator system (SX10, Sx20, SX80), and the good news is there is an easy way to tell using a free third party application on an iOS device. I am not sure if the same company makes this app on other OS’s but on an iPhone it works extremely well.
SpectrumView will present the ultrasound output from your device in a easy to read format. You will have to change the default range to get the range required to see the Proximity output but this is easy enough to do in the settings of the app.
Below is a screenshot of Proximity turned off. In my case I just turned the power to my third party screen off that was connected to an SX80. As you can see the required range highlighted in red is pretty quite. If you haven't worked it out yet this is the equivalent of a none functioning Proximity pairing signal.
Below I have turned my screen back on and the Proximity pairing signal is coming through just fine again highlighted in red.
If ultrasound is detected but the audio levels are low, try increasing the ultrasound volume using the command below:
xConfiguration Proximity Pairing Audio Volume MaxLevel: <0-90> default: 70
Hope this helps with your Proximity troubleshooting.
VoIPNorm
This is not a failure prone device, its far from it but when you do have an issue because it does not happen very often it can be difficult to find troubleshooting information. Below are some tips and tricks I have seen and used to help diagnose and fix issues.
Issue: Audio tracking and face detection not aligning
This is a much harder condition to diagnose because it looks like its working but seems really slow to change camera angles and zoom in on the face detected.
The best way to discover this issues is with these two commands:
xCommand Experimental SpeakerTrack Diagnostics Start
xCommand Experimental SpeakerTrack Diagnostics Stop
Once your in diagnostic mode what you will notice is a lot of red squares which means a face has been detected as shown below but not a lot of green which means a voice has not been matched to a face. I also noticed that F value was pegging at around 100%.
Solution: Firstly you should always open a TAC Case but in saying that you can also factory reset the SpeakerTrack unit (not the codec). This can help to recover the SpeakerTrack and restore functionality.
Refer to page 17 of the SpeakerTrack Admin guide how to do this:
For the MX700 Dual the picture below points to where the reset button is for the camera modules. Handy to know if you have a single camera that goes offline. The ST unit also has a similar factory reset button. This can also be done via a null modem cable connected to the serial port but most people do not often have a modem cable handy and a paper clip is much easier to find.
More Handy Commands for SpeakerTrack:
Checking status:
xstatus // speakerTrack
*s Cameras SpeakerTrack Availability: Available
*s Cameras SpeakerTrack LeftCamera VideoInputConnector: 1
*s Cameras SpeakerTrack RightCamera VideoInputConnector: 2
*s Cameras SpeakerTrack Status: Active
xstatus // Peripherals
*s Peripherals ConnectedDevice 1045 Name: "SpeakerTrack 60"
*s Peripherals ConnectedDevice 1045 SoftwareInfo: "MT7.3.0.8cb420c"
*s Peripherals ConnectedDevice 1045 Status: Connected
*s Peripherals ConnectedDevice 1045 Type: SpeakerTracker
Things to look for are whether ST is connected and also the software version number aligns with your codec versioning.
Turning on/off SpeakerTrack:
xCommand Cameras SpeakerTrack Activate
xCommand Cameras SpeakerTrack Deactivate
SpeakerTrack Setup document:
Previous Troubleshooting post:
http://voipnorm.blogspot.com/2015/08/troubleshooting-cisco-telepresence.html
If you have run into other commands that are handy or tips and trick's please feel free to post in the comments.
VoIPNorm
More and more companies I am working with are deploying Cisco TelePresence SpeakerTrack 60 with either a MX integrated device or as a standalone with an SX80. So I thought it would be good to let everyone in on a very helpful command to watch the SpeakerTrack in action. There are a couple of steps involved to turn on the diagnostic mode and it can only be done via the command line today.
If you have never used SSH to log in to a Cisco TelePresence device your going to have to download and install a SSH client like Putty or from a MAC use the command line. Here is the link to Putty: http://www.putty.org/
SSH into the codec via its IP address.
Log in.
Run the following commands to turn SpeakerTrack diagnostic mode on and off.
xCommand Experimental SpeakerTrack Diagnostics Start
xCommand Experimental SpeakerTrack Diagnostics Stop
Below is a screenshot of diagnostic mode turned on and a face is detected but no audio match.
Now the engineer is speaking below, and the green square indicates a positive match for facial detection and voice. Therefore the system will zoom in to this person.
The indicators down the bottom of the screen match up with the following:
F = 10.1% detected voice
T = 91.6% non-noise
E = 0% voice from far end
C = 28.1% camera movement
U = 0% ultrasound detected
N = 89.9% silence
S = 178 samples from sound algorithm
If you run this it will help you understand if SpeakerTrack is working but you will need someone in the room to see it displayed on the screen and hae a face to actually track. You wont see jack if you do not have someone in the room with the SpeakerTrack!
Here is the API reference guide just in case your curious on other commands:
VoIPNorm
CUCM TFTP server selection for Cisco phones has been a well known architecture for quite some time. The phone looks up a TFTP server address based on DHCP option 150 and downloads its configuration and files from the published address. Simple enough. Jabber on the other hand works a little differently as it does not use DHCP directly. The underlying PC takes care of addressing and Jabber has to find alternative methods to get to its TFTP server to download its configuration file.
In most cases Jabber uses a SRV records to locate a CUCM server running the User Data Service (UDS). UDS is enabled by default on all your CUCM servers by the way. Once this is located a service profile is returned which has a number of things, but in our case we are most interested in is the TFTP server addresses. Depending on how many TFTP servers you have enabled in your environment your service profile file will list all of them automatically. So if you have turned on TFTP on ever server in your cluster that’s what it will return. See slide below for a more graphical look at the process.
Initially this may seem like a good idea to turn TFTP on every CUCM server and you have redundancy but this isn't how Jabber reads the file. Jabber will check to see if the first three TFTP servers are available only and if all three of those TFTP servers happen to be in a data center that is off line the client will not be able to pull down the jabber-config.xml file.
So what is the best practice? Never have more than two CUCM TFTP servers per cluster enabled per data center for Jabber. This will ensure that Jabber will never be stuck looking for a third server in the same datacenter and will need to look else where, hopefully in another datacenter where you have a third TFTP running. This doesn’t affect how a phone retrieves its information though because a phone as we mentioned earlier is using DHCP option 150. This also doesn’t affect how many TFTP servers you can have in your cluster just where you turn the service on if your also running Jabber and what high availability. In saying that ideally three TFTP servers is probably the optimal amount you will want or need there is nothing stopping you having more. I would suggest that if your desire is more than three have a solid engineering reason behind it.
As always, I hope this helps some hapless sole looking for an answer.
VoIPNorm
As most of you know when Microsoft moved to Exchange 2013 their architecture changed quite a bit. They introduced the Client Access Server as a new role for Unified Messaging and disbanded the UM role altogether putting the processes that ran on the UM server to the Mailbox Server role.
This isn’t a big deal but what happens during an initial call setup is Exchange uses a number of refer and moved temp messages to get the user to the right Mailbox Server running the UM process when a user tries to dial into voicemail via the voicemail pilot number. Now if you’re a larger Exchange customer this may present some issues integrating with CUCM or CUBE or maybe you just haven’t noticed this issue or you just decided its not that important any more. Either way I have a fix for you.
CUCM Issue, workaround and fix
Previous to version 11 of CUCM there is an issue where CUCM can not process the refers correctly and calls into the voicemail pilot number will not connect correctly. The fix is upgrade to version 11. I also discovered the same bug in 2010 when Exchange 2010 would refer back to Exchange 2007.
This does not affect any other functionality if that is a concern. The ability to leave a voicemail, MWI etc. all still work. It is only the ability to retrieve a voicemail via the Vmail pilot number that is affected by this bug. The other functions are using different methods to find and access the correct voicemail box.
If for some reason you would prefer not to upgrade to CUCM 11 there is a work around using CUBE. CUBE has the ability to consume these refer messages coming from Exchange 2013 CAS and UM processes. There is very little information available online for the right configuration of CUBE for use with Exchange 2013 Unified Messaging. I have highlighted below some of the key commands required for at least the ability to have the voicemail pilot connect and be referred to the right Exchange Mailbox server.
You may notice under dialpeer 100 I have highlighted max-redirects 3 specifically in red. This is a very important command that if not implemented will not allow the CUBE to correctly consumer the refer and moved-temp messages and basically cause a never ending loop of invites and moved-temp messages. Thanks to the Cisco TAC for discovering that command.
Does this configuration work for Exchange Online you may ask? I have no idea to be quite honest but it may be worth testing if you are curious. I found basically a void of information in regards to CUBE interop with Exchange Online so this may or may not work with the service.
voice service voip
no ip address trusted authenticate
mode border-element
media flow-around
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
supplementary-service media-renegotiate
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
referto-passing
!
dial-peer voice 100 voip
preference 1
max-redirects 3
destination-pattern <voicemailPilot>
no notify redirect ip2ip
session protocol sipv2
session target ipv4:<ExchangeCASIP>:5060
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
no vad
no supplementary-service sip moved-temporarily
!
dial-peer voice 300 voip
preference 1
destination-pattern [2-9].........
session protocol sipv2
session target ipv4:<CUCMIP>
session transport tcp
incoming called-number .
dtmf-relay rtp-nte
codec g711ulaw
no vad
no supplementary-service sip moved-temporarily
!
As always, I hope this helps some hapless sole looking for an answer.
VoIPNorm
I am still around folks just been busy. Traveling, golf, studying and work all adds up after a while. I am in the process of writing a new interoperability post for CUBE and Exchange 2013 UM and should have it up by next week. It should be an interesting read if you have ever run into issues with Exchange 2013 UM and the way it does refers to CUCM or CUBE.
Talk to you soon.
VoIPNorm
