Problem with Helix ServerTimeout Value

Adding server-dev, more below....

ext-anuj.dhamijanokia.com wrote:
> Hi,
> 
> ServerTimeout in Helix is used to decide frequency of
sending RTSP 
> keep-alive messages [OPTIONS message] to streaming
server. Currently a 
> keep-alive message is sent every n seconds where n is
(half of) minimum 
> of timeout value suggested by sever (ie the value of
timeout field in 
> response from server) and timeout value specified in
configuration file 
> (ServerTimeout).
> 
> So if server suggests a timeout value of 60 secs and
configuration says 
> 20 secs (which is default for Helix) then an OPTIONS
message is sent 
> every 10 secs (20/2).
> 
> While playing one of streaming links from
m.youtube.com
> ( _http://ww
w.youtube.com/watch?v=QmcKGcKW76M_ ), server closes 
> connection at 50th message in the session. In this case
video is of 
> duration 30 minutes. Server timeout value is 60 seconds
which would 
> equate to 30 keep alives during the whole duration. Now
Helix sends out 
> keep-alive every 10 seconds (using default configured
timeout value of 
> 20) . So 50 keep-alives are sent during first 8 minutes
itself. Server 
> breaks the connection down on receiving message with
CSeq 50.
> 
> When same link is played with player which sends
keep-alive at around 
> same time as suggested by server (every 60 secs) then
clip is played to 
> the full. With Helix, increasing the ServerTimeout
value in 
> configuration file increases the play duration. So
setting ServerTimeout 
> value to 60 makes effective keep-alive message every 30
secs enabling 
> the play time to stretch upto 25 minutes.
> 
> Please suggest me that what is the reason for not using
the timeout 
> value as prescribed by server for sending keep alive
messages? Also is 
> the behavior of a server to abruptly disconnect at some
specific message 
> count justified?

Here are my thoughts, the server team might know more:

o I imaging that we don't use the timeout value from the
server
   because we found bugs on certain servers or proxies and
had
   to work around them. Changing the timeout value to what
the
   server suggests may break those again (I am just guessing
as
   to the history here).
o Does the server return OK for all those keep alive
messages?
   If the server returns an error or some other message
then
   perhaps we can code around this one server and not
change
   the behavior for all the others.
o Changing the timeout value will not fix the problem, it
will
   simply die on longer clips since the server will still
   disconnect after 50 messages correct?

If you have a wireshark/ethereal trace that would be helpful
to
look at for us.

--greg.


> 
> thnx & regds
> AD
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> Protocol-dev mailing list
> Protocol-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

Hi Greg,

Server does acknowledge all keep-alives with OK. 

Probably for longer clips, server may suggest a bigger
timeout value
enabling longer playbacks. It may be a traffic management
mechanism
implemented on server side to control incoming traffic.

I am attaching RTSP Stream (as text file). (N/W capture is
pretty big to
attach).

Thnx & regds
AD

-----Original Message-----
From: ext Greg Wright [mailto:gwrightreal.com] 
Sent: Tuesday, February 26, 2008 12:06 PM
To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas)
Cc: protocol-devhelixcommunity.org;
TP-SP-SWD-MMC-VIDEO-HELIX DG;
server-devreal.com
Subject: Re: [Protocol-dev] Problem with Helix ServerTimeout
Value

Adding server-dev, more below....

ext-anuj.dhamijanokia.com wrote:
> Hi,
> 
> ServerTimeout in Helix is used to decide frequency of
sending RTSP 
> keep-alive messages [OPTIONS message] to streaming
server. Currently a

> keep-alive message is sent every n seconds where n is
(half of) 
> minimum of timeout value suggested by sever (ie the
value of timeout 
> field in response from server) and timeout value
specified in 
> configuration file (ServerTimeout).
> 
> So if server suggests a timeout value of 60 secs and
configuration 
> says 20 secs (which is default for Helix) then an
OPTIONS message is 
> sent every 10 secs (20/2).
> 
> While playing one of streaming links from m.youtube.com
( 
> _http://ww
w.youtube.com/watch?v=QmcKGcKW76M_ ), server closes 
> connection at 50th message in the session. In this case
video is of 
> duration 30 minutes. Server timeout value is 60 seconds
which would 
> equate to 30 keep alives during the whole duration. Now
Helix sends 
> out keep-alive every 10 seconds (using default
configured timeout 
> value of
> 20) . So 50 keep-alives are sent during first 8 minutes
itself. Server

