Revised MMUSIC Minutes

[Joerg Ott <[e-mail]>]

Folks,

please find below the revised MMUSIC minutes.

Thanks to Dave Thaler who pointed out a number of small issues
that should be fixed now.

You can find the slides and information on the new MMUSIC mailing
list at

         http://www.dmn.tzi.org/ietf/mmusic/

This page is still rudimentary but should improve over time
(the set of current drafts should be up there next week).

Comments and suggestions should be sent directly to me.

Please also let me know (via private mail) which other links should
be included on the page.

Joerg

------------------------------------------------------------------

Revised Draft MMUSIC Meeting Minutes
====================================

Prepared by Tom Taylor and Joerg Ott.
Many thanks to Tom Taylor for taking extensive notes.

MMUSIC met on Thursday afternoon and was chaired by Joerg Ott. 


1. Agenda bashing 
================= 

The proposed agenda was accepted. 


2. Status Report (Joerg Ott)
============================

The revised charter is coming.  The mailing list is moving to
[e-mail].  The mailing list management uses majordomo. 
Participants will have to subscribe explicitly -- there will be no
automatic transfer from the confctrl list.  For some time to come,
mails sent to [e-mail] will be automatically forwarded to
[e-mail].


3. SAPv2 (Colin Perkins) 
========================
(draft-ietf-mmusic-sap-v2-06.txt) 

Status: Colin had thought SAPv2 was ready for Last Call after
Washington, but the WG Last Call brought out lots of issues.  One issue
remains open.

The following changes were made:
* The timer reconsideration algorithm was changed to match the one
  used for RTCP.
* The timeout field was removed (was used only for encrypted SAP).
  As it now stands, a receiver either understands the payload or the
  announcer sends an explicit delete, or the receiver times out the
  announcement because it has not heard of it for some time.
* A number of editorial changes were made to the spec, including

  cleaning up the terminology used in the document.
* All authorization schemes are now optional. 

The open issue: how is authentication done?  In the past, it was by
means of authenticated transport.  The suggestion now is to use an
authenticated payload instead.  Colin pointed out that SAP is
independent of the payload, so it is possible to authenticate the
sender independently of any announcements.  Mark Handley saw this as a
key point: SAP is meant for use with proxies who don't necessarily
understand the content.  Finally, it is not just the payload but also
the SAP operation (announce vs. delete) that needs authentication.

The meeting agreed that both payload authentication and transport
authentication are useful (and may be used alone or in combination),
although transport authentication is preferable.

It was agreed to issue a new WG Last Call immediately after the IETF.


4. The SAP Server Access Issue 
==============================

SAP is really a server-to-server protocol.  A SAP server access
protocol is also needed.  Amongst other things, this would allow a
client to iniate an announcement and to receive selected
announcements.

Some people use HTTP for this purpose, others LDAP.  It would be nice
to have current practice documented.  Colin noted that SAP gives the
same scope to announcements and to data, where HTTP does not.

There is a server location problem and a  server communications
problem.  The latter can be solved in various ways once the location
problem has been solved.

A volunteer is requested to compile a current practice document. 


5. The Directory SAP Media Type (Ross Finlayson)
================================================ 
(draft-ietf-mmusic-sdp-directory-type-00.txt) 

The SAP directory has a group address and port; hence it can be
treated like any other media session.  In particular, it can be
advertised using SDP.

Currently the draft specifies one transport: "SAP".  Others such as
"LDAP" are possible.

"Directory" is not a top-level MIME type.  Other possibilities don't
seem to be quite right.

Aside from this, the issues are generally the same as for other media
types: 
* lifetime 
* announcers within the directory session depend on continued
  advertisement of the directory
  - announcers can participate in the advertisement of the directory 
    - have to be careful about extension of lifetime 
    - not a problem: announcer propagates the life of the directory 
  - single announcer may be simpler. 

