asterisk users - Jan 2019 - (NAT) direct media to host on local net when registering from external address

On Tue, 2019-01-15 at 09:00 -0700, John Kiniston wrote:
>  How is your endpoint currently configured in asterisk?
It's configured as a chan_sip peer.
> Have you tried
> rtp_symmetric to see if the endpoint sends audio to asterisk if
> asterisk
> can send audio back to the client?
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?
> 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.
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190115/37424325/attachment.sig>

On Tue, Jan 15, 2019, at 12:18 PM, Brian J. Murrell
wrote:
> On Tue, 2019-01-15 at 09:00 -0700, John Kiniston wrote:
> > How is your endpoint currently configured in asterisk?
> 
> It's configured as a chan_sip peer.
> 
> > Have you tried
> > rtp_symmetric to see if the endpoint sends audio to asterisk if
> > asterisk
> > can send audio back to the client?
> 
> 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 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: www.digium.com & www.asterisk.org

On Tue, 2019-01-15 at 12:01 -0500, Joshua C. Colp wrote:
> 
> The chan_sip module has this implemented under the "nat" option
using
> "comedia" as I recall.
Yeah.  The help for which reads:

Send media to the port Asterisk received it from regardless
of where the SDP says to send it.
> It causes media to be sent to where media was originally received
> from.
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?
> 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.
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190115/c6e5fb03/attachment.sig>