> breaks the connection down on receiving message with
CSeq 50.
> 
> When same link is played with player which sends
keep-alive at around 
> same time as suggested by server (every 60 secs) then
clip is played 
> to the full. With Helix, increasing the ServerTimeout
value in 
> configuration file increases the play duration. So
setting 
> ServerTimeout value to 60 makes effective keep-alive
message every 30 
> secs enabling the play time to stretch upto 25
minutes.
> 
> Please suggest me that what is the reason for not using
the timeout 
> value as prescribed by server for sending keep alive
messages? Also is

> the behavior of a server to abruptly disconnect at some
specific 
> message count justified?

Here are my thoughts, the server team might know more:

o I imaging that we don't use the timeout value from the
server
   because we found bugs on certain servers or proxies and
had
   to work around them. Changing the timeout value to what
the
   server suggests may break those again (I am just guessing
as
   to the history here).
o Does the server return OK for all those keep alive
messages?
   If the server returns an error or some other message
then
   perhaps we can code around this one server and not
change
   the behavior for all the others.
o Changing the timeout value will not fix the problem, it
will
   simply die on longer clips since the server will still
   disconnect after 50 messages correct?

If you have a wireshark/ethereal trace that would be helpful
to look at
for us.

--greg.


> 
> thnx & regds
> AD
> 
> 
>
------------------------------------------------------------
----------
> --
> 
> _______________________________________________
> Protocol-dev mailing list
> Protocol-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

ext-anuj.dhamijanokia.com wrote:
> Hi Greg,
> 
> Server does acknowledge all keep-alives with OK. 
> 
> Probably for longer clips, server may suggest a bigger
timeout value
> enabling longer playbacks. It may be a traffic
management mechanism
> implemented on server side to control incoming
traffic.
> 
> I am attaching RTSP Stream (as text file). (N/W capture
is pretty big to
> attach).

The formatting is very hard to read. Can you not filter the
dump and
zip that up? You can filter by just TCP so you don't get any
data
packets. But, this looks very strange:

OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 6 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 6 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 7 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 7 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 8 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 8 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 9 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 9 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 10 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 10 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 11 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 11 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 12 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 12 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 13 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 13 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 14 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 14 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 15 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 15 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 16 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 16 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 17 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 17 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 18 User-Agent: RealMedia Player
HelixDNAClient/10.0.0.6839 (S60 HX 
cvs_cays221_20080220:19:00:00utc 20 Feb 2008 16:40) Session:
30bd4304
RTSP/1.0 200 OK Public: DESCRIBE, SETUP, TEARDOWN, PLAY,
PAUSE CSeq: 18 Session: 30bd4304 Server: Google RTSP 1.0
OPTIONS
rtsp://bfehug.rtsp-youtube.l.google.com/CiULENy73wIaHAmj75bC
GQpnQhMYESARFEIJbXYtZ29vZ2xlSAQM/0/0/0/video.3gp/ RTSP/1.0
CSeq: 19


Those are not keep alive requests, those are OPTION requests
and I
have never seen a client sent them more then 1 time per
stream.
Something is wrong with the client.

--greg.


> 
> Thnx & regds
> AD
> 
> -----Original Message-----
> From: ext Greg Wright [mailto:gwrightreal.com]

