headers
philippe.gentric | 2 Jun 2003 15:57
Picon

RTSP redirection


dear MMUSICers,

following the post last week on RTSP redirection
there was a discussion during the last RTSP phone call

here are the results (please comment/correct )

********************************************************

1) The core RTSP spec needs a few clarifications about redirection
(that -in short- [redirection=failure])

1.A) There is a need for a piece of text explaining that in general the server providing
the RTSP streaming service (i.e. SETUP etc ...)  is assumed to also be the one
that provides the session description (i.e. DESCRIBE) [reasons: simplicity/logic,
easier to do interrop testing, backward compatibility]

1.B) Specifically a minimal RTSP client implementation does not need to expect
that the response to DESCRIBE would be used to point to another server
whatever mean would be used for that (i.e. content-location, absolute URL
is SDP etc) unless it is signaled *explicitely* as a redirection:

1.C) Specifically if a server wishes to redirect a client at DESCRIBE time
(e.g. for load balancing etc) it MUST issue a 3xx code (TBD) and the answer
MUST NOT contain any SDP (i.e. this is the single minimal interoperable RTSP
redirection behavior)

Open Issue: what is the most appropriate way to signal the alternate server ?
is it Content-Location ?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Magnus Westerlund | 2 Jun 2003 16:21
Picon
Favicon

Re: RTSP redirection

Hi Phillipe,

Comments below.

philippe.gentric <at> philips.com wrote:
> dear MMUSICers,
> 
> following the post last week on RTSP redirection
> there was a discussion during the last RTSP phone call
> 
> here are the results (please comment/correct )
> 
> ********************************************************
> 
> 1) The core RTSP spec needs a few clarifications about redirection
> (that -in short- [redirection=failure])
> 
> 1.A) There is a need for a piece of text explaining that in general the server providing
> the RTSP streaming service (i.e. SETUP etc ...)  is assumed to also be the one
> that provides the session description (i.e. DESCRIBE) [reasons: simplicity/logic,
> easier to do interrop testing, backward compatibility]
> 
> 1.B) Specifically a minimal RTSP client implementation does not need to expect
> that the response to DESCRIBE would be used to point to another server
> whatever mean would be used for that (i.e. content-location, absolute URL
> is SDP etc) unless it is signaled *explicitely* as a redirection:
> 
> 1.C) Specifically if a server wishes to redirect a client at DESCRIBE time
> (e.g. for load balancing etc) it MUST issue a 3xx code (TBD) and the answer
> MUST NOT contain any SDP (i.e. this is the single minimal interoperable RTSP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Marshall | 2 Jun 2003 18:16
Picon
Favicon

Re: RTSP redirection

> >2.C) The exact mean to indicate redirection is TBD.
> >Content-location  has been proposed.
> 
> The usage of Content-Base may actually be more appropriate as it has not 
> any semantic meaning more than being the base for any relative URL. 
> Content-Location has a semantic meaning that the content actually 
> hides/(also present) behind the used URL and instead can be 
> found/referenced using the URL present i Content-Location. Further input 
> into the matter is desired.

I agree that Content-Base is the way to go.

I discussed this matter with Rob Lanphier and others last week.  The wording
in 2326 was designed to discourage redirection via the Content-Base header
out of a desire to reduce complexity (or at least not add more complexity). 

On the other hand, it seems to be more consistent to allow redirection via
the Content-Base header.  First, it is more consistent with the way SDP is
handled when retrieved via HTTP.  If the HTTP server sends a Content-Base
header, the host portion is expected to be honored, so why not with RTSP? 
If the SDP contains absolute control urls, why should the client connect to
different servers depending on how it got the SDP?  Second, it is more
consistent when a proxy is involved.  The client will receive the DESCRIBE
response with Content-Base header that points to a different server.  It
will then request a SETUP on the url resulting from the Content-Base header
and the control url.  The proxy will connect to the other server to send the
SETUP request.  Why should the client alone act any differently?

