I have a one-way-audio problem with my Cisco Jabber Voice installed in several Android phones. (Several phones running Android 4.3 and also one new Nexus 5, Android 4.4.) The android Cisco Voice Jabber is working properly inside the corporative network.
I have also double-checked the CUCM configuration and I do not see any important difference with Cisco document Jabber for Android Configuration Example Document ID: 113471
I have tried native VPN client from Android and also VPNCILLA to connect to the vpn. The ping into CUCM and Service Presence is successful, I have tried with one dedicated vpn profile without split tunneling and also the one used for corporative PCs. So basically I discard that the problem is related with the vpn configuration.
However, when I try to connect from 3g or different network I’ve found that the Cisco Jabber Voice is using the 3g or Wifi interface IP address to register into the CUCM instead of the tunnel interface IP address.
As a result, the phone is registered but there is one way audio for all calls.
Is there any possibility to force the ip address of an application or the phone? Any ideas any workaround? Any suggestions?
Some screenshots to show the problem attached-
Wifi IP address 10.151.101.143
VPN tunnel interface 10.200.254.77
Here you have a screenshot of the Device-Phone from the CUCM (System version: 220.127.116.1100-1)
(I had to resize the image to make it fit in the screenshot).
Thank you in advance for your help!
I have the same problem. I haven't try from the corporate network yet.
Did you get to the bottom of it?
It looks as if we have a bug on this as does google.
CSCuo82476 – J4A call failure on new Android OS 4.4 under HomeWifi + VPN
I don't believe that Google's bug applies in this case with Jabber for several reasons. (1) Jabber runs its own interface selection algorithm (you can observe this in the debug logs of Jabber) to determine what IP to encapsulate in its "register" message to the CUCM server. (2) The issue described in Google's bug is that the actual Source IP address of packets destined for a public IP address exiting out a public Interface is a Private IP space. Jabber's problem is the other way around - Private packets inside the tunnel contain an outside Public IP address. (3) The actual IP traffic flow is completely fine between Jabber and the CUCM - the packets don't have the wrong source IP address. We're talking about a message body, not IP header, issue.
The issue is that inside the SIP "REGISTER" message (and also therefore the SIP SDP messages), Jabber is telling the CUCM "hey, my IP address is this outside public IP address" - when it should be saying that it's IP address is the IP address of the AnyConnect tunnel.
The issue of interface selection when registering a soft client has always existed, in IP Communicator there is a preference setting just for this. If auto selection isn't working, you could add an identical preference setting to Jabber on Android - simple solution and the same one as Cisco has used before on Windows. Screenshot from CIPC:
That is the settings screen we need available to us in Jabber for Android, specifically the "network adapter" pop-up menu.
It looks like is not unique problem of Cisco jabber.
Here I found another problem with SIP + VPN
So far I have the same problems.
In our company, we have solved this with Cisco Vcs Expressway where Jabber does not requires VPN connection.
Hope it helps.
I have tried the Jabber voice directly in the corporate network and it works fine.
The problem appears only when in add VPN to the equation.
Was this issue ever resolved? Still seeing it on Android 4.4.4. Jabber Voice is registering to CUCM using the IP address of the phone's WIFI interface rather than the IP assigned by the AnyConnect client. This causes one-way audio and prevents the solution from working.
It's very strange issue as sometimes it seems to work and sometimes (i think after re-connects of vpn client after connection loss) it's no longer working.
Does anybody know already a workaround or did someone open already a case at cisco for this?