> Sent: Tuesday, February 26, 2008 12:06 PM
> To: Dhamija Anuj
(EXT-InfoVisionConsultants-MSW/Dallas)
> Cc: protocol-devhelixcommunity.org;
TP-SP-SWD-MMC-VIDEO-HELIX DG;
> server-devreal.com
> Subject: Re: [Protocol-dev] Problem with Helix
ServerTimeout Value
> 
> Adding server-dev, more below....
> 
> ext-anuj.dhamijanokia.com wrote:
>> Hi,
>>
>> ServerTimeout in Helix is used to decide frequency
of sending RTSP 
>> keep-alive messages [OPTIONS message] to streaming
server. Currently a
> 
>> keep-alive message is sent every n seconds where n
is (half of) 
>> minimum of timeout value suggested by sever (ie the
value of timeout 
>> field in response from server) and timeout value
specified in 
>> configuration file (ServerTimeout).
>>
>> So if server suggests a timeout value of 60 secs
and configuration 
>> says 20 secs (which is default for Helix) then an
OPTIONS message is 
>> sent every 10 secs (20/2).
>>
>> While playing one of streaming links from
m.youtube.com ( 
>> _http://ww
w.youtube.com/watch?v=QmcKGcKW76M_ ), server closes 
>> connection at 50th message in the session. In this
case video is of 
>> duration 30 minutes. Server timeout value is 60
seconds which would 
>> equate to 30 keep alives during the whole duration.
Now Helix sends 
>> out keep-alive every 10 seconds (using default
configured timeout 
>> value of
>> 20) . So 50 keep-alives are sent during first 8
minutes itself. Server
> 
>> breaks the connection down on receiving message
with CSeq 50.
>>
>> When same link is played with player which sends
keep-alive at around 
>> same time as suggested by server (every 60 secs)
then clip is played 
>> to the full. With Helix, increasing the
ServerTimeout value in 
>> configuration file increases the play duration. So
setting 
>> ServerTimeout value to 60 makes effective
keep-alive message every 30 
>> secs enabling the play time to stretch upto 25
minutes.
>>
>> Please suggest me that what is the reason for not
using the timeout 
>> value as prescribed by server for sending keep
alive messages? Also is
> 
>> the behavior of a server to abruptly disconnect at
some specific 
>> message count justified?
> 
> Here are my thoughts, the server team might know more:
> 
> o I imaging that we don't use the timeout value from
the server
>    because we found bugs on certain servers or proxies
and had
>    to work around them. Changing the timeout value to
what the
>    server suggests may break those again (I am just
guessing as
>    to the history here).
> o Does the server return OK for all those keep alive
messages?
>    If the server returns an error or some other message
then
>    perhaps we can code around this one server and not
change
>    the behavior for all the others.
> o Changing the timeout value will not fix the problem,
it will
>    simply die on longer clips since the server will
still
>    disconnect after 50 messages correct?
> 
> If you have a wireshark/ethereal trace that would be
helpful to look at
> for us.
> 
> --greg.
> 
> 
>> thnx & regds
>> AD
>>
>>
>>
------------------------------------------------------------
----------
>> --
>>
>> _______________________________________________
>> Protocol-dev mailing list
>> Protocol-devhelixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
> 


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

Keep-Alive requests need to be sent more frequently than the
server
specified value in order to ensure that the connection is
kept alive.
If the server specifies 60 sec (and will thus time out the
session
after 60 seconds of inactivity) and the client actually
waits a full 60
secs between messages then there is a very good chance the
server will
see 60 seconds or more of inactivity and timeout the session
just before
receiving that next message. Especially on mobile networks
where your
latency can vary quite a bit! Halving the interval might be
excessive
though.

YouTube mobile *was* using Darwin servers. According to this
trace, it
is using "Google RTSP 1.0" server. Seems likely to
be based on Darwin
core.

The client in this trace is not doing anything wrong with
regards to
RTSP keep-alives. Are you certain that the *only* thing you
are
changing is the interval between keep-alive RTSP requests
and this
*does* keep the connection alive?

There is something funky going on in an intermediate proxy
though, (and
said proxy is not making itself known with Via headers).
Note that the
client gave its ports as 6970-6971 and 6972-6973, but the
response
claims to be sending to client ports 21010-21011 and
21012-21013.

There are some other issues appearing in this trace that
would not 
affect keep-alive but which are strange - first, the client
is sending
a Require: com.real.retain-entity-for-setup in the DESCRIBE
request.
It should not be doing that here, since it is clearly not
carrying the
DESCRIBE on a session and is instead operating in standard
RTSP.
Secondly, since the server clearly is not supporting that
required
option, it should have responded with a 551 (not supported).
I would
note here that I have seen that Darwin ignores Required
parameters
rather than responding with 551, which is part of the reason
I believe
this server to still be Darwin based.

Thanks,
Jamie

ext-anuj.dhamijanokia.com wrote:
> Hi Greg,
> 
> Server does acknowledge all keep-alives with OK. 
> 
> Probably for longer clips, server may suggest a bigger
timeout value
> enabling longer playbacks. It may be a traffic
management mechanism
> implemented on server side to control incoming
traffic.
> 
> I am attaching RTSP Stream (as text file). (N/W capture
is pretty big to
> attach).
> 
> Thnx & regds
> AD
> 
> -----Original Message-----
> From: ext Greg Wright [mailto:gwrightreal.com]

