[SIP] Revised Minutes, SIP WG, IETF 47

"Dean Willis" <dwillis@greycouncil.com> Wed, 03 May 2000 04:40 UTC

Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14800 for <sip-archive@odin.ietf.org>; Wed, 3 May 2000 00:40:27 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1421D44351; Wed, 3 May 2000 00:34:47 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 4C9284434D for <sip@share.research.bell-labs.com>; Wed, 3 May 2000 00:34:42 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 3 00:38:19 EDT 2000
Received: by lists.bell-labs.com (Postfix) id 07A2744345; Wed, 3 May 2000 00:25:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id C3E8244341 for <sip@lists.bell-labs.com>; Wed, 3 May 2000 00:25:09 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix) id 76DD052BB; Wed, 3 May 2000 00:25:08 -0400 (EDT)
Delivered-To: sip@lists.research.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6472552B6 for <sip@lists.research.bell-labs.com>; Wed, 3 May 2000 00:25:06 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed May 3 00:24:20 EDT 2000
Received: from kevlar.softarmor.com ([63.64.250.82]) by dusty; Wed May 3 00:24:18 EDT 2000
Received: from dwillis (dwillis2.directlink.net [63.64.250.83]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id KAA04101 for <sip@lists.research.bell-labs.com>; Wed, 3 May 2000 10:25:57 -0500
Message-ID: <003401bfb4b7$75322a60$53fa403f@directlink.net>
From: Dean Willis <dwillis@greycouncil.com>
To: IETF SIP <sip@lists.research.bell-labs.com>
Date: Tue, 02 May 2000 23:24:13 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: [SIP] Revised Minutes, SIP WG, IETF 47
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

These are the hopefully final minutes of the SIP WG at the 47th IETF in
Adelaide.  They vary from the draft in that the consensus seems to be that
draft-campbell-sip-service-control-00.txt was not adopted as a WG item as
previously reported, but that the authors were encouraged to submit it as
an individual submission on informational track.

If there are no other changes I will conclude the revision of minutes and
post the final.

----

Minutes of SIP WG, IETF 47. Notes recorded by Tom Taylor.


1. Agenda Bashing
=================

The proposed agenda was accepted.  Presenters from Kyoto University
asked to be added to the agenda.  The request was denied because their
draft had not been submitted in time to be published by the IETF.

2. Status
=========

Dean Willis presented a summary of status of the WG work items,
followed by a brief discussion of potential charter items. There was
discussion as to whether the DCS drafts would be considered for
adoption by the WG. The current drafts still have RFC2026 complienace
issues preventing WG adoption as work items, but these issues may soon
be resolved. The general consensus seems that several of the DCS
drafts are likely to be adopted once the IPS is resolved.


The WG indicated consensus to adopt several tasks as chartered WG
activities, including:
SIP server features (standards track)
Call flows (informational)
Session Timer (standards track)
Reliability of provisional messages (standards track)
SIP-T efforts:
ISUP MIME types (standards)
ISUP mapping (undetermined)
Single Line Extension (undetermined)
Guidelines for Extensions.


As a general note regarding the management of the work of the WG:
Jonathan Rosenberg is attempting to assemble teams around specific work
items, with the proviso that individual participants should not be
over-committed.  The "single line extension" team is an example of this.



3. Summary of Current Discussion On The List
============================================

Jonathan Rosenberg summarized the status of discussion of a number of
current issues.

3.1 draft-nair-sip-dhcp-00.txt

No issues have been raised on the list, nor comments received from the
DHCP WG.  The fast-track procedure applied to this work appears to be
acceptable to the SIP WG.

3.2 Content In INVITE

Discussion in late December of how to include of content such as JPEG
images in INVITEs brought out a number of points:
 -- whether to include the actual content, include it indirectly through
provision of a URI, or include it indirectly as a media stream
 -- location of the content, in a header or in the body
 -- the need to identify how the content is to be used.
Jonathan perceived no consensus on these items, due to lack of comment
on specific proposals made to the list.


3.3 WWW-Authenticate Syntax

There is a proposal before the list, but no comments have been received.

3.4 tel:// vs. sip:// URLs

Jonathan emphasized the importance of the issue, discussion of which has
stalled.  He would like to see a new push to resolve it.

3.5 URL Parameters For Telephone Numbers

A couple of issues have been discussed under this heading: how to
indicate that the number shown is the result of an LNP lookup, and how
to indicate private dialing plans.  Again, Jonathan would like to see
a renewed effort to resolve these issues.

3.6 To Quote Or Not To Quote: Digest-URI

Robert Sparks commented that most implementations use quotes around the
digest-URI.  Usage for other fields is variable.  He suggests that all
fields be quoted.

3.7 Re-INVITE Glare

Jonathan noted that three proposals are on the table for handling of
coincident re-INVITEs.  Scott Petrack noted the need for a solution that
works with more than two parties.  Jonathan responded that SIP states
are shared only on a per-call-leg basis, except possibly in the case of
multicast, so multileg coincidental invites may not be an issue.

[A couple of points in Jonathan's charts were skipped because they are
being considered by the SIP security task force.]

3.8 When To Send 183 Response

Jonathan presented the rules for use of the 183 response which had come
out of discussion on the list.  A brief discussion followed, in which a
problem with the first rule was noted and resolved.

3.9 Overlap Dialling

Jonathan noted that there was no easy solution to the possibility of
forking for a call in which overlap dialling is being used.  David Oran
suggested that when the gateway rejects the first call, it should return
a contact which redirects all subsequent INVITEs to the same gateway.
Jonathan noted that this changed the meaning of the Contact: header
slightly, but its usage remains within acceptable bounds.

3.10 Early Media Criticality

Jonathan noted a continuing unresolved issue of how to distinguish
between critical and non-critical early media.

In general Jonathan intends to put out notes to the list to stimulate
further discussion of the open issues.

4. Status Of I-Ds (Jonathan Rosenberg)[charts]
======================================

4.1 Caller Preferences
 (draft-ietf-sip-callerprefs-01.txt)

Jonathan summarized a number of changes in the current draft.  There
have been no objections to the use of case-sensitive matching.  The
draft is due to go to the IESG, but Jonathan is looking for volunteeers
to check it out first.

4.2 Supported: Header
 (draft-ietf-sip-serverfeatures-02.txt)

The draft has undergone a major overhaul.  The one open point had to do
with use of the header with ACK.  This has been fixed and the draft has
been forwarded to the IESG.

4.3 Reliable Provisional Responses
 (draft-ietf-sip-100rel-00.txt)

A number of open issues still remain.
 -- cumulative acknowledgements: looking for an application to justify
inclusion of the mechanism
 -- response to PRACK: retain mechanism
 -- CANCEL for PRACK: disallow
We are looking to pass this document to the IESG as a Proposed Standard
by mid-April.

4.4 Guidelines For Authors Of SIP Extensions
 (draft-rosenberg-sip-guidelines-00.txt)


Jonathan proposed that this be a WG work item.  It would eventually
become a BCP, but not for another year.  For now it would be a living
document as the WG accumulates experience.  The sense of the meeting was
to adopt the work item, but there were mixed views on how quickly it
should be given formal status, with some arguing for near-term RFC
status.  This point will be taken to the list.  Jonathan has volunteered
to maintain the document if the WG chooses to make it a long-term
project as he proposes.

4.5 Third-Party Call Control
 (draft-rosenberg-sip-3pcc-00.txt)
This document has a number of dependencies, and various models of
control are possible.  In general the work does not involve an
extension to SIP, but only a description of the usage of its
mechanisms.  For this reason Jonathan does not propose that it be a WG
work item, but would like people to comment on it.

5. DCS Drafts
=============

5.1 Resource Reservation (Bill Marshall) [charts]
 (draft-manyfolks-sip-resource-00.txt)

This draft came about through the compromise merger of
draft-ietf-mmusic-qos-00.txt and draft-dcsgroup-sip-resource-01.txt.
The two-stage INVITE has been discarded.  SDP enhancements in support
of QOS and security negotiation include two new attributes (a=qos: and
a=security:), with syntax provided for confirmation that the requested
attribute values have been granted.  Extensions to SIP in support of
the negotiation of these attributes are covered in the same document
as the SDP changes, with AD approval. SIP extensions include use of a
header indicating that preconditions have been met.

The question was raised, whether there was any problem with using the
a=qos: attribute with provisional responses to allow the invitee to
set preconditions.  Bill made the point that the first user of the
attribute has to know whether the other end would understand it.

5.2 Caller Identity (Flemming Andreasen) [charts]
 (draft-dcsgroup-sip-privacy-01.txt)

Flemming summarized changes in the draft.  Earlier work has been
extended to recognize the possibility of boundaries between
proxies. In geneal, rather than requiring a nounary proxy to remove
calling party information, any proxy may encrypt the field and list
itself as an authenticator.  A new header, "Remote-Party-ID", has been
defined.  The set of possible operator services has been generalized.

Scott Petrack suggested that a specific tag for operator services might
not be in the spirit of SIP.  Jonathan agreed that an alternate approach
might be possible.  The basic idea, as always in SIP, is to define a
small set of reusable features rather than a variety of specialized
ones.

5.3 Distributing Call State (Bill Marshall) [charts]
 (draft-dcsgroup-sip-state-01.txt)

The mechanism has changed completely since the previous draft, in an
attempt to make it more general.  The draft now takes care to
distinguish between transaction state, connection state, and call
state.  The rules for including the "State" header have been
simplified.  There was a comment to the effect that the state
information must include the information necessary to ensure that it is
not used for a different call from the one which generated it.

5.4 Proxy-to-Proxy Extensions (Mike Mannette) [charts]
 (draft-dcsgroup-sip-proxy-proxy-01.txt)

Mike reviewed the changes from the previous draft.  LNP support has been
provided and hostport is now a required field in the "Gate" header.  The
"Billing-Info" and "Billing-Id" headers are unchanged.

5.5 Media Authorization (B. Beser) [charts]
 (draft-dcsgroup-sip-call-auth-01.txt)

This draft addresses the need for a per-call mechanism to authorize the
flow of media.  The new draft has been changed to focus only on the
client.  The former "DCS-Local-Gate" header has been renamed to
"Media-Auth".  The content has been generalized to hexadecimal.

6. Subscribe-Notify (Adam Roach)
==========================================
 (draft-roach-sip-subscribe-notify-00.txt)

Motivation: there is a need for a central definition of concepts which
have been mentioned in various documents.

The draft formalizes the methods and headers associated with
subscription and notification.  Distinctions are made between
call-related and resource-related subscriptions, with the latter
typically being of interest to third parties.  Rules are set down for
notifications and for duration of subscriptions.  The author attempted
to avoid disruption to PINT, but it might be possible to combine the
PINT work with this new material.

Scott Petrack noted that PINT had spent a great deal of time working
to make their mechanisms sufficiently generic.  He urged Adam to
review the PINT archives.  Unsubscription proved to be a tricky topic,
and PINT found it preferable to list events in bodies rather than in
headers.  Scott and Adam will discuss this further off-line.

Henry Sinnreich asked what measures had been taken to coordinate with
the Instant Messaging and Presence (IMPP) WG.  Jonathan replied that
IMPP is addressing a different problem and had already judged SIP to
be unsuitable for their purposes.  He also recalled that a general
subscription/notification BOF was held, but nothing came out of it
because the problem was too broad.

Scott Petrack noted that PINT will change if necessary to conform to
SIP.

An example subscription/notification service was presented, where the
caller is rung back when the callee becomes free.  There are open issues
where further work is required.  Jonathan proposed that another task
force be set up on the Egroup mail server, to refine the problem
statement.

Michael Thomas questioned whether SIP really needed an asynchronous
method of completing a call when the current protocol can support a
blocking approach.

7. Mobility (S. Baba) [charts]
=========================
 (draft-itsumo-sip-mobility-req-00.txt)

The draft provides requirements, open issues, and relevant work items
in SIP and other WGs.  The requirements are organized on a functional
basis.

Addressing the charts, Lawrence Conroy asked what was meant by the
requirement to "utilize" CDMA soft hand-off.  He saw this as invisible
at the IP level.  The presenter pointed out that the process might
involve multiple IP addresses for the same UA.  This would represent a
major extension to SIP.

James Polk noted that the forthcoming Location Information BOF might
be relevant to this problem.

[end of first session]

8. Review Of Charter Work Items  (Dean Willis) [charts]
===============================

Dean asked for comments on the proposed work items before the WG
chairs reviewed them and passed the results of the review on to the
list.  There were no comments.

9. INFO Method, Session Timer, 183 Session Progress (Steve Donovan)
[charts]
===================================================

9.1 INFO Method

Work on the INFO method, draft-ietf-sip-info-method-01.txt, is basically
done.

9.2 Session Timer

The Session Timer draft (draft-ietf-sip-session-timer-01.txt) underwent
significant change to reflect the new "Supported" header.  Some issues
remain before WG Last Call:
 -- refreshing of the timer.  Jonathan suggested that this be done by
re-INVITE, rather than a new method.  Agreed.
 -- Session-Expires header problematic in anything but INVITE -- will be
allowed with INVITE only.
 -- Can a proxy add Required headers? -- could end up with multiple
Required headers if the UAC also includes one.  This doesn't seem to
break anything, but there is an interaction with authorization.  In the
absence of comment from anyone but Jonathan, this should be checked out
on the list.
 -- the question was asked: what happens if the called UA includes
Session-Expires with a re-INVITE and it contradicts the one set by the
calling UA?  Steve suggested that it would be up to the implementation
to sort this out.  The list will be invited to comment.

Next steps:
 -- agreed that this becomes an official WG work item
 -- submit shortly to WG Last Call.

9.3 183 Session Progress

draft-ietf-sip-183-00.txt has a lot of dependencies, resulting in
improved understanding of the issues.  It may be used for early media
and for pre-conditions.  Summarizing the extensions involved:
 -- full session description bodies in 18x responses
 -- add the 183 response
 -- provide the "Session" header to indicate the purpose of the session
description body
The first two items are in 2543 bis already.

It is proposed that the Session header draft be refined to narrow its
focus, taking advantage of the 183 documentation.

10. Call Control (Robert Sparks) [charts]
================================

10.1 Framework For Call Control Extensions
 (draft-campbell-sip-cc-framework-00.txt)

Needs to be aligned with the guidelines.

10.2 Call Transfer
 (draft-sparks-sip-cc-transfer-00.txt)

Proposes a new TRANSFER method (not BYE ALSO), which does not alter the
original session.  Open issues:
 -- name of the method.  Jonathan interjected that he does not want to
build protocols for specific services, hence the method should have a
more abstract name and definition. Dean Willis suggested "Introduce".
 -- whether the method can carry bodies
 -- authentication.  Dean Willis suggested an "Introduced-By" header,
signed by the transferor.

10.3 Service Context -- Use of the SIP Request URI
 (draft-campbell-sip-service-control-00.txt)

This is an informational draft proposing the transmission of service
context through use of a distinctive Request-URI.  Robert provided an
example application and described the advantages of the mechanism.

David Oran was unclear on the intent of the work.  He noted that it
takes the opposite approach to that of HTML, by using the left side of
the URL rather than the right.  The syntax conflict could make the
result different depending on the server. Dean Willis pointed out that
SMTP also uses the left hand side, and that web URLs lack the @ and
therefore HAVE no left hand side.

Robert responded that the URL is intended to be an opaque entity bound
as a whole against a particular service.  David agreed that under these
conditions the format was acceptable.

The authors were encouraged to submit this work for informational
RFC status. This work was not adopted as a group effort of the
SIP WG.

10.4 Call Flow Examples (Presentd by Robert Sparks)
 (draft-ietf-sip-call-flows-00a.txt)

The draft has had a number of updates.  Please forward any further flows
to Alan Johnston (alan.johnston@wcom.com).

Jonathan noted that the document is getting too large to handle easily.
He proposes to farm out subsections to volunteers to review.  Ideally
they should simulate the flows to validate them.  Alan Johnston will
coordinate the work.

There is an issue with dependencies on work in progress.  The document
will be partitioned so that the stable part is processed first.

11. IETF SIP MIB (David Walker)
 (draft-ietf-sip-mib-00.txt)

Issue: the document is 70 pages long.  Can this be reduced?  It covers
RFC 2543 plus the INFO method and the 183 response.  Items are defined
within configuration, statistics, and notification groups for each of
the UAC, UAS, proxy, registrar, and redirect server, except that
elements common to all of these are grouped separately.  (Nothing has
been defined as yet to be specific to the redirect server.)

Concern: too many measurements.  Discussion of this brought out the
following:
 -- measurements should be defined only if there is a stated use for
them
 -- they are used as a troubleshooting tool, but a message history tool
would do a better job
David will send a note to the list to provoke further discussion.
Comments on how measurements are used will be welcome.  The note will
also raise a number of other questions for comment.

The current draft contains a couple of known errors.

12. BCP For SIP to ISUP Mapping (Gonzalo Camarillo) [charts]
 (draft-camarillo-sip-isup-bcp-00.txt)

This draft covers requirements, call flow examples, and the mapping of
parameters between the two protocols.  Gonzalo went over the changes to
the draft:
 -- new name
 -- additional extension: umbrella REQUIRE
 -- refinement of scope
 -- a discussion of SIP bridging between ISUP networks
 -- corrections to the handling of overlap signalling
 -- added examples.

He presented a walk-through of the overlap signalling case.  There is a
lot of messaging, but, unlike in the previous draft, it works.  There is
an open issue of how to control routing of overlap signalling in the
case of a stateless proxy forwarding to loadsharing MGCs.

A question was asked: how is connection redundancy handled -- for
example, UA multihoming.  What if the successive messages arrive at
different answers.  The reply was that this issue was out of scope of
the draft.  Jonathan remarked that SCTP transport for SIP is a topic
for the future.

Gonzalo concurrently presented a report on the status of the SIP-T
work.  It was noted that of the SIP-T work, the highest priority is to
obtain approval of the ISUP MIME types document. This is currently
planned for May 2000.

13. SIP Mapping Of MLPP (James Polk) [charts]
 (draft-polk-sip-mlpp-mapping-00.txt)

There is a mismatch between SIP "priority" levels and MLPP levels.
The draft proposals are to add a level and add administrative hooks.
Jonathan remarked that the standard is not the place to specify the
administrative hooks -- they belong in an RFP.

Subsequent discussion brought out two points:
 -- added priority level in RFC 2543bis
 -- additional document describing operation of MLPP.  This would cover
a number of items besides SIP, so it should not be a SIP WG document.

Jonathan also wondered whether MLPP really impacts SIP except at the
gateway, since it is concerned with preemption of limited call
resources in the face of higher-priority demand and IP resources are
not so obviously limited as circuits.  Brian Rosen disagreed, pointing
out that MLPP is not only about preeemption.

The outcome of the discussion was consensus to discuss adding another
priority level to 2543bis, or possibly adding "token" to the grammar
allowing arbitrary extension. This will require list review. James
Polk may submit a detailed fraft showing how the SIP priority levels
can be used to implement MLPP requirements.


14. Update On ISUP MIME Types (Lyndon Ong)
 (draft-ong-sip-qsig-mime-00.txt)

The draft has one open issue: the amount of ISUP version information
required. Followup is occuring in the SIP-T subteam and will be
reviewed on the main list when ready.

15. SIP and QOS (Henry Sinnreich) [charts]
 (draft-sinnreich-sip-qos-osp-01.txt)

Henry presented a list of "to do" items associated with the work.  He
hypothesized that a new WG may be required.  As evidence of this he
cited the need for a framework, within which different QOS models might
operate.

Radhika Roy mentioned that ITU-T Study Group 16 is also doing QOS work,
and the two groups could share their results.  Henry agreed that this
was possible.

Patrice Calhoun asked about the relationship between QOS and OSP (Open
Settlement Protocol, which appeared on Henry's charts).  Henry indicated
that OSP was relevant because it supports the clearing house model of
settlements, and the latter differs from the AAA WG model.

Melinda Shore remarked that overall (thinking also of DCS) there seemed
to be some strange QOS work going on, driven by charging models.  Hooks
within SIP are in scope for SIP WG discussion, but the general topic of
QOS for VoIP is out of scope.

Continuing in his presentation, Henry presented call flows showing the
tight coupling between signalling, QOS, and AAA.

Jonathan remarked again that ONLY changes required to SIP are within
the SIP WG's scope.

Dave Oran observed that DCS covers the "push model" of QOS: policy is
pushed to the enforcement point.  There is a need to develop a system
for the pull model, with open security issues standing in the
way. Dave proposed COPS-PR for this role.

Dean Willis suggested that perhaps the Transport Area WG could tackle the
larger problem.  Jonathan proposed discussing the matter with the ADs.

16. SIP Through Firewalls and NATs (Jonathan Rosenberg) [charts]
 (draft-rosenberg-sip-firewalls-00.txt)

Jonathan noted that the topic of firewall/NAT traversal is being covered
by the foglamps BOF.  The question is whether the SIP WG wants to do an
Informational RFC on the specific topic of SIP operation through these
barriers.

Dean Willis suggested that the question of whether this work belongs
in SIP is of the same order as whether MLPP does -- that is, both are
enablements for SIP within specific sectors.

There was a weak hum in favour of the work item.

17. Usage of TRIP For Gateway Registration (Jonathan Rosenberg)
 (draft-rs-trip-gw-00.txt)

This was simply an alert to the topic, which had been raised in the
meeting of the IPTEL WG the previous day.

18. Transferring User Control Information In SIP REGISTER Payloads
(Jonathan Rosenberg)
 (draft-lennox-sip-reg-payload-00.txt)

We need a way to pass scripts from the client to the server.  This
draft is the same as the original version a year ago, with minor
changes.  There are several open issues.  Jonathan asked "Should this
be a SIP work item?", which started a lively discussion.

Radhika Roy suggested there was a relationship to and potential impact
on mobility; Jonathan disagreed.  Lawrence Conroy wondered how the
scripts would be authenticated.  Dean Willis mentioned several
approaches that have been suggested.

Dean put the question: "even with the other alternatives, is it useful
to do this function via REGISTER?"  There was a slight hum in favour,
no opposition, with most registering no opinion.  The work was
accepted subject to approval on the list.

19. Finding A SIP Server With SLP (James Kempf)
 (draft-kempf-sip-findsrv-00.txt)

The intention is to add a template to the IANA service type registry.

Motivation: there are several ways to locate a SIP server through DNS --
for example, by use of a naming convention.  The method presented allows
location by characteristics.  This is useful because different proxies
in a domain can have different characteristics.  The approach taken is
to have one SLP abstract service type: "service-sip", with two concrete
service types.

Jim presented an example: find a registrar supporting CPL.

An open issue is how to handle incoming calls.  With other methods of
DNS usage, one can parse down the hierarchy of server names.  With SLP
it may be necessary to use SIP forking or multicast.

Should this be a WG work item or an individual draft?  IANA approval
requires RFC documentation and approval by Eric Guttman (servloc
Chair).  Comments on the draft can go to Jim directly or to the list.

Jonathan noted that this is one of many possible methods, but that's
OK.  There is certainly no point in discussing whether this work
should go forward as opposed to some other approach. The consensus was
to not adopt this as a WG task at this time, but to follow the work as
it matures and reconsider at a futue point.

20. CGI Interface (Jonathan Rosenberg)
 (draft-lennox-sip-cgi-03.txt)

The draft is being cleaned up.  A couple of issues have been resolved.
There are alternative methods for transfer of the CGI scripts. There
appears to be no intent to make this a WG item at this time.

21. Distributed Multipoint Conferences Using SIP (Jeff Mark) [charts]
 (draft-mark-sip-dmcs-00.txt)

Jeff provided some examples, showing manipulation of full mesh
conferences.  Is there SIP interest in further such full mesh work?

Jonathan noted that conference control is not part of the SIP WG mandate.
The problem of topology management is overly complicated because call
control should be separated from link state propagation.  The latter is not
something SIP is good at.

Jonathan will organize a first pass at rearchitecting the proposal,
but there are other approaches to multi-party conferencing that may prove
worth discussing.


--
Dean Willis
dwillis@greycouncil.com








_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip