Equinox ASBCE , no audio for remote workers
Equinox ASBCE , no audio for remote workers
(OP)
Hello,
We have avaya aura core R8 + ASBCE 7.2
We are about to implement remote workers using avaya equinox client from outside , we followed application note for configuring ASBCE and session manager , signaling , ringing works fine , when hang up there is no audio transmitted.
TESTs applied from 2 equinox clients using 4G , 2 equinox clients : one from outside and one internal wifi, and last test for 1 equinox outside network and ONE H323 PHONE and for all tests no audio from both sides.
All ports are opened on customer firewall as mention on Port Matrix.
Any suggestion or someone experienced something similar ??
We have avaya aura core R8 + ASBCE 7.2
We are about to implement remote workers using avaya equinox client from outside , we followed application note for configuring ASBCE and session manager , signaling , ringing works fine , when hang up there is no audio transmitted.
TESTs applied from 2 equinox clients using 4G , 2 equinox clients : one from outside and one internal wifi, and last test for 1 equinox outside network and ONE H323 PHONE and for all tests no audio from both sides.
All ports are opened on customer firewall as mention on Port Matrix.
Any suggestion or someone experienced something similar ??
Talk To Other Members
RE: Equinox ASBCE , no audio for remote workers
As in, I've done a traceSBC watching my cell remote worker on wifi. I saw SIP registration come from my carrier LTE public IP and then I saw PPM requests come from my wifi internet at home public IP.
Otherwise, for a remote worker to get audio - like on 192.168.1.x at your house natted through your router, the SBC makes the client open both streams.
So, what you'd normally see in a packet capture is SIP signaling to set up a call and the SDP in the invite/200OK or whatever sets up between certain IPs and ports, but the remote worker client first sends a RTP packet out to the SBC for the leg of audio of SBC-->client. That punches a hole in the NAT for the SBC to send audio back to the client on. Then the client sends its audio to the SBC on the port it's supposed to.
The SBC also has a spot for public IP override. So, if you have 172.16.x.x as your B1 with a public IP of 200.200.200.200 on your edge router natting it to the 172 address, you best pop that in as the public IP otherwise you'll see SIP signaling hit your remote client telling it to send audio to 172.x and go nowhere.