RE: [MMUSIC] Draft MMUSIC Minutes

["Orit Levin" <[e-mail]>]

Unfortunately, I couldn't participate in the last MMUSIC meeting.
Reading the minutes, I found this one peculiar:
------------------
* Semantics are undefined for multiple "m=" lines with the same port
   and "c=" The interpretation should go into the SDP-new draft as a
   clarification. There are minor implications on the offer-answer
   examples. Gonzalo Camarillo <mailto:[e-mail]>
   sent some text, but for a different case (hierarchical
   encoding). Flemming Andreasen <mailto:[e-mail]> proposed
   that we simply prohibit this construct. The meeting agreed to the
   prohibition.
-------------------

I am wondering how can you allow for one particular application and prohibit all the others?
For the existing implementations, that don't understand the fid attribute and the associated grouping, it will appear exactly as the same case.

Orit.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Joerg Ott
Sent: Monday, December 01, 2003 1:56 AM
To: [e-mail]; [e-mail]
Subject: [MMUSIC] Draft MMUSIC Minutes

Folks,

attached are the draft minutes from the MMUSIC WG meeting at the 58th IETF in MPLS.

Please review and post comments to the list.

The corresponding slides can be retrieved from

http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-ppt.zip
http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-pdf.zip
http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-ps.zip

Thanks,
Joerg


58th IETF: MMUSIC Minutes
-------------------------

Reported by Tom Taylor <mailto:[e-mail]>
and Colin Perkins.

MMUSIC met on Friday morning, November 14. The meeting was chaired by Jörg Ott <mailto:[e-mail]> and Colin Perkins <mailto:[e-mail]>.

The agenda was accepted with two minor changes: a discussion of Source and Sink SDP attributes was added, and the discussion of SDP parameters for H.263 and H.261 options took place in AVT instead.


Introduction and Status Update
------------------------------