> Sent: Tuesday, February 26, 2008 12:06 PM
> To: Dhamija Anuj
(EXT-InfoVisionConsultants-MSW/Dallas)
> Cc: protocol-devhelixcommunity.org;
TP-SP-SWD-MMC-VIDEO-HELIX DG;
> server-devreal.com
> Subject: Re: [Protocol-dev] Problem with Helix
ServerTimeout Value
> 
> Adding server-dev, more below....
> 
> ext-anuj.dhamijanokia.com wrote:
>> Hi,
>>
>> ServerTimeout in Helix is used to decide frequency
of sending RTSP 
>> keep-alive messages [OPTIONS message] to streaming
server. Currently a
> 
>> keep-alive message is sent every n seconds where n
is (half of) 
>> minimum of timeout value suggested by sever (ie the
value of timeout 
>> field in response from server) and timeout value
specified in 
>> configuration file (ServerTimeout).
>>
>> So if server suggests a timeout value of 60 secs
and configuration 
>> says 20 secs (which is default for Helix) then an
OPTIONS message is 
>> sent every 10 secs (20/2).
>>
>> While playing one of streaming links from
m.youtube.com ( 
>> _http://ww
w.youtube.com/watch?v=QmcKGcKW76M_ ), server closes 
>> connection at 50th message in the session. In this
case video is of 
>> duration 30 minutes. Server timeout value is 60
seconds which would 
>> equate to 30 keep alives during the whole duration.
Now Helix sends 
>> out keep-alive every 10 seconds (using default
configured timeout 
>> value of
>> 20) . So 50 keep-alives are sent during first 8
minutes itself. Server
> 
>> breaks the connection down on receiving message
with CSeq 50.
>>
>> When same link is played with player which sends
keep-alive at around 
>> same time as suggested by server (every 60 secs)
then clip is played 
>> to the full. With Helix, increasing the
ServerTimeout value in 
>> configuration file increases the play duration. So
setting 
>> ServerTimeout value to 60 makes effective
keep-alive message every 30 
>> secs enabling the play time to stretch upto 25
minutes.
>>
>> Please suggest me that what is the reason for not
using the timeout 
>> value as prescribed by server for sending keep
alive messages? Also is
> 
>> the behavior of a server to abruptly disconnect at
some specific 
>> message count justified?
> 
> Here are my thoughts, the server team might know more:
> 
> o I imaging that we don't use the timeout value from
the server
>    because we found bugs on certain servers or proxies
and had
>    to work around them. Changing the timeout value to
what the
>    server suggests may break those again (I am just
guessing as
>    to the history here).
> o Does the server return OK for all those keep alive
messages?
>    If the server returns an error or some other message
then
>    perhaps we can code around this one server and not
change
>    the behavior for all the others.
> o Changing the timeout value will not fix the problem,
it will
>    simply die on longer clips since the server will
still
>    disconnect after 50 messages correct?
> 
> If you have a wireshark/ethereal trace that would be
helpful to look at
> for us.
> 
> --greg.
> 
> 
>> thnx & regds
>> AD
>>
>>
>>
------------------------------------------------------------
----------
>> --
>>
>> _______________________________________________
>> Protocol-dev mailing list
>> Protocol-devhelixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
> 

_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

Hi Jamie, 

I don't exactly understand what you mean by : "Are you
certain that the
*only* thing you are changing is the interval between
keep-alive RTSP
requests and this *does* keep the connection alive?"
Increasing time between successive keep-alives does increase
the play
duration. It is direct consequence of fact that server is
disconnecting
at 50th message. So increasing keep-alive interval delays
the 50th
message and so video is played till late. Connection is
alive as long as
server recieves some message within stipulated timeout
duration.

Disconnecting based on message count looks like something
Google
Server's implementation rule. You know of any other server
implementations which do this?

Greg,
I think OPTIONS message is used as keep-alive message in
case of Helix.

Regds
AD


-----Original Message-----
From: ext Jamie Gordon [mailto:jgordonreal.com] 
Sent: Tuesday, February 26, 2008 1:52 PM
To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas)
Cc: gwrightreal.com; protocol-devhelixcommunity.org;
server-devreal.com; nokia-private-devhelixcommunity.org
Subject: Re: [Protocol-dev] Problem with Helix ServerTimeout
Value

