Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #121 - 3 msgs

From: [email-masked]
Date: Sun, 29 Feb 2004 20:06:02 -0800

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net)
   2. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net)
   3. [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT. (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:43:21 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause

Bugs item #507882, was opened at 2002-01-24 09:30
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: RTP timestamps when playing after pause

Initial Comment:
What happends to the RTP timestamp when you issue a play after being paused for some time?

The following was my interpretation of the proposal for a solution. The
RTP timestamp is equal to display time. So it you do pause, wait five
seconds and then press play the timestamp will be 5 seconds later for
the first packet when resuming.

This behavior works fine when the play contains a range, for queued play
following after each other, but not for resuming play. The reason is the
delay between a user on the client side pressing pause and until the
client stops receiving data packets. If the client then does resume
play, i.e. play without range, the server will continue after the last
packet sent. In this case the client needs to show first the packet
arriving directly after pressing pause (which according to the used
model is past time), and then correctly synchronize the new packet which
has a significant offset in timestamp corresponding to the period of
pause the server has seen. The solution to this is to not use resume
play and instead say play from the point where user pressed pause.

On the other side I don&#039;t believe any other model will not have worse
problems.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:43

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:41

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:40

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:37

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 15:12

Message:
Logged In: YES 
user_id=302620

Aravind has agreed to write up the example and necessary
text. Transfering bug to him.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 10:48

Message:
Logged In: YES 
user_id=302620

A Clear example of RTP Timestamp and synchronization will be
added in appendix B - RTP transport.

The discussion in MMUSIC has made it clear that a continous
time model is needed to make RTCP work correctly. It has to
be accpeted that for on-demand media this will result in
slightly more code for the clients and servers. However all
pices to makes things work is already present. 

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-23 16:05

Message:
Logged In: YES 
user_id=302620

This has been further discussed in the MMUSIC mailing list. 

A important point is that RTP and RTCP to function as
intended in this environment must have a timestamp space
that increase continously with real time. 

A client handling the RTSP range header and RTP-Info can
always synchronize the data correctly independtly of which
case the server sent out. 

Using a continous RTP Timestamp space allows the same
timestamp model for both on-demand and live media.

The proposed resolution is to clrafiy in the RTP appendix of
the specification that a RTP timestamp space continous in
regards to real-time SHALL be used. Further write a warning
that this has been missunderstood and clients is RECOMMENDED
to handle both cases. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:45:22 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause

Bugs item #507882, was opened at 2002-01-24 09:30
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: RTP timestamps when playing after pause

Initial Comment:
What happends to the RTP timestamp when you issue a play after being paused for some time?

The following was my interpretation of the proposal for a solution. The
RTP timestamp is equal to display time. So it you do pause, wait five
seconds and then press play the timestamp will be 5 seconds later for
the first packet when resuming.

This behavior works fine when the play contains a range, for queued play
following after each other, but not for resuming play. The reason is the
delay between a user on the client side pressing pause and until the
client stops receiving data packets. If the client then does resume
play, i.e. play without range, the server will continue after the last
packet sent. In this case the client needs to show first the packet
arriving directly after pressing pause (which according to the used
model is past time), and then correctly synchronize the new packet which
has a significant offset in timestamp corresponding to the period of
pause the server has seen. The solution to this is to not use resume
play and instead say play from the point where user pressed pause.

On the other side I don&#039;t believe any other model will not have worse
problems.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:45

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:43

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:41

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:40

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:37

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 15:12

Message:
Logged In: YES 
user_id=302620

Aravind has agreed to write up the example and necessary
text. Transfering bug to him.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 10:48

Message:
Logged In: YES 
user_id=302620

A Clear example of RTP Timestamp and synchronization will be
added in appendix B - RTP transport.

The discussion in MMUSIC has made it clear that a continous
time model is needed to make RTCP work correctly. It has to
be accpeted that for on-demand media this will result in
slightly more code for the clients and servers. However all
pices to makes things work is already present. 

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-23 16:05

Message:
Logged In: YES 
user_id=302620

This has been further discussed in the MMUSIC mailing list. 

A important point is that RTP and RTCP to function as
intended in this environment must have a timestamp space
that increase continously with real time. 

A client handling the RTSP range header and RTP-Info can
always synchronize the data correctly independtly of which
case the server sent out. 

Using a continous RTP Timestamp space allows the same
timestamp model for both on-demand and live media.

The proposed resolution is to clrafiy in the RTP appendix of
the specification that a RTP timestamp space continous in
regards to real-time SHALL be used. Further write a warning
that this has been missunderstood and clients is RECOMMENDED
to handle both cases. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:55:34 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT.

Bugs item #742348, was opened at 2003-05-23 16:21
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194

Category: General
>Group: Resolved - Need write up
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: Usage of implicit REDIRECT. 

Initial Comment:
The RTSP specification provides two explict methods of
redirection, the REDIRECT method and the 3XX response
codes. 

Further it is possible to do implict redirection in the
media description. This is done by affecting the RTSP
control URLs present for the different media. By giving
the client a description that either contains absolute
URLs or URLs that resolve to another host the
redirection takes place.

The redirection changes the URL in the redirection.
This can be done in three ways:
Changing the absolute URLs in the description. 
Using Content-Location header to set the Base URL to
point to another host.
Using Content-Base header to set the base URL to point
to another host. 

The two last may require changes of any relative URLs
in the description also.

Of these methods the usage of Content-Location may be
the one that have the most correct semantics. This of
course requires that the host being redirected to has
the complet session including description. As the
Content-Location header tells the client that the given
location is an possible resolution for this exact
description. 

The Client Implementation requirement to get this
functionality is that it after resolving the URLs check
them against the current server address. If different
it needs to get a new connection to the new server.
This seems fairly simple. 

Also see mail to MMUSIC mailing list from Philippe Gentric

The question is if this behavior shall be considered a
valid one or not. The outcome of the discussion should
be written in as a clarification to the text of the
RTSP specification. 

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:55

Message:
Logged In: YES 
user_id=302620

There is need for text proposal on this bug. 

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 17:54

Message:
Logged In: YES 
user_id=302620

From the 57th IETF meeting 16th of July 2003:

Issue: How to handle implicit redirection through session
description protocol.

Discussion: Seems to be desired functionality to have an
optimized way for saving a RTT when you perform load
balance. There where also the issue that if a server would
give a content-base or other base URL. A client should not
reconnect unless explicitly redirected. This may result in
different behaviour depending if the client are behind a
proxy or not. First it was proposed that a new 200 code can
be used to indicate that you get the SDP but are redirected.
However this seem to have backwards problem. To optimize
this in a efficient way you can use a new 350 code to
indicate redirection but the client does receive a SDP. This
way a old client will do the redirect as it interprets is as
3xx code, while a new client can avoid wasting a extra
describe. There are also a need to clarify that a server
should not change the host address of the control in regards
to the describe URI.

Resolution: Create a 350 code for this plus clarify the
SHOULD NOT change the host address. Seems reasonable to put
into the core specification. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194

End of Rtspspec-bugs Digest

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic