Jabber 8.6 one way audio in iPhone and Android

Unanswered Question
Mar 15th, 2012

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (2 ratings)
Jimmi2shooz Wed, 04/04/2012 - 14:23

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

yuzhao Wed, 04/04/2012 - 17:20

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.

Jimmi2shooz Wed, 04/04/2012 - 20:09

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

yuzhao Thu, 04/19/2012 - 16:12

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.

yuzhao Fri, 04/20/2012 - 09:58

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.

michael.woolley.1 Wed, 10/10/2012 - 07:28

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!

cbordinat@syman... Thu, 04/19/2012 - 15:50

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

yuzhao Thu, 04/19/2012 - 16:06

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.

yuzhao Fri, 04/20/2012 - 09:57

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 Mon, 04/23/2012 - 07:08

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?

nalonsovoip Tue, 04/24/2012 - 11:36

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.

tahequivoice Tue, 04/24/2012 - 11:59

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

yuzhao Tue, 04/24/2012 - 12:37

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.

tahequivoice Tue, 04/24/2012 - 12:42

I finally resolved it. I had to have 2 nat statements, one normal with the egress and ingress interfaes stated, and another with the proxy arp disabled and let the ASA do the egress.

What is odd is both are at the top of the list, and I tried it with one, then the other, and neither one worked, but adding both worked.  I also tried duplicate statements, the difference being which interface and network was first. One outside>inside, the other inside>outside.  I have TAC looking at the before and after configs to give me an answer to it.

tahequivoice Tue, 04/24/2012 - 12:56

nat (outside,outside) source static ClientVPN ClientVPN destination static EZVPN EZVPN

nat (outside,outside) source static EZVPN EZVPN destination static ClientVPN ClientVPN no-proxy-arp route-lookup

The other one is the same with a different group that has the inside networks.

The group ClientVPN is the local pool subnet, the group EZVPN are all the EZVPN networks in one group.

If I take the second one, and remove the no proxy arp and route lookup, then it fails.

tahequivoice Tue, 04/24/2012 - 13:15

Those are remote 800 series routers with phones hanging off of them. The problem I had occurred both internally and externally, so fixing one fixed them both.  I didnt post the other statement because it created a DM group since I didnt create a group with the networks, I just listed them when I created the rule. I used the ASDM for all of the NAT. I find he ASDM so much easier to create and troubleshoot the NAT, but still use CLI for everything else.

nalonsovoip Tue, 04/24/2012 - 16:06

Thank you very much tahequivoice, that did it for me! I had to use a different command on ASA 8.3.2 to disable proxy arp on the ourside interface:

(config)#  sysopt noproxyarp outside

Good looking out bud!

Actions

Login or Register to take actions

This Discussion

Posted March 15, 2012 at 8:56 AM
Stats:
Replies:19 Avg. Rating:5
Views:3926 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard