Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #97 - 4 msgs

From: [email-masked]
Date: Wed, 24 Sep 2003 20:25: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-477403 ] Missing session header in response (SourceForge.net)
   2. [ rtspspec-Bugs-811815 ] Use of c= in SDP to know possible address classes (SourceForge.net)
   3. [ rtspspec-Bugs-493054 ] IPv6 issues (SourceForge.net)
   4. [ rtspspec-Bugs-494957 ] 457 Invalid range for aggregate (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 24 Sep 2003 01:19:18 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477403 ] Missing session header in response

Bugs item #477403, was opened at 2001-11-02 08:20
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&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: Magnus Westerlund (magwes)
Summary: Missing session header in response

Initial Comment:
Page 38 first example: Example missing session header in response.

Should not the client respond with what session id the respond relates to, as the

request contained one.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-24 10:19

Message:
Logged In: YES 
user_id=302620

The text in draft 05 has been updated in regards to the

session ID, see session header and SETUP that has been

totally restructed. Is this acceptable in regards to the

previous issue questions?

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

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

Message:
Logged In: YES 
user_id=302620

There has been some text changes on this section in the 04

draft. I don't think the changed text actually covers the

case completly in regards to the old text. It is also a

tighter definition. 

The new definition does not allow one to create session

without a session id as RFC2326 does. This functionality to

use some other method, like dynamic URLs, seems unspecified.

Therefore I propsoe that it is dissallowed.

Secondly the comments about when one MUST send the session

identifier:

- Robla is correct that the text does not require a server

in the response to include a session header. 

- In response to kjh1905m's comment, this MUST relates to

the client. IF you read carful it says that the client MUST

use the session identifier, if defined by the server, in any

request that is in relation to the created session. 

Actions:

- Question: Is there any need to not require the server to

generate a session ID? The use of any other method to bind

sessions is not specified. In my opinion any client being

faced with this would not understand it, and if it had the

intention of doing aggregate control, it will not know how. 

- The text in the 04 draft version should propably be

improved. I think that mentioning cases where the session

header must or must not be included in the response will

improve understanding. An example of this is the TEARDOWN,

where the presence of a session id header indicates that the

session still exist. I would also guess that having at as

default behavior to return the session ID in responses is

beneficial, but not required or something a client or proxy

cna depend on.

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

Comment By: Jaehwan, Kim (kjh1905m)
Date: 2003-09-04 07:42

Message:
Logged In: YES 
user_id=365760

Then, what is the meaning of 'MUST'?

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

12.37 Session

   This request and response header field identifies an RTSP 

session

   started by the media server in a SETUP response and 

concluded by

   TEARDOWN on the presentation URL. The session identifier 

is chosen by

   the media server (see Section 3.4). Once a client receives 

a Session

   identifier, it MUST return it for any request related to that

   session.  A server does not have to set up a session 

identifier if it

   has other means of identifying a session, such as 

dynamically

   generated URLs.

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-29 00:23

Message:
Logged In: YES 
user_id=3796

I don't think this is a mistake.  The server isn't required to send back a session identifier if the client sends 

one.  It's only required to generate one if the client *doesn't* specify one....and only then in the SETUP 

message.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 18:51

Message:
Logged In: YES 
user_id=3796

Whoops...will fix.

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 24 Sep 2003 07:59:26 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-811815 ] Use of c= in SDP to know possible address classes

Bugs item #811815, was opened at 2003-09-24 16:59
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=811815&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: Use of c= in SDP to know possible address classes

Initial Comment:
While reviewing the text regarding "c=" in SDP I

thought about the potential problem of knowing what

address types the server is capable of delivering to.

For example it is hard to know if a server can deliver

media to both IPv4 and IPv6. 

One potential solution for this indication was to allow

the usage of c= address class IP4 and IP6. However as

this requires use of two "c=" lines it is not possible

to use to declare that both are available. There exist

a solution for this limitation in form of the "alt"

grouping attribute for the RFC 3388 SDP semantics. 

Question is this something worth solving?

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 24 Sep 2003 08:00:54 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-493054 ] IPv6 issues

Bugs item #493054, was opened at 2001-12-13 23:49
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493054&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: IPv6 issues

Initial Comment:
Need a second audit of IPv6 stuff.

