Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #104 - 7 msgs

From: [email-masked]
Date: Fri, 24 Oct 2003 20:29:01 -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-522602 ] Should Allow S->C  "Teardown" (SourceForge.net)
   2. [ rtspspec-Bugs-829528 ] SDP appendix and RFC 3388 (SourceForge.net)
   3. [ rtspspec-Bugs-539001 ] Transport header should override m= (SourceForge.net)
   4. [ rtspspec-Bugs-500875 ] State diagram clarifications (SourceForge.net)
   5. [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready (SourceForge.net)
   6. [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net)
   7. [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:41:57 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-522602 ] Should Allow S->C  "Teardown"

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

Category: General
Group: Fix for DS - Need WG Input
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
>Assigned to: Magnus Westerlund (magwes)
Summary: Should Allow S->C  "Teardown" 

Initial Comment:
Table 2 in section 10 of RFC2326 seem to disallow S->C 
Teardown. And section 10.7 is vague on whether S->C 
teardown is OK.

This should be relaxed, because Server might have to 
use TEARDOWN to tell client a live session is over.

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

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

Message:
Logged In: YES 
user_id=302620

As it is being take care of and new tracking bug 810678 will
be used for this issues instead. 

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

Comment By: Thomas M Zeng (zengtm)
Date: 2003-09-30 06:10

Message:
Logged In: YES 
user_id=20397

Since during Vienna IETF, we have decided to add 
END_OF_STREAM, Teardown from S->C is not necessary.
We can close this issue.

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

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

Message:
Logged In: YES 
user_id=302620

To be discussed

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 04:38:46 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-829528 ] SDP appendix and RFC 3388

Bugs item #829528, was opened at 2003-10-24 13:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=829528&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: SDP appendix and RFC 3388

Initial Comment:
Should we add text in the SDP chapter on how to handle
the Grouping of media lines for SDP, RFC 3388? 

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 05:20:08 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-539001 ] Transport header should override m=

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

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
>Assigned to: Magnus Westerlund (magwes)
Summary: Transport header should override m=

Initial Comment:
Section C.1.7 ("Connection Information") states the
following:  "for on-demand unicast streams and some
multicast streams, the destination is specified by the
client via the SETUP request".  The rest of this
section mainly refers to the "c=" line in SDP, but it's
not clear that the SETUP Transport header also
overrides the port given in the m= line.  Clarification
of this is needed.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 14:20

Message:
Logged In: YES 
user_id=302620

This has been clarified in the SDP appendix. There has been
alignment between what is possible between ports and addresses. 

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:35:20 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500875 ] State diagram clarifications

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

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Sean Sheedy (seansh)
>Assigned to: Magnus Westerlund (magwes)
Summary: State diagram clarifications

Initial Comment:
My understanding is that the state diagram in Appendix
A is per-session, not per-client.  However, this is not
explicitly stated.  This should be made clear in the
description.

Errors within the media server (series 5xx) often leave
a stream in an unplayable, unrecoverable state in which
the client's only option is to tear down the session
and start over.  This should be reflected in the state
diagram.

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

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

Message:
Logged In: YES 
user_id=302620

I hope that the resolution in the state machine chapter is
satisfactory. AS no comments on the resolution has been
given in the last year I hereby close the bug. 

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

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

Message:
Logged In: YES 
user_id=302620

The state machine has been updated and clearly represent a
RTSP session. The effect 5xx error codes may have has also
been clarified. A 5xx response is in general recoverable
from. But the server is allowed to terminate the session for
errors of unrecoerable nature. The client will detect this
when issuing another request to that session and receive a
454 (Session Not Found) as response. 

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

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

Message:
Logged In: YES 
user_id=302620

This one is realted to bug report #500803

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 04:51:03 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready

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

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Magnus Westerlund (magwes)
Summary: Client issues PAUSE while server ready

Initial Comment:
If a client issues a PAUSE and the server acknowledges
and enters ready state, what is proper server response
if the player issues another PAUSE?

There appear to be two possible correct behaviors:

1. server responds with OK because it does not change
state and does no harm.

2. server responds with error 455 because PAUSE does
not make sense in this state.

