Subject: Draft MMUSIC minutes

From: Joerg Ott <[email-masked]>
Date: Mon, 11 Jan 1999 00:28:44 +0100

Folks,

attached are the draft MMUSIC minutes of the Orlando IETF.
Please let us know quickly if there are any comments/corrections as we
would like to submit them on Monday.

Joerg

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

MMUSIC MINUTES, ORLANDO IETF
============================
prepared by Mark Handley and Joerg Ott

MMUSIC met once at the Orlando IETF.

Internet Multimedia Conferencing Architecture
---------------------------------------------
Mark Handley briefly reported on the (currently expired) I-D on the
Conferencing Architecture -- this draft has been updated, and will be
resubmitted to the I-D archive shortly after the IETF.  The authors
plan to issue WG last call on this for Informational RFC in January.

SAP and SAP Security
--------------------
Mark Handley presented the status of SAP and the SAP security draft.
The SAP and the SAP Security specifications have been merged into a
single document.  Two major issues arose with respect to the use of
encryption within SAP:

* There has been disagreement between the authors on the use of public
  key encryption algorithms in a mode that effectively turns them into
  symmetric algorithms.  The arguments for and against this were
  presented in the hope of getting consensus from the group.  Little
  feedback was forthcoming.

* Also, there was the more fundamental issue of whether encryption of
  SAP announcements should be supported at all; the motivation for not
  supporting encryption would be to discourage people from misusing SAP
  to announce small private sessions to a potentially large audience;
  instead different mechanisms should be used.  The following discussion
  showed various scenarios that would warrant keeping encryption of
  session announcements.  The group consensus was to at least keep the
  use of symmetric encryption algorithms for now and to allow for future
  extensions to include other algorithms as well.
  [It was also pointed out that some key participants were not able to
   attend the meeting, and hence a follow up discussion on this second
   issue would be taken on the mailing list.]

SAP and IPv6
------------
Colin Perkins presented a modified version of SAP that can support
IPv6.  SAP announcements containing IPv6 addresses are identified by
taking one bit of the MT field to indicate the address type.  The IPv6
SAP address to be used is FF0X:0:0:0:0:0:2:7FFE with X being the four
bit scope value as defined for IPv6.  Along with various scopes, the
proposal also defines bandwidth limitation for SAP traffic.