Keep-Alive requests need to be sent more frequently than the
server
specified value in order to ensure that the connection is
kept alive.
If the server specifies 60 sec (and will thus time out the
session after
60 seconds of inactivity) and the client actually waits a
full 60 secs
between messages then there is a very good chance the server
will see 60
seconds or more of inactivity and timeout the session just
before
receiving that next message. Especially on mobile networks
where your
latency can vary quite a bit! Halving the interval might be
excessive
though.

YouTube mobile *was* using Darwin servers. According to this
trace, it
is using "Google RTSP 1.0" server. Seems likely to
be based on Darwin
core.

The client in this trace is not doing anything wrong with
regards to
RTSP keep-alives. Are you certain that the *only* thing you
are changing
is the interval between keep-alive RTSP requests and this
*does* keep the connection alive?

There is something funky going on in an intermediate proxy
though, (and
said proxy is not making itself known with Via headers).
Note that the
client gave its ports as 6970-6971 and 6972-6973, but the
response
claims to be sending to client ports 21010-21011 and
21012-21013.

There are some other issues appearing in this trace that
would not
affect keep-alive but which are strange - first, the client
is sending a
Require: com.real.retain-entity-for-setup in the DESCRIBE
request.
It should not be doing that here, since it is clearly not
carrying the
DESCRIBE on a session and is instead operating in standard
RTSP.
Secondly, since the server clearly is not supporting that
required
option, it should have responded with a 551 (not supported).
I would
note here that I have seen that Darwin ignores Required
parameters
rather than responding with 551, which is part of the reason
I believe
this server to still be Darwin based.

Thanks,
Jamie

ext-anuj.dhamijanokia.com wrote:
> Hi Greg,
> 
> Server does acknowledge all keep-alives with OK. 
> 
> Probably for longer clips, server may suggest a bigger
timeout value 
> enabling longer playbacks. It may be a traffic
management mechanism 
> implemented on server side to control incoming
traffic.
> 
> I am attaching RTSP Stream (as text file). (N/W capture
is pretty big 
> to attach).
> 
> Thnx & regds
> AD
> 
> -----Original Message-----
> From: ext Greg Wright [mailto:gwrightreal.com]
> Sent: Tuesday, February 26, 2008 12:06 PM
> To: Dhamija Anuj
(EXT-InfoVisionConsultants-MSW/Dallas)
> Cc: protocol-devhelixcommunity.org;
TP-SP-SWD-MMC-VIDEO-HELIX DG; 
> server-devreal.com
> Subject: Re: [Protocol-dev] Problem with Helix
ServerTimeout Value
> 
> Adding server-dev, more below....
> 
> ext-anuj.dhamijanokia.com wrote:
>> Hi,
>>
>> ServerTimeout in Helix is used to decide frequency
of sending RTSP 
>> keep-alive messages [OPTIONS message] to streaming
server. Currently 
>> a
> 
>> keep-alive message is sent every n seconds where n
is (half of) 
>> minimum of timeout value suggested by sever (ie the
value of timeout 
>> field in response from server) and timeout value
specified in 
>> configuration file (ServerTimeout).
>>
>> So if server suggests a timeout value of 60 secs
and configuration 
>> says 20 secs (which is default for Helix) then an
OPTIONS message is 
>> sent every 10 secs (20/2).
>>
>> While playing one of streaming links from
m.youtube.com ( 
>> _http://ww
w.youtube.com/watch?v=QmcKGcKW76M_ ), server closes 
>> connection at 50th message in the session. In this
case video is of 
>> duration 30 minutes. Server timeout value is 60
seconds which would 
>> equate to 30 keep alives during the whole duration.
Now Helix sends 
>> out keep-alive every 10 seconds (using default
configured timeout 
>> value of
>> 20) . So 50 keep-alives are sent during first 8
minutes itself. 
>> Server
> 
>> breaks the connection down on receiving message
with CSeq 50.
>>
>> When same link is played with player which sends
keep-alive at around

>> same time as suggested by server (every 60 secs)
then clip is played 
>> to the full. With Helix, increasing the
ServerTimeout value in 
>> configuration file increases the play duration. So
setting 
>> ServerTimeout value to 60 makes effective
keep-alive message every 30

