[Live-devel] UDP sockets don't use ReceivingInterfaceAddr?

Patrick White patbob at imoveinc.com
Tue Feb 24 08:32:34 PST 2009


> >I'm trying to use ReceivingInterfaceAddr & SendingInterfaceAddr to control
> >which interface RTSP/RTP traffic is going in and out on.
> >In setupDatagramSocket(), there is the line:
> >     if (port.num() == 0) addr = ReceivingInterfaceAddr;
> >This line is just prior to the bind() call.  So.. UDP ports are only bound
> > to a particular interface if portnum is also 0.  Because of this, all the
> > UDP sockets used for RTP traffic are bound to IP_ADDRANY.
> >Is there a particular reason for this?  Is it a multicast thing or
> > something?
>
> Yes, I think so.  I think the intention was that you would want to
> create a datagram socket with an initial non-zero port number only
> for multicast streams, in which case you probably wouldn't want to
> bind() to something other than INADDR_ANY.  But I'm not sure.
>
> But anyway, if you're really doing this for unicast RTSP/RTP, then
> you shouldn't run into this issue, because - in this case - the port
> number should be 0 when the socket is created, I think.

We're doing unicast, and the port number is never 0 through this code -- it's 
always 6970+, so the adapter assignment can never happen.

By default, ReceivingInterfaceAddr is 0 (IP_ADDRANY), which is also what addr 
is by default, so normally this assignment makes no difference.  I've tried 
it with unicast RTP and it works fine.  It should also work fine with 
multicast, restricting the outbound traffic to a particular adapter, but I 
don't have any way to test multicast anything at the current time.

I figured I'd ask before committing the change, just in case you or someone 
else knows why it needs to be this way.  Since we're trying to push as many 
changes as we can back into your library, I don't want to push back bugs if 
we can help it.

> >Can I change it to make it always set addr from ReceivingInterfaceAddr?
> This is Open Source; you can change it to whatever you want :-)  I
> can't guarantee that it will work, though.

The change works fine for us.. and yes, we have the source so we can change 
it.

thanks,
patbob


More information about the live-devel mailing list