2.7.8 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 15-Jun-99

Chair(s):

Ruth Lang <rlang@sri.com>
Eve Schooler <schooler@cs.caltech.edu>
Mark Handley <mjh@isi.edu>
Joerg Ott <jo@tzi.uni-bremen.de>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

Mailing Lists:

General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail

Description of Working Group:

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) is chartered to develop Internet standards track protocols to support Internet teleconferencing sessions. MMUSIC's focus is on supporting the loosely-controlled conferences that are pervasive on the MBone today. However, the WG also will ensure that its protocols are general enough to be used in managing tightly-controlled sessions.

To date, MMUSIC has drafted protocols for:

- distributing session descriptions -- Session Description Protocol (SDP) and Session Announcement Protocol (SAP),

- providing security for session announcements -- SAP Security,

- controlling on-demand delivery of real-time data -- Real-Time Stream Protocol (RTSP),

- initiating sessions and inviting users -- Session Initiation Protocol (SIP), and

- managing tightly-controlled sessions -- Simple Conference Control Protocol (SCCP).

In addition, the WG has drafted two informational documents: the first describes the architectural framework for MMUSIC, and the second describes interoperability scenarios for ITU- and Internet-based teleconferencing systems.

The WG's protocols reflect coordination with other IETF efforts related to multimedia conferencing (e.g., AVT, RSVP). In addition, the WG will collaborate with liaisons to ITU standards bodies and industry consortiums as appropriate to ensure interoperable standards (e.g., SIP/SAP/SDP with ITU H.323 and H.332).

The WG has defined two sets of goals -- immediate goals to be accomplished over the next several months, and longer-term goals which will be reviewed and possibly revised after the immediate goals are met. The immediate goals include bringing several protocols to Proposed Standard (SDP, RTSP), or Experimental RFC status (SAP), and to produce Informational RFCs for the informational drafts listed above. The longer-term goals are to bring the remaining protocols to Proposed Standard status (SIP, SAP Security, SAP), to investigate the requirements for a next-generation session description protocol, and to continue the development of SCCP.

Goals and Milestones:

Jul 97

  

Conduct WG Last Call for SAP Internet-Draft

Jul 97

  

Submit a revised Internet Multimedia Conferencing Architecture I-D.

Jul 97

  

Submit SDP to the IESG for consideration as a Proposed Standard.

Jul 97

  

Submit a revised SIP I-D.

Aug 97

  

Submit a revised ITU Interoperability Scenarios I-D.

Aug 97

  

Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol.

Oct 97

  

Conduct WG Last Call for RTSP Internet-Draft.

Oct 97

  

Submit Internet-Draft on Internet Multimedia Conferencing Architecture.

Nov 97

  

Submit RTSP to IESG for consideration as a Proposed Standard.

Nov 97

  

Submit ITU Interoperability Scenarios Internet-Draft to IESG for consideration as an Informational RFC.

Jan 98

  

Conduct WG Last Call for SIP Internet-Draft.

Feb 98

  

Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard.

Apr 98

  

Conduct WG Last Call for SAP Security Internet-Draft.

Apr 98

  

Conduct second WG Last Call for SAP.

May 98

  

Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard.

May 98

  

Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2326

PS

Real Time Streaming Protocol (RTSP)

RFC2327

PS

SDP: Session Description Protocol

RFC2543

PS

SIP: Session Initiation Protocol

Current Meeting Report

Minutes of the MMUSIC WG

Reported by Tom Taylor and Joerg Ott

The MMUSIC meetings took place on Tuesday afternoon, July 13 (1300-1515), and on Wednesday evening, July 14 (1930-2200). The second (informal) slot was scheduled on site to meet the huge demand for air time and to cover the large number of Internet Drafts submitted after the WG scheduling deadline. Virtually all presentations were carried out in the officially announced slot, the second one was reserved for detailed technical discussions and follow-ups from the first session.

The sessions were chaired by Joerg Ott [jo@tzi.uni-bremen.de].

1. Agenda Bashing

