Sangoma SBC VM

Commercial Products and Partners Sangoma
1

Hi,

So in our infrastructure, we have a freepbx behind a Sangoma SBC VM and we’re connecting to a SIP provider through a firewall that’s NATing.

We’re having some issues where after a certain amount of time, the SBC sip trunk to the ITSP provider will simply drop.

When we check the logs, it seems like on our side, the SBC keeps sending registration requests with a random rport and the other side accepts it and send it back to that random rport.

Here’s the transaction that the ITSP is receiving:

2019-10-09T17:37:04.634709Z|sip-forwarder[171108]|bc64ff9b-71c8-4d54-a8d5-f59a5aef32e0|IS|723| RECEIVED message from UDP:My IP:43035 at UDP:ITSP IP:5060:

REGISTER sip:ITSP IP;transport=udp SIP/2.0

Via: SIP/2.0/UDP My IP;rport=43035;branch=z9hG4bKrgUZ62QgDB7QH

Max-Forwards: 70

Contact: <sip:username@My IP:5060;transport=udp;gw=To_ITSP>

To: <sip:username@ITSP IP;transport=udp>

From: <sip:username@ITSP IP;transport=udp>;tag=DZKB9QFXH186H

Call-ID: bc64ff9b-71c8-4d54-a8d5-f59a5aef32e0

CSeq: 10767494 REGISTER

Expires: 300

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE

Supported: pw-info-package, path, replaces

User-Agent: NetBorder Session Controller

Content-Length: 0

My question is, how we can change that rport with header manipulation or if it’s at all possible or maybe the problem is completely unrelated to that and you guys have suggestions.

Thanks,

2

The random port is your NAT at work.

It it not clear what you mean by the trunk will drop, but if you mean incoming calls fail, you might want to look at the NAT and firewall timeout settings.

3

Hi,

I thought only PAT should be giving out random source ports not NAT.

By the trunk will drop, I simply mean that the registration will expire without a renewal so the trunk status goes to down and our ITSP expires as well making it impossible to make or receive calls to the SBC.

4

If you want to do a 1:1 NAT without PAT you will have to configure your firewall to do that. The rport=randomport that you see in your provider’s logs is because they are detecting the source port and including it in that tag.

In your first post you said that registration was getting a successful response back from the provider. Check your firewall logs to see whether those registration responses are getting back through to your SBC. They should be. NAT/PAT requires a stateful firewall to keep track of those things. Or figure out how to turn off the PAT so that you can pass through unchanged.

5

Right now our firewall is configured to do 1:1 NAT.

When checking the logs, the only time the SBC actually registers is when the providers send back the 200 OK at 5060. I’m guessing while using random ports, at one point it just rolsl back to 5060 and then finally registers.

But there’s a setting on it called Hide NAT changes source port for SIP over UDP IP. I’m guessing that setting is the reason of the high port, is it possible that the fact that the firewall is using a random port is the reason why the SBC is not getting back the answers?

6

It seems to me that if you do not want the firewall to alter the source port and instead let the traffic pass as 5060, that setting should be disabled according to this guide: VoIP R80.10 Administration Guide

Yes, but it’s supposed to work ok like that. The firewall should manage the port translation. Why it’s not working for you is unclear.

7

Well in a best case scenario, I’d want my SBC to be able to answer to the random port used by my ITSP to send the answers to the requests.

Is there a place on the SBC where I can configure the listening ports to registrations? Because I can’t seem to find any documentation on that to help me.

Thanks,

8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.