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

Home » Asterisk Users » Asterisk As A Client: Can I Get The Remote SIP Server To Ignore Rport?
Asterisk Users 6 Comments

Hi list,

I have a fresh install of Asterisk 12.0.0 and I’m going to use it only as a client. I’m trying to SIP REGISTER with a remote SIP provider.

The situation is that Asterisk is running in a VMware VM with a RFC IP
address ( The provider of the VM performs static NAT from the RFC IP address to a dedicated public IP address, however, they are rewriting ports at will. That’s the problem.

Here’s an excerpt from tcpdump:

IP > UDP, length 411
Via: SIP/2.0/UDP;branch=z9hG4bK25a36d76
Max-Forwards: 70
From: ;tag=as762d7322
Call-ID: 778c50f84e80a9db60dcd35a2f8a1498@
Supported: replaces, timer User-Agent: Asterisk PBX 12.0.0
Expires: 120
Content-Length: 0

Then the remote SIP provider answers of course with “401 Unauthorized”
but that reply never makes it to Asterisk, because it doesn’t come in on port 5060, where it actually originated on the VM, but on a random port that the VM hosting providers’ NAT router rewrote to, in the below case port 63664. And the remote SIP provider tries to send the reply back on that random port. Note MY.PUBLIC.IP.ADDRESS and rport below:

IP > UDP, length 534
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP;branch=z9hG4bK25a36d76;received=MY.PUBLIC.IP.ADDRESS;rportc664
From: ;tag=as762d7322
To: ;tag=as45cffa11
Call-ID: 778c50f84e80a9db60dcd35a2f8a1498@
Server: FPBX-2.10.0(
Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm=”asterisk”, nonce=”1d46fec6″
Content-Length: 0

I’m thinking the answer is “no”, but is there any option how I can get the remote SIP provider to answer me on port 5060? Without having them to change anything in their config.

Thank you!

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


    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 ( where Asterisk “client” is running:

    IP > UDP, length 428
    IP > UDP, length 544
    IP > ICMP udp port 16025
    unreachable, length 556

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

    IP > UDP, length 428
    IP > UDP, length 544
    IP > ICMP udp port 16025
    unreachable, length 556

    The initial REGISTER received from without force_rport:

    Via: SIP/2.0/UDP;branch=z9hG4bK1780c521

    And with force_rport enabled:

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

    But of course, Asterisk on 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 answers to

    Via: SIP/2.0/UDP;branch=z9hG4bK279a0a9b;received=;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:


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

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

    And now, even though 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!

  • 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 D N 5060 OK (57 ms)
    2212008/2212008 D N 5060 OK (50 ms)
    2212000/2212000 D N 5060 OK (51 ms)
    220810/220810 D N 53277 OK (728 ms)
    220807/220807 D N 4121 OK (44 ms)
    220806/220806 D N 47822 OK (57 ms)
    220805/220805 D N 31820 OK (44 ms)
    220804/220804 D N 4175 OK (42 ms)
    220803/220803 D N 15386 OK (42 ms)
    220802/220802 D N 28632 OK (44 ms)
    220800/220800 D N 47043 OK (44 ms)
    219249/219249 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!

  • 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!