Jörg Ott gave an introduction and status update. The working group has had one RFC published since the last meeting: the RTCP attribute for SDP (RFC 3605 <http://www.ietf.org/rfc/rfc3605.txt>), and draft-ietf-mmusic-sdpng-trans-04.txt is with the RFC Editor. The IESG has reviewed draft-rajeshkumar-mmusic-gpmd-03.txt and suggested some changes. The authors are considering these, and will produce an update.

Colin Perkins has updated the revision to SDP
(draft-ietf-mmusic-SDP-new-15.txt) to reflect IESG comments, implementing the changes suggested at the 57th IETF meeting. The working group was urged to review the draft to make sure the latest changes haven't broken anything. Some discussion took place:

* There was a question on the time scale for SDP-new approval. The
   chairs expect an immediate WG review, then off to the IESG.
   Volunteers were requested for an in-depth review. They were asked to
   send an E-mail to Joerg to indicate that they were volunteering.

* Jon Peterson <mailto:[e-mail]> indicated that he was
   still worried about the "k=" line text. The problem is that the
   existing text has a normative dependency on informative text:
   "SHOULD NOT use in absence of <informative refs>".

* There is a problem with the text media type: it's widely used, and
   referenced in RFC 2327 <http://www.ietf.org/rfc/rfc2327.txt>, but
   got missed from the original IANA registry for SDP top-level
   types. We could do it indirectly by putting it into SDP-new.
   Interested parties are asked to send text to be added to sdp-new for
   the purpose. Future SDP extensions are strongly discouraged by the
   WG charter.

* Semantics are undefined for multiple "m=" lines with the same port
   and "c=" The interpretation should go into the SDP-new draft as a
   clarification. There are minor implications on the offer-answer
   examples. Gonzalo Camarillo <mailto:[e-mail]>
   sent some text, but for a different case (hierarchical
   encoding). Flemming Andreasen <mailto:[e-mail]> proposed
   that we simply prohibit this construct. The meeting agreed to the
   prohibition.

The source filter (draft-ietf-mmusic-sdp-srcfilter-05.txt) and comedia
(draft-ietf-mmusic-sdp-comedia-05.txt) drafts have been reviewed by the area director, and need to be updated. The new SDP bandwidth parameters
(draft-ietf-mmusic-sdp-bwparam-05.txt) are with the area director, and an IETF last call is expected shortly.


Internet Media Guides
---------------------

Requirements:

Yuji Nomura <mailto:[e-mail]> discussed requirements for Internet Media Guides (draft-ietf-mmusic-img-req-00.txt). There are lots of changes in the latest revision of the requirements draft. A new background and motivations section has been added. The editor moved in the problem statement from the old framework draft, but shortened it.
Congestion control has been added as a requirement. Security considerations were added. For the next revision:

* requirements will be numbered
* terminology will be modified for consistency
* clarifications have been requested: many more receivers than
   senders; senders continually connected, not receivers; and the
   tradeoff between customization and scalability

The revised draft is coming out in the next few weeks. The authors expect it to be ready for Last Call shortly after that.


Framework:

Pekka Luoma <mailto:[e-mail]> discussed the IMG framework (draft-nomura-mmusic-img-framework-02.txt). This is an individual submission, since it missed the cutoff; a working group draft will be submitted shortly after the meeting. Changes from the last version are as follows:

* The use cases in the latest version of the draft were extended to
   include content-oriented use cases.
* A section has been added to discuss the applicability of existing
   protocols.
* New section 6.3 summarizes the outstanding needs that existing
   protocols do not seem to supply:
   o need for a multicast transport protocol
   o need to specify how to use specific unicast transport
     protocols in this application
   o specification of the "metadata envelope", a new term for an
     existing concept in the framework that gives independence
     from transport protocol and metadata format
   o agreement on the basic metadata models (informative only)

Next steps are an editorial cleanup and a new section outlining what pieces of the work are in IETF scope (the transport protocols and transfer envelope) and out of scope (the data models and application specific metadata). It was suggested that an IMG metadata identifier is needed, likely a URI to differentiate between complete specification, delta, and filter. Jörg suggested avoiding the term "metadata" altogether, since it causes confusion.

Magnus Westerlund <mailto:[e-mail]> remarked that this was not exactly a framework document. Colin suggested an offline discussion on this point. Magnus will comment by E-mail.

Rod Walsh <mailto:[e-mail]> indicated that whether changes use the same syntax as the original announcements is still an open question. It is not clear how reusable the syntax may be.

Target is to have WG Last Call in December.


Other issues

Rod Walsh outlined some open technical issues and design choices relating to the IMG work:

* There are a number of design choices for transport protocols; for
   multicast, ALC/FLUTE is a very good candidate.
* The Subscribe (unicast) model can be handled by SIP and SIP events.
* The Metadata Envelope could be: a. XML file/wrapper, or b. header
   extension of transport protocols. Both?
* Data types and channelization: could correlate data type and
   transport channel? Or could divide delivery over multiple channels?

There is a middlebox authentication and integrity issue, since a middlebox could invalidate the sender signature in some cases (by performing header modification). Various possible solutions exist:
trusted middlebox; middlebox could inform the sender of its change and request re-signing; middlebox could sign the data. Jonathan Rosenberg <mailto:[e-mail]> asked whether in this discussion "middlebox" connoted a NAT or firewall, or whether it simply meant some router in the abstract? Rod confirmed that the latter meaning was intended. Jonathan advised him not to call it a middlebox, to avoid confusion.


Alternative IP versions for SDP
-------------------------------

Gonzalo Camarillo <mailto:[e-mail]> outlined the Alternative IP Versions Semantics for the SDP Grouping Framework (draft-camarillo-mmusic-alt-02.txt). The proposed IPV extension is backward compatible. Dual-stack hosts are strongly encouraged to implement IPV. The question is whether to make it a WG item?

Flemming Andreassen suggested that text was needed to clarify the relationship to ICE. He noted that the key point of the extension is to avoid establishing multiple media streams. That said, could the extension be applied to abstract properties, beyond IPv4 vs IPv6?
Gonzalo confirmed that it could. Jonathan Rosenberg affirmed that the draft does need text to make the relationship to ICE clear. It was suggested that IPV may not be the appropriate name.

The consensus of the group was to make this a WG draft.


Source and Sink SDP attributes
------------------------------

Gonzalo Camarillo <mailto:[e-mail]> discussed SDP source and sink attributes (draft-camarillo-sipping-transc-3pcc-00.txt).
This draft came from the transcoding design team in SIPPING. It deals with a problem in the routing of media types, which is really a service location problem.

Jörg suggested that this was really a small subset of the XCON WG topic area. The draft raises a potential problem: signalling by SDP could conflict with other media policy mechanisms. Gonzalo agreed that the team would clarify whether should use the more general mechanism or whether this one is justified.


Security Descriptions
---------------------

Flemming Andreassen reviewed the changes in the latest revision of the security descriptions draft (draft-ietf-mmusic-sdescriptions-02.txt).
The draft has been generalised into a core framework and an SRTP specific part, and numerous editorial changes and clarifications have been included. In detail, the changes are:

* offer/answer highlights differences between unicast/multicast and
   the initial/subsequent offer
* rekeying is addressed via offer/answer; everything can be changed
* additional rules and considerations for communicating the SRTP SRC
   parameter
* removed the SRTP "use" parameter, which is now inferred from context
* added Window-Size Hint and <From,To> to SRTP profile
* more rules for extensions...
* updated IANA considerations and grammer

There are still four open issues. Issue 1 was with multicast:

* Shared vs. per-participant key?
* When a key is shared, the streams need unique SSRCs per destination.
* If per-participant keys are used, each participant has to convey
   his/her key separately.
* How to support for hierarchical layered encoding schemes is
   another multicast issue.

Flemming was not sure there is a single good solution. The proposal was made that multicast streams should be left for further study, and not included in this draft. Jon Peterson wondered if we had found the logical dividing line between unicast and multicast. Jonathan Rosenberg wanted to be sure the solution is mature before deciding this. Jörg indicated that he would like to progress the draft, since it addresses fairly urgent issues. There was agreement that it was reasonable to leave multicast for further study.

Issue 2 was several problems with respect to the SRC parameter. Most of them are multicast based, hence can be left aside for now. There are still the questions of:

     * how many crypto contexts can sdescriptions establish?
     * handling SSRC collisions.

There was a suggestion to remove the SSRC part and support single context only. However, Magnus Westerlund pointed out that you can get multiple SSRC from the same host. The decision was therefore to keep the SSRC part in the document for the moment.

Issue 3 (on Flemming's slides) was purely multicast, and so was skipped.

Issue 4 was the "Use" parameter which was removed, since it led to complexity and could be inferred from context. Is there any need for it?
No feedback from the room - please read and comment.

Flemming expects to provide an update by December. There are no other known issues. Should it go to WG Last Call? Need volunteers to give it a thorough review. Magnus volunteered on the spot. Jon Peterson is to organize as Security Area review.


Security Preconditions
----------------------

Flemming Andreassen outlined
draft-andreasen-mmusic-securityprecondition-00.txt on security preconditions. The problem: an ambiguity in security description selection. There is a need to block sending until the ambiguity is resolved. Should this be a WG work item?

Gonzalo Camarillo suggested the WG look at RFC 3329 (Security Mechanism Agreement for the Session Initiation Protocol (SIP)) as a model to ensure not they are not introducing a security risk. Jon Peterson suggested the WG look at the possible use of security associations between hosts. He argued against the presence of security preconditions in RFC 3312 <http://www.ietf.org/rfc/rfc3312.txt> because of bootstrapping concerns. He was trying to recall detailed arguments: we had better look at the archives.

Resolution: think about it a bit more.


Interactive Connectivity Establishment
--------------------------------------

Jonathan Rosenberg discussed ICE (draft-ietf-mmusic-ice-00.txt), which was accepted as an MMUSIC work item in Vienna. Since then, the draft has been rewritten to make it protocol independent:

* generic session establishment protocol;
* defined semantics in terms of that protocol;
* ICE compliance defined in terms of mapping to generic protocol;
* showed mapping for SIP (RTSP and H.323 are other possibilities,
   for future work)

Another change is that it is necessary to know, through configuration, which is a public TURN relay (there may be non-public ones; public one is default). ICE now uses the TURN SEND mechanism to tell the relay to send a packet to a particular address-port; this can only be used before lockdown and is needed in inter-enterprise cases.

Jonathan walked through a call flow. Magnus was concerned about a packet loss case after lockdown, before return to client. Jonathan will add a case to cover this. A question was asked: can a binding be removed? TURN can, but not ICE. Lockdown cannot be removed: keep things simple. In the rewrite, Jonathan removed the massive call flows section from the draft:
SIP usage is not the point.

Open issues include getting TCP to work (needs a connect method, and there is the issue: demultiplexing of STUN and data on the connection - perhaps try to avoid it by restricting functionality) and prioritization of addresses, basically pushing routing to endpoints. Is there a better way? Flemming Andreasen, without being specific, suggested that there may be something in the middle that can handle routing better.

Issues to be addressed:

* RTSP mapping? Jonathan lacks expertise and time...

* Sequential send attempts: Magnus suggested to do the semantics only
   once, but Jonathan warned that we must not make assumptions about
   topology.

* Use of multiple STUN servers? There was discussion on extra round
   trips. Jonathan indicated he would be pleased to see a better
   solution. There are tradeoffs: effficiency vs. reliability and
   safety. We can continue to think about optimizations (such as
   assuming the RTSP server is on the public network), but with great
   care.

* Is it OK to have username/password in clear?

* SDP ALT parameter conflict with 3GPP: Jonathan will fix. Jon
   Peterson noted that he wouldn't mind more warning from 3GPP. The
   IESG is working on a liaison process to achieve this.


RTSP
----

Magnus Westerlund presented a number of changes incorporated in the latest draft version of RTSP (draft-ietf-mmusic-rfc2326bis-05.txt).
Further changes have been agreed, but are not yet documented:

* Implicit Redirect using new 3xx code to get SDP for supporting
   terminals. A feature tag will associated with this for backward
   compatibility.
* Address class in "c=" needs to be checked.
* Caching of methods is unspecified
* Aggregate control URI deriving will be unspecified
* Clarify the usage of SDP "a=range" for TiVo type of devices
* The server MAY close the TCP connection after receiving the 2xx
   message for a REDIRECT request
* To write something about request to response time limitations.
   Keep the specification simple, details to be worked out.
* ABNF to be collected in a single chapter
* Issues with changing transport parameters using SETUP
* Should the Location header work as base URI for requests with
   REDIRECT without SESSION header
* Request/response time is not limited; needs clarification

There are few open issues, but lots of editorial stuff to clean up. The team will try to edit out all known bugs by the end of year. A clean-up review can be held from January to March, with WG Last Call by March.
The teleconferences will continue, starting on 3rd December.


RTSP NAT
--------

Thomas Zeng <mailto:[e-mail]> discussed RTSP NAT traversal (draft-ietf-mmusic-rtsp-nat-01.txt). There is still lots of work to do on the -01 draft based on Vienna comments, but work on the core RTSP spec took priority. Current focus is to clarify the requirements:

* MUST work for all flavors of NAT, including symmetric
* MUST work for firewalls, including those with ALGs
* SHOULD have minimal impact on clients in the open and not dual hosted
* SHOULD be simple to use/implement
* SHOULD be secure

Jonathan cautioned on the wording of requirements with respect to
firewalls: make sure the aim is to support administrative control.

There is an issue with dual-hosted clients. Thomas proposed to add a mechanism to support them: many RTSP servers won't allow such clients, to prevent DDOS attacks. Jon Peterson suggested that the most important task at hand is to explain the problem in great detail.

Moving forward the next revision will clarify "statement of intention"
and provide list of requirements. Will also remove any solutions requiring protocol extensions to a separate draft. Jonathan noted that some mechanisms can be provided on the basis of "required to implement, not required to use"


RTSP END-OF-STREAM proposal
---------------------------

Thomas Zeng discussed the END-OF-STREAM proposal for RTSP (draft-zeng-mmusic-rtsp-end-of-stream-01.txt). Background: RTCP BYE is awkward; would like to be able to reuse SSRC. Lately the RTSP team has been finding a requirement to push various items to the client:
END-OF-STREAM, session descriptions and updates, error events. Some earlier drafts have been written in the area.

Strawman proposal: extend RTSP, adding a Server-to-Client method with feature tag. There was a recent suggestion to use ANNOUNCE for the End-of-Stream application. Should this be generalized for other information? Tom Marshall suggested using a SET parameter. Jörg didn't think the semantics felt right.

Regarding the strawman proposal: Jörg would like to avoid having to respecify connection management for the Server-to-Client direction. This was more a matter that the client should keep the connection up to receive notifications.

Thomas provided an example of possible syntax. Magnus expressed a concern with the "bytes" specification in Range; this is a conflict. The example will be cleaned up.

The next step is expand scope of draft to cover ANNOUNCE as an extension of the core specification. Should this be a WG item? Magnus and Colin both suggested further work before making this decision. We can decide on the mailing list after the next revision. We might consider pulling back this capability into the main specification.



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



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