There are implications for SDP proxies (between SAP and some other
directory management protocol or firewall).  It is unscalable for the

proxy to traverse the entire graph of directory sessions.  The proxy
should open and read only the useful directories.

The question was raised: where is this work leading?  It would seem to
be material for an Experimental RFC, but the future of SAP itself is
in question.  Is it worth working on enhancements to SAP?  Comments
suggested that the work could be valuable, and could be useful even
without SAP.

The consensus was that the WG should accept the work item, with a view
to producing an Experimental RFC.


6. Expressing Source Filters In SDP (Dave Thaler)
=================================================

Source filters are needed for single-source sessions in 232/8.  They
are also needed for other Include-mode sessions.

The authors presented two possible alternatives that would allow
applications to express source filters in SDP:

  (A) a new addrtype 
  (B) a new attribute name 

A reminder on the latter: the SDP specification mandates to ignore an
attribute if it is not understood.   Also note that c= and a= lines
cannot be intermixed.

Source filters are supposed to work for include mode, i.e. explicitly
listing the allowed sources, as well as for exclude mode, i.e. listing
those source from which data shall not be received.

Is is noted that option (A) is not backward compatible and won't work
in the exlude mode.  Option (B) is backward compatible as legacy
implementations that do not understand the new attribute will not
cause problems.

The authors propose option (B) to be pursued and presented a number of
examples for using the new attributes "a=excl:" and "a=incl:".

There is a question whether the filter should be a session-level
attribute.

To process the attribute, it is necessary to copy information out of
the c= line and apply the filter.  If the receiver ignores the
information, it will try to join the group normally; this may not
matter.

Jonathan Rosenberg saw an application to source authentication in SIP.

Ross Finlayson suggested that it would be much neater to put all of
the information on the c= line, since it all relates to transport. 
The counter-argument was that, since it is not mandatory for the
feature to work, the attribute approach is better.  Steve Casner saw
the filter as a media-specific attribute, so the suggestion was that
both representations may be needed.

The list will be asked to determine whether one way of representing
the information will be chosen or both allowed.

A new question: can there be domain names, or must all the entries be
addresses?  For IN IP4, only addresses are allowed.

Can address types (IP4, IP6) be mixed?  Such mixing is part of the a=
proposal.

How to handle multiple groups with the same filter? 

* group range? 
* multiple c= lines? 
* would wildcard be OK for the address part? 

Steve pointed out that the star notation could be used, even with a
single c= line.

SAP is limited to 1 kilobyte payload, which translates to around 15
IPv6 or 39 IPv4 addresses without compression.  There was a
suggestion: remove the limit from the specification.  It was noted
from the audience that no implementations are known which enforce the
limit.

A single-source session should have a=recvonly, but one cannot assume
the reverse.

The above points need to be written up.  Mark Handley qualified this,
saying that it should be written up outside of the SDP specification,
since it is attribute-based.  To add it to the SDP specification
would cause the latter to recycle to Proposed status.  Allison Mankin
suggested that point needs discussion.


7. Specifying ATM Connections In SDP (Tom Taylor) 
=================================================
(draft-rajeshkumar-mmusic-sdp-atm-01.txt) 

In the absence of the author, Tom Taylor ([e-mail])
presented the syntax for ATM connections proposed in the document. 
These are meant to be used specifically for narrowband telephony
running over ATM AAL1 and AAL2 connections.  The issues dealt with are
bearer identification, specification of payloads over ATM (reusing the

RTP codes), and specification of ATM QOS parameters.  The main changes
to SDP include specification of the "ATM" nettype and new ATM
addrtypes on the c= line, m= lines modified to take account of ATM
transport and ATM-based profiles, and a number of new attributes to
carry bearer correlators, negotiate codec selection, and transmit
various ATM-related parameters.  The "$" wildcard notation is
introduced on the m= line to designate portions of bearer identifiers
to be selected by the recipient of the session description.

