Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #113 - 10 msgs

From: [email-masked]
Date: Tue, 03 Feb 2004 05:06:05 -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-795314 ] Caching of OPTIONS request (SourceForge.net)
   2. [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces. (SourceForge.net)
   3. [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter (SourceForge.net)
   4. [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method (SourceForge.net)
   5. [ rtspspec-Bugs-500906 ] Client liveness criteria vague (SourceForge.net)
   6. [ rtspspec-Bugs-501599 ] Collect BNF at end, convert to 2234 (SourceForge.net)
   7. [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter (SourceForge.net)
   8. [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4 (SourceForge.net)
   9. [ rtspspec-Bugs-850256 ] When must RTP-Info be included? (SourceForge.net)
  10. [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 03:50:51 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-795314 ] Caching of OPTIONS request

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Caching of OPTIONS request

Initial Comment:
Geetha Srikantan thought of the question if OPTIONS
request are cachable, and if, how to determine the
expiration of such cached command. 

My answer
Maybe, it is actually a problem of what OPTIONS is used
for. 
As long it is only used for determing server capability
it is not a problem. However if it is used to maintain
session liveness, i.e. session ID present, no. Also
depending on the URI and the possibilities to cache ma
y vary. Needs further consideration.

This is a tough problem. I don't think there are. The
Expires header is an entity header, but the text in RFC
2616 seems to mean the whole request. So this is also
something that needs consideration. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 12:50

Message:
Logged In: YES 
user_id=302620

If one looks at the caching chapter of the RTSP
specification, it is rather clear that only DESCRIBE
responses can be cached. 

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 03:54:09 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces.

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

Category: Editorial
>Group: Resolved - Added to text
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: CSEQ is direction dependent in numberspaces.

Initial Comment:
IETF 58 off-line discussion resulted in one point to 
ensure is edited in:It needs to be clarified that CSeq 
sequence number spaces are direction dependent. The 
C->S Requests uses a different space then S->C 
Requests.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 12:54

Message:
Logged In: YES 
user_id=302620

A clarification has been made and is checked in. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 04:11:42 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter

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

Category: Editorial
>Group: Resolved - Added to text
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gather all ABNF in syntax chapter

Initial Comment:
- All ABNF needs to be gathered in the syntax chapter.
- Ensure that it is in 2234 form
- When necessary put references into text when the ABNF
gets moved. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 13:11

Message:
Logged In: YES 
user_id=302620

The changes are performed and checked in. 

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 04:13:52 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method

Bugs item #492546, was opened at 2001-12-13 18:44
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=492546&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Magnus Westerlund (magwes)
Summary: Shouldn't close on unsupported method

Initial Comment:
When a server (or client) receives an unsupported method, and the request is well-formed 
(complies with BNF for Request, and contains CSeq), we should mandate that a server MUST not 
close down an existing playback session.

This is an extensibility issue.  If, during playback, the client requests a certain method that the 
server doesn't support, and we allow session shutdown, then we've painted ourselves in a corner 
where we can't comfortably extend the protocol.

The client may determine that support for a method is required, at which point, the client may 
disconnect the session.  However, the client should be given the option to account for the error 
and continue playback.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 13:13

Message:
Logged In: YES 
user_id=302620

No comments received on text. Closing issue. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-25 21:05

Message:
Logged In: YES 
user_id=302620

Some text on this has been edited in to the specification in
the chapter regarding TCP connections. 

There is also a clarification regarding the use of the
"Connetion" header and the option "close".

Please review these changes.

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 04:20:41 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500906 ] Client liveness criteria vague

Bugs item #500906, was opened at 2002-01-08 18:14
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500906&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Sean Sheedy (seansh)
Assigned to: Magnus Westerlund (magwes)
Summary: Client liveness criteria vague

Initial Comment:
The current standard is vague about what constitutes a
client "liveness" indication sufficient to prevent the
media server from freeing a client's session.  It also
does not address under what circumstances a media
server may close an inactive persistent control
connection from a client.

These areas should be more explicitly specified so that
clients can reliably maintain their sessions with
minimum liveness detection overhead.

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

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

Message:
Logged In: YES 
user_id=302620

As no comments on this bug has been raised in a year it will
be closed. 

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

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

Message:
Logged In: YES 
user_id=302620

The criteria for closing connections has been clarified in
the chapter connections.  

The liveness signaling has also been clarified in the
session header chapter. 

Changes are checked in.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-01-14 11:13

Message:
Logged In: YES 
user_id=302620

Primary source of livness information is RTCP, which should be clarified. 
Secondly the new method PING could be used, see bug report #477400. 

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 04:22:35 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-501599 ] Collect BNF at end, convert to 2234

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

Category: General
Group: Fix for DS - Large task
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Henning Schulzrinne (hgschulz)
Assigned to: Magnus Westerlund (magwes)
Summary: Collect BNF at end, convert to 2234

Initial Comment:
For the SIP spec revision, we collected all BNF in one
place. This makes the spec somewhat shorter and easier
to read. Also, we need to convert BNF to 2234 format to 
pass IESG.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 13:22

Message:
Logged In: YES 
user_id=302620

This bug has been taken care of and the editorial changes
are tracked by bug 850267. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-25 13:38

Message:
Logged In: YES 
user_id=302620

A question is if the syntax chapter is the only place where
there should be syntax. This mean deleting it everywhere
else. Is this a good thing?

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

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

Message:
Logged In: YES 
user_id=302620

This is being done, closing bug 477429 and use this instead
until work is completed. 

The BNF is mostly converted. Comments please if non changed
syntax is found. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 04:23:07 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-850267 ] Gather all ABNF in syntax chapter

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

Category: Editorial
Group: Resolved - Added to text
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gather all ABNF in syntax chapter

Initial Comment:
- All ABNF needs to be gathered in the syntax chapter.
- Ensure that it is in 2234 form
- When necessary put references into text when the ABNF
gets moved. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 13:23

Message:
Logged In: YES 
user_id=302620

However the ABNF verifier needs to be run over the syntax. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 13:11

Message:
Logged In: YES 
user_id=302620

The changes are performed and checked in. 

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 04:58:20 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4

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

Category: Editorial
>Group: Resolved - Added to text
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in rfc2326bis-04 example 15.4

Initial Comment:
The last two messages in this example is:

   C->M: PLAY rtsp://live.example.com/concert/audio 
RTSP/1.0
         CSeq: 3
         Session: 0456804596

   M->C: RTSP/1.0 200 OK
         CSeq: 3
         Session: 0456804596
         Range:npt=now-

But I wonder how the receiver could perform the sync
between RTP timestamp and NPT, without a RTP-Info 
header in the PLAY response? I wouldn't like to see 
such RTSP conversation in our applicatoin.

A real implementation would likely to conduct the PLAY 
request/response including RTP-Info, for example: 

C->M: PLAY rtsp://live.example.com/concert/audio 
RTSP/1.0
         CSeq: 3
         Session: 0456804596
         Range: now-

   M->C: RTSP/1.0 200 OK
         CSeq: 3
         Session: 0456804596
         Range:npt=1000-
         RTP-Info: 
url=rtsp://live.example.com/concert/audio; seq=1473; 
rtptime=80000

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 13:58

Message:
Logged In: YES 
user_id=302620

I agree, however as there are only a single media, there is
nothing except NPT to synchronize against. As it is a live
session no time scale is given, by the now- answer. Thus I
think it in this example could actually be okay to exclude
the RTP-Info. 

However I have added the proposed text to the example.

If anyone has comments on this resolution please respond. 

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

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

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:00:21 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included?

Bugs item #850256, was opened at 2003-11-27 15:06
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&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: Nobody/Anonymous (nobody)
Summary: When must RTP-Info be included?

Initial Comment:
At the RTSP discussion at IETF 58 there where some
discussion in regards if RTP-Info really can be
presented in all Play Responses when the media streams
are RTP. The argument was Live media. 

The current specification (05) requires this. 

Are there really a reason for changing this?

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 14:00

Message:
Logged In: YES 
user_id=302620

The text has been changed to have RTP-Info as SHOULD be
included for RTP transported streams. Further motivation why
it is important has been given.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-11-28 08:59

Message:
Logged In: YES 
user_id=302620

The argument why a server could not present a RTP-Info
header in a PLAY response was due to that the distribution
server might not be aware of inter media synchronization of
the media streams it forwards. If that is the case there
exist the possibility to perform intermedia synchronization
with RTCP. 

In regards to Jae-Whan's comments: 

Regarding "1) The beginning of the live service" the first
comment is that there is no way of knowing that a session is
live. This we have addressed through the definition that any
open range in the SDP a=range attribute shall be considered
Live. 

"When a player gets the first rtp packet, it should store the 
rtptimestamp and has to subtract it from the remains." I
don't see how this relates to the intermedia synchronization
problem. A client can't rely on that all media streams first
packet will represent the same point in time and would
therefore result in bad synchronization between the media. 

In regards to 2: In a live session if you are continuing
after a couple of minutes there is no reason for removing
the timestamp gap. In a live media session the media will
have advanced during the paused time, therefore there does
not seem to be any reason to synchronize the media prior to
the pause to the one after the pause. Therefore the player
should in a live case flush the buffers when it resumes play
after a pause. Thus the lack of RTP-Info in this case would
have no effect. As the RTP timestamp continues correctly
during the paused time the intermedia synchronization
established prior to pausing will still be valid

I think the main problem of not always requiring RTP-Info is
the intermedia synchronization. RTCP can be used, however
the time until RTCP has been received for all media may be
on order of seconds, thus possibly resulting in that
playback has to be commeneced without synchronization. 

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

Comment By: Jaehwan, Kim (kjh1905m)
Date: 2003-11-28 07:18

Message:
Logged In: YES 
user_id=365760

IMHO, it is enough that we focus on 2 cases: 1) the 
beginning of the live service 2) live PAUSE/Resume because 
we don't believe live streaming session supports random 
access.