>> secs enabling the play time to stretch upto 25
minutes.
>>
>> Please suggest me that what is the reason for not
using the timeout 
>> value as prescribed by server for sending keep
alive messages? Also 
>> is
> 
>> the behavior of a server to abruptly disconnect at
some specific 
>> message count justified?
> 
> Here are my thoughts, the server team might know more:
> 
> o I imaging that we don't use the timeout value from
the server
>    because we found bugs on certain servers or proxies
and had
>    to work around them. Changing the timeout value to
what the
>    server suggests may break those again (I am just
guessing as
>    to the history here).
> o Does the server return OK for all those keep alive
messages?
>    If the server returns an error or some other message
then
>    perhaps we can code around this one server and not
change
>    the behavior for all the others.
> o Changing the timeout value will not fix the problem,
it will
>    simply die on longer clips since the server will
still
>    disconnect after 50 messages correct?
> 
> If you have a wireshark/ethereal trace that would be
helpful to look 
> at for us.
> 
> --greg.
> 
> 
>> thnx & regds
>> AD
>>
>>
>>
------------------------------------------------------------
---------
>> -
>> --
>>
>> _______________________________________________
>> Protocol-dev mailing list
>> Protocol-devhelixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
> 

_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

ext-anuj.dhamijanokia.com wrote:
> Hi Jamie, 
> 
> I don't exactly understand what you mean by : "Are
you certain that the
> *only* thing you are changing is the interval between
keep-alive RTSP
> requests and this *does* keep the connection
alive?"
> Increasing time between successive keep-alives does
increase the play
> duration. It is direct consequence of fact that server
is disconnecting
> at 50th message. So increasing keep-alive interval
delays the 50th
> message and so video is played till late. Connection is
alive as long as
> server recieves some message within stipulated timeout
duration.
> 

What I meant was just are you certain that it is the number
or
frequency of messages that is the issue, as opposed to
something else,
such as the server not receiving/acknowledging RTCP
feedback. It
definitely sounds like you've made certain that it is the
number/frequency that is the issue. So if you increase the
interval,
it will always disconnect at 50, regardless when that
occurs? That
is crazy.

> Disconnecting based on message count looks like
something Google
> Server's implementation rule. You know of any other
server
> implementations which do this?
> 
This would be very strange. If they always disconnect at 50
messages,
then certainly they can't handle long sessions at all. I
mean even if
the client sends at exactly the server specified timeout
duration,
it will hit 50 messages after 50 minutes! Frequency seems a
bit more
sensible, but even so I would expect once per 10 seconds to
be
considered too frequent.

Thanks,
Jamie

> Greg,
> I think OPTIONS message is used as keep-alive message
in case of Helix.
> 

> Regds
> AD
> 
> 
> -----Original Message-----
> From: ext Jamie Gordon [mailto:jgordonreal.com]