Both interpretations have been implemented.  The latter
appears to be more correct, but a client that assumes
the first may misbehave if the server implements the
second.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 13:51

Message:
Logged In: YES 
user_id=302620

This clarification of behavior has now beend added to the
text and will be published in v5. The text is in the state
machine and pause method section.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-14 17:17

Message:
Logged In: YES 
user_id=302620

The working assumption is that a 200 OK should be sent even
if already in ready state. Also the pause point needs to be
included in the response. 

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

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

Message:
Logged In: YES 
user_id=302620

This should be clarified. Input from implementors wanted.
The resolution should be made evident in the state machine. 

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 09:14:10 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved

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

>Category: Feature Request
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP/AVP/TCP w/o interleaved

Initial Comment:

If a Transport line specifies RTP/AVP/TCP
and does not also use the interleaved
parameter, the transport setup details
seem undocumented (maybe I'm not looking
in the right place ...).

I'm thinking of the level of detail the
comedia I-D provides for TCP: which
side accept()s and which side connect()s,
how many connections to set up, framing, 
etc.

Are there pre-existing implementations 
that use this transport mode? I happened
to stumble onto this in writing the TCP
appendix for the MWPP "implementation
guidelines" ... which may spawn off a
generic I-D specifying how to use comedia
with RTP (framing, specifying the fmt
tokens after TCP, etc). So, one option
is to add RTP/AVP/TCP w/o interleaving
details to that I-D, if adding it to
to the RTSP I-D isn't desirable for
some reason ...

john lazzaro -- [email-masked]

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

Comment By: Rob Lanphier (robla)
Date: 2003-05-28 18:34

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: we should leave this until RTP framing is done
# Magnus: this is basically a feature request
# Magnus: this might well be a separate draft
# Rob: agreed
# Aravind: agreed
# Tom: we'll have to deal with this issue when DCCP comes along
# Anders: I saw this in use
# Tom: they might be using interleaving or not
# RESOLUTION: separate draft for non-interleaving; narrow
spec for      interleaving 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 05:07:50 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs

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

>Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
>Assigned to: Magnus Westerlund (magwes)
>Summary: Synchronising multiple SSRCs

Initial Comment:
taken from a thread in mmusic

We have a problem in RTSP when a media stream 
needs to contain multiple
RTP SSRCs. This can't be expressed today clearly.

When one is only interested in controlling the media and 
not each
individual source the following scenarios should be 
supported:
A SINGLE SETUP request can result in one of the 
following:
1. A media stream with a single SSRC.
2. A media stream with retransmission with SSRC 
multiplexing. This
requires a SSRC for the original and one for the 
retransmission packets.
It is an advantage if both can be explicitly signalled, but 
is no
requirement.
3. Live session with any number of participants and 
unlimited use of
dynamic chosen SSRCs.

Due to clients capability the different scenarios need to 
be explicitly
signaled. Scenario 2 will be that from an SDP 
description and support of
retransmission will be signaled by requesting AVPF in 
the transport
header. However today there exist no way to signal if it 
is scenario 1
or 3. So this needs to be resolved in a nice backwards 
compatible way. I
think that support for 3 can require support for any extra 
signaling
while scenario 1 must work without any extra parts.

By doing all these scenarios with a single SETUP per 
media stream we
keep the signaling to a minimum and avoid further 
requirements on SDP.
It might be advantageous in the future to create a SDP 
attribute
declaring the streams type.

If one desires to control the individual source one either 
declare
individual media streams for each source. This will 
require use of
ANNOUNCE in dynamic settings. The alternative would 
be to create a new
media resource control protocol which is suited for this. 
However I
don't see real need to solve this problem in standard 
RTSP better than
by using ANNOUNCE.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 14:07

Message:
Logged In: YES 
user_id=302620

This was discussed in the telecon the 28th April 2003.

The resolution was to clarify in RTSP that only a single
SSRC one can be given in RTSP. Any furhter SSRC may be
present in the stream, however they must be synchronised
using RTCP. 

This has been clarified in the specification. 

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

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

End of Rtspspec-bugs Digest

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