> Date: Wed, 17 Dec 2008 17:20:01 +0100
> Subject: Re: [Live-devel] Nat and RTCP
>
>
> Thanks!
>
> I have another question.
> If I have another application that I will open the socket audio and video,
> how can I fix OnDemandServerMediaSubsession order to avoid reopening a
I have another question.
If I have another application that I will open the socket audio and
video, how can I fix OnDemandServerMediaSubsession order to avoid
reopening a socket already opened (so that he can use without
opening it)?
There's nothing wrong with "OnDemandServerMediaSubsession",
> Date: Wed, 17 Dec 2008 05:14:02 -0800
> To: live-de...@ns.live555.com
> From: finlay...@live555.com
> Subject: Re: [Live-devel] Nat and RTCP
>
>>it is a blasphemy to speak of RTCP on the same port RTP to have
>>fewer problems with NAT?
>
> Yes (it'
it is a blasphemy to speak of RTCP on the same port RTP to have
fewer problems with NAT?
Yes (it's not just 'blasphemy'; it won't work).
One thing you can do, however, is use RTP/RTCP-over-TCP streaming
(using the RTSP channel). That way, you need only relay one (TCP)
port number - the one f
My hunch tells me the RTCP ports are dynamically set by the stack
Yes, however, the RTP and RTCP ports start at 6970 by default (see
"liveMedia/include/OnDemandServerMediaSubsession.hh"). (I chose that
number because other servers - e.g., Apple's - use the same number.)
RTP ports are always
Thanks Ross for your quick reply!
Regards,
Ken
2008/8/20 Ross Finlayson <[EMAIL PROTECTED]>
> Now the client can make an RTSP request just fine and start playing the
> stream. However, the RTCP packets from the client to the server get lost and
> as a result, the server stops the streaming wit
Now the client can make an RTSP request just fine and start playing
the stream. However, the RTCP packets from the client to the server
get lost and as a result, the server stops the streaming with
liveness timeout after 45 seconds. I've captured RTCP packets and
found out that the packet's des
