IPO Server Edition 9.1 with Session Border Controller - trouble with OneX Mobility client on Android

[NormWesley]

We have an IPO Server Edition 9.1 and a SBC. SIP trunks are provided by our ISP (Allstream). We have 18 branch locations on our MPLS network. We use a Sonicwall NSA 4600 with latest firmware in our main Server room. Network is very stable. Internet connections are very stable as well. The Sonicwall works well (generally).

Internal calls use QoS and the quality is excellent. We have over 100 SIP Trunks - very satisfied with the performance.

Our issue is that I'm pulling my hair out trying to get the OneX mobility client to work on our (mainly) Android phones. We've installed the OneX Mobility client on a few Samsung phones. We've combed through the ports to open and the configuration on the Sonicwall. We've created a separate Public Interface on the NSA 4600 to connect to B1 of the SBC. We've been working with our provider to try and get the SBC to do the routing to the OneX Server. I've configured the client and I get a Green bar on the Android.

When I dial in to an internal extension from my Android, the audio is perfect for me hearing them (me on my Android can hear the end-user on his Avaya SIP phone). But he cannot hear me whatsoever.

As I'm new here, I was wondering if anyone had any ideas of how I might resolve this. Our provider is very good, but they feel that the issue is with my firewall or network and they're losing patience with troubleshooting.

I read through a number of postings on setting up OneX but did not come across this issue - where one side of the call had good audio but not the other side.

I appreciate all answers and ideas.

 

[kyle555]

What does your speech path look like? Is it the one-X Mobile registering thru the SBC as a remote worker, or is it calling PSTN through the SIP trunk?

 

[amriddle01]

Rule of thumb for one way audio...it's your router/firewall , well 99.9% of the time anyway

 

[nicka29]

Hi

Im having near enough the same problem.

I get no speech at all.

If I point the NAT rule straight to the IPO on the firewall when you run a trace you can see the UDP ports going backwards and forwards. As soon as you point the NAT to the SBC you cant

Nick

 

[NormWesley]

Not sure if this helps.

amriddle01 - any suggestions? It's a Sonicwall NSA4600. It's pretty feature-rich. I'm sure there must be a way to do something to fix. I'm event thinking of bringing in a second circuit just for 1 IP for this feature and bypass the firewall for testing - just to see if it is indeed an issue with the firewall...

 

[kyle555]

Follow the 9.0 IPO and SBC doc -

https://www.devconnectprogram.com/fileMedia/download/078b0088-8b61-4d46-99fa-106db843ae8a

- and you can do pcaps on the on the SBC public and private interface and see where your media is flowing.

One thing I noted from a knowledge base article somewhere was specifically that to set up a speech path with a remote worker, you absolutely have to get that remote worker to open the connection and send audio first so the SBC knows how to map audio back to the remote worker. The SBC has no way of knowing what IP and port you're using at home.

What if you turned off direct media path for the extension logging in through the SBC and tied the speech path down to the IPO?

If you're a remote worker calling out a SIP trunk I wouldn't even know if your media would be pinned down to the public or private interface of the SBC, and if you're disabling media anchoring, it might even be possible that you're sending SDP trying to have the public IP of your Mobile user send right to the public IP of the SIP trunk and vice versa.

Are Allstream SIP trunks available on the public internet or do you have some private IP from them to send SIP to? That might be one mechanism that would force audio through your network to Allstream or not. What version of SBC are you at? 6.3 has "traceSBC" as a command line tool that makes a nifty SIP ladder and you can simulate where the RTP is going based on the SDP info. That might shed some light on things and give you some visibility into how tweaks you make impact the call setup.