The Content-Base method requires minimal changes to the spec.  It would
mostly require some text that makes it clear the client MUST (or at the very
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aravind Narasimhan | 2 Jun 2003 18:33
Picon

Minutes from 28 May Telecon on RTSP

May 28th Teleconference Meeting Minutes:

Agenda:
-------

1. Opening of meeting.
2. Since last meeting (14th of May).
    a. Bug 533691 &  513880
        - Waiting for updated text after resolution of issues.
    b. http://rtsp.org/bug556295 - Thomas to write text.
    c. Multiple SSRC in RTSP.
        - Aravind to write updated text.
    d. Other?
3. New Things
    a. http://rtsp.org/507882 - RTP timestamp and pause
    b. http://rtsp.org/739845 - "a=range" is missing IANA registration 
and clear rules
    c. http://rtsp.org/742328 - How to handle PLAY request when at the 
end of a media clip
    d. http://rtsp.org/742348 - Usage of implicit REDIRECT.
4. Administrative
    a. Phase 2 of the work. Getting text into shape.
5. Any other Issues
6. Next meeting - Proposal: 11th of June?
7. End meeting

Attendees:
----------
Magnus Westerlund
Geetha Srikantan
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Jun 2003 13:47
Picon
Favicon

I-D ACTION:draft-ietf-mmusic-sdp4nat-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: RTCP attribute in SDP
	Author(s)	: C. Huitema
	Filename	: draft-ietf-mmusic-sdp4nat-05.txt
	Pages		: 7
	Date		: 2003-6-2
	
The session description protocol (SDP) is used to describe the 
parameters of media streams used in multimedia sessions. When a 
session requires multiple ports, SDP assumes that these port have 
consecutive numbers. However, when the session crosses a network 
address translation device that also uses port mapping, the ordering 
of ports can be destroyed by the translation. To handle this, we 
propose an extension attribute to SDP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-sdp4nat-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 4 Jun 2003 11:19
Picon
Favicon

RTSP telecon 16th of June 18.00 CET

Hi,

I have now decided that the next RTSP telecon is the 16th of June at the 
normal time of 18.00 CET. The reason for not keeping with the normal two 
week pattern is that there is very few work days at least for me until 
the 11th.

Agenda will be posted later.

Best Regards

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: magnus.westerlund <at> ericsson.com
Permalink | Reply | 0 comments |
headers
philippe.gentric | 4 Jun 2003 16:51
Picon

Re: RTSP redirection

Magnus you wrote:

[erased context]

>What would be the motivation behind using a differnet 2xx code than 200?
>  Please elaborate with pro and cons.

CONS (use 200)

because the response to the DESCRIBE is simply *successful* ...

PROS (use some 2xx code xx!= 00)

RFC2616 uses the following codes:

  10.2.1   200 OK ...................................................58
   10.2.2   201 Created ..............................................59
   10.2.3   202 Accepted .............................................59
   10.2.4   203 Non-Authoritative Information ........................59
   10.2.5   204 No Content ...........................................60
   10.2.6   205 Reset Content ........................................60
   10.2.7   206 Partial Content ......................................60

These codes are used to distinguish between seleral "flavor" for
a successful response ...

in our case we have a succesful describe BUT the client is requested
to continue at a different location ...

Could also help to indicate different caching status ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 4 Jun 2003 21:22
Picon
Favicon

Protocol Action: RTCP attribute in SDP to Proposed Standard


The IESG has approved the Internet-Draft 'RTCP attribute in SDP'
<draft-ietf-mmusic-sdp4nat-05.txt> as a Proposed Standard. This
document is the product of the Multiparty Multimedia Session Control
Working Group. The IESG contact persons are Allison Mankin and Jon
Peterson.

Technical Summary

The new version of RTP (draft-ietf-avt-rtp-new-12) relaxes the requirement
in 1889 that the port number used for the Real Time Control Protocol (RTCP)
must be one port number higher than the port chosen for an RTP stream.
Because of this, protocols like the Session Description Protocol which use
RTP now need a way to explicitly specify the port that will be used for an
RTCP stream corresponding to an RTP stream; previously, SDP had no need for
this capability since implementations just assumed that RTP/RTCP used
consecutive numbers.

So, this document proposes a new SDP attribute (a=rtcp:<port>) that allows
this change in RTP, and the proposed change to SDP, RTCP had a great deal of
trouble traversing NATs in SDP-based applications (like SIP). The document
therefore considers NAT traversal as a motivating case for the addition of
this attribute. The use of this new attribute to facilitate NAT traversal is
intended to be used in concert with STUN (RFC 3489).

Working Group Summary

The MMUSIC WG supported the advancement of this document.

Protocol Quality
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 5 Jun 2003 01:19
Picon
Favicon

Last Call: SDP: Session Description Protocol to Proposed Standard


The IESG has received a request from the Multiparty Multimedia 
Session Control Working Group to consider SDP: Session Description 
Protocol <draft-ietf-mmusic-sdp-new-13.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2003-6-18.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-13.txt
Permalink | Reply | 0 comments |
headers
rtspspec-bugs-request | 5 Jun 2003 17:14
Picon

Rtspspec-bugs digest, Vol 1 #77 - 11 msgs


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-633779 ] SET_PARAMETER responses (SourceForge.net)
   2. [ rtspspec-Bugs-634944 ] Restarting media not allowing seek (SourceForge.net)
   3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net)
   4. [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net)
   5. [ rtspspec-Bugs-631148 ] Better Info on usage of Proxies (SourceForge.net)
   6. [ rtspspec-Bugs-745191 ] Appendix B - Clarification? (SourceForge.net)
   7. [ rtspspec-Bugs-745191 ] Appendix B - Clarification? (SourceForge.net)
   8. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net)
   9. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net)
  10. [ rtspspec-Bugs-536713 ] ControlURL parsing order must be changed (SourceForge.net)
  11. [ rtspspec-Bugs-507408 ] clarify use of interleaved param (SourceForge.net)

--__--__--

Message: 1
To: noreply <at> sourceforge.net
From: "SourceForge.net" <noreply <at> sourceforge.net>
Date: Wed, 28 May 2003 09:28:56 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses

Bugs item #633779, was opened at 2002-11-05 04:19
(Continue reading)

Permalink | Reply | 0 comments |

Gmane