Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Equinox ASBCE , no audio for remote workers

Equinox ASBCE , no audio for remote workers

Equinox ASBCE , no audio for remote workers


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 ??

RE: Equinox ASBCE , no audio for remote workers

Don't use port 5060/5061 on the outside for registration. I've seen a lot of cell carriers reserve those ports in the phone OS. Try 6060/6061.

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 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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close