Subject: Draft MMUSIC Minutes

From: Joerg Ott <[email-masked]>
Date: Sun, 4 Apr 1999 22:22:41 +0200 (MET DST)

Folks,

please find attached the draft minutes for the MMUSIC WG meeting in
Minneapolis.  Please send comments in asap.

Ruth, Eve, Mark, and Joerg

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

Draft Minutes of the MMUSIC WG
==============================

Reported by Mark Handley and Joerg Ott

The authors would like to thank to Colin Perkins for the notes.

The MMUSIC WG met once at the 44th IETF, on Wednesday morning 9.00-11.30.
Jorrg Ott briefly introduced the agenda for the meeting, virtually all
items relating to the SIP specification itself and to extenions to it.
The meeting agenda was set up to allow for high bandwidth discussion of
the major issues that surfaced on the mailing list since the last IETF.
Mark Handley briefly reported that SIP was now published as RFC 2543
and it was augmented that the formal SIP bakeoff is scheduled to
happen on 8/9 April 1999 at Columbia University, New York.

Jonathan Rosenberg introduced the concept of caller preferences for
SIP-based calls.  Caller preferences constitute one component of the
earlier SIP call control I-D that has been split up.  Caller
preferences allow a caller to indicate preferences where and how to
reach a callee (e.g. location, media types, etc.), control proxy
behavior (forking or not, etc.).  However, they are only hints to a
callee's proxy that may but need not be followed.  While a callee's
preferences are conveyed to the SIP proxy in the REGISTER message,
caller preferences only apply to a certain call and hence should be
passed in the INVITE message for this particular call.  There was
significant interest in the group to take this up as an MMUSIC work
item.

Steven Donovan introduced the various SIP issues that came up on the
mailing list since the last IETF.  SIP session timers are found to be
needed to allow removal of per-call state in stateful proxies in
special cases of call termination (e.g. no BYE sent, BYE lost,
endpoint crashed).  A calling endpoint would include a timout for the
call state in its INVITE message and subsequently extend this timeout
if it is about to expire before the call terminates.  There was
substantial discussion but no final conclusion could be reached and so
this issue will be taken to the mailing list.

A second issue is the proposal to add a new method to SIP called
"INFO" to allow carrying ISUP payloads transparently across an IP
network.  This provoked controversial discussion with very different
viewpoints: Some considered this to make use of SIP as a transport;
instead, SIP should be used to indicate the presence of a separate
transport as defined by the SIGTRAN WG.  Others felt that SIP
delivering a bag of bits transparently through an IP network may cause
interoperability problems at the edges (since different dialects of
ISUP do exist); the gateways should rather (partially) interpret the
contents of the ISUP messages (which may be required for some ISUP
functions anyway) and transcode parts of the ISUP messages into SIP
messages.  Such as extension of SIP, however, might gradually turn SIP
into a telephony-specific call/conference control protocol rather than
a protocol for setup and teardown -- which would probably be the task
of a different protocol.  The issue was not revolved during the
meeting and hence this discussion needs to be continued on the mailing
list.

A third problem identified is how to allow for voice feedback from a
(PSTN) gateway to be propagated to a SIP endpoint before the "200 OK"
response is received.  Various proposals have been made on the list
which were discussed at the meeting.  The one presented during the
meeting was sending a 183 response to include a temporary SDP
description of the media source so that media streams can start
flowing.  An alternative proposed on the list was a nested INVITE from
the callee's side (more precisely: the entity initiating transmission
of media streams prior to 200 OK) back to the caller to create a
temporary second session used only for this (audible) feedback.  No
conlusion was reached during the meeting; discussion will continue to
be discussed on the list.

Finally, a specific multipart encapsulation message format for SIP
message bodies was proposed to include an SDP description, an ISUP
message part, and e-commerce information -- all of which are optional.
It was commonly found that no specific multipart format should be
prescribed and rather the generic multipart message format should be
used in order not to restrict future extensibility.  This rather new
item will also require further discussion on the mailing list.

Jonathan Lennox gave a brief presentation on the usage of SIP as
transport for scripts of the Call Processing Language (CPL).  In the
meeting of the IPTEL WG a day earlier, it was found that it is not
up to IPTEL to define how to carry CPL scripts in any possible transport
but rather that the precise mechanism should be left up to the group
responsible for designing the transport itself.  This was primarily
a heads up presentation for a possible new work item.

Finally, the working groups chairs proposed their view on how to deal
with SIP-related issues in the context of the MMUSIC WG: generic SIP
mechanisms as well as revision/extensions/corrections of the base SIP
spec are supposed to be included in MMUSIC while applications of SIP
(such as the PINT profile) are out of scope.  A borderline case
constitutes IP telepony and related specifications.  In any case, the
MMUSIC WG will decide on a per case basis in consultation with the ADs
whether or not to take up certain tasks, but the aforementioned
principles will serve as guidelines.

With respect to the future evolution of the Session Announcement
Protocol (SAP), Mark pointed out that Colin Perkins from University
College London (UCL) joined the team of editors.

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 5 Apr 1999 16:40:47 -0500

Excellent minutes, Joerg. Good work.

One minor contention:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Joerg Ott
> Sent: Sunday, April 04, 1999 3:23 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; Joerg Ott
. . . .
> meeting and hence this discussion needs to be continued on the mailing

The INFO method is intended not to support ISUP, but is intended as a
general mechanism for doing mid-call signaling that does not involve a
parameter change (as would be handled by a new INVITE). This is the same
problem as was diccussed previously in the context of SUBSCRIBE/NOTIFY
methods. Trasnporting mid-call ISUP messages is just one application of an
INFO or NOTIFY method.

I suspect that the group bogged down on the example that Steve used to
demonstrate the INFO concept (ISUP), not on the general requirement for
mid-call messaging. As recent discussion in PINT and otherwhere indicates,
mid-call signaling is useful in many scenarios.

--
Dean