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

From: [email-masked]
Date: Wed, 20 Nov 2002 12:15:42 -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-640897 ] Transport header example mode case ([email-masked])
   2. [ rtspspec-Bugs-619421 ] Range header in PLAY response ([email-masked])
   3. [ rtspspec-Bugs-619421 ] Range header in PLAY response ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Tue, 19 Nov 2002 12:17:20 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640897 ] Transport header example mode case

Bugs item #640897, was opened at 2002-11-19 20:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640897&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ashley Wee (hashuser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport header example mode case

Initial Comment:
There is a case issue with the mode. The examples 
in the RFC shows both mode=play and 
mode="PLAY" in examples.

In RFC 2326, it state Methods are case sensitive. 
"10 Method Definitions ... The method is case-
sensitive"

The bug [ 477415 ] Transport header example only 
addresses the ". The case issue in the examples of 
the RFC has to be fixed as servers and clients are 
expecting different cases due to the ambiguity.

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 20 Nov 2002 12:02:06 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response

Bugs item #619421, was opened at 2002-10-06 16:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194

Category: General
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: Range header in PLAY response

Initial Comment:
Current RTSP RFC makes Range header in PLAY response
from server optional.

If the PLAY request includes a Range header indicating
a possible seek, then it is probably necessary to
include Range in the response since it is possible that
the requested seek position could not be honored and
playback will resume at the nearest seekable point
which is not known to the client.

Note:  To fix this issue in 3GPP, Range in a PLAY
response was made mandatory for all PLAY responses.

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

>Comment By: Rob Lanphier (robla)
Date: 2002-11-20 12:02

Message:
Logged In: YES 
user_id=3796

Per a conversation with Magnus and I, we think we should
soften the language somewhat (strong SHOULD instead of MUST).  

One case to consider is a live stream, which one would think
would obviate the need for this header.  However, the
rationale for having it in live is when dealing with RTP. 
Since RTP audio and video streams can have a completely
different timestamp base, there needs to be an out-of-band
technique for synchronization.  The two techniques used in
RTSP are:

1.  RTSP "Range:"<->RTSP "RTP-Info:"<->RTP timestamp synch
2.  RTCP timestamp<->NTP mapping

Eventually, a well-behaved RTSP client will synch the
streams based on
the RTCP timestamps (when received).  However, there's a
period before the first RTCP packet arrives that there's no
sync, unless a Range header is known.

So, that also points to what the Range header should look
like.  The
Range header should include an open-ended wallclock range,
like so:
   Range: clock=20021120T133205Z- 
   RTP-Info:url=rtsp://example.com/fizzle/audiotrack;
            seq=5712;rtptime=934207921,
            url=rtsp://example.com/fizzle/videotrack;
            seq=57654;rtptime=2792482193

The spec should make this clear.

An interesting consideration to make here is a restriction
on Range response. The current rtsp spec states that "The
unit of the range in the reply is the same as that in the
request".  Perhaps an alternate syntax, if the PLAY request
has a Range: header in npt is as follows:

   Range: npt=now;time=20021120T133205Z

The "time" allows for mapping to occur.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:36

Message:
Logged In: YES 
user_id=302620

Yes, the range header is need for RTP synchonization. The
draft specification has been updated to require this when
using RTP to make synchonization possible. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 20 Nov 2002 12:06:18 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response

Bugs item #619421, was opened at 2002-10-06 16:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: Range header in PLAY response

Initial Comment:
Current RTSP RFC makes Range header in PLAY response
from server optional.

If the PLAY request includes a Range header indicating
a possible seek, then it is probably necessary to
include Range in the response since it is possible that
the requested seek position could not be honored and
playback will resume at the nearest seekable point
which is not known to the client.

Note:  To fix this issue in 3GPP, Range in a PLAY
response was made mandatory for all PLAY responses.

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

>Comment By: Rob Lanphier (robla)
Date: 2002-11-20 12:06

Message:
Logged In: YES 
user_id=3796

One other thing...put Maureen Chesire in the acknowlegements
for raising this....

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

Comment By: Rob Lanphier (robla)
Date: 2002-11-20 12:02

Message:
Logged In: YES 
user_id=3796

Per a conversation with Magnus and I, we think we should
soften the language somewhat (strong SHOULD instead of MUST).  

One case to consider is a live stream, which one would think
would obviate the need for this header.  However, the
rationale for having it in live is when dealing with RTP. 
Since RTP audio and video streams can have a completely
different timestamp base, there needs to be an out-of-band
technique for synchronization.  The two techniques used in
RTSP are:

1.  RTSP "Range:"<->RTSP "RTP-Info:"<->RTP timestamp synch
2.  RTCP timestamp<->NTP mapping

Eventually, a well-behaved RTSP client will synch the
streams based on
the RTCP timestamps (when received).  However, there's a
period before the first RTCP packet arrives that there's no
sync, unless a Range header is known.

So, that also points to what the Range header should look
like.  The
Range header should include an open-ended wallclock range,
like so:
   Range: clock=20021120T133205Z- 
   RTP-Info:url=rtsp://example.com/fizzle/audiotrack;
            seq=5712;rtptime=934207921,
            url=rtsp://example.com/fizzle/videotrack;
            seq=57654;rtptime=2792482193

The spec should make this clear.

An interesting consideration to make here is a restriction
on Range response. The current rtsp spec states that "The
unit of the range in the reply is the same as that in the
request".  Perhaps an alternate syntax, if the PLAY request
has a Range: header in npt is as follows:

   Range: npt=now;time=20021120T133205Z

The "time" allows for mapping to occur.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:36

Message:
Logged In: YES 
user_id=302620

Yes, the range header is need for RTP synchonization. The
draft specification has been updated to require this when
using RTP to make synchonization possible. 

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

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

End of Rtspspec-bugs Digest

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