cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9741
Views
10
Helpful
20
Replies

Jabber 8.6 one way audio in iPhone and Android

yuzhao
Level 1
Level 1

Hi guys,

We are testing out Jabber 8.6 for iPhone and Android.  The CUCM version is 7.1.5 and CUPS is 8.6. The CUCM version might be old but it's listed as supported version on Cisco Jabber release notes.

Issues we are having is Jabber client couldn't be heard by the remote party. If I call a deskphone from Jabber, I can hear the deskphone but the deskphone can not hear me. This happens both to iPhone and Android version. When Jabber calls another Jabber, they can't hear each other. It seems Jabber doesn't send audio at all.

So we put a wireshark on the Deskphone side, and we didn't see and audio from Jabber to deskphone. However, when putting a wireshark on the Android phone during the call from Android to iPhone, we DID see the both way g.711 traffic, even though they couldn't hear each other.

It's not the firewall because: 1, CUPC 8.6 works on the same network without audio issue. 2, Cisco mobile 8.0 works on the same iphone, same network without audio issue; 3, Android and iPhone are connected to the same wireless AP having the same IP range during the testing.

We limit the RTP port to a smaller range in SIP profile. It works well with CUPC, CIPC, but it doesn't work well with Jabber. Jabber seems to be able to pick a random UDP port out of this range.

Any thoughts?

Thanks,

Rick.

20 Replies 20

Jimmi2shooz
Level 1
Level 1

Hi Rick,  Any luck on this problem??   We're actually experiencing the exact same thing. 

If you've received any insight on this via TAC or these forums, i'd appreciate anything you could share.

thanks!

-james

Hi Jimmi,

It's actually a bug in Jabber. When you define the udp port range in sip profile, the jabber will try to use asymmetric UDP ports for incoming and out going rtp stream. But in my CUCM 7.1.5, udp port range is a requried field which can't be blank. I had a tac ticket open for this. There is no work around but the fix will be in the new release available middle of May according my tac engineer.

Hope this helps.

Rick.

Hi Rick,

Thanks for the reply. We were actually able to resolve this as well.

Only we did it by going to the Line configuration page I CUCM and associating the user to the line, instead of just associating the user to the device like you normally would.

Having said that, I don’t know if our issues were the same. But our symptoms were definitely dead on.

What we are still experiencing, are issues with CTI and getting the call to transfer from the jabber app on the mac, to the IP phone. Like Cisco advertises in their “dual mode” solution.

Are you able to get this to function??

Thanks!

-J

Hi Jimmi,

Sorry to reply to your post so late. I took some days off and forgot about this.

When you associate users with their lines it's just for line appearance, which is for the presence feature. I don't think it could cause audio issue though.

I haven't tried transferring yet. Will test it tomorrow and let you know the outcomes.

Thanks,

Rick.

Hello There,

 

The on way issue got resolved,

we are also facing the same issue.

hile we are calling from outside through vpn connect  there is one way audio issue.ip phone user can hear the audio from the jabber user.

But opposite side there is no audio.Also we are not able make the call from the ip phone (Desk phone).

We have found that while 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

Thanks in Advance..

Hi Jimmi,

Just tested the transfer features, it works in our jabber. No audio sending out from Jabber client is the only issue for us.

This solution actuall y worked for me too.  Now got full audio between desk phones and the iphones through a VPN tunnel  Thanks for the post!  Will test transfers next!

Hi Rick

Did TAC identified the bug? ie which bug ID is it?

We ran  into same issues ie calling a deskphone from Cisco Jabber from iphone  and the deskphone couldn't hear the Jabber client.  I also opened a TAC case and the engineer made me check the MTP required. Then the one way audio issue seems to resolve. However it introduces a one way audio with 3 party conferences. However, I still found inconsistent behaviors regardless if MTPrequired box is checked or not.

