[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Rtspspec-bugs digest, Vol 1 #72 - 4 msgs

To: mmusic@ietf.org
Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #72 - 4 msgs
From: rtspspec-bugs-request@lists.sourceforge.net
Date: Fri, 31 Jan 2003 12:17:29 -0800
>return-path: <rtspspec-bugs-admin@lists.sourceforge.net>
List-help: <mailto:mmusic-request@ietf.org?subject=help>
List-id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-post: <mailto:mmusic@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>,<mailto:mmusic-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>,<mailto:mmusic-request@ietf.org?subject=unsubscribe>
Old-to: rtspspec-bugs@lists.sourceforge.net
Reply-to: mmusic@ietf.org
Sender: mmusic-admin@ietf.org


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-678107 ] Change of Proxy-Require header (SourceForge.net)
   2. [ rtspspec-Bugs-619421 ] Range header in PLAY response (SourceForge.net)
   3. [ rtspspec-Bugs-507332 ] RTSPS/TLS support (SourceForge.net)
   4. [ rtspspec-Bugs-507332 ] RTSPS/TLS support (SourceForge.net)

--__--__--

Message: 1
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Fri, 31 Jan 2003 04:43:11 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-678107 ] Change of Proxy-Require header

Bugs item #678107, was opened at 2003-01-31 13:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Change of Proxy-Require header

Initial Comment:
Current text: Says that proxy-require applies to both
proxy and server.

New Proposal: The feature tags in a "Proxy-require"
header will only apply to the proxies, and not the
server. For feature that the server must support the
"Require" header shall be used. If required feature
support from both proxy and server both "Proxy-Require"
and "Require" must be used.

Pro:
- Align with SIP's usage of header
- Makes it possible to create features tags for proxy
only functionality. Otherwise all servers will be
mandated to also know about proxy only features.

Cons: 
- Backwards compatibility. (Actually this does not
matter much as: A old server implementing the old way
would also not work with any new feature tags for
proxies. So it will block operation independent of
changed semantics or not.)


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

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


--__--__--

Message: 2
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Fri, 31 Jan 2003 04:49:47 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response

Bugs item #619421, was opened at 2002-10-07 01: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: Magnus Westerlund (magwes)
Date: 2003-01-31 13:49

Message:
Logged In: YES 
user_id=302620

As discussed in the teleconf the 22 jan 2003:
We should look at strengting the requirement on having the
Range header also for live streams when using RTP. A
solution based on Range:npt=now- with optional time or using
Range:clock=x can work. But careful wording is required.

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

Comment By: Rob Lanphier (robla)
Date: 2002-11-20 21: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 21: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 19: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: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Fri, 31 Jan 2003 05:00:00 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507332 ] RTSPS/TLS support

Bugs item #507332, was opened at 2002-01-23 04:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194

Category: None
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTSPS/TLS support

Initial Comment:
Currently, the version of RTSP that's checked into the
repository has TLS support and rtsps:.   This is
probably just a relic of the fact that we pulled this
at the very last minute when going to Proposed
Standard, and it never got checked in.

It's an interesting feature, but one that probably
warrents a separate draft on it's own track.

robla:  I vote for taking this out.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-01-31 14:00

Message:
Logged In: YES 
user_id=302620

The current decision from telecon in december 2002 is that
we should have it as a seperate extension document. Anyone
interested may start writing on such a document. 

Any more than informative text shall be removed from base spec. 

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

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

Message:
Logged In: YES 
user_id=302620

If it is going to be left in the spec it needs further work. 

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

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


--__--__--

Message: 4
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Fri, 31 Jan 2003 05:00:54 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507332 ] RTSPS/TLS support

Bugs item #507332, was opened at 2002-01-23 04:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194

Category: None
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTSPS/TLS support

Initial Comment:
Currently, the version of RTSP that's checked into the
repository has TLS support and rtsps:.   This is
probably just a relic of the fact that we pulled this
at the very last minute when going to Proposed
Standard, and it never got checked in.

It's an interesting feature, but one that probably
warrents a separate draft on it's own track.

robla:  I vote for taking this out.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-01-31 14:00

Message:
Logged In: YES 
user_id=302620

The current decision from telecon in december 2002 is that
we should have it as a seperate extension document. Anyone
interested may start writing on such a document. 

Any more than informative text shall be removed from base spec. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-01-31 14:00

Message:
Logged In: YES 
user_id=302620

The current decision from telecon in december 2002 is that
we should have it as a seperate extension document. Anyone
interested may start writing on such a document. 

Any more than informative text shall be removed from base spec. 

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

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

Message:
Logged In: YES 
user_id=302620

If it is going to be left in the spec it needs further work. 

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

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




End of Rtspspec-bugs Digest

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
Prev by Date: [MMUSIC] RTSP teleconference 5 february 18.00 CET
Next by Date: [MMUSIC] RTSP and NATs
Previous by thread: [MMUSIC] RTSP teleconference 5 february 18.00 CET
Next by thread: [MMUSIC] RTSP and NATs
Index(es):
- Date
- Thread