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

From: [email-masked]
Date: Fri, 13 Feb 2004 08:06:12 -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-795295 ] TEARDOWN using * and the Ready-nm state (SourceForge.net)
   2. [ rtspspec-Bugs-810666 ] Removal of SETUP in play state (SourceForge.net)
   3. [ rtspspec-Feature Requests-810678 ] How to indicate end of media stream (SourceForge.net)
   4. [ rtspspec-Bugs-840304 ] CSEQ is direction dependent in numberspaces. (SourceForge.net)
   5. [ rtspspec-Bugs-850256 ] When must RTP-Info be included? (SourceForge.net)
   6. [ rtspspec-Bugs-850265 ] Removed features are unspecified, not forbidden (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-494533 ] The use of the word require in the RFC. (SourceForge.net)
  10. [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 09 Feb 2004 08:50:52 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state

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

Category: None
Group: Resolved - Added to text
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: TEARDOWN using * and the Ready-nm state

Initial Comment:
The 20 february 2002 we discussed
http://rtsp.org/bug506412, for conclusion of that
discussion see minutes:
http://rtsp.org/2002/telecon/minutes20Feb.html

However to me it seems that the need for state Ready-nm
is not that great. Also the use of "*" as a URL will
not work when proxies are present, unless requirements
are put on them to maintain certain state in regards to
sessions. The use of the presentation URL also is
problematic as some sessions may not have a defined
session URL, like for example for sessions intended to
be used in non-aggregted mode. 

Therefore my suggestion is that the Ready-nm state is
removed and that teardown using "*" is dissallowed.
Comments please. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-09 17:50

Message:
Logged In: YES 
user_id=302620

No comments, the change is edited in. Closing.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-22 18:30

Message:
Logged In: YES 
user_id=302620

The removal has now been performed and checked in in the
following commit:

/cvsroot/rtspspec/changes.tex,v  <--  changes.tex
new revision: 1.18; previous revision: 1.17
/cvsroot/rtspspec/iana.tex,v  <--  iana.tex
new revision: 1.14; previous revision: 1.13
/cvsroot/rtspspec/machine.tex,v  <--  machine.tex
new revision: 1.13; previous revision: 1.12
/cvsroot/rtspspec/methods.tex,v  <--  methods.tex
new revision: 1.33; previous revision: 1.32

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-22 18:04

Message:
Logged In: YES 
user_id=302620

As no comments has been raised, this will be edited out. 

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 09 Feb 2004 08:58:09 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-810666 ] Removal of SETUP in play state

Bugs item #810666, was opened at 2003-09-22 17:30
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&group_id=23194

Category: None
Group: Resolved - Added to text
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Removal of SETUP in play state

Initial Comment:
On MMUSIC there is a proposal to remove the
functionality for setup in play state to add a new
individual media stream. This not about changing
transport parameters!

First the need for this is not clear. The only use
cases seems to be to do switching between different
media streams variants. As this doesn't look as the
best method and secondly that switching at all is an
add on functionality this seem to not belong in core spec.

Secondly removing this will simplify the specification
writing.

Third, if the method is need in the future it will be
possible to write an extension specification. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-09 17:58

Message:
Logged In: YES 
user_id=302620

No comments received. Closing bug. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-22 18:30

Message:
Logged In: YES 
user_id=302620

The removal has now been performed and checked in in the
following commit:

/cvsroot/rtspspec/changes.tex,v  <--  changes.tex
new revision: 1.18; previous revision: 1.17
/cvsroot/rtspspec/iana.tex,v  <--  iana.tex
new revision: 1.14; previous revision: 1.13
/cvsroot/rtspspec/machine.tex,v  <--  machine.tex
new revision: 1.13; previous revision: 1.12
/cvsroot/rtspspec/methods.tex,v  <--  methods.tex
new revision: 1.33; previous revision: 1.32

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-22 18:03

Message:
Logged In: YES 
user_id=302620

No comment against this removal has been raised. Therefore
this will be editied.

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 09 Feb 2004 08:59:38 -0800
Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-810678 ] How to indicate end of media stream

Feature Requests item #810678, was opened at 2003-09-22 17:48
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377747&aid=810678&group_id=23194

Category: None
>Group: None
Status: Open
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: How to indicate end of media stream

Initial Comment:
discussed at the 57th IETF meeting 16th of July 2003.

Issue:  Possible methods for signalling end of
stream/media (not session) in RTP.