1) The beginning of the live service
At this moment, there is no way for a player to see if the 
session is live or not. But if there is no RTP-Info, the player 
can start its session by the following way:
When a player gets the first rtp packet, it should store the 
rtptimestamp and has to subtract it from the remains.

2) Live PAUSE/Resume
Currently, we use monotonic rtptimestamp increament for 
random access. However, if a player requests PAUSE and 
Resume after a couple of minute, then rtptimestamp has to 
have the time gap. Without RTP-Info, how can the player 
remove the rtptimestamp gap? How can it continue the live 
session without any timegap? 

If RTSP Range header field also doesn't exist, a player can do 
that. From the begginning, the player should remember the 
first rtptimestamp and after the resume, we can just subtract 
the first from the lastest rtptimestamp. And then, we can 
calculate the real presentation time from it, comparing with 
the real PAUSE time gap.

But this behavior of a player is different from general on-
demand service having RTP-Info. Therefore, we need to chek 
our if the player can do that the both cases, RTP-Info and no 
for live. It means a general VOD player might not continue to 
work after live PAUSE.

Feel free to give me an advise regarding this matter if I am 
wrong.

Thank you!
Jae-Hwan

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

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

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:05:36 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts

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

Category: None
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Magnus Westerlund (magwes)
Summary: Allow Rtp-Info header in more contexts

Initial Comment:
Currently, the RFC states that the Rtp-Info header is 
required in the PLAY response.  But it is not clear 
whether or not the Rtp-Info is allowed in other 
contexts.

I think of three other cases where it might be useful:

1. In the RECORD request. If a client is sending data 
to the server, the client SHOULD send the Rtp-Info 
header to the server, so that the server can know the 
initial RTP sequence number and RTP timestamp.

2. In the SETUP response. If the server is already 
playing, and the client sends a SETUP command to 
select a stream that previously was not selected, I 
believe the server will start sending data for this 
stream immediately.  

(Check the RFC, I am not sure it clearly states 
whether the newly selected stream will be streamed 
immediately or not.)

In this case, it would be useful for the client to be 
able to recieve an Rtp-Info header as a part of the 
SETUP response.  But this has to be seen as an 
optional optimization -- the client can always send a 
second PLAY command, and the Rtp-Info header will then 
be available in the PLAY response.

3. In the ANNOUNCE command.  If the server is already 
playing, and something related to the SDP description 
suddenly changes, the server can send a new SDP to the 
client using the ANNOUNCE command.  It might be 
necessary to include a new Rtp-Info header in this 
case.

A similar situation happens when the server is 
reconding something, and the client sends an ANNOUNCE 
command to the server.

Again, this is probably just an optional optimization, 
because the client can always send a new PLAY command 
and obtain the Rtp-Info header again.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 14:05

Message:
Logged In: YES 
user_id=302620

The usage of RTP-Info is now furhter clarified in relation
to PLAY and SETUP. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-25 13:44

Message:
Logged In: YES 
user_id=302620

As Record and Announce has been removed from the
specification these questions are not longer relevant to the
core specification. However any future definition needs to
consider them.

RTP-Info for SETUP is currently used in two cases:
1. When in play state adding a stream to the session
2. When in play state changing the transport parameters

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

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

Message:
Logged In: YES 
user_id=302620

I agree that RTP-Info i SETUP while be necessary for the
optional functionality of SETUP and TEARDOWN while playing. 

For RECORD this should be part of the work in defining how
it should really work. 

For ANNOUNCE we need to further discuss this. 

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

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

End of Rtspspec-bugs Digest

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