[Live-devel] openRTSP

[Andro Debevere]

We are testing with the Darwin streaming server. This server does reuse
RTP/RTCP socket numbers for multiple streams, only if the destination port
numbers are different. To make it clear I added an example below:

----------------------------------------------------------------------------
------------------------------------------
Sending request: SETUP rtsp://test/test.mp4/trackID=65544 RTSP/1.0
CSeq: 9
Transport: RTP/AVP;unicast;client_port=39616-39617
Session: 8926136580911184994
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.02.10)

Received SETUP response: RTSP/1.0 200 OK
Server: DSS/6.0.3 (Build/526.3; Platform/Linux; Release/Darwin Streaming
Server; State/Development; )
Cseq: 9
Session: 8926136580911184994
Last-Modified: Thu, 04 Feb 2010 08:19:02 GMT
Cache-Control: must-revalidate
Date: Mon, 01 Mar 2010 08:25:25 GMT
Expires: Mon, 01 Mar 2010 08:25:25 GMT
Transport:
RTP/AVP;unicast;source=157.193.213.35;client_port=39616-39617;server_port=69
70-6971;ssrc=3CD1781C

Setup "audio/MPEG4-GENERIC" subsession (client ports 39616-39617)
----------------------------------------------------------------------------
---------------------------------------------
Sending request: SETUP rtsp://test/test.mp4/trackID=65572 RTSP/1.0
CSeq: 27
Transport: RTP/AVP;unicast;client_port=39616-39617
Session: 8926136580911184994
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.02.10)

Received SETUP response: RTSP/1.0 200 OK
Server: DSS/6.0.3 (Build/526.3; Platform/Linux; Release/Darwin Streaming
Server; State/Development; )
Cseq: 27
Session: 8926136580911184994
Last-Modified: Thu, 04 Feb 2010 08:19:02 GMT
Cache-Control: must-revalidate
Date: Mon, 01 Mar 2010 08:25:25 GMT
Expires: Mon, 01 Mar 2010 08:25:25 GMT
Transport:
RTP/AVP;unicast;source=157.193.213.35;client_port=39616-39617;server_port=69
72-6973;ssrc=53F273FA

Setup "audio/MPEG4-GENERIC" subsession (client ports 39616-39617)
----------------------------------------------------------------------------
------------------------------------------------

For the first track the client port numbers proposed are "39616-39617" and
the server port numbers are "6970-6971". For the second stream, the client
port numbers are also "39616-39617", but now the server port numbers are
"6972-6973", as you suggested in your post.

Although this is correct, the recording will not start, because in the
select statement, one of these socket handles will never be set as readable,
even though packets are send correctly. Therefore, in the syncOK function,
we will never reach the point where s.fNumSyncedSubsessions equals
s.fNumSubsessions and the recording will never start (remember, we need
synchronized streams).

To solve this, you either try to determine from which server port number
each packet was sent (so you can set the synchronization flag for the
corresponding track id manually), or you make sure all streams use different
client port numbers (just by creating a NoReuse object or disabling the
default SO_REUSEADDR option).


As for the ephemeral socket numbers, I understand that you get random port
numbers this way, but I don't like it holding socket handles open for
sockets with an odd port number, especially in environments where resources
are scarce. This is related to the SO_REUSEADDR issue above, because if set,
you would get a working socket pair eventually, but if it is not set, there
is a chance (however very unlikely) that you couldn't create a usable socket
pair. I know this is nitpicking, just found it odd ;)

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Saturday, February 27, 2010 6:30 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] openRTSP

>I did not ran into the limit of sockets per thread but using netstat, I
>found out that sometimes two pairs of sockets used the same RTP and RTCP
>port numbers.

It's the server that decides what port numbers are used for RTP and 
RTCP for each stream.  If RTP and/or RTCP port numbers are being 
reused, then that appears to be a bug in your server.  (Our RTSP 
server code should not be doing this, so I hope your server is not 
using our code.)


>Also, in the MediaSubsession::initiate(int useSpecialRTPoffset) function
>only the pointer value of fRT(C)PSocket is checked after the creation of a
>Groupsock object. But if the socket creation call returns -1 in the
>constructor, the program will continue using the invalid socket handle.
>Apart from the pointer value of fRT(C)PSocket, the value of fSocketNum
>should be checked.

Yes, you're probably right.


>A last remark in the MediaSubsession::initiate(int useSpecialRTPoffset)
>function: I noticed that when the user does not specify a start port value
>(fClientsPortNum) sockets are created and checked if they are bound to an
>even port. If they don't they are added to a socketHashTable and a new
>socket is created until successful. Why not just create two sockets and
>trying to bind them to a given port number, just as is done when the user
>actually does give a start port number

Because that's not what we want to do.  Instead, we want the 
operating system to chose a port number for itself (this is, by 
convention, called an "ephemeral port number").  We just have to make 
sure that even port numbers are used for RTP.
-- 

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