The agenda as presented by Joerg was accepted.

2. SAP V2 Status

Colin Perkins [C.Perkins@cs.ucl.ac.uk] presented the current draft
- sap-v2-01.txt. It merges -sap-00.txt, -sap-sec-04.txt, and
- sap-v2-00.txt. Colin provided an overview of the changes reflected in the combined document:

- support for IPv6 has been added,
- directory sessions are now supported,
- a new specification of ports and TTL settings is incorporated,
- recommendations for bandwidth are given,
- now zlib rather than gzip is used for compression,
- payload types have been added to syntax,
- encryption and authentication are supported.

Open issues include:
- Should the SAP document define the SDP syntax for directory sessions?
- Clarification of announcement interval calculations are needed.

Two of these items have the potential to break existing implementations: the port assignment proposals, and the use of zlib rather than gzip. Colin asks for feedback if these will cause real problems.

The intention is to publish SAP as Informational RFC as soon as possible to have proper documentation of existing applications in the field.

3. SIP Session Timer and SIP 183 Session Progress Message

Steve Donovan [Steven.R.Donovan@wcom.com] presented updates on two extension proposals: for the SIP session timer (draft-ietf-mmusic-sip-session-timer-02.txt), and for the 183 session progress message (draft-donovan-mmusic-183-00.txt).

The SIP session timer was discussed in Minneapolis, so this presentation was an update. The basic question at this meeting was whether to proceed with the session-expires concept. After brief discussion suggested that the details still needed refinement, it was agreed to move ahead with the suggested solution in principle, but some aspects still need to be sorted out.

The 183 session progress message is a proposed solution to several problems posed by interworking with the PSTN. Steve reviewed the other solutions that had been proposed and why they had been rejected.

One comment was on the need for SDP to do QOS negotiation. It was agreed that this was a separate topic. On the topic at hand, it was noted that the terminating network cannot be trusted to indicate whether it will return ringing tone. In consequence, the ingress UA should supply ringing indication until it receives content in the media stream.

The Chair remarked that the working group seemed to be receiving a series of disjoint proposals for incremental modification for interoperation with the PSTN, and wondered whether there could be a coordinated effort based on an architectural document. Steve replied that an effort of this sort was in progress.

4. Reliable Provisional Responses; SIP Session Preconditions; SIP Call Control

Jonathan Rosenberg [jdrosen@dnrc.bell-labs.com] presented.

draft-ietf-mmusic-sip-100rel-01.txt:
- Interest in reliable provisional responses for SIP has increased with the work on SIP telephony. In the latest draft, Require: headers are no longer needed; UAs can infer that reliable provisional responses are required by the presence of RSeq and RAck. Some outstanding problems of interactions with reliable requests have been fixed. The current issue is whether the reliability should be provided on an end-to-end or hop-by-hop basis. The advantage of end-to-end operation is that the server knows when the UAC has received the response. This could be useful in the case of the 183 session progress message, to trigger tone insertion from the terminating end. Hop-by-hop operation in contrast requires no new methods, but proxies must process the additional messages.

The meeting agreed that work on reliable provisional responses should go ahead. The Chair noted that at some point the material would have to go into the base protocol document. In the discussion on end-to-end versus hop-by-hop acknowledgements, Christian Huitema raised the point that in ISUP the message sequence is not invariant: one message can subsume another (e.g. ANM means ACM need not be passed on). The Chair noted that there may be a consensus in favour of end-to-end acknowledgements.

draft-ietf-mmusic-sdp-qos-00.txt:
- SIP session preconditions are a new issue. Jonathan noted that a caller might wish to ensure that QOS resources had been reserved and that secure communications had been established before proceeding with a call. In Jonathan's view, these are media-related concerns, and should be negotiated on an end-to-end basis. They should use SDP rather than SIP because SIP is media-unaware and the preconditions could vary by medium. Session preconditions therefore require no change to the SIP model.

A discussant raised issues of key distribution and key escrow. Jonathan argued that these are not SIP issues.

draft-ietf-mmusic-sip-cc-01.txt:
- SIP call control had been removed from the base specification to allow concentration on the latter., Call control itself has been split into caller preferences and call control. A document dealing with the latter has now been reissued. The basic mechanisms proposed are the Also, Replaces, and Requested-By headers. The latest draft provides changes in usage to address the very important issues of security raised with the introduction of third party control. Current work is in the area of the race conditions which can present themselves during the operation of a fully-distributed multi-party call, where each party can independently leave or add new members. The approach being considered is like that of OSPF, distributing state amongst the members of the group. Jonathan listed a number of open issues with this work.

In a broader perspective, Jonathan asked what the goal of the call control work should be. This is probably not material for the base SIP specification. What other services should it cover? Joerg Ott remarked that SIP may not be the protocol to use for conference control. Scott Petrack [scott.petrack@metatel.com] had further issues, discussion of which was deferred to the second MMUSIC session. Steve Donovan noted that the discussion of call feature requirements was useful independently of the mechanisms used to provide them.

It was concluded that call control was definitely an issue worth looking into but also that further investigations are required to determine how to realize such functionality in the context of SIP.

5. SIP-PSTN Interworking

Adam Roach [Adam.Roach@Ericsson.com] presented. The documents he presented are intended to provide a standard set of extensions required to allow SIP to interwork with the PSTN.

draft-roach-sip-isup-parameters-00.txt:
- Indicates which ISUP messages would map into which SIP messages. Building on draft-ietf-sigtran-mime-isup-00.txt, it allows network operators to provide complete end-to-end ISUP transparency, so that information such as billing parameters can be safely conveyed.

draft-roach-mmusic-sip-provisional-media-00.txt:
- Aims to allow media flows before the session has been fully established, as required for a number of PSTN operations.

draft-roach-mmusic-sip-pstn-require-header-00-txt:
- Provides a concise way to call up all of the needed extensions for PSTN interworking at once. One of the extensions mentioned on Adam's final slide was transport of DTMF via SIP signalling. This brought negative comments from Scott Petrack and Christian Huitema.

Steve Donovan remarked that call control services are a separate topic from
PSTN interworking.

6. PacketCable DCS Group Presentations

Representatives of the PacketCable DCS initiative presented a series of drafts dealing with the use of SIP to establish authorization and reserve resources before setting up the user call. The presentations described and justified a number of extensions that would be required in SIP to meet the various requirements.

Architecture (draft-dcsgroup-mmusic-arch-00.txt)

The initial presentation by K.K. Ramakrishnan [kkrama@research.att.com] described the requirements the group was working with and the architecture that had resulted from their work. The key drivers were the desire to provide differentiated QOS, the protection of the network from theft of services, the provision of confidentiality to users, and the ability to operate on a large scale. The key architectural elements are the untrusted SIP user endpoints, the DCS proxies, which are co-located with policy engines called Gate Controllers, and the edge routers AKA Gates, which enforce the policy set by the Gate Controllers.

Call setup is in two phases. In the first phase, the INVITE goes from the originating UA to the originating DCS proxy, from there to the terminating DCS proxy and finally to the far-end user. The completion of this transaction reserves the access resources at each end. The DCS proxies provide tickets to the respective endpoints and at the same time prime the Gates (edge routers) to accept them. The resource setup phase is completed when the originating user initiates backbone resource reservation by issuing a PATH request containing its ticket to its edge router. This modification of RSVP procedure is being submitted as a proposal to the RSVP WG.

The second phase is an ordinary UA-to-UA call, except that each UA also signals its Gate to commit the access resources which have been allocated to it. Extensions being requested for this phase help to provide user privacy and speed the setup of the media path when the called user answers.

Steve Donovan asked if there was always more than one DCS proxy in the path. The answer was that there could be just one. Steve also asked what happens to QOS if there is more than one network between the two user endpoints. This was deferred to offline discussion. There was one further comment, to the effect that the distancing of the DCS proxy from the QOS control point could be an impediment to billing. The authors felt that this point had been covered in their design.

The current DCSGroup drafts are all copyright-restricted. Steve Donovan asked if there were any intent to submit them as fully-available IETF documents. The matter is still under consideration at PacketCable.

Call Setup (draft-dcsgroup-mmusic-resource-00.txt)

Bill Marshall [wtm@research.att.com] talked about the need to speed the setup of the media path when the called user answers in the second call setup phase. The concern is to avoid clipping of the called party's answering greeting. The proposal is that second-phase signalling, and the 200 OK message in particular, should bypass all proxies to make sure that it is received at the calling end in advance of the the called party's media streams. This imposes a requirement that the resource setup phase provide the endpoints with the addresses to be used in the actual call setup phase. A byproduct of this solution is that call forwarding operates like call transfer, with the forwarding entity being cut out of the call path before the call goes through.

One comment was that direct end-to-end signalling cannot operate through firewalls. As a result, the proposed solution works only if just one transport/signalling provider is involved.

Jonathan Rosenberg expressed his doubt that clipping would occur in an IP network, because of the way packetization operates.

[Reporter's note: the remaining DCSGroup presentations on the details of their work were given at the Wednesday evening session, but are reported here in sequence to preserve the narrative context.]

Privacy (draft-dcsgroup-mmusic-privacy-00.txt)

Flemming Andreasen [fandreas@telcordia.com] spoke on privacy issues and how to support them in SIP. Where permitted, it is desirable to present the caller's name and number to the called party. In any event, these must be available to the network to support malicious call tracing. This raises the distinction between caller identity delivery services and presentation services: the former ensure that caller identity is transported to where it is required, while the latter provide the caller with control over what identifying information is presented to the called party.

The DCS Group scenario assumes that the calling UA cannot be trusted to provide caller identity reliably in the Display-Name header. Thus if this information is needed for network purposes, it must be supplied by DCS Proxies, which obtain it by unspecified means and maintain a trust relationship amongst themselves. To control the presentation of caller-identifying information, both at the application level and at the IP address level, the DCS Group proposes an additional SIP privacy header. Flemming also noted a number of other issues which must be addressed to ensure privacy.

There were some comments to the effect that a trust boundary might be crossed before the call is delivered to the called UA. The assumption is that the last trusted proxy in the chain would strip out identifying information as required.

Mark Handley [mjh@aciri.org] cautioned that there are limits to what proxies can do: some fields cannot be touched, or the protocol will fail.

Proxy-to-Proxy Extensions (draft-dcsgroup-mmusic-proxy-proxy-00.txt)

David Oran [oran@CISCO.COM] motivated his discussion by pointing out the need to perform such operations as billing correlation and support of Local Numbering Plan (LNP) services between the two ends of the call. On billing, the DCS Group sees the need for three headers: one to identify the billed party, one to carry billing information, and the third to identify the points where resource usage is being recorded. LNP support optimization requires a new header to cache the results of the initial number look-up so that it doesn't have to be repeated at subsequent proxies. It is clear that the billing headers convey sensitive information, and should be passed over secure links only and not beyond the boundary of trust.

Jonathan Rosenberg expressed the concern that the semantics and procedures for the proposed Billing-ID header are unclear. The presenters accepted the action to provide a better explanation.

Integration of Call Authorization and Call Signalling (draft-dcsgroup-mmusic-call-auth-00.txt)

David Oran also spoke about call authorization. The outcome of call authorization is that gates are opened at the edge routers during the resource setup phase. Coming out of the resource setup phase, the user application at each end needs to know the location of its gate. A proposed new header gives the address of the gate and a token allowing its use. Use of the gate requires an additional protocol between the user host and the edge router -- not intended to be an MMUSIC work item.

Scott Petrack asked when the event records are generated for billing. They are created at four points during the call.

Jonathan Rosenberg expressed his confusion over the relationship between the proposed new Commit/Commit Ack exchange and RSVP. The explanation is that the DCS Proxy should be viewed as also being a COPS Policy Decision Point: it knows which edge router will serve a given user host.

Mark Handley expressed a concern that the proposed solution is too special-purpose: the aspect that requires the proxy to know the gate location is problematic. Joerg Ott added that the proposal makes assumptions about the design of the network. During the discussion of these points, it became clear that the ultimate source of the problem is the desire for direct end-to-end transmission of the 200 OK response during the call setup phase.

Jonathan Rosenberg added his concern that the solution is insufficiently general. He proposed that the list clarify the requirements first before considering the solution. One aspect of this would be to determine what is missing from RSVP.

Mark Handley raised the possibility of a one-day interim meeting to discuss the issues and bring out the background to the proposals. He invited volunteers to host such a meeting.

Distributed Call State (draft-dcsgroup-mmusic-state-00.txt)

Jon Fellows (jfellows@gi.com) proposed a new state header, to carry call state information -- in effect, a cookie. This allows proxies not to retain call state (although they must still keep transaction state). The state information in the new header is encrypted and signed by the proxy. It is sent to the called UA on the resource setup phase INVITE, and passed to the calling UA in the 200 OK response to that INVITE. In support of this, a "private" extension of the Host and User-Param headers was also proposed.

Jonathan Rosenberg kicked off a long discussion on the rules for use of cookies. Mark Handley noted that two different states are involved: one dealing with the call itself, the other with the relationship between the caller and the service provider. David Oran responded that the Working Group concern should be with the mechanism itself: the rules for its use cannot be written into a protocol document.

Douglas Clowes [dclowes@OZEMAIL.COM.AU] asked what would happen if the UA failed to send back the cookie at the end of the call. The answer was that some billing information is contained in the edge router. The cookie is not needed to generate the call termination record.

Miscellaneous Items

A miscellaneous group of additional proposals ended the DCS Group presentation. One was to drop the "@<gateway>" part of the sip: URL to signify that the given address is a telephone number. It was pointed out that this is a general problem, and could be handled using the proposed tel: URL (see draft-antti-telephony-url-0x.txt).

Another proposal was for an OSPS/TOPS header to support operator break-in to a call. It was noted that such a header would need authentication.

The DCS Group also would like to have the proposed Also and Replaces headers.

Overall, the long discussions of the DCS group proposals showed significant interest in their work. Types of questions posed revealed, however, that not all the objectives of and motivations for DCS group proposal were already fully understood from the Internet Drafts, but understanding grew during the session. It was agreed that presentation of further detail as well as background information is necessary to allow members of the MMUSIC WG to better contribute to the work.

7. Capability Negotiation Beyond SDP

Joerg Ott [jo@tzi.uni-bremen.de] gave a brief presentation of draft-ott-mmusic-cap-00.txt. He noted that SDP falls short of the requirements for multimedia session capability negotiation, while H.245 is too complex. A capability negotiation protocol should support more complex descriptions than SDP currently can, particularly including mutually exclusive sets of alternatives. It should be easily extended and easy to parse. There should be a migration path from existing capability description protocols. Finally, it should be possible for an entity between the exchanging endpoints to find the intersection of the capability sets presented by them without understanding every capability in detail. Joerg summarized the proposals made by himself and his colleagues to meet these requirements.

It was noted that the procedures for use of the suggested q-preference factors was unclear. Joerg accepted that, pointing out that the intent at this stage was to indicate the possibilities for development of the protocol rather than a complete solution.

Finding the intersection of the capability sets was viewed by the audience as a matter of information compression. As such, the proposed solution drew two adverse comments. One was that the Conneg WG is already addressing a similar problem. Joerg agreed, but said that he had found that the Conneg solution did not meet the requirements put forward here. Stephen Casner [casner@cisco.com] noted that the compression being worked on for RTP is more concise than that presented.

Tom Taylor [taylor@nortelnetworks.com] described the pressing interest the Megaco WG has in an improved capability negotiation protocol. There was even some suggestion that Megaco work on such a protocol, until it was realized that MMUSIC might not be happy with this endeavour. Tom asked at this point whether this perception of MMUSIC's attitude was correct. Responding as a WG Chair, Joerg suggested that if MMUSIC accepted new work in capability negotiation, Megaco should pass in its requirements to MMUSIC rather than doing the work itself.

Jonathan Rosenberg expressed his view that new MMUSIC work on SDP evolution is acceptable, but the results should be no more complex than necessary to meet the requirements. Joerg replied that excatly this was motivation and intention of their design.

8. Simple Phone Control Protocol

Tsuyoshi Go Kanai [kanai@FLA.FUJITSU.COM] gave a brief presentation of draft-kanai-spcp-00.txt. This is a protocol which would run between a PC terminating a call control protocol such as H.323 and an IP Phone under the control of that PC. It would allow the PC to add value to the exchange by presenting additional data to the IP Phone and intercepting data moving in the reverse direction. He gave as application examples a PC-based phone book and a caller ID database.

Tom Taylor remarked that SPCP was relevant to Megaco, in that its functionality would fall into the same space as a Megaco event package.

9. Message Bus Update
- draft-ott-mmusic-mbus-req-00.txt
- draft-ott-mmusic-mbus-semantics-00.txt
- draft-ott-mmusic-mbus-transport-00.txt

Joerg Ott provided an update on the work on the Message Bus since the April meeting. Documentation has now been split into three drafts one on requirements, one on transport, and one on semantics. The transport draft has nothing particularly new in it. The Semantics I-D describes a simple command naming scheme, generic call control, and conference control.

Generic call control contains common elements compatible with SIP/H.323/ISDN ..., plus protocol-specific extensions. These are basically suitable for use in gateways. There are requests and indications for setup, accept/reject, and teardown. Redirection and call forwarding are supported.

Henry Sinnreich [henry.sinnreich@WCOM.COM] remarked that this was a more general approach than the one used by Megaco, and that Megaco should look at it. Tom Taylor accepted responsibility for forgetting to invite Joerg to present at the Megaco kickoff meeting in December, but noted that it was a bit late for Megaco to change direction now. Joerg noted that the Message Bus protocol as presently constituted assumes a benign network environment.

Continuing in his review of the capabilities added in the Semantics I-D, Joerg noted the various types of commands envisioned so far:
- optional messages for specific media types and functions,
- messages to support voting and report status,
- transport-related commands, and
- tool-specific commands.

He was asked whether the commands could be embedded in a scripting language such as PERL or TCL. Joerg indicated that he had thought about doing this.

Joerg noted two wish list items: the ability to discover supported commands, and a value meter level indication. There now exist three interoperable implementations: at TZI, in Java and C++, where they already have created a SIP UA and a telephony endpoint, with coordination provided by a SIP proxy/H.323 Gatekeeper. The other implementation is at UCL.

Joerg pointed out that this is NOT a Megaco work item, because it deals with a peer-to-peer architecture and focuses on the role of endpoints. The question is whether it is a work item for MMUSIC. It extends horizontal protocols into local systems and fosters a building block approach for endpoints.

Henry Sinnreich suggested that NITS (Networks In The Small) might provide a home for this work. David Oran obtained confirmation that the design premise is that the communication links are local. Scott Petrack agreed that the NITS possibility should be considered seriously.

In other discussion, Joerg was asked whether there might be an executor which could launch applications. Joerg responded that this was possible, but one could also have an application registry which would allow peers to locate the applications.

10. SIP INFO Method

Steve Donovan [Steven.R.Donovan@wcom.com] led the discussion of draft-ietf-mmusic-sip-info-method-01.txt. The new draft has mainly editorial changes. The original purpose was to carry mid-call signalling events. It can be used in any situation where information has to be carried which does not change the call state. To achieve the complete intent of this message, the ISUP MIME type is needed. The question is whether there is an objection to this approach.

Joerg noted the objection raised previously: the preferable approach would be to use SIP to open a transport channel over which ISUP or other call signalling could be exchanged. Christian Huitema remarked to the contrary, that all signalling should follow the signalling path. David Oran agreed, both because this makes it easier to correlate the call states between SIP and the other protocol, and because one may want proxies to look at the carried ISUP. For example, a proxy may provide an ISUP variant translation service in the middle of the network.

Jonathan noted that SIP is a poor transport protocol, and message sizes with ISUP encapsulation raise the the possibility of message fragmentation. This was dismissed as a potential issue because of the limited size of ISUP messages. Jonathan also wondered if there was a potential state conflict if the carried ISUP turned out to be state-altering (e.g. it was a RELEASE message). The response to this point is that it would break the rules for use of the INFO method, and would therefore be a bug in the gateway implementation.

Scott Petrack asked what will happen if the encapsulated ISUP message is badly-formed. The response was that one could return a 401 Unacceptable response at the SIP level, as is done for bad SDP. The body of the response should identify the problem.

Jonathan asked if there are timing constraints: why don't the same questions arise as in Sigtran? The response was that INFO does not relate to call set-up and tear-down, and so is not timing critical.

The question at this point was where to take the work next. By show of hands, the consensus was that the function is required. There was a suggestion that the functionality overlaps that of the proposed SUBSCRIBE/NOTIFY methods.

Mark Handley placed the action on Steve Donovan to ensure that PINT agrees that SUBSCRIBE/NOTIFY are not sufficient for the purpose.

11. Proposal For New SIP/Telephony Working Group

Joerg Ott presented on behalf of MMUSIC management.

The current MMUSIC charter has expired. The proposal is to place the telephony-related work into a separate group. MMUSIC would be rechartered to handle architecture, SAP, SDP and any successor, and local session coordination, including the message bus and possibly generic conference control. MMUSIC would also retain responsibility for evolution of the base SIP specification.

Henry Sinnreich protested that separating the telephony work would put it too much under the control of the incumbent industry. David Oran suggested a different partitioning, with a single group devoted to SIP and all of its applications. Mark Handley had a counter-argument: that keeping SIP in MMUSIC would prevent telephony from running away with it. Joerg suggested that the telephony group would have a finite charter.

David confessed his real concern: that DCS would get cut in two: some parts are telephony specific, while others would belong in MMUSIC. KK Ramakrishnan backed this up, noting that SIP generality is why DCS came to MMUSIC in the first place.

Mark Handley made an alternate proposal: place SIP applications in general into a separate group. Jonathan Rosenberg noted that this would present management problems, because the same people would be involved in both MMUSIC and the new group. Henry urged that SIP applications not be separated from the base work, because we don't yet know where internet telephony is going.

Christian Huitema prefaced his remarks by noting that he is more current on SIP than on telephony. He noted the natural divisions of work which might be considered: by protocol or by time horizon. He suggested that MMUSIC regain its original research focus and hive off the extension work. Steve Donovan supported this proposal.

Scott Petrack voiced the need to ensure that the telephony work gets turned into general-purpose extensions.

Mark Handley concluded that pushback to the original proposal is evident. The WG will have to think some more about how to evolve. He invited feedback to the Chairs and Area Directors.

Slides

SIP Call Control
SUCC (SDP)
SIP INFO Method
Message Bus Update
Information Model for describing network policy and services
Simple Phone Control Protocol
Reliable Provisional Responses in SIP
QoS Policy Schema
SDP Session Preconditions
SIP 183 Session Progress Message
Simple Phone Control Protocol
SIP Session Timer
Session Announcement Protocol
Architectural Considerations for Providing Carrier Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP... Class Telephony Services Utilizing SIP...
Integration of Call Authorization and Call Signaling Integration of Call Authorization and Call Signaling for IP for IP Telephony
SIP Extensions for Caller SIP Extensions for Caller Privacy
SIP Proxy-to-Proxy extensions SIP Proxy-to-Proxy extensions
Integration of Resource Management and Call Integration of Resource Management and Call Signaling for IP Signaling for IP Telephony
SIP Extensions for Supporting Distributed Call State SIP Extensions for Supporting Distributed Call State