6 thoughts on - Asterisk As A Client: Can I Get The Remote SIP Server To Ignore Rport?

• http://www.ietf.org/rfc/rfc3581.txt

  To force RFC3581 support for outbound REGISTER messages, you can set
  “nat=force_rport” in the general section of your sip.conf. (This also forces RFC3581 compliance for inbound messages, for any peers that inherit this general option)

  In my testing this results in the outbound REGISTER setting rport like

  “Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK493d3405;rport”

  If the far end supports RFC3581 it should respond back to the port from what it received requests. That should be 5060 if they receive the message from 5060. However.. if your VM/Network provider is rewriting things, then they could potentially remove your rport value, send it out over a different port, or do any number of crazy things. Depending on what they have going on in their network, receiving it back at 5060 is no guarantee it’ll get back to your Asterisk VM.

• Am 20.02.2014 22:20, schrieb Rusty Newton:

  Thank you for the suggestion, I just tried that. Unfortunately it doesn’t help in my case. The problem remains that my hosting provider is rewriting ports:

  Packets on the hosted VM (1.1.1.1) where Asterisk “client” is running:

  IP 1.1.1.1.5060 > 2.2.2.2.5060: UDP, length 428
  IP 2.2.2.2.5060 > 1.1.1.1.16025: UDP, length 544
  IP 1.1.1.1 > 2.2.2.2: ICMP 1.1.1.1 udp port 16025
  unreachable, length 556

  And on 2.2.2.2, the remote SIP server (another Asterisk box for testing):

  IP 1.1.1.1.16025 > 2.2.2.2.5060: UDP, length 428
  IP 2.2.2.2.5060 > 1.1.1.1.16025: UDP, length 544
  IP 1.1.1.1 > 2.2.2.2: ICMP 1.1.1.1 udp port 16025
  unreachable, length 556

  The initial REGISTER received from 1.1.1.1 without force_rport:

  Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK1780c521

  And with force_rport enabled:

  Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK279a0a9b;rport

  But of course, Asterisk on 2.2.2.2 will reply on the port where the request originated, in the above case, port 16025 which was rewritten from 5060 to 16052 by the evil hosting provider. This is what the Via header looks like when 2.2.2.2 answers to 1.1.1.1:

  Via: SIP/2.0/UDP
  1.1.1.1:5060;branch=z9hG4bK279a0a9b;received=1.1.1.1;rport025

  So, if there would be some kind of implementation that said “Ignore the actual port that the request originated from, instead force answer on a port that is transmitted via some header setting”, that would help me.

  Some fantasy option in sip.conf:

  nat_rport_forcedP60

  Could generate a header in the initial REGISTER from 1.1.1.1 to 2.2.2.2
  like this:

  Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK279a0a9b;rport_forcedP60

  And now, even though 2.2.2.2 received the request originating from port
  16025, it would honor the “rport_forced” setting and reply back on port
  5060 instead of 16025.

  Maybe such an option exists, I just haven’t found it yet? 🙂

  Thank you!
  Markus

• To be fair NAT is rewriting your SIP packet source port. This happens all day, on almost every NAT device out there. Stop thinking it is purely a port rewriting issue, something else is going on.

  Have you set localnet and externip in sip.conf. Maybe the NAT device has a short UDP translation timeout — try setting qualifyfreq in sip.conf to generate traffic so the NAT box does not close the translations

  Here is an example sip show peers on one my my boxes. Three different locations are show. The ones you see with 5060 are either not NAT’d or they have a proxy at the customer location. The ones with a different port are NAT’d.

  2212012/2212012 xxx.27.201.xxx D N 5060 OK (57 ms)
  2212008/2212008 xxx.27.201.xxx D N 5060 OK (50 ms)
  2212000/2212000 xxx.27.201.xxx D N 5060 OK (51 ms)
  220810/220810 xxx.242.17.xxx D N 53277 OK (728 ms)
  220807/220807 xxx.242.17.xxx D N 4121 OK (44 ms)
  220806/220806 xxx.242.17.xxx D N 47822 OK (57 ms)
  220805/220805 xxx.242.17.xxx D N 31820 OK (44 ms)
  220804/220804 xxx.242.17.xxx D N 4175 OK (42 ms)
  220803/220803 xxx.242.17.xxx D N 15386 OK (42 ms)
  220802/220802 xxx.242.17.xxx D N 28632 OK (44 ms)
  220800/220800 xxx.242.17.xxx D N 47043 OK (44 ms)
  219249/219249 xxx.99.200.xxx D 5060 OK (47 ms)
  219244/219244 xxx.99.200.xx D 5060 OK (49 ms)

  —–Original Message—

• Am 21.02.2014 01:33, schrieb Eric Wieling:

  In the meantime, the provider has reconfigured the VM to work with the public IP address. That means the RFC IP address was removed and the public IP is now configured on the VM directly. The effect is the same, ports on outgoing packets still get rewritten.

  Yes, I have played around with local and externaddr. But the IP is not the problem, the port is. I think the translation timeout doesn’t matter, because the router rewrites outgoing packets to a different port, but doesn’t do so on incoming packets, and that’s the issue.

  And I’m pretty sure if you look at any of those peers that have a non-5060 port, the routers in front of them will rewrite packets destined for ports 53277, 4121, 47822 etc. to the proper corresponding internal IP:port where something is listening. The router of my provider won’t. It rewrites ports on outgoing packets, but it passes incoming packets 1:1 to the VM.

  IMHO, my hosting provider is at fault, and I’m working with them to get it fixed. I was just wondering if there is some magic switch which can fix such a broken scenario.

  Thank you!
  Markus

• Wow, if this is the case then I would be changing VM providers immediately. You would have problems not only with Asterisk but with most other services you wanted to host on it. There are many VM
  providers out there that work just fine with Asterisk even on a 1:1 NAT
  like Amazon Web Services.

• Am 21.02.2014 15:12, schrieb Andres:

  Update: the VPS provider has fixed the issue with their router and now everything works as expected. Unfortunately, in this particular “exotic”
  country, it seems there is exactly *1* VPS hosting provider, so switching to another provider would not be really feasible, and switching to another country is not at option either. 🙂

  All is good now!

  Thanks!
  Markus