[MMUSIC] Draft MMUSIC Minutes

[Joerg Ott <[e-mail]>]

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