[asterisk-dev] PJSIP and RTP address selection

[Joshua Colp]

On Thu, Sep 13, 2018, at 7:00 PM, Matt Fredrickson wrote:

<snip - see previous messages for full context, cause this thing is big>

> > I have two potential fixes (and two that aren't practical options I
> > don't think but might be with knowledge I don't have) both with
> > advantages and disadvantages:
> >
> > 1.  Bind the socket against the advertised address.
> 
> That seems interesting, although I'm not sure what that means in a
> multi-homed world with multiple address/media streams (IPv4 + IPv6).
> Also, I wonder how this works with ICE/STUN/TURN across many
> interfaces and address families.  Multi-home is hard to get right for
> all scenarios.  I can't help but wonder if instead of binding to the
> wildcard address we should be explicitly binding to each
> interface/address and making our own source address selection rather
> than letting the kernel decide.  Sometimes the kernel will decide in a
> way that surprises you and I think that's what you're hitting.

Indeed, the other problematic area of binding to the advertised address is that due to asynchronous DNS resolution what you end up going out on may not be what you thought - so the RTP instance and SDP has to be updated or else you could get IPv4 SDP but the traffic going out over IPv6, which is technically acceptable but things sometimes don't like it. In a pure environment where you know with greater certainty ahead of time it's easier to choose early in the process and use one.

> 
> > 2.  Upon receiving the first rtp, "narrow" the socket listening address
> > to the received "to" address.
> 
> That also doesn't seem unreasonable, but I'd rather hear what Josh
> thinks since he spent lots of time with his head in this code.

The problem is getting this information. You'd need to read in the full IP packet from the socket, parse the IP header itself, and look at that information. It should be possible but it's not something that has been done in Asterisk, and I'm not sure if it alters the underlying permissions required if running as a user.

> 
> > (3.)  Have the RTP sent to my primary address to begin with, not the
> > socket address as for PJSIP transport.
> > (4.)  Update the rtp engine to be able to have multiple socket pairs and
> > switch between them as the remote side does.
> 
> That seems "most right", and matches my idea solution from above.  But
> then again, I'm curious how it would affect our ICE/STUN/TURN stack.

Indeed - that is the most right. A question arises though - which one do you use for sending early media if you haven't received any media yet?

> 
> > The first has various disadvantages as I understand from Joshua.  Most
> > of them over my head.  The advantage is that the source address would be
> > (more) deterministic upon sending RTP.  This can be done by passing the
> > transport address to rtp instance, presumably similar to what chan_sip
> > does.  This would in some cases break things like signaling on ipv4 and
> > rtp on ipv6 if pjsip transport is not bound to ANY.  This was as I
> > understood one of Joshua's bigger concerns.
> 
> Yeah....

Indeed, and we (both Matt and I as well as others) actually use this every day for meetings. Our video conference server (using Asterisk of course) has both IPv4 and IPv6 ICE candidates. Matt ends up using IPv4, I use IPv6.

> 
> > The second option has the advantage that unless the address to which the
> > remote side sends changes things should just work.  This can be
> > implemented by creating a new socket, binding it to the more specific
> > address and then using dup2() to replace the old socket file descriptor,
> > before closing the newly creating file descriptor.  It can be returned
> > to "ANY" in a similar manner if required.  RTCP ports will need to be
> > re-bound as well.
> >
> > This should probably be a configurable option either way, and one could
> > add a transport option "bind_rtp_to_transport_address", and/or a
> > "narrow_rtp_address" (the latter would make no sense if the former is
> > active, unless the bind address is an ANY of sorts).  These can be
> > implemented in conjunction or separately.
> 
> I'd hate having to add another options for this behavior.  It seems
> like there should be a path forward that gets most of the right cases
> most of the time without it being an optional behavior.

I don't think it's possible to please every scenario without an option, short of the major rework of having multiple sockets which I'd only be comfortable with in master.

> 
> > The third option basically involves binding the socket to ANY and
> > pretending to send data to the known addresses for the peer and using
> > those addresses in the SDP (if we've seen SDP for the conversation
> > already, those addresses, otherwise for the remote address of the SIP
> > communication - this would break a number of things potentially, thus
> > likely not a serious option.  For example, if we're sending an INVITE to
> > a web-socket transport, then potentially the web-socket connection has
> > been proxied and the remote address of the web socket connection isn't
> > actually where the remote side is, for example, if proxying via
> > httpd/apache to localhost:8088 then asterisk sees 127.0.0.1 as the
> > "rermote".
> >
> > I'm tending towards option 2.  This would perhaps also have a side
> > effect of minimizing attack surface for things like RTP bleed.
> 
> It might be the lowest friction way forward (without rewriting the
> RTP/ICE/STUN/TURN layers).

It would be.

> 
> > I suspect this has not come to light before since most setups is likely
> > to only have a single IPv4 and single IPv6 global address, or in the
> > case of multi-homing would have one on each interface with the kernel
> > RPF filter getting rid of traffic from a source other than where it
> > would route back to, basically forcing an IP match based on route-based
> > address selection.
> 
> Multiple IPv4 address are not very common among non-carriers.
> 
> > Joshua suggested that before coding on this is started all use-cases
> > should be explored and documented, which I think is a good idea.  I'd be
> > happy to drive that process, I'd however need to understand where this
> > should be documented.  So in this respect this email servers as a
> > request for pointers.
> 
> +1

We could grant you wiki access if you'd like to make a wiki page there to organize things in an easier fashion.

As for an over all response I've been seeing if I could come up with any other alternative options which are less invasive but would still be effective. I'm continuing to research and look.

Cheers,

-- 
Joshua 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