Dear Sir:<br><br>I have conquered this problem today. It was my carelessness since I didn&#39;t apply genWindowsMakefiles to build live555 but instead open a new porject in VC6 and import the sources to compile.<br><br>By default, only WIN32 is defined. But 
NetCommon.h requres __WIN32__, _WIN32, _WINNT or WINNT to be defined on Windows XP. This causes winsock2.h and ws2tcpip.h not to be included such that inappropriate macros used to call setsocketopt() leads to failure of joining a multicast group.
<br><br>Besides, in a practical multicast client application, it may be a problem if the RTSP server doesn&#39;t specify the media port in its SDP, for example, m=video 0&nbsp; 0 RTP/AVP 96. This will cause MediaSubession::fClientPortNum to be assigned 0. and then RTSPClient::setupMediaSubsession() will return False because the following condition holds:
<br><pre class="fragment">rtpNumber = <a class="code" href="http://www.live555.com/liveMedia/public/doxygen/html/AVIFileSink_8cpp.html#25e0e015bb23ec5ef03f7e9b9be9b7f4">subsession</a>.<a class="code" href="http://www.live555.com/liveMedia/public/doxygen/html/classMediaSubsession.html#626cf63889f4f00a8eb28355c73abbb0">
clientPortNum</a>();<br><span class="keywordflow">if</span> (rtpNumber == 0) {<br>         envir().setResultMsg(<span class="stringliteral">&quot;Client port number unknown\n&quot;</span>);<br><a name="l00902"></a>         
<span class="keywordflow">break</span>;<br><span style="font-family: monospace;">}</span><br></pre>How about assigning a randomly generated port number here when initializing a MediaSession with SDP since it is not relevant for this application?
<br><br>Actually RFC2326 seems not to force the server to explicitly specify a media port number:<br><pre>C.1.2 Media streams<br><br>   The &quot;m=&quot; field is used to enumerate the streams. It is expected that<br>   all the specified streams will be rendered with appropriate
<br>   synchronization. If the session is unicast, the port number serves as<br>   a recommendation from the server to the client; the client still has<br>   to include it in its SETUP request and may ignore this<br>   recommendation.  
<span style="font-weight: bold;">If the server has no preference, it SHOULD set the</span><br style="font-weight: bold;"><span style="font-weight: bold;">   port number value to zero.</span><br><br>   Example:<br>     m=audio 0 RTP/AVP 31
</pre>BR.<br>Brain Lai<br><br><br><div><span class="gmail_quote">2007/11/12, Brain Lai &lt;<a href="mailto:brainlai@gmail.com">brainlai@gmail.com</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear Sir:<br><br>Multicast applications on Windows platform seem to have a problem. After doing some experiments with your test program, I found the openRTSP agent compiled with VC6 fails to receive video stream multicast by testMPEG4VideoStreamer on Linux(that is, getNextFrame() never get a frame after RTSP PLAY response). However, the cross-compiled(mingw32) version of openRTSP succeeds! Since VLC for win32 is also cross-compiled, it also has no problem. 
<br><br>Using wireshark(previous ethreal) to capture the network packets, I found that the cross-compiled version sent IGMP V3 membership message to join the multicast group but the VC6 compiled version doesn&#39;t.<br><br>

I am not familiar with Windows socket programming but there seems something missing or wrong. Do you ever get into this trouble and solve it?<br><br>BTW, all the tests link to the latest live555.<br><br>BR.<br><span class="sg">
Brain Lai<br>
</span></blockquote></div><br>