Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #50 - 3 msgs

From: [email-masked]
Date: Fri, 18 Oct 2002 12:18:05 -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-625339 ] need clarification for stand alon SDP ([email-masked])
   2. [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3 ([email-masked])
   3. [ rtspspec-Bugs-625352 ] clarification for SETUP/a=control ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Fri, 18 Oct 2002 10:57:31 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625339 ] need clarification for stand alon SDP

Bugs item #625339, was opened at 2002-10-18 17:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
Assigned to: Nobody/Anonymous (nobody)
Summary: need clarification for stand alon SDP 

Initial Comment:
When a SDP file is download other than via RTSP (e.g. 
HTTP, FTP), control strings need to be all absolute.  
Should probably put clarification or give an example for 
this case to avoid confusion.

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Fri, 18 Oct 2002 11:00:57 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3

Bugs item #625342, was opened at 2002-10-18 18:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625342&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
Assigned to: Nobody/Anonymous (nobody)
Summary: DESCRIBE Res needed in C.2 and C.3

Initial Comment:
In the examples for aggregate control SDP and 
subsequent SETUP request, it is confusing how a URL 
for SETUP is created.  It is missing a DESCRIBE 
response and gives an impression that a sesseion level 
control string was used as a base URL.

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Fri, 18 Oct 2002 11:41:47 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625352 ] clarification for SETUP/a=control

Bugs item #625352, was opened at 2002-10-18 18:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625352&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
Assigned to: Nobody/Anonymous (nobody)
Summary: clarification for SETUP/a=control

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.

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

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