(NAT) Direct Media To Host On Local Net When Registering From External Address

Home » Asterisk Users » (NAT) Direct Media To Host On Local Net When Registering From External Address
Asterisk Users 5 Comments

This is going to be a bit of an odd situation, but perhaps might become more and more common (as mobile phone SIP clients utilize PUSH proxies instead of the battery draining direct registering with SIP servers).

I have a SIP client which can be on the same RFC-1918 LAN as my Asterisk server. Even though it’s on the same LAN as the Asterisk server, it’s registration comes from an IP address external to the LAN. This is because the client is registering to the local Asterisk server through a SIP proxy server that is external to the LAN.

Is there any way for Asterisk to determine that this is what is happening and to direct/setup the media session to the client on it’s LAN address?

Put another way, even though the registration comes from an external
(NATted) IP address, I want the media connection to stay within the LAN.

One solution of course is to add the external IP address of the SIP
proxy — the address that the client’s registration is coming from

5 thoughts on - (NAT) Direct Media To Host On Local Net When Registering From External Address

  • How is your endpoint currently configured in asterisk? Have you tried rtp_symmetric to see if the endpoint sends audio to asterisk if asterisk can send audio back to the client?

    Alternatively if your SIP Proxy is also a Media proxy you could set the media_address on the endpoint to be your proxy and let your proxy handle proxying the media to your endpoint.

  • It’s configured as a chan_sip peer.

    That would require using chan_pjsip wouldn’t it? Not that I am opposed to trying that. I need to use chan_pjsip at some point to be able to authenticate to my SIP provider for SIP SIMPLE anyway.

    But will rtp_symmetric really solve the problem? Isn’t the problem the setting up of the RTP session, so there is no address and port that it receives from yet?

    The idea of sending my media out of the LAN (where I have almost zero latency) and introducing the latency of a round trip to the proxy and back doesn’t seem like a great solution.

    Cheers, b.

  • The chan_sip module has this implemented under the “nat” option using “comedia” as I recall. It causes media to be sent to where media was originally received from. As for whether it would work or not… this all ultimately depends on how exactly the intermediary behaves, what is let through, what is altered. There’s nothing inherent in either chan_sip or chan_pjsip to know/care, as it’s just SIP. You’d need to look at the SIP signaling and the SDP to understand what is happening.

    —
    Joshua C. Colp Digium – A Sangoma Company | Senior Software Developer
    445 Jan Davis Drive NW – Huntsville, AL 35806 – US
    Check us out at: http://www.digium.com & http://www.asterisk.org

    —

  • Yeah. The help for which reads:

    Send media to the port Asterisk received it from regardless of where the SDP says to send it.

    Right. But this is the part I don’t think I’m understanding. What is
    “originally received from”? There is no media at the point where the media session is being set up according the the SDP is there?

    I have looked. Asterisk on my LAN is sending an INVITE to the mobile client and since the INVITE is being sent to an external IP, it is
    (correctly for all other cases) writing the external IP into the SDP
    payload. What else could/should I be looking for?

    Ultimately I don’t think comedia is the problem or solution because it’s not where Asterisk is sending it’s media that is the problem.

    The problem is that Asterisk is sending an INVITE to the client with it’s external IP address in the SDP because it sees the client as being external and the client is then correctly trying to set up the media session with the external IP address of the Asterisk instead of it’s internal address.

    What needs to happen is that Asterisk has to know “somehow” that even though the client registered from an external address, that it really is internal. Probably that “somehow” doesn’t actually exist at this point.

    Let me ask this, in the REGISTER request, where is the IP address of the client taken from? Is it taken from the Via: header?

    b.

  • It waits until the RTP flows to determine this.

    Ah yes… yeah, there’s nothing built in to handle the scenario.

    For what purpose? The SIP response goes to the source of the request. If you mean the registration address, that is the Contact header. A REGISTER essentially means “I can be reached at this Contact address for requests”.

    —
    Joshua C. Colp Digium – A Sangoma Company | Senior Software Developer
    445 Jan Davis Drive NW – Huntsville, AL 35806 – US
    Check us out at: http://www.digium.com & http://www.asterisk.org

    —