RE: Problem with HelixServerTimeout Value

Hi All,

This may or may not be relevant here...

In the past, we have seen some networks set up such that if
you chatted
with them too much too fast, they considered it a
denial-of-service
attack and closed the connection.  I do not remember the
exact
circumstances in which we hit that scenario, but it may be a
reason for
what you are seeing.

Anuj, if you think this is relevant, please stop by and we
can chat.


pat


-----Original Message-----
From: nokia-private-dev-bounceshelixcommunity.org
[mailto:nokia-private-dev-bounceshelixcommunity.org] 
Sent: Tuesday, February 26, 2008 1:15 PM
To: gwrightreal.com
Cc: nokia-private-devhelixcommunity.org;
protocol-devhelixcommunity.org; server-devreal.com
Subject: [Nokia-private-dev] RE: [Protocol-dev] Problem
with
HelixServerTimeout Value

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