[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Minutes from RTSP telecon 22 of january
Attendees of RTSP telecon 22 of january, 2003
Andrea Basso
Tom Marshall
Jorg Ott
Magnus Westerlund
Adlers Klemets
Thomas Zeng
Agenda Bashing:
Magnus: Please everyone take a look at A proposal for RTP interleaved in
TCP: draft-lazzaro-avt-rtp-framing-contrans-00.txt. It is available from the
IETF repository at:
http://www.ietf.org/internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-0
0.txt
Meeting notes:
- Follow up on last telecon
* 304 and REDIRECT "*" text proposal.
(Tom's proposal -- see corresponding email sent by Tom Marshall on Jan 21
entiled [MMUSIC] Proposed update to draft-02.
Mag(nus): The paragraph on redirect out to proxy and clients is back
wards?
Tom: I don't understand...
Mag: I mean the order of control channel teardown...
Tom: Why order is important? why a particular order?
Mag: Perhaps my misunderstanding ?
Tom: Proxy can answer requests on behalf of the clients, therefore
order (of answering vs taking done the RTSP
session) is no longer important.
Resolution: add a session that proxy should answer redirect request to
the server on behalf of its down stream clients
- 3rr codes:
Thomas: What is 3rr useful for?
Mag: If a client closed TCP after setup, then connect again to send
play request but Server wanted to REDIRECT, then
Server would use 3rr responses.
Mag: I have more ecommments: have you (Tom) considered header
usability? eg. Location header for 3rr responses ...
Should update table 4 and 5 such that Location header should be
allowed for all methods.
(Action item: Tom to add wording to allow 3rr for other method responses).
Thomas: I'd like to bring up the proposal from Magnus (or Mag in short)
to use REDIRECT as a way to say "TEARDOWN" from
S->C.
Tom: I don't like using REDIECT to replace TEARDOWN from S->C. I prefer
END_OF_STREAM in this case to close a session.
Jorg: I agree with Tom. Compared to TEARDOWN from S->C, REDIRECT means
something else.
Mag: We can say REDIRECT with empty Location header to mean redirecting
to cyber space.
Jorg: It still is not convincing.
Tom: A "*" location maybe?
Mag: Perhaps END_OF_STREAM (or END_OF_SESSION) is more appropriate?
Adrea: what about backwards compability? in that regard REDIRECT is better
(than END_OF_STREAM/SESSION)...
Mag: I don't know whether it belongs to RTSP (i.e., RTCP BYE is better to
signal end of live session)...
Tom: I ahve an idea. Suppose server live feed goes away, then server
redirect its clients to itself. Then client
reconnect;
Magnus: Yah, you can actually redirect to info page
Resolution: use redirect to tell the clients to teardown and reconnect to
the same server. Then tell the clients that
service is not available via perhaps a info page. That way we have good
backwards compatibility and no
need for TEARDOWN S->C nor END_OF_STREAM.
Mag: Let's go on to extension mechanism
- Extension mechanism
Mag: basic idea is to use feature tags and require/Proxy-requre headers
as well as the Support/Unsupported header from SIP. End points will
list all feature tags
it supports in a request and the other side includes all its tags in
its response
Andrea: it's not clear who will be the master (e.g., 324-M one guy takes
the role of the master)
Mag; it's up to the requester
Andrea: in the case of streaming you are right it is the client to decide
Mag: it applies to two way as well
Andrea: what about two way? a capability exchange must have a master
Mag : but we are talking about server capabilit not media capabilty
Jorg: Clarifying 324M ... Feature tags are independent of master slave
Feature tags only indicate what's available , independent of
hieraarchical relationships (master / slave).
Andrea: for streaming scenario it is clear to me.
Mag: This is basically the idea if you require a feature put in Require
header. If server does not have the capability
it responds with error (code 551) with an Unsupported header containing
the feature tags in question that are not supported.
The feature tag representing the updated specification with basic
playback functionality is necessary due to the few non-backwards
compatibility issues we have. To be able to use the following
mechanism
in RTSP both end-points need to support "play.basic":
-- IPv6 addresses in source and destination parameters in
transport header
-- Use of "RTCP_client_port" and "rtcp_server_port"
transport header parameters.
This mechanism makes it possible to evolve the RTSP standards
(e.g. possible future IPV6 or RTCP back channel (?) extensions).
Thomas : Makes sense since SIP had a success with it.
Mag: We have the options method which is a perfrect place to include
Supported header.
* Feature tags
- play.basic
Mag: The tag, play.basic signals the min implementation of the new
spec.
There are also play.speed and play.scale tags.
Thomas: let's require Range in PLAY response in play.basic (i.e. min
implementation) if there is no objection.
Mag: the draft alreadys requires Range header in all Play responses
for on-demand media.
Thomas: Let's do the same with Live.
Resolution: Let's propose to require Range in Play responses (for
live, use range "now- ") to the mailing list.
Magnus: A comment, for live streams if possible it is better to
give a real
clock if possible. I think UTC times can be useful also in
live streams.
- registration
Jorg: There is a big issue with registration, which should be
centralized by IETF to reg all feature tags.
For event packages may not necessaryly be regi by IETF.
We have seen too many attmpts to abuse it.
Keep strict control here is to ensure people don't do strange
things. For RTSP we want same security
so RTSP don't open up too many doors.
We should probably start with strict registration, but we are aware
of propriatary tags in the existing servers.
SIP says don't mess up existing registered feature tags if you have
propriatary features.
Ensure we don't get collisions in the registration process. Should
have an open documentation for that. It's up to
group to decide whether we have allowance to experimentations,
since people don't want to wait until it's all finished.
What are people's thoughts whether to make it very strict or very open?
Mag: Judging by 3gpp experience, 3 months turn around is too long. I'd
rather see it faily open registration
Jorg: Just not say anything about how to use feature tags? not a good
idea.
Mag: first come first serve is an option.
Conclustion: More thougts are required. Please look at the existing
registration route in the drafts as well as the 7
tags. Identify potential parties who will likely send requests to
register tags (e.g. 3gpp and ISMA).
Jorg: My goal is to avoid too many profiles of RTSP -- we have had enough
incompabilites b/w SIP in general and
3gpp SIP. Neither side should be relying on anything.
Mag: I have been talking to 3gpp. RTSP so far hasn't suffered much in
terms of "profiling RTSP".
Jorg: there is going to be a meeting b/w 3gpp and IETF next week. I'll
speak to Allison on this issue.
(Action item: Jorg to post a feedback after next week's meeting.)
* Require header
* Proxy-require header
- Shall it really require server to support these? See SIP, RFC
3261 which uses Proxy-Require only for proxies.
Tom: all Proxy headers are hop by hop in HTTP 1.1
Magus: it makes sense to align with SIP than HTTP at this moment.
Magnus: can you see Proxy only feature tags?
e.g. cache feature tags for RTSP that are only for proxies?
Current servers are not to honor Proxy-require headers.
Jorg: if you want tag be supported by both proxy and servers then use
both Require and Proxy-Require.
Mag: Do you Tom support Proxy-require?
Tom: yes, but there is no specific tags.
in previous server, Proxy-require not honored by servers. It's
changed in recent release.
Conclusion: Propose to MMUSIC that Proxy-require should not be honored
by servers, only by Proxys. Likewise, Require
is only for servers, not Proxy. This would be aligning with SIP.
Mag: Tom's and my servers both honor Proxy-require headers. So there is
backwards compatibility issue, but minor engouh.
- Next meeting
Magnus: when?
also think about editorship.
Let's say two weeks.
Thomas : any objectisn to two weeks?
Two weeks it is.
---------------------------------
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@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic