Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #100 - 8 msgs

From: [email-masked]
Date: Wed, 01 Oct 2003 20:28:33 -0700

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-533691 ] Clarify Range Where t0 <= t1 (SourceForge.net)
   2. [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative (SourceForge.net)
   3. [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification (SourceForge.net)
   4. [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification (SourceForge.net)
   5. [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 (SourceForge.net)
   6. [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative (SourceForge.net)
   7. [ rtspspec-Bugs-513737 ] Unclarities when doing resetup (SourceForge.net)
   8. [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 08:16:50 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1

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

Category: None
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
>Assigned to: Aravind Narasimhan (arvy_n)
Summary: Clarify Range Where t0 <= t1

Initial Comment:
If the server receives a PLAY range from t0-t1, where

t0 < t1, should it reject the PLAY, or should the 

server play backwards as if the timescale is -1?

If t0 = t1, should the server send any media data 

after responding 200 OK?  

We've seen different servers behave differently in 

this scenario.

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

>Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 11:16

Message:
Logged In: YES 
user_id=437699

The following text has been added to the spec with regards

to this bug:

By default, range intervals increase, where the second point

is larger than the first point.

   Example:

       Range: npt=10-15

However, range intervals can also decrease if the Scale

header (see section  13.34) indicates a negative scale

value. For example, this would be the case when a playback

in reverse is desired.

   Example:

       Scale: -1

       Range: npt=15-10

Decreasing ranges are still half open intervals as described

above.  Thus, For range A-B, A is closed and B is open. In

the above example, 15 is closed and 10 is open. An exception

to this rule is the case when B=0 in a decreasing range. In

this case, the range is closed on both ends, as otherwise

there would be no way to reach 0 on a reverse playback.

   Example:

       Scale: -1

       Range: npt=15-0

   In this range both 15 and 0 are closed.

A decreasing range interval without a corresponding negative

Scale header is not valid.

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

Comment By: Thomas M Zeng (zengtm)
Date: 2003-03-05 12:53

Message:
Logged In: YES 
user_id=20397

If scale positive, t1 must >= t0.

Otherwise, t1 must <= t0

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

Comment By: Thomas M Zeng (zengtm)
Date: 2002-03-22 12:41

Message:
Logged In: YES 
user_id=20397

I just came across 513880, which is closely related.

That is to say, if timescale is positive, should the play 

range to be required to have t1 > t0?

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 08:22:04 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative

Bugs item #513880, was opened at 2002-02-06 13:48
Message generated for change (Comment added) made by arvy_n
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194

Category: None
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
>Assigned to: Aravind Narasimhan (arvy_n)
Summary: How to use Range when Scale is negative

Initial Comment:
I think the spec could use an example that shows how 

to use the Range header when rewinding (Scale header 

is set to a negative value.)  Or, instead of an 

example, some explanatory text could be added.

The issue that I find a little bit confusing is how 

the server should specify the end of the range. The 

end of the range would be numerically smaller than the 

start of the range.

I think the following illustrates a valid exchange:

C->S:

PLAY rtsp://server/a RTSP/1.0

Scale: -1

Range: npt=45-

S->C:

RTSP/1.0 200 OK

Scale: -1

Range: npt=45-0

This is the type of example that I think would be nice 

to have in the spec.

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

>Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 11:22

Message:
Logged In: YES 
user_id=437699

The following text has been added to the spec with regards

to this bug:

When indicating a negative scale for a reverse playback, the

Range header must indicate a decreasing range as described

in section 13.29.

Example of playing in reverse at 3.5 times normal rate:

    Scale: -3.5

    Range: npt=15-10

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

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

Message:
Logged In: YES 
user_id=302620

This needs to be discussed.

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 08:36:09 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification

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

Category: None
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Aravind Narasimhan (arvy_n)
Summary: Requirement levels for Transport:SSRC needs clarification

Initial Comment:
The SSRC parameter in the transport header has a few

unclarities.

- Why should a client be allowed to propose a SSRC to

the server?

- If allowed as current text indicates, what is the

requirement level on the server to follow the proposed

value. MAY or SHOULD.

First I would like to know the motivation a client has

to suggest a SSRC. This can probably not be removed but

unless there is good reasons for it I think the

requirement on a server to follow the request is MAY.

With a good motivation  the level is SHOULD. 

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

>Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 11:36

Message:
Logged In: YES 
user_id=437699

To address this bug the following text has been added to

13.40 of bis04:

ssrc: The ssrc parameter, if included in a SETUP response,

indicates the RTP SSRC [23] value that will be used by the

media server for RTP packets within the stream. It is

expressed as an eight digit hexadecimal value. If the server

does not act as a synchronization source for stream data

(for instance, server is a translator, reflector, etc.) the

value will be the "packet sender's SSRC" that would have

been used in the RTCP Receiver Reports generated by the

server, regardless of whether the server actually generates

RTCP RRs. If there are multiple sources within the stream,

the ssrc parameter only indicates the value for a single

synchronization source. Other sources must be deduced from

the actual RTP/RTCP stream.

The functionality of specifying the ssrc parameter in a

SETUP request is deprecated as it is incompatible with the

specification of RTP in RFC 1889. If the parameter is

included in the transport header of a SETUP request, the

server MAY ignore it, and choose an appropriate SSRC for the

stream. It MAY set the ssrc parameter in the transport

header of the response.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-12 07:31

Message:
Logged In: YES 
user_id=302620

Plan is to deprecate the behavior that a client is allowed

to specify SSRC to the server. See telecon minutes from 28

April 2003. 

the behavior on how it shall be used will also be clarified.

See discussion on multiple SSRCs. 

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 08:38:13 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification

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

Category: None
>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: Requirement levels for Transport:SSRC needs clarification

Initial Comment:
The SSRC parameter in the transport header has a few

unclarities.

- Why should a client be allowed to propose a SSRC to

the server?

- If allowed as current text indicates, what is the

requirement level on the server to follow the proposed

value. MAY or SHOULD.

First I would like to know the motivation a client has

to suggest a SSRC. This can probably not be removed but

unless there is good reasons for it I think the

requirement on a server to follow the request is MAY.

With a good motivation  the level is SHOULD. 

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

Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 11:36

Message:
Logged In: YES 
user_id=437699

To address this bug the following text has been added to

13.40 of bis04:

ssrc: The ssrc parameter, if included in a SETUP response,

indicates the RTP SSRC [23] value that will be used by the

media server for RTP packets within the stream. It is

expressed as an eight digit hexadecimal value. If the server

does not act as a synchronization source for stream data

(for instance, server is a translator, reflector, etc.) the

value will be the "packet sender's SSRC" that would have

been used in the RTCP Receiver Reports generated by the

server, regardless of whether the server actually generates

RTCP RRs. If there are multiple sources within the stream,

the ssrc parameter only indicates the value for a single

synchronization source. Other sources must be deduced from

the actual RTP/RTCP stream.

The functionality of specifying the ssrc parameter in a

SETUP request is deprecated as it is incompatible with the

specification of RTP in RFC 1889. If the parameter is

included in the transport header of a SETUP request, the

server MAY ignore it, and choose an appropriate SSRC for the

stream. It MAY set the ssrc parameter in the transport

header of the response.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-12 07:31

Message:
Logged In: YES 
user_id=302620

Plan is to deprecate the behavior that a client is allowed

to specify SSRC to the server. See telecon minutes from 28

April 2003. 

the behavior on how it shall be used will also be clarified.

See discussion on multiple SSRCs. 

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 08:38:17 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1

Bugs item #533691, was opened at 2002-03-22 12:36
Message generated for change (Settings changed) made by arvy_n
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: Clarify Range Where t0 <= t1

Initial Comment:
If the server receives a PLAY range from t0-t1, where

t0 < t1, should it reject the PLAY, or should the 

server play backwards as if the timescale is -1?

If t0 = t1, should the server send any media data 

after responding 200 OK?  

We've seen different servers behave differently in 

this scenario.

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

Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 11:16

Message:
Logged In: YES 
user_id=437699

The following text has been added to the spec with regards

to this bug:

By default, range intervals increase, where the second point

is larger than the first point.

   Example:

       Range: npt=10-15

However, range intervals can also decrease if the Scale

header (see section  13.34) indicates a negative scale

value. For example, this would be the case when a playback

in reverse is desired.

   Example:

       Scale: -1

       Range: npt=15-10

Decreasing ranges are still half open intervals as described

above.  Thus, For range A-B, A is closed and B is open. In

the above example, 15 is closed and 10 is open. An exception

to this rule is the case when B=0 in a decreasing range. In

this case, the range is closed on both ends, as otherwise

there would be no way to reach 0 on a reverse playback.

   Example:

       Scale: -1

       Range: npt=15-0

   In this range both 15 and 0 are closed.

A decreasing range interval without a corresponding negative

Scale header is not valid.

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

Comment By: Thomas M Zeng (zengtm)
Date: 2003-03-05 12:53

Message:
Logged In: YES 
user_id=20397

If scale positive, t1 must >= t0.

Otherwise, t1 must <= t0

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

Comment By: Thomas M Zeng (zengtm)
Date: 2002-03-22 12:41

Message:
Logged In: YES 
user_id=20397

I just came across 513880, which is closely related.

That is to say, if timescale is positive, should the play 

range to be required to have t1 > t0?

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 08:38:59 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative

Bugs item #513880, was opened at 2002-02-06 13:48
Message generated for change (Settings changed) made by arvy_n
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&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: Aravind Narasimhan (arvy_n)
Summary: How to use Range when Scale is negative

Initial Comment:
I think the spec could use an example that shows how 

to use the Range header when rewinding (Scale header 

is set to a negative value.)  Or, instead of an 

example, some explanatory text could be added.

The issue that I find a little bit confusing is how 

the server should specify the end of the range. The 

end of the range would be numerically smaller than the 

start of the range.

I think the following illustrates a valid exchange:

C->S:

PLAY rtsp://server/a RTSP/1.0

Scale: -1

Range: npt=45-

S->C:

RTSP/1.0 200 OK

Scale: -1

Range: npt=45-0

This is the type of example that I think would be nice 

to have in the spec.

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

Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 11:22

Message:
Logged In: YES 
user_id=437699

The following text has been added to the spec with regards

to this bug:

When indicating a negative scale for a reverse playback, the

Range header must indicate a decreasing range as described

in section 13.29.

Example of playing in reverse at 3.5 times normal rate:

    Scale: -3.5

    Range: npt=15-10

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

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

Message:
Logged In: YES 
user_id=302620

This needs to be discussed.

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 08:50:12 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513737 ] Unclarities when doing resetup

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

Category: None
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Aravind Narasimhan (arvy_n)
Summary: Unclarities when doing resetup

Initial Comment:
Setup is used to change transport parameters of a already setuped stream. What happends if the 

new SETUP contains errors? Except of responding with an error message, what happends to the 

session and transport state? It should be clarified in the specification. Which of the following 

alternatives are correct?

1. Keep the old setting and states as if the second SETUP never happend.

2. Invalidate the media in the session until a correct setup has happend.

To me case 1 seems more natural but will require more from the server. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-15 04:09

Message:
Logged In: YES 
user_id=302620

A clarified third paragraph in the SETUP section (11.3) has

been added. If a setup request fails the previous state

shall be left as it was, i.e. proposal 1 in the initial

declartion of this bug. 

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 01 Oct 2003 09:00:15 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC

Bugs item #630920, was opened at 2002-10-30 02:44
Message generated for change (Comment added) made by arvy_n
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&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-Info does not support multiple SSRC

Initial Comment:
The RTP-Info header can't be used to synchronize

multiple RTP flows using different SSRC as a single

media stream. As each SSRC has its own RTP sequence and

timestamp space to allow synchronization it needs to be

possible to give these values for each SSRC in the

media stream. 

This bug has connection with bug# 625352.

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

>Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 12:00

Message:
Logged In: YES 
user_id=437699

The following text has been added to 13.33 of bis04 to

address this bug:

The RTP-Info response-header field is used to set

RTP-specific parameters in the PLAY response. These

parameters correspond to the synchronization source

identified by the ssrc parameter of the Transport response

header in the SETUP reponse. For streams using RTP as

transport protocol the RTP-Info header SHALL be part of a

200 response to PLAY.

. . .

Additionally, the RTP-Info header parameter fields only

apply to a single SSRC within a stream (the SSRC reported in

the transport response header; see section  13.40). If there

are multiple synchronization sources present within a RTP

session, RTCP must be used to map RTP and NTP timestamps for

those sources, for both synchronization and drift-checking.

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

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

End of Rtspspec-bugs Digest

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