Discussion: Need to signal that a stream/media has
ended exist mostly in unbound sessions. Proposal
brought up to indicate this is RTCP BYE when the sender
stops sending and has waited some time it can remove
the SSRC of that source and send the BYE to indicate
this. Another proposal was to send this information in
RTSP methods. One could use sever to client TEARDOWN to
indicate this session really are over, nothing more can
be done. PAUSE can be sent when the media has been
served but the client may rewind do other operations.
The TEARDOWN idea was not liked as certain applications
require session data to be sent from client to server
using SET_PARAMETER. A new method should be evaluated.
There might also exist significant synchronization
problems in this.

Resolution: Propose a RTSP extension with a new method.
Thomas Zeng to write strawman proposal for evaluation
to mailing list.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-09 17:59

Message:
Logged In: YES 
user_id=302620

Moving this to feature request as this is what it has become. 

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

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

Message:
Logged In: YES 
user_id=302620

A strawman proposal is avail in this MMUSIC messge:
https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01978.html

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 09 Feb 2004 09:02:25 -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 (Settings changed) 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: Magnus Westerlund (magwes)
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: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 09 Feb 2004 09:04:05 -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 (Settings changed) 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: Magnus Westerlund (magwes)
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: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 10 Feb 2004 07:54:49 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-850265 ] Removed features are unspecified, not forbidden

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

Category: Editorial
>Group: Resolved - Need write up
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Removed features are unspecified, not forbidden

Initial Comment:
In cases where feature has existed or could be defined,
but the core specification does not define them, this
should be clearly indicated in the text. 

A convention definition of unspecified can be added.
Then used in the interesting places in the text. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-10 16:54

Message:
Logged In: YES 
user_id=302620

At least a few of the cases has been corrected. However a
read through is needed to find any remaining places. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 10 Feb 2004 07:52:00 -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 (Settings changed) 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: Magnus Westerlund (magwes)
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, 10 Feb 2004 07:50:54 -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 (Settings changed) 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: Magnus Westerlund (magwes)
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: Fri, 13 Feb 2004 07:32:46 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494533 ] The use of the word require in the RFC.

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

Category: Editorial
Group: Fix for DS - Large task
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: The use of the word require in the RFC.

Initial Comment:
The RFC contains different usage of the word require. Sometimes it means that a implementation 
must interpret and understand a header or method. Othertimes the a certain header must be sent 
togheter with a method. 

One fix is to create a better table for the headers that clarifies the two different cases. Another is 
looking over the methods and use cases and clearly write when they must be included. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 10:42

Message:
Logged In: YES 
user_id=302620

There are also a great need to look at the usage of
normative language according to RFC 2119. 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-19 02:29

Message:
Logged In: YES 
user_id=3796

We need to rework that table to clarify the difference between the two.

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

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

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 13 Feb 2004 08:03:21 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP

Bugs item #853175, was opened at 2003-12-03 11:00
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&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: Magnus Westerlund (magwes)
Summary: Dest_addr needs indicator for using RTSP IP

Initial Comment:
The transport header parameters dest_addr and src_addr
that has been introduced to cope with non-adjacent
ports and same IP address for media transport protocols
like RTP that requries multiple streams to work. 

There seem to be motivated to ensure that previously
allowed behavoir to exclude giving a destination
address and instead have the server to deliver the
media to the source ip of the RTSP carrying TCP
connection. To enable this with the new paramters some
changes are required, the 05 version requries you to
put in some address. So either we change this, or
define a indicator for this behavior. 

This will allow that clients in private address spaces
using some addesstranslation techniuqes to use them
without being  requried to learn their external
address. Examples of such translation are realm
specific IP and NAT's without port translation. Please
do also note that for these translations the usage of
public STUN server works. 

However it should be noted the lack of destination
address is not without its consideration. IF an RTSP
proxy is used, it will be requried to add the
destination address, before forwariding any SETUP
request. There are also need to furhter review if any
furhter security considerations are needed.

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

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

Message:
Logged In: YES 
user_id=302620

I don't think we need to have a indication in dest_addr. The 
lack of dest_addr or destination will be a indication that the 
server should perform this. I have added text to indicate this.

However I wonder if we also should clarify that a server 
should always respond with a destination indication to show 
where it interprets the media should be delivered. This would 
allow a client to make some error handling. 

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

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

End of Rtspspec-bugs Digest

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