We have seen similar problems, i.e. the same port numbers being assigned
to 2 different streams.
Basically our client would work for several successive instantiations
and shutdowns of the client app and each time the OS (or whatever it is
that hands out the next available port number) would increment the
assigned port numbers until eventually it hit the limit of assignable
ports (something like max short, something pretty close to the 34394
that your seeing) and then it would always assign the same port numbers
to both streams. I think the only way to clear the problem and get it
working again was to reboot the system.We did check, and there were not
zombie instances of the client running and we didn't seen any left over
connections in the socket tables.
I don't think we've figured this one out yet.
Matt S.
Guido Marelli wrote:
Hi,
I've found that in some cases (it seems to be random) the method
mediaSubsession::initiate will use the same UDP ports for both a video
stream and an audio stream. A sample output for the openRTSP program
is the following:
Created receiver for "video/MP4V-ES" subsession (client ports
34394-34395)
Created receiver for "audio/PCMU" subsession (client ports 34394-34395)
Setup "video/MP4V-ES" subsession (client ports 34394-34395)
Setup "audio/PCMU" subsession (client ports 34394-34395)
The problem seems to be the SO_REUSEPORT socket option on the
setupDatagramSocket function.
So, my question is: Is it safe to disable that option?
I look forward to hearing from you,
Regads,
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