> Sent: Tuesday, February 26, 2008 1:52 PM
> To: Dhamija Anuj
(EXT-InfoVisionConsultants-MSW/Dallas)
> Cc: gwrightreal.com; protocol-devhelixcommunity.org;
> server-devreal.com; nokia-private-devhelixcommunity.org
> Subject: Re: [Protocol-dev] Problem with Helix
ServerTimeout Value
> 
> Keep-Alive requests need to be sent more frequently
than the server
> specified value in order to ensure that the connection
is kept alive.
> If the server specifies 60 sec (and will thus time out
the session after
> 60 seconds of inactivity) and the client actually waits
a full 60 secs
> between messages then there is a very good chance the
server will see 60
> seconds or more of inactivity and timeout the session
just before
> receiving that next message. Especially on mobile
networks where your
> latency can vary quite a bit! Halving the interval
might be excessive
> though.
> 
> YouTube mobile *was* using Darwin servers. According to
this trace, it
> is using "Google RTSP 1.0" server. Seems
likely to be based on Darwin
> core.
> 
> The client in this trace is not doing anything wrong
with regards to
> RTSP keep-alives. Are you certain that the *only* thing
you are changing
> is the interval between keep-alive RTSP requests and
this
> *does* keep the connection alive?
> 
> There is something funky going on in an intermediate
proxy though, (and
> said proxy is not making itself known with Via
headers). Note that the
> client gave its ports as 6970-6971 and 6972-6973, but
the response
> claims to be sending to client ports 21010-21011 and
21012-21013.
> 
> There are some other issues appearing in this trace
that would not
> affect keep-alive but which are strange - first, the
client is sending a
> Require: com.real.retain-entity-for-setup in the
DESCRIBE request.
> It should not be doing that here, since it is clearly
not carrying the
> DESCRIBE on a session and is instead operating in
standard RTSP.
> Secondly, since the server clearly is not supporting
that required
> option, it should have responded with a 551 (not
supported). I would
> note here that I have seen that Darwin ignores Required
parameters
> rather than responding with 551, which is part of the
reason I believe
> this server to still be Darwin based.
> 
> Thanks,
> Jamie
> 
> ext-anuj.dhamijanokia.com wrote:
>> Hi Greg,
>>
>> Server does acknowledge all keep-alives with OK. 
>>
>> Probably for longer clips, server may suggest a
bigger timeout value 
>> enabling longer playbacks. It may be a traffic
management mechanism 
>> implemented on server side to control incoming
traffic.
>>
>> I am attaching RTSP Stream (as text file). (N/W
capture is pretty big 
>> to attach).
>>
>> Thnx & regds
>> AD
>>
>> -----Original Message-----
>> From: ext Greg Wright [mailto:gwrightreal.com]
>> Sent: Tuesday, February 26, 2008 12:06 PM
>> To: Dhamija Anuj
(EXT-InfoVisionConsultants-MSW/Dallas)
>> Cc: protocol-devhelixcommunity.org;
TP-SP-SWD-MMC-VIDEO-HELIX DG; 
>> server-devreal.com
>> Subject: Re: [Protocol-dev] Problem with Helix
ServerTimeout Value
>>
>> Adding server-dev, more below....
>>
>> ext-anuj.dhamijanokia.com wrote:
>>> Hi,
>>>
>>> ServerTimeout in Helix is used to decide
frequency of sending RTSP 
>>> keep-alive messages [OPTIONS message] to
streaming server. Currently 
>>> a
>>> keep-alive message is sent every n seconds
where n is (half of) 
>>> minimum of timeout value suggested by sever (ie
the value of timeout 
>>> field in response from server) and timeout
value specified in 
>>> configuration file (ServerTimeout).
>>>
>>> So if server suggests a timeout value of 60
secs and configuration 
>>> says 20 secs (which is default for Helix) then
an OPTIONS message is 
>>> sent every 10 secs (20/2).
>>>
>>> While playing one of streaming links from
m.youtube.com ( 
>>> _http://ww
w.youtube.com/watch?v=QmcKGcKW76M_ ), server closes 
>>> connection at 50th message in the session. In
this case video is of 
>>> duration 30 minutes. Server timeout value is 60
seconds which would 
>>> equate to 30 keep alives during the whole
duration. Now Helix sends 
>>> out keep-alive every 10 seconds (using default
configured timeout 
>>> value of
>>> 20) . So 50 keep-alives are sent during first 8
minutes itself. 
>>> Server
>>> breaks the connection down on receiving message
with CSeq 50.
>>>
>>> When same link is played with player which
sends keep-alive at around
> 
>>> same time as suggested by server (every 60
secs) then clip is played 
>>> to the full. With Helix, increasing the
ServerTimeout value in 
>>> configuration file increases the play duration.
So setting 
>>> ServerTimeout value to 60 makes effective
keep-alive message every 30
> 
>>> secs enabling the play time to stretch upto 25
minutes.
>>>
>>> Please suggest me that what is the reason for
not using the timeout 
>>> value as prescribed by server for sending keep
alive messages? Also 
>>> is
>>> the behavior of a server to abruptly disconnect
at some specific 
>>> message count justified?
>> Here are my thoughts, the server team might know
more:
>>
>> o I imaging that we don't use the timeout value
from the server
>>    because we found bugs on certain servers or
proxies and had
>>    to work around them. Changing the timeout value
to what the
>>    server suggests may break those again (I am just
guessing as
>>    to the history here).
>> o Does the server return OK for all those keep
alive messages?
>>    If the server returns an error or some other
message then
>>    perhaps we can code around this one server and
not change
>>    the behavior for all the others.
>> o Changing the timeout value will not fix the
problem, it will
>>    simply die on longer clips since the server will
still
>>    disconnect after 50 messages correct?
>>
>> If you have a wireshark/ethereal trace that would
be helpful to look 
>> at for us.
>>
>> --greg.
>>
>>
>>> thnx & regds
>>> AD
>>>
>>>
>>>
------------------------------------------------------------
---------
>>> -
>>> --
>>>
>>>
_______________________________________________
>>> Protocol-dev mailing list
>>> Protocol-devhelixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev