Hello. I am a new user to ProSBC and have my system up and running. I am able to route calls to/from the various NAPs that I have built, however I have run into an issue with what ProSBC sees as a looped call. From my perspective, a loooped call is a call that comes back into an SBC on the SAME interface upon which it originally received that call. However, what I am doing is what I would descriube as a hairpinned call. Below is a text picture of what I am doing.
Client 1 → SBC → Proxy/Billing/Manipulation Server –
|
Client 2 ← SBC ← Proxy/Billing/Manipulation Server ←
Client 1 and Client 2 are separate ATAs, connecting to ProSBC on the outside SIP interface from seprate IP addresses. The Proxy/Billing/Manipulation Server (PBMS) is on the INSIDE SIP interface of ProSBC.
Client 1 calls Client 2, and I have the routing set that only traffic originating from the Proxy/Billing/Manipulation Server (PBMS) will route to the appropriate Client NAP based on called party dialplan. As a result, all calls entering ProSBC from the OUTSIDE interface will be routed directly to the PBMS.
However, when I place such a call from Client1 to Client2, the call egresses ProSBC from the inside, hits the PBMS which determines that the destination endpoint is on the outside of ProSBC and sends a refer to send the call back to ProSBC for additional routing. That is where the call fails due to Loop call detected".
I had a look at the default routing plan, but cannot find something that jumps out at me for looped call detection. Could someone point me to where I can turn this off?
@TB: It might be a good idea to add some text to this page that mentions looped call, as it would it made it easier to find this.
I reviewed the instructions, but when creating the NAP column I do not see a selection in “Type attributes” showing NORMAL|REDIRECT. I did check the settings in SIP, profiles and gateway and found them to be as required. My question is what drives the “Type attributes” options so that NORMAL|REDIRECTwould be available as a selection?
I guess you have only 1 SBC and 1 PBMS and the requirement is to route calls from Client 1 to Client 2.
How about creating 2 NAPs for the PBMS, one for receiving calls from the SBC and the other one for sending calls to the SBC. Each NAP uses its own transport server (SBC IP and port).
In this configuration, the PBMS needs to send the call to the SBC at port 5062 so that the call will come in from NAP_PBMS_IN.
A NAP is a unique combination of below parameters:
SBC IP Interface (Define in Transport Server)
SBC Port (Define in Transport Server)
Remote side Proxy Address (Define in NAP)
Remote side Proxy Port (Define in NAP)
Thanks for the suggestion, but we are trying to keep our PBMS configurations similar across our network. We are traditionally an Audiocodes shop, and have been for almost two decades. We really don’t want to deploy a custom PBMS configuration just for ProSBC, which at this time is purely an evaluation. The link I referenced ablve suggest that I should be able to do this by selecting REDIRECT instead of NORMAL. I am not seeing that option available, so could this be an issue with the version I am running, or is there another dependency that might not be mentioned in the link?
Hi. It is a bit better, but there is an large delay in the call reaching Client 2 from client 1 in the order of about 2.7 seconds between trying and ringing. Even stranger, the call doesn’t pass RTP properly. i.e. the call signalling works, but no audio. I have Wiresharked traffic to/from the SBC on both the inside and outside interfaces and I see RTP coming from each of Client1 and Client2 being sent to the SBC, but I do not see the corresponding streams being hairpinned through the SBC back to the other Client device.
We’re a bit closer, but I think something is still missing here. Thanks!
I was reviewing your post and wanted to share some insights that might help.
The absence of RTP you’re seeing could be related to the fact that your proxy does not have media-handling capabilities (like an rtp-proxy). In this scenario, the outgoing leg from the SBC advertises the SBC IP as the media source in the SDP. When the proxy sends the call back, it reflects that same IP in the SDP. As a result, the SBC ends up being instructed to send RTP traffic back to itself — which obviously won’t work.
You generally have two approaches to solve this:
A) Ensure that RTP flows to and from the PBMS (or another rtp-proxy) so that the SDP negotiation points media correctly; B) Enable media bypass on the SBC, allowing Client1 and Client2 to negotiate the RTP/SDP directly (this can be configured in the profile used by the NAPs and routes).
Option B works fine if both endpoints (Client1 and Client2) are on public IPv4 addresses. However, if there’s NAT — and especially if an ALG is involved — this may introduce other issues. ProSBC can handle NAT scenarios, but depending on the network design, it might not fully resolve them in every case.
At this point, it would be really helpful to know more details about your setup, such as the IP addresses being advertised in the SDP and how routing is handled on each side. With that information, we could better pinpoint the issue and guide you through the right configuration.
Let us know how it goes once you try one of these approaches!
Hi. We simply ran out of time troubleshooting this issue with ProSBC and deployed with an Audiocodes Mediant 800 SBC which supports this mode of operation out of the box. I have a bit of development time coming up in my calendar, and signed up for the ProSBC course. I will make certain I didn’t miss anything in the installation first then circle back with this problem.