Subject: RE: [MMUSIC] a=control in SDP

From: Thomas Zeng <[email-masked]>
Date: Fri, 13 Sep 2002 12:14:28 -0700

Magnus:

I am yet to be convinced that the trailing slash will not work, beyond an
athetatic issue that is minor, so far.
I am very concerned with defining a new reserverd token "*" for a=control:
line, in the sense that the existing
servers or clients would not understand the new syntax.

See answers to your questions below.

Thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Thursday, September 12, 2002 12:03 AM
To: Thomas Zeng
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] a=control in SDP

>Hi Thomas,

>I think this can hurt someone. It is flawed in consistency.

>The client does describe on a URL without a trailing slash. It gets a 
>response that has a Content-Base URL that points to the URL with slash. 
>Which results in that the aggregated control URL has trailing slash. If 
>one would like to do a new describe using the aggregated control URL 
>with a slash it does not work as intended.

[tz] A new DESCRIBE request with trailing slash is OK.  I doubled checked
   RFC1808, a trailing slash is allowed in an URL. I understand your concern
that
   two absolute URLs may be used to refer to same content (one with trailing
slash, one without).
   However, I have not come across any rule
   specifiying a content must be refered to by one absolute URL. After all,
isn't this a server implementation 
   issue, not part of RTSP protocol?

>If the server would do a 
>ANNOUNCE it would also be strange and inconsistent between the URLs. 
>This may create worse problem when one tries to expand the protocol. If 
>anyone would try to use the Content-Location header to indicate the 
>base-url they would actually lie about where this SDP came from.

[tz] In the case of Annonce I can say, as an example, the following (based
on the Announce example in 2326).
    Is there any problem?  
     As to Content-Location, having a trailing slash or not makes no
difference, I think, as shown below. Here I again
    I see no requirement that Content-Location must correspond to an unique
URL. At least not in RFC2068.

C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo/ RTSP/1.0 
CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT 
Session: 47112344 
Content-Type: application/sdp 
Content-Length: 332 
Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Location: rtsp://server.example.com/fizzle/foo/

 v=0
 a=Control:*
 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
 s=SDP Seminar
 i=A Seminar on the session description protocol
 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
 e=[email-masked] (Mark Handley)
 c=IN IP4 224.2.17.12/127
 t=2873397496 2873404696
 a=recvonly
 m=audio 3456 RTP/AVP 0
 a=Control: trackID=1
 m=video 2232 RTP/AVP 31
 a=Control: trackID=2

>I think that my proposal using */ is more consistent. And consistency is 
>one of the things that are important in the update of RTSP.

[tz] I agree that your proposal is cleaner. But how do you propose to
retrofit the existing servers out there? 
     It will be a nightmare to support backwards compatibility. 

>I guess that the 3GPP Interop your referring to is IMTC's PSS interop. I 
>would be much more pleased of this group if they had the decency to 
>report any found inconsistencies to MMUSIC. I would also like you to 
>inform MMUSIC about your proposal to fix the bugs. I know that I is easy 
>to get involved in details. But to make RTSP a useful protocol in the 
>future a certain level of afterthought must be made when suggesting 
>restrictions and resolutions.

In general it is highly desirable to have more liason b/w user groups of
RTSP and MMUSIC.
I am not a member of 3GPP so I can't speak for them. I have asked someone
else (Ralph Neff) who
represents PacketVideo in 3GPP to reply on this issue.

Regards,
thomas

>
>-----Original Message-----
>From: Magnus Westerlund [mailto:[email-masked]]
>Sent: Wednesday, September 11, 2002 12:21 AM
>To: [email-masked]
>Cc: IETF MMUSIC WG
>Subject: Re: [MMUSIC] a=control in SDP
>
>
>Hi Aaron,
>
>Aaron wrote:
>
>>I was under the impression that you could support this functionallity by 
>>doing the following
>>
>>In the DESCRIBE response
>>Content-Base: rtsp://example.com/donald.mp4/
>>On session level:
>>a=control:*   
>>On media level
>>a=control:trackID=2
>>
>>Is that not the case?
>>
>No, It would solve the problem at media level and that URL would resolve 
>to "rtsp://example.com/donald.mp4/trackID=2" which is what I want. 
>However the aggregated control URL on the session level would become 
>"rtsp://example.com/donald.mp4/". And in this URL that extra slash is 
>not desired.
>
>Regards
>
>Magnus
>
>
>>Aaron
>>
>>On Tue, 10 Sep 2002, Magnus Westerlund wrote:
>>
>>>Hi,
>>>
>>>I have found a problem when using relative URLs in a=control: lines. One 
>>>would like for on-demand stored files to not have to edit any of the 
>>>control URLs when responding on a DESCRIBE request. This would be 
>>>extremely good to have for container files like MP4 files. All media is 
>>>part of the file and can be referenced within the file with just a track 
>>>id. But as the relative URL scheme is defined in RFC 2396 which updates 
>>>RFC 1808 referenced in the RTSP RFC, any relative URL must at least 
>>>contain the filename of the container file. This results in that a SDP 
>>>document delivered to a client may look like this.
>>>
>>>For a container file that has the URL: rtsp://example.com/donald.mp4
>>>On session level:
>>>a=control:*
>>>On media level
>>>a=control:donald.mp4/trackID=2
>>>
>>>Container files that stores SDPs would not like to have the filename of 
>>>the file in there. Having the filename in the files creates problem when 
>>>copying or renaming the file. A server may update the filename but this 
>>>puts more load on the server when the goal of these container files it 
>>>to put minimal load on the server and be media independent. Therefore it 
>>>would be good if one could make SDP a=control lines like this:
>>>
>>>On session level:
>>>a=control:*
>>>On media level
>>>a=control:*/trackID=2
>>>
>>>So does any see problems with extending the semantics of "*" in 
>>>a=control URLs to allow the above media level usage?
>>>
>>>Then I have a second question. Is the use of "/" before "trackID=" the 
>>>most appropriate way of referencing into a container file? Or would 
>>>parameter or any other separator be better? At least "#" seems to be a 
>>>bad choice as it refers to actions for the user agent (client).
>>>
>>>Regards
>>>
>>>Magnus Westerlund
>>>
>>>
>>>From RFC 2326:
>>>----------------------------------------
>>>C.1.1 Control URL
>>>
>>>  The "a=control:" attribute is used to convey the control URL. This
>>>  attribute is used both for the session and media descriptions. If
>>>  used for individual media, it indicates the URL to be used for
>>>  controlling that particular media stream. If found at the session
>>>  level, the attribute indicates the URL for aggregate control.
>>>
>>>  Example:
>>>    a=control:rtsp://example.com/foo
>>>
>>>  This attribute may contain either relative and absolute URLs,
>>>  following the rules and conventions set out in RFC 1808 [25].
>>>  Implementations should look for a base URL in the following order:
>>>
>>>  1.     The RTSP Content-Base field
>>>  2.     The RTSP Content-Location field
>>>  3.     The RTSP request URL
>>>
>>>  If this attribute contains only an asterisk (*), then the URL is
>>>  treated as if it were an empty embedded URL, and thus inherits the
>>>  entire base URL.
>>>----------- end of quote -----------
>>>
>>>
>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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