With some devices, it has the issue ie one way audio issue with a desk phone ( desk phone can't hear) and with another device it doesn't have the issue.

Thanks!

Cathy

Hi Cathy,

Thanks for your update. I tried to enable MTP required but didn't make difference for the Android version. I will test iPhone version tomorrow. It will be weird if MTP is the cause though.

TAC didn't give me a bug ID, he just said it's identified as internal bug and will be fixed in the next release. I guess it has something to do with our CUCM version as well, it's still 7.1.5.

Thanks,

Rick.

Hi Cathy,

I tested both Android and iPhone (iPad) version of jabber 8.6, none of them worked. I still get no audio from Jabber client after checking the MTP option.

tahequivoice
Level 2
Level 2

I know this is old, but still relevant. I am having the same issues with an iPhone and iPad using Mobile 8 and Jabber.

What I found is the incoming voice packets from the iphone/ipad are being seen as the public IP of the device, not the VPN IP, so they get blocked at the ASA.

External calls though are working fine, only into an extension do we have the caller not being heard.

Has anyone been able to find a solution to this?

I'm on the same boat here. Using Cisco Jabber on iPhone 4S. One way audio towards Cisco 7945 set. I hear them, they don't hear me. Same when I call Unity voice-enabled directory, it doesn't get my voice to match a name. I guess a bug that won't be fixed until mid may this year? That's a loooong way out for such a serious bug, which renders this product useless.

I opened a TAC case on this after exhausting any debugs I can think of.  After reviewing the logs and running other tests, including connecting to an EZVPN hard phone, which I discovered the main issue with, the SIP is being translated by the ASA.  I got full audio by encrypting the ASA IP on the 800 router, I found the router was natting the IP of the ASA. Why, that I dont know.

If you read the log, starting from the bottom up, notice that the inside phone, 10.129.100.96 has a translation built to the ASA IP on port 30872, then follow the records and notice that  the seesions are built and then the public IP of the remote phone is suddenly there, using that port, being denied. 

4|Apr 24 2012|08:54:16|106023|66.2x.x.x|17396|10.129.100.96|30872|Deny udp src outside:66.2x.x.x/17396 dst inside:10.129.100.96/30872 by access-group "Outside-In" [0x0, 0x0]

4|Apr 24 2012|08:54:16|106023|66.2x.x.x|17396|10.129.100.96|30872|Deny udp src outside:66.2x.x.x/17396 dst inside:10.129.100.96/30872 by access-group "Outside-In" [0x0, 0x0]

4|Apr 24 2012|08:54:16|106023|66.2x.x.x|17396|10.129.100.96|30872|Deny udp src outside:66.2x.x.x/17396 dst inside:10.129.100.96/30872 by access-group "Outside-In" [0x0, 0x0]

4|Apr 24 2012|08:54:16|106023|66.2x.x.x|17396|10.129.100.96|30872|Deny udp src outside:66.2x.x.x/17396 dst inside:10.129.100.96/30872 by access-group "Outside-In" [0x0, 0x0]

6|Apr 24 2012|08:54:16|302015|10.229.2.9|17396|10.129.100.96|30872|Built inbound UDP connection 3965253 for outside:10.229.2.9/17396 (10.229.2.9/17396)(LOCAL\admin) to inside:10.129.100.96/30872 (10.129.100.96/30872)

6|Apr 24 2012|08:54:16|302015|10.229.2.9|17396|10.129.100.96|30872|Built inbound UDP connection 3965253 for outside:10.229.2.9/17396 (10.229.2.9/17396)(LOCAL\admin) to inside:10.129.100.96/30872 (10.129.100.96/30872)

6|Apr 24 2012|08:54:16|607001|10.229.1.4|5060|10.229.2.9||Pre-allocate SIP SIGNALLING TCP secondary channel for inside:10.229.1.4/5060 to outside:10.229.2.9 from 200 message

6|Apr 24 2012|08:54:16|607001|10.229.1.4|5060|10.229.2.9||Pre-allocate SIP SIGNALLING TCP secondary channel for inside:10.229.1.4/5060 to outside:10.229.2.9 from 200 message

6|Apr 24 2012|08:54:16|607001|10.129.100.96|30873|10.229.2.9||Pre-allocate SIP RTCP secondary channel for inside:10.129.100.96/30873 to outside:10.229.2.9 from 200 message

6|Apr 24 2012|08:54:16|607001|10.129.100.96|30873|10.229.2.9||Pre-allocate SIP RTCP secondary channel for inside:10.129.100.96/30873 to outside:10.229.2.9 from 200 message

6|Apr 24 2012|08:54:16|607001|10.129.100.96|30872|10.229.2.9||Pre-allocate SIP RTP secondary channel for inside:10.129.100.96/30872 to outside:10.229.2.9 from 200 message

6|Apr 24 2012|08:54:16|607001|10.129.100.96|30872|10.229.2.9||Pre-allocate SIP RTP secondary channel for inside:10.129.100.96/30872 to outside:10.229.2.9 from 200 message

6|Apr 24 2012|08:54:16|607001|10.229.2.9|17397|10.129.100.96||Pre-allocate SIP RTCP secondary channel for outside:10.229.2.9/17397 to inside:10.129.100.96 from 200 message

6|Apr 24 2012|08:54:16|607001|10.229.2.9|17397|10.129.100.96||Pre-allocate SIP RTCP secondary channel for outside:10.229.2.9/17397 to inside:10.129.100.96 from 200 message

6|Apr 24 2012|08:54:16|607001|10.229.2.9|17396|10.129.100.96||Pre-allocate SIP RTP secondary channel for outside:10.229.2.9/17396 to inside:10.129.100.96 from 200 message

6|Apr 24 2012|08:54:16|607001|10.229.2.9|17396|10.129.100.96||Pre-allocate SIP RTP secondary channel for outside:10.229.2.9/17396 to inside:10.129.100.96 from 200 message

6|Apr 24 2012|08:54:16|305011|10.129.100.96|30873|66.x.x.x|31791|Built dynamic UDP translation from any:10.129.100.96/30873 to outside:66.x.x.x/31791

6|Apr 24 2012|08:54:16|305011|10.129.100.96|30873|66.x.x.x|31791|Built dynamic UDP translation from any:10.129.100.96/30873 to outside:66.x.x.x/31791

6|Apr 24 2012|08:54:16|305011|10.129.100.96|30872|66.x.x.x|31790|Built dynamic UDP translation from any:10.129.100.96/30872 to outside:66.x.x.x/31790

6|Apr 24 2012|08:54:16|305011|10.129.100.96|30872|66.x.x.x|31790|Built dynamic UDP translation from any:10.129.100.96/30872 to outside:66.x.x.x/31790

This is a different issue though. In my case, there is no VPN or ASA in between. The bug is related to CUCM SIP Profile and port ranges.

However, I did have issues when VPN was in place. I read from other posts for all kinds of VPN related one way audio issues, either caused by split tunnelling or NAT. Cisco said there is a built-in security option in Jabber 8.6 which should be used instead of VPN.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: