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. Joerg 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 now has been published as RFC 2543 and 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 an 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 resolved 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 conclusion 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.