[Live-devel] Setting an upper limit on ports available for RTP use

Matt Schuckmann matt at schuckmannacres.com
Thu Sep 27 10:29:23 PDT 2012



On Wednesday, September 26, 2012 8:04:38 PM, Ross Finlayson wrote:
>> As part of upgrading our version of LiveMedia I'm reminded of a
>> modification that we put in our code and suggested to you but
>> apparently never made it into the code.
>>
>> We put in a way to set an upper limit on the ports available for
>> RTP/RTCP use. We did this for servers that are behind a NAT or
>> firewall where only a limited number of ports are forwarded through
>> to the server and we didn't want the server to assign ports outside
>> that range.
>>
>> We simply added a number of ports parameter to RTSPServer and
>> OnDemandServerMediaSubsession (where it's really used in
>> getStreamParameters()).
>> Do you think this feature could be added to the code?
>
> Mumble... Maybe, but I don't consider this a high-priority request,
> because it would make the server *less* functional.  (If the server
> could only allocate port numbers that were outside your preferred
> range, then the stream would still be accessible if the client
> happened to be inside your firewall.) Also, just setting an upper
> limit on port numbers wouldn't be enough; I would also need to update
> the code to respond to the "SETUP" with an error response code if the
> server were unable to allocate port numbers in the desired range.

I'm not so sure about the less functional statement, if I'm setting up 
a server with this feature then I have good reasons for it and I 
probably don't care if a client inside a firewall could access the 
server on a port outside of my specified range, probably because I 
don't intended to have any clients inside the firewall.

With regards to needing to respond to the SETUP with a response code, I 
would argue that you need this regardless if you add this feature or 
not.
Currently if no ports are available getStreamParameters() will loop 
infinitely, even though it's unlikely to happen it's still bad design.

If you really don't want to add a response code on failure I'd be happy 
with just looping through he specified range of ports until an 
available pair of ports are found.

Another alternative is to break up getStreamParameters() with some sort 
of virtual method to get the next port to try or a method to create the 
groupsock, so that subclasses can implement there own algorithm for 
obtaining ports.

Thanks,
Matt S.

>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


More information about the live-devel mailing list