PJSIP changes TCP source port

Asterisk Asterisk SIP
1

Hi there,

i talked to Deutsche Telekom why we often get a forbidden when dialing out with a PJSIP-Trunk.
Product of them is called Company Flex.

Result: They want us to stick with the identical TCP Port on dialing out that we used for the register.

How can me make it stick with the TCP-Port?

Asterisk Version: 18.12.1

image
image1079×117 41.3 KB

When that Source-Port changes on another register, we have the “forbidden” issue.
It sticks long with the same TCP-Port, but then all of a sudden: port changes.
I tried rewrite_contact=no and yes but did not help.

allow_reload=yes will force the problem on applying changes and the port will change.

“pjsip send register companyflex-out” needed afterwards

image
image981×854 261 KB

Transport

[transport-tcp-37eda84c495b784c1dd0]
type=transport
protocol=tcp
local_net=192.168.222.0/24
local_net=192.168.202.0/24
local_net=10.5.3.0/24
bind=0.0.0.0:5060
allow_reload=no
symmetric_transport=no

Profile

[p13](!)
media_encryption=no
dtls_setup=active
force_rport=yes
ice_support=no
rtp_symmetric=yes
rewrite_contact=no
use_avpf=no
direct_media=yes
disable_direct_media_on_nat=no
dtls_verify=yes
rtcp_mux=no
media_use_received_transport=no
media_encryption_optimistic=no
asymmetric_rtp_codec=no
dtls_fingerprint=sha-256
dtls_rekey=0
send_diversion=yes
send_pai=no
send_rpid=no
webrtc=no
max_video_streams=5
max_audio_streams=5
transport=transport-tcp-37eda84c495b784c1dd0

[p13-aor](!)
qualify_frequency=30
qualify_timeout=3
remove_existing=yes
support_path=no
default_expiration=300
maximum_expiration=600
minimum_expiration=240

Trunk

[companyflex-out](p13-aor)
type=aor
max_contacts=1
contact=sip:+49199296000000601234@tel.t-online.de:5060
outbound_proxy=sip:552233556611.primary.companyflex.de\;lr
qualify_frequency=30
qualify_timeout=3

[companyflex-out]
type=identify
endpoint=companyflex-out
match=tel.t-online.de

[companyflex-out]
type=registration
endpoint=companyflex-out
transport=transport-tcp-37eda84c495b784c1dd0
outbound_auth=companyflex-out-oauth
server_uri=sip:tel.t-online.de:5060
client_uri=sip:+49199296000000601234@tel.t-online.de:5060
contact_user=+49199296000000601234
retry_interval=60
max_retries=10000
forbidden_retry_interval=60
expiration=300
line=yes
auth_rejection_permanent=no
outbound_proxy=sip:552233556611.primary.companyflex.de\;lr

Thanks a lot

2

Hi there,

Telekom (Provider) says this:

REGISTER from Port 1, o.k.
INVITE from Port 1, o.k.
INVITE from Port 1, o.k.
INVITE from Port 1, o.k.
INVITE from Port 2, SIP 403 forbidden.
REGISTER von Port 2, o.k.
INVITE from Port 2, o.k.
INVITE from Port 2, o.k.
INVITE from Port 2, o.k.
INVITE from Port 3, SIP 403 forbidden.
REGISTER from Port 3, o.k.
and so on…

So there is a local portchange on an invite. Why and how to fix?

Thanks a lot.

3

Because one end or the other closed the TCP connection that was used for the REGISTER.

I’d consider this to be a non-compliant provider. Even if they didn’t close the connection, there is no reason to reject the normal recovery from a lost connection. Actually, there is no need to match incoming INVITEs against incoming REGISTERs; it is perfectly valid not to have registered before an outbound call, even if you need to register to receive calls.

4

Some providers over in Europe also ignore the specifications when it comes to SRV, and expect you to always use the same IP address/port and connection as the outbound registration, instead of load balancing according to their SRV configuration. There’s no option in Asterisk to ignore the specifications and work that way.

5

But quite some Asterisk based PBXes made Deutsche Telekom with Company Flex Trunk work just fine.
How would that be possible?

6

If I recall, some people have just run local DNS solutions that answer with a single IP address always instead. For other solutions I do not know. There’s been posts in the past on here if I recall, so search may find information.

7

I don’t know what triggers the port-change. But does not look like a change in IP to me.
Our IP does not change, nor does the IP of the provider change. Think sngrep shows that good in the screenshot above.

8

You’d need to dig further into things, then, such as looking at Asterisk core debug and more TCP level packet captures.

9

Hi,

as jcolp wrote, you should do a packet capture. We have seen cases with Deutsche Telekom products where the firewall killed the TCP connection some time after registration (due to missing traffic, idle timer in firewall). Asterisk then establishes a new connection with an outgoing INVITE and may end up on a different IP address, which is where the 403 comes from. In this case increase the idle timeout of inactive TCP connections.

When capturing packets, check whether the TCP connection is cut and therefore a new connection to a different destination is established.

We have no problems with Asterisk and CompanyFlex.
Best regards
Karsten

10

With Deutsche Telekom products in particular, you should ideally use the provider’s DNS. With CompanyFlex, the NAPTR lookup may only provide sips access via SIP TLS.

We recently had a case where 1.1.1.1 and 8.8.8.8 were entered as the DNS. In the DNS SRV entries, the priorities were then reversed for successive queries because the two DNS servers provided different answers.
I don’t know if the behavior was correct, but after entering 8.8.8.8 and 8.8.4.4 or the Telekom DNS servers, the error disappeared.

11

Thanks for the input so far.

TCP Aging on the Lancom router is already at 400s.
Expiration on the Company Flex Trunk is 300. It really registers after 5 minutes.

Is there a keep alive setting for TCP I can check and how?
Edit:I just checked: Keep Alive Interval is at 90.

Thanks again

12

Just a stupid question from someone who never used sip over tcp:
Is there a difference in behaviour between udp and tcp? Because with udp I can say for sure that asterisk always uses the configured bind port as source port.

Regarding your problem, there are firewalls where you can configure “same source port” rules. So whenever a device sends pakets, the firewall will do NATing to the same configured source port. This is something that may help in your situation.
Unfortunately, as I know LANCOM quite well, I don’t think it’s possible with their routers.

13

This is different in tcp. The source port is chosen by the kernel when a connection is set up. As the connection persists until explicit closed, answer packets get back for sure, using the socket of the connection. Think of Your browser: the source port would never be 80 or 443.
As udp is connection less, answers are directed to the source.
I don’t know LANCOMs but I think, the setting you mentioned is for udp.

14

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