SBC Setup Question

[84Mike]

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 10.1.50.4 (B1 interface) and the internal (A1 interface) is 10.1.50.16, Session Manager SIP interface is 10.1.50.15.

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.

 

[kyle555]

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 10.1.50.4!". With a public IP in there, the SBC knows to straight up replace 10.1.50.4 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 192.168.1.0/24 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 10.1.50.15!" and you'd need to map something like "when SM gets a register from A1 10.50.1.16, 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 10.1.50.15!" and then you get the triangle error thingy 15-20 seconds after your initial register.