Here's an initial survey of IPv6 readiness by Philip J. Nesser II ([email-masked])

http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt

Section 3.2 RTSP URL defines:

   The "rtsp" and "rtspu" schemes are used to refer to network resources

   via the RTSP protocol. This section defines the scheme-specific

   syntax and semantics for RTSP URLs.

   rtsp_URL  =   ( "rtsp:" | "rtspu:" )

                 "//" host [ ":" port ] [ abs_path ]

   host      =   <A legal Internet host domain name of IP address

                 (in dotted decimal form), as defined by Section 2.1

                 of RFC 1123 \cite{rfc1123}>

   port      =   *DIGIT

Althought later in that section the following text is added:

   The use of IP addresses in URLs SHOULD be avoided whenever possible

   (see RFC 1924 [19]).

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-24 17:00

Message:
Logged In: YES 
user_id=302620

After updating some syntax the specification that will be

available in 05 seems to cover all necessary elements to

provide IPv6 support in the signalling. This will need review. 

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

Comment By: Rob Lanphier (robla)
Date: 2002-12-26 23:42

Message:
Logged In: YES 
user_id=3796

Discussed at 2002-Dec-11 telecon

http://rtsp.org/2002/telecon/minutes11Dec.html#section2.2.3

RESOLUTION: accepted that IPv6 should be added to spec

Colin: feature tag should be taken up as separate issue

Magnus: people should look at spec for feature tag

ACTION ITEM (all): read spec for how feature tag works

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

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

Message:
Logged In: YES 
user_id=302620

An IPv6 explanation chapter started in the connetion

chapter. May need more text. 

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

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

Message:
Logged In: YES 
user_id=302620

The specification has been updated so that URL's can handle

IPv6 in them. A note of caution that this will cause

interoperability problems has also been added. 

Propose that a chapter is written on IPv4/IPv6

Interoperability to better explain the issues. Demand that

implementers of option-tag "play.basic" supports IPv6 so

that this can be checked before trying.

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

Comment By: Jonathan Sergent (sergent)
Date: 2002-01-15 18:27

Message:
Logged In: YES 
user_id=79184

We have implemented IPv6 in our RTSP server.  The above

issue--strings in URLs--is not particularly relevant to us

since we do not attempt to parse the host and port

information in our server (we just treat it as a string),

and we do not have an RTSP client.

The issue that is not mentioned above that is much more

significant is the Transport header's handling of

addresses.  The grammar does not allow IPv6 addresses.

We will deliver RTP over IPv6 if it can be negotiated

without passing addresses through the Transport header (i.e.

no multicast, and source and destination are the same as the

RTSP endpoints).  If we can decide on the format for this,

we will be able to implement it and try it out.

I think that some rules need to be set out w.r.t. the use of

mapped addresses and such in the header.  And should IPv6

potentially be negotiated as a different protocol in the

header?  (i.e. Transport:

RTP/AVP/UDP6;unicast;foo,RTP/AVP/UDP;unicast;bar to indicate

a preference for V6 over V4)

Also, it should probably be clarified that c=IN IP4 0.0.0.0

in SDP is just a flag value and does not indicate the

preference or the availability of V4, only that the

parameters will be negotiated at SETUP time.

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 24 Sep 2003 08:02:02 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494957 ] 457 Invalid range for aggregate

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

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: 457 Invalid range for aggregate

Initial Comment:
When shall 457 be used in the case of aggregated control?

In a single media session its unambigous to when a range is valid or not. But in the aggregated 

case the range given in a play can be valid for one media and invalid for another. Which of the two 

following interpretetations should be used?

1. A aggregate range is invalid only if all media see it as invalid.

2. A aggregate range is invalid in any media see it as invalid.

I would argue for reasons of simplicity and clearnes that case 2 is the better.  

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-24 17:02

Message:
Logged In: YES 
user_id=302620

As this bug has been resolved for quite a while without

comments I herby close it. 

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

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

Message:
Logged In: YES 
user_id=302620

This has been clarified in the specification so that a given

range in a PLAY request must be inside the bounds of at

least one of the medias part of the aggregate. Otherwise a

457 response shall be given. The same rules apply for PAUSE.

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

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

End of Rtspspec-bugs Digest

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