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!
  • Students Click Here

*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


SBC Setup Question

SBC Setup Question

SBC Setup Question

I am new to the SBC/Session Manager systems, and trying to work out some minor issues. Currently having calls drop/retry after 30-45 seconds. Anyway, I'm wondering if having the SBC behind a firewall is an issue. Or, maybe the addressing scheme is an issue. Not sure.

Currently, public IP natted to (B1 interface) and the internal (A1 interface) is, Session Manager SIP interface is

Is this setup okay? Should I have the public IP on the B1 interface, and bypass the firewall? Just trying to get a handle on this stuff.

Thanks in advance for any assistance.

RE: SBC Setup Question

In your network configuration for B1, you have a public IP address you can pop in. If you don't, then everything out of B1 to the outside world would have in the SDP for media setup "send audio to!". With a public IP in there, the SBC knows to straight up replace with your public IP where it makes sense, like deep in SIP messaging that tells the far end where to send audio.

I'd look at the firewall. What kind is it? They tend to have application layer gateways enabled by default that try to manipulate protocols through the NAT they're doing for you. To say, once upon a time my customer had a new office with site-to-site VPN on a Juniper firewall and SIP phones there. That SIP phone would call the main office, get ringback, the user at the main office would pickup, and the SIP phone at the remote site kept getting ringback. Because we could trace from the call server at the core and a softphone at the remote office, I could see the signaling end to end and that 200OK from the call server being sent to the remote phone and it never coming out of the firewall towards the phone. One tick box for disabling the SIP ALG fixed that.

A tell tale sign that messages are being lost somewhere is it being sent repeatedly, and more slowly. Like a 200OK from your carrier to your SBC and it doesn't get anywhere. Then it comes again a second later. Then 2 seconds later and then 4 seconds later and then 8 seconds later. Your audio got setup but the totality of the call setup wasn't right.

Another thing to be aware of is media timeouts. Carriers can typically implement something to terminate your call if you don't send RTP for a period of time when they were expecting you to. Like, a session is set up with "send/recv" in the SDP, and 5 minutes go by with no RTP packets coming from either of the two ends where they were supposed to be, your carrier would look on their SIP server running that audit and see that it spontaneously spit out a BYE to both ends of the call

Are you setting up for remote worker or for SIP trunking? For remote worker, there's a few more considerations because the SBC still needs to get through to your phone on your home Linksys on a network. The first way it juggles the NAT is by forcing the remote worker to open both streams towards the SBC. To say, if you wanted RTP on port 3000 for the remote worker, even if an internal user were calling the remote worker, when the remote worker picks up, he sends 1 packet of RTP on 3000 and then sends his audio on 3001. Now that the port on 3000 is opened, that's what the SBC uses to send the half of the audio of the other person to the remote worker.

Also, if you're using AST/Avaya SIP/96xx/Equinox/things that use PPM, there are mapping profiles to set up in SM and the SBC. To say, the profile data SM sends a registered phone includes "register to!" and you'd need to map something like "when SM gets a register from A1, return the PPM to say register to PUBLIC IP". There's a "remote access" menu in Session Manager / application configuration as well as a PPM mapping service in the SBC to address that.
Were you to do that wrong, you could feasibly type in the public IP in your softphone, register and get PPM that erroneously says "no, you should register to SM!" and then you get the triangle error thingy 15-20 seconds after your initial register.

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!

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