Force subsequent requests to be sent to source port of invite

Asterisk Asterisk SIP
#1

Using Vitelity and IP authentication to make outbound calls.

My firewall translates the source port of outgoing packets.
The destination port that Vitelity sends trying, ringing and 200 OK to is the source port of my outgoing invite, which is what I want.
I have rport set in the via header.

However when Vitelity sends a BYE to me it’s not sent to the invite source port, but to 5060, and therefore my firewall blocks that packet.

How do I force subsequent incoming requests like BYEs to be sent to the source port of the initial invite?

#2

You can’t force it, the remote side may do this based on NAT traversal policy (like is available in chan_sip and chan_pjsip for endpoints that are behind NAT) but otherwise it uses the contents of the Contact header for subsequent requests.

1 Like
#3

So if I omit the rport parameter in the via header entirely, responses and subsequent requests will be sent to whatever values are set in the contact header.

Unless the other side has a NAT traversal policy in place that prevents that and always sends to the source port.

Correct?

#4

Responses would go to the information in the Via header. The “rport” is strictly for responses, it has no impact on requests. Requests always go to the Contact unless there is policy like mentioned.

#5

Trying, ringing, 200 OK are considered responses, a BYE and reinvite would be requests?

#6

Yes, that is correct.

#7

And what exactly do you mean by “NAT traversal policy”?
Let’s say the other party was running Asterisk, what value would have to be set on their end to send responses and subsequent requests not to via and contact values but to source port and IP of the invite oiginating the session?

Or would that be something that’s set on their firewall?

#8

In the case of chan_sip that is done using the “nat” option. In the case of chan_pjsip that is done using the “rewrite_contact” option.

#9

Does the “nat” option only have bearing on telling the other party how I want to receive packets or also how I send them?

In other words there is no setting in Asterisk to force my firewall to use a specific source port on outgoing requests?

#10

It doesn’t tell the other party anything. It is strictly if a remote endpoint is behind NAT. It means that Asterisk will ignore the information in the SIP packet and send to the actual source IP address/port.

Asterisk cannot influence your firewall.

#11

So if I e.g. set nat=yes in my local endpoint settings, will that mean that my server will ignore the information in incoming sip packets and send responses to source IP address/port, or that the remote party will ignore the information in the sip packets I am sending?

#12

We can’t control the remote endpoint. It is strictly how Asterisk behaves.

#13

I thought maybe like with rport, you tell the remote server to which port to send a response.

So just to clarify, if I set nat=yes for my local chansip endpoint, that determines that my local server will ignore the IP and port information in the sip headers of an incoming invite and instead send responses to the source IP address/port of the IP packet.
Correct?

#14

Yes, that is correct.

1 Like
#15

I though nat=yes was just a deprecated shorthand for force_rport and comedia. The former causes Asterisk to behave as though every request had rport. It has no effect on subsequent outgoing requests.

I believe only one side can have comedia enabled, otherwise you will end up with a stalemate and a silent call.

#16

@david551 Comedia, at least in the case of Asterisk, will still send to the provided address in SDP even if it hasn’t received traffic yet - it doesn’t drop the traffic. Thus it still works even with both enabled.

#17

So setting nat=force_rport does not mean that I am sending rport in the via header of my requests, but that my Asterisk server treats every incoming request as if it had rport in the via header and sends responses to the IP address/port of the incoming packet instead of the information in the via header.
Correct?

How do I determine if my server sends rport in the via header and which port it is?

#18

Use the CLI “sip set debug on” command

#19

Won’t that still cause a stalemate if it was really needed, i.e. the address in the SDP is not suitable, in both directions?

#20

If neither can talk to each other then it doesn’t matter, comedia or not.