Mark Handley judged the principle of SDP extension for non-IP
transport to be acceptable.  The c= syntax looked OK.  The attributes
need a consistent naming convention or they will get out of hand. 
There was a suggestion that the authors could learn from the RTSP
experience.

Alison undertook to consult with the Transport Area Directorate on
whether the MEGACO or the MMUSIC WG should be prime for completing the
document.

Joerg Ott summed up by saying that such work should meet these criteria: 

* conformance to the rules of SDP syntax 
* no duplication of effort -- look for more general solutions where
  possible.

The meeting expressed no opposition to allowing the work to proceed. 


8. Codec Capabilities Attribute For SDP
=======================================
(draft-beser-mmusic-capabilities-00.txt) 

An SDP media announcement has multiple interpretations: it could be an
expression of capabilities, or it could be a definitive selection of
parameters.  One consequence of this ambiguity is that it is unclear
how much payload bandwidth to reserve.  This quantity is needed to use
RSVP reservation.  The proposal is to add an a=cap: attribute to
indicate capabilities as opposed to selections.  The list of payload
types within the attribute would be ordered from most to least
preferred.

The one comment was that resource reservation and capability exchange
are two different operations.   

9. Caching In RTSP/RTP Servers (Mark Green) 
=========================================== 

The topic is one of dynamic replication of content to bring it nearer
to users.  Mark presented a list of issues to be considered when
caching RTSP/RTP:

* transfer loss 
* transform loss 
* cache coherency 

* AAA 
* copy protection. 

Transfer loss makes it difficult to create a perfect copy.  This is a
bigger problem with UDP transport than with HTTP, but with UDP it is
easier to maintain cache coherency.

There are a couple of approaches.  With the packet recorder approach,
loss is a problem.  This is an RTP issue.  The file transfer approach
uses RTSP/TCP.  Transfer is more reliable, but the cache needs to know
the file formats.

One possibility is RTSP/TCP to tyransfer RTP, with an additional
metachannel to carry retransmissions.

Copy protection is a concern with the possibility of rogue caches
making illegal copies.

Comments: Rogue caches are not an RTSP issue.  The metachannel would
have a special format which would depend on the data and file format
being transferred.  The author agreed that this was so, but hopes that
a reasonably general set of classes of transfer can be defined.

Further discussion is invited on the list.   


10. RTSP Extensions: Additional Transports and Performance
    Enhancements (Sean Sheedy)
==========================================================
(draft-sheedy-mmusic-rtsp-ext-00.txt) 

The proposed extensions are based on existing implementations at
Oracle and nCube.  These support a commercial broadcast environment
featuring high bit rates, simple endpoints, high QOS, MPEG-2 encoding,
and low latencies in the order of 250 ms.  The server topology
includes bridging servers along the path of transmission.

The authors found it necessary to define new transports, so transport
extensions are proposed, along with new profiles beyond AVP.  Addreess
extensions were required to make addressing unique, since DOCSIS does
not allow an easy mapping between the client IP address and the

optical server.

Several optimizations were added for faster operation.  Setup and
tear-down are critical: setup should happen within 1 s, play and
rewind within 200 ms.  The optimizations included:

* the possibility of changing the URI within PLAY, to allow reuse of
  transport 
* wildcarded URIs to represent the currently active presentation,
  although these have limitations because of the potential ambiguity
  they introduce
* bandwidth reservation 
* two options for over-riding queued PLAY commands: Play-Now, and
  No-Flush.

The optimizations introduced several issues.  For example, how can the
client tell when the end of the stream has been reached?  The proposed
solution is to provide a server callback: the server sends a request
to the client when state transitions occur.

The authors are sharing this information with an invitation to work on
standardizing the suggested extensions.  The question was raised: what
does "extension" mean?  Joerg stated that all extensions to a protocol
must be backward compatible.   He also asked the authors to coordinate
with the MEGACO work on ATM addressing to arrive at a single general
purpose extension.