In his presentation, Colin also addressed the issue of supporting
multiple payload types in SAP, to be identified by a MIME
"Content-Type:" header at the start of the SAP payload
("application/sdp" would be used for SDP payloads but would also allow
for non-SDP payload (e.g. SMIL).  Such a mechanism would also be used
to allow fragmentation of SDP announcements.  On the other side, it
adds complexity and might hinder interoperability.  There was
contentious discussion in the group on the tradeoff between
flexibility and interoperability; no consensus was reached.

A general issue raised by Colin was how to allow joining
e.g. multimedia streaming sessions from a web page.  The proposal is
to reference a SAP announcement (e.g. held in a local cache).  The
corresponding SAP URL could be composed of the announcement
originator's source address and its locally assigned message id
fields; e.g. "sap://128.16.64.45/1234".  A number of people noted that
most current implementations don't correctly fill in the appropriate
SAP header fields, so there may be a deployment problem.  Apart from
this, the (little) feedback received was positive about the concept.
No final decision was taken.

SIP
---
Mark Handley presented the changes to the SIP spec that were requested
by the IESG.  Besides a large number of purely editorial work to
remove ambiguities in the specification, the changes include the
following:

- The UDP backoff timers were changed to prevent SIP control messages
  from potentially causing congestion.
- The DNS lookup rules were changed: MX records were removed, SRV
  records are now optional (since they are defined as an experimental
  RFC while SIP is standards track).
- It was discussed whether IPv6 literal addresses should be supported
  in SIP URLs; as literal addresses seem to be unimportant no changes

  were made to the SIP spec.
- In the past, the SIP specification completely disallowed proxies to
  translate between the short and the long SIP representation or to
  change the message layout.  This is now permitted unless message is
  authenticated.
- While earlier revisions of the SIP spec allowed arbitrary message
  formats to be signed, SIP now defines a canonical form to be used
  with authentication.
- Text was added to precisely define how SIP uses the HTTP basic and
  digest authentication mechanisms.
- The usage of SDP in order to set up asymmetric sessions was
  clarified.  
- The use of the SIP Date field was restricted from allowing any valid
  HTTP date form to only the RFC 1123 form being allowed.

None of these changes were controversial.  The group was asked whether
they believe they need a new WG last call to review these changes.
No-one wanted a new WG last call and so the revised document will be
re-submitted to the IESG.

Reliability for SIP 1xx Responses 
---------------------------------
Jonathan Rosenberg presented an internet draft on SIP provisional
response reliability.  The problem stated is that provisional
responses in SIP are not sent reliably and that this may cause
difficulties for all state machines driven by 1XX responses, for
signaling between gateways, for signaling transport, etc.  The
proposed solution is a SIP extension -- support of which is to be
indicated by "org.ietf.sip.100rel" -- that defines ordering and
reliability for provisional responses as follows: Provisional
responses are extended to carry a sequence number (RSeq); they are
acknowledged by the client retransmitting the original request with an
acknowledgement number (RAck).  Currently, reliability is based on a
lock step mechanism for simplicity.

Jonathan identified various issues when this approach is used with
proxies:
- Proxies may discard provisional responses; hence, end points depending
  on reliable transmission of 1XX responses must be able to request
  that proxies support 1XX reliability; a Proxy-Require header is
  needed to achieve this.
- Proxies themselves may generate provisional responses adding the
  need for hop by hop reliability.
- Forking proxies may receive responses from different branches where
  there is no absolute ordering; proxies must be able to merge these
  responses before forwarding upstream.

Finally, Jonathan pointed out a variety of issues to be discussed.  A
window size larger than one could be used to achieve better throughput
with SIP (at the cost of additional complexity); in conjunction with
this, SIP might need to incorporate congestion control mechanisms and
may use selective acknowledgements to confirm reception of multiple
responses.  The potentially most important issue with the 100rel
proposal is the isomorphism of SIP requests: formerly, the quadruple
(To, From, CallID, CSeq) uniquely identified a request which is no
longer true.

There was a significant amount of discussion in the group, but no
consensus was reached on the technical conclusions to be drawn from
this proposal.  However, there did seem to be resonable consensus that
the problem is worth looking at.  Further discussion will take place
on the mailing list.

SIP CGI
-------
Jonathan Rosenberg presented an internet draft on SIP CGI.  The
motivation for this proposal is the need to program SIP servers to
perform proxying, redirection, forking of calls, modify headers,
perform various kinds of searches, etc.  The idea behind the proposal
is to separate the program logic from the SIP server functionality.
In particular, the program logic could be provided by third parties
and work with many SIP server implementations.  Such a "definition
language" would be targeted at system administrators rather than end
users.  The requirements presented include flexibility, simplicity,
and independence of programming languages.  The proposal presented is
to use CGI which is supposed to match the aforementioned requirements
and is well-established technology.  Benefits of the approach taken
were presented as were the differences between SIP CGI and HTTP CGI.
Also, some details of the operation in conjunction with SIP protocol
operation were outlined.  The group felt that the separation between
SIP server and program logic is basically a good idea, but there was
consensus that defining this is not a work item to be pursued in the
MMUSIC WG.

MPEG-4 and RTSP/SDP
-------------------

Paul Christ presented work on RTSP-based stream control for MPEG-4.
MPEG-4 does not provide simple Application Signaling for media stream
control in version 1; also, there is no accepted "simple"
architecture, nor an accepted transport to convey application
signaling information.  Rather, the mechanisms available from MPEG-4
version are very complex, with many types of streams, many possible
levels of indirection, and a tight coupling of control interactions
and scene syntax and semantics.  As an alternative that may be
considered within the IETF, a control scheme based upon RTSP and SDP
is proposed to provide the required media stream control
functionality.  However, this would require an SDP syntax that allows
to describe MPEG-4 objects (initially); also, an appropriate update
mechanism would be needed to convey changes to the object descriptors
within a streaming session.  Furthermore, some additions to RTSP would
be necessary to provide the functional range desired by the MPEG-4
community.  There was little feedback from the group and hence no
decisions were to address this further within the scope of MMUSIC.

Message Bus (Mbus)
------------------
Joerg Ott presented an update to the message bus, which had been
discussed at the previous IETF.  The major changes include a
modification in the addressing concept -- turning fixed address
quadrupels into tagged tuple sets -- and a significant extension of
the semantics specifications (which have not yet been turned in as an
Internet Draft).  Joerg reported that they are now two implementations
available and that also prototypes of media and control tools running
Mbus emerge.  Work is being continued on further semantics definitions
for building gateways, local capability exchange, and to provide hooks
for easily integrating policies for local decisions in MBus-based
systems.

There was significant discussion about whether this should be modified
to permit wide-area operation (currently it's purely intended for
local coordination).  The authors are reluctant to turn it into a
general purpose conference control protocol since the perceive
functionality and semantics for local coordination to be different.

Finally, it has not yet been decided whether this should be an MMUSIC
work item or not.  The authors propose to pursue this work further and
provide an update at the next IETF when more experience is gained and
the proposal is more complete and then revisit the issue how (if at
all) to deal with the Mbus as a work item in the IETF.

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 11 Jan 1999 14:37:37

>Message Bus (Mbus)
[...]
>all) to deal with the Mbus as a work item in the IETF.

As I noted in the Chicago (I think) IETF, I'd like to see a message
bus-like protocol become a work item in the IETF (probably MMUSIC).
However, to avoid the "kitchen sink" effect, we should try to keep its
focus and applicability limited at first (e.g., to media device/conference
control on a low-latency LAN without packet reordering), while keeping an
eye out for future extensibility.

I'd also like to see the current "mbus" draft split into two separate
documents: (i) a general "requirements and architecture" document, and (ii)
the author's description of their own protocol proposal.  I hope that we
can relatively quickly adopt document (i) as a work item, and come to
consensus on it, before moving on to specific proposals (such as document
(ii)).  At this time, however, only document (i) should be given the
"draft-ietf-mmusic-..." prefix; specific protocol proposals should remain
named as "draft-<authors>-...".

	Ross.

---

From: Peter Parnes <[email-masked]>
Date: Tue, 12 Jan 1999 00:57:47 +0100

Talking about message protocols I just wanted to point out my Control Bus 
protocol that we are using within several of our applications/products. It is 
a general agent messaging protocol with support for resource discovery of both 
available agents that can be controlled and how they can be controlled. I.e., 
which control points that are currently available. It is of course based on 
IP-multicast (what else :-) but is designed to run over any reliable transport 
(unicast or multicast).

More information is available from http://www.cdt.luth.se/~peppar/infocom99/ 
(general framework) and http://www.cdt.luth.se/~peppar/im99/ (implementation 
stuff).

Perhaps some of it is useful in the context discussed here?! 

/P