Minutes of SIP WG at IETF 46, Final

Dean Willis <dean.willis@wcom.com> Wed, 08 December 1999 05:43 UTC

Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09387 for <sip-archive@odin.ietf.org>; Wed, 8 Dec 1999 00:43:43 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix) id 2067352B6; Wed, 8 Dec 1999 00:41:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7450B52DD; Wed, 8 Dec 1999 00:41:20 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8A4C252B6 for <sip@lists.research.bell-labs.com>; Wed, 8 Dec 1999 00:41:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Dec 8 00:39:28 EST 1999
Received: from pmesmtp01.wcom.com ([199.249.20.1]) by dusty; Wed Dec 8 00:38:00 EST 1999
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #41714) id <0FME00B01QDQMP@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 8 Dec 1999 05:39:26 +0000 (GMT)
Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #41714) with ESMTP id <0FME00994QDPEG@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 08 Dec 1999 05:39:25 +0000 (GMT)
Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by omzrelay.mcit.com (8.8.7/) with ESMTP id FAA05337 for <sip@lists.research.bell-labs.com>; Wed, 08 Dec 1999 05:39:27 +0000 (GMT)
Received: from dwillispc4 ([166.44.162.174]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19991208053922.NFEW91@dwillispc4> for <sip@lists.research.bell-labs.com>; Wed, 08 Dec 1999 05:39:22 +0000
Date: Tue, 07 Dec 1999 23:42:07 -0600
From: Dean Willis <dean.willis@wcom.com>
Subject: Minutes of SIP WG at IETF 46, Final
To: IETF SIP <sip@lists.research.bell-labs.com>
Message-id: <000f01bf413e$f6b38080$0200a8c0@dwillispc4>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


An HTML version is available at:
http://www.softarmor.com/sipwg/meets/IETF46/notes/minutes.htm

-------------------------------------------
Minutes, SIP Working Group at IETF 46

The SIP Working Group met in conjunction with the 46th meeting of the IETF
in Washington DC on November 8 and 10, 1999. There were two standard
sessions, both of which were well attended (app. 200 persons), with very
full agendas. In addition to ongoing working group efforts, seventeen
Internet drafts were presented and discussed.

First Session, Monday November 8 0930-1130
------------------------------------------

Topic: Agenda Bashing, Current Work, WG Charter Review, presented by WG
chairs

Dean Willis discussed the agenda, with no objections being raised. Jonathan
discussed current mailing list topics including call termination procedures
(cancel vs. bye) and feature availability headers
(Supported/Unsupported/Desired/Required). The meeting consensus appeared to
be that the apparent consensus reached on the mailing list with respect to
bye and cancel overlaps is adequate for most cases of overlapping cancel/OK.
We expect this to be clarified in the next SIP specification document. There
seemed to be good consensus on the semantic range of feature availability
using the four headers (Supported/Unsupported to describe availability,
Desired/Required to describe rigidity of need). Further discussion of this
topic is required on-list. Jonathan also introduced the concept of
content-disposition for SIP message bodies. It may be that this mechanism
can be adopted from HTTP to address the application semantics of SIP. We
probably need a volunteer to analyze the HTTP usage and suggest
applicability for SIP.


Topic: SIP INFO Method, presented by Steve Donovan
draft-ietf-sip-info-method-00.txt

This is a WG charter item. The draft is fairly mature, and there is a strong
consensus to adopt the INFO method as a SIP component. There seemed to be a
good consensus to publish as an extension to SIP rather than including INFO
in the base spec at this time. The author agreed to finalize the draft with
this intent (address nits) and resubmit it with the intent of moving rapidly
to a WG last call.


Topic: ISUP bodies for SIP messages, presented by Eric Zimmerer
draft-zimmerer-sip-isup-mime-00.txt

Yet another MIME encoding for ISUP messages. No clear consensus has been
reached. We propose that the authors of the various approaches get together
and come up with a common approach. Tom Taylor noted that some sort of
version information in the encoding would be very helpful.


Topic: SIP BCP Draft, presented by Eric Zimmerer
draft-zimmerer-mmusic-sip-bcp-t-00.txt

The draft discusses a SIP-PSTN interworking methodology. Discussion centered
on limitations of the approach (for example, forking is not addressed and
may be precluded). The opinion appeared to be that the work, while
informational, may not yet constitute as "best current practice" as it does
not seem to have been actually implemented anywhere. Jonathan Rosenberg
called for input as to whether the SIP WG is the appropriate place to carry
this work forward, with other alternatives including a specialized working
group or an implementor's forum. Lawrence Conroy noted that there are really
two pieces of work here -- a set of extensions to SIP, and a profile of SIP
usage for telephony interworking, and that it should be possible to
decompose the work along these lines. There was consensus to definitely do
this work within IETF and that the work would move forward in such a way as
making it more broadly applicable, such as handling multiple proxies.


Topic: SIP-ISUP Mapping, presented by Gonzalo Camarillo
draft-camarillo-mmusic-sip-isup-bcp-00.txt

This draft deals with SG-MGC-MG architectures and the interworking between
an MGC and a SIP UA, specifically with message flows for calls in both
directions and parameter mappings. Gonzalo proposes that advanced ISUP
feature mapping can be vendor specific -- and that we need standardization
only on basic aspects. Accordingly, the draft is based on Q.767 rather than
Q.763. Discussion centered on issue of coordination of work on mapping and
references used. There may also be an need to clarify legal requirements on
the GSTN side. There were no substantive disagreements voiced with the
approach taken in the draft.

Topic: QSIG body for SIP messages, presented by Mo Zonoun
draft-ong-sip-qsig-mime-00.txt

QSIG is essentially a suite of peer-to-peer protocols between PBXs used for
feature signaling. The draft proposed a MIME encoding for QSIG and transport
of the MIME encodings as SIP message bodies, with call flows and various
examples. There was some discussion of the similarity between the QSIG and
ISUP approaches, with Henry Sinnreich asking if the various related drafts
could be unified. Jonathan Rosenberg commented that the interworking
difficulties not so obvious with ISUP, because of QSIG vs. SIP feature
interactions, and that there are interesting situations that might occur
when working between telephony and non-telephony endpoints, with QSIG
transport less likely to be general-purpose because of its more direct
conflict with SIP role. David Oran noted that QSIG in H.323 led to trouble,
with customers requiring H.323 awareness of some features. Christian Huitema
stated that awareness of the QSIG features in SIP collides directly with the
purpose and transparency requirement of SIP. The basic consensus is that the
approach for MIME types for ISUP, QSIG, etc. should be unified, and that
QSIG interworking is a separate issue. The WG did not state an opinion on
the need to carry out this interworking effort, with further discussion
deferred to the list.


Topic: SIP Call Flows, presented by Robert Sparks and Alan Johnston
draft-johnston-sip-call-flows-00.txt
draft-sparks-sip-service-examples-00.txt

These two documents contain several hundred pages of detailed call flows
showing a variety of SIP and SIP-PSTN sessions. The consensus of the group
was that this is a critical contribution, and that the WG should adopt a
call flow document as an ongoing effort. During the remainder of the
meeting, several requests were made to add specific scenarios or feature
invocations to the anthology. Jonathan Rosenberg proposed that these
documents be combined with the test cases from the bake-offs into an
informational RFC for issuance in January. This proposal received a loud hum
of consensus.


Topic: Intelligent Network Application Part (INAP) in SIP, presented by
Frans Haerens
draft-haerens-sip-inap-00.txt

This draft discusses approaches for exercising IN applications from SIP
devices. It was noted by Jonathan Rosenberg to have some commonalities with
a Lucent draft presented last year and that it might be possible to combine
the efforts. One speaker noted a strong overlap with SPIRITS work, but it
was noted that there is a need to fill in SIP as such as registration
outside of SPIRITS. Jonathan noted that there had been discussion in the
IPTEL meeting about a perceived lack of IN expertise in the IETF, making the
IETF an inappropriate forum for this sort of work. Jonathan whether the SIP
group feels more confident in this effort. After some noncommittal
responses, Dean Willis suggested that this conversation could move to the
list, which seemed to stimulate the conversation. Paul proposed that this
task is equivalent to the ISUP mapping work, only this for INAP, and is
therefore as appropriate in IETF as is ISUP mapping. Lawrence Conroy
suggested that ITU SG-11 might be addressing the topic, and suggested
submitting the draft there as well. Lawrence further proposed that mapping
to INAP should be done in ITU/ETSI, but that they might not understand SIP
well enough to do it right. Chip raised the question -- with respect to INAP
mapping, what does the author asking this WG? The response is that the SIP
WG would address the SIP enhancements needed to support INAP. Chip inquired
as to what forum would work the protocol between the softSSF and SIP Proxy,
and was told that it is not currently being worked. One speaker noted that
third-party call control is being worked in IPTEL using CPL, raising the
question as to whether multiple approaches are needed. Jonathan Rosenberg
responded that the IN approach has value, but fails in different
architectural contexts than the CPL approach, and that each should be used
appropriately.


Second Session, Wednesday November 10, 1300-1500
------------------------------------------------

Topic: Caller Preferences, presented by Jonathan Rosenberg
draft-ietf-sip-callerprefs-00.txt

Jonathan presented the current state of work on caller preferences.
The open issues include:

1) relationship with CPL: has description now
   how to reconcile conflicts between CPL and caller preferences, options
including
        -- let proxies decide,
        -- view both CPL and caller preferences as hints, etc.
Scott Petrack suggested that caller preferences take precedence.

2) syntax for capabilities. Can we use the CONNEG work?

3) IANA procedure for registering new capabilities. Joerg Ott suggested we
may wish to impose constraints or require documentation. What additional
capabilities should go into the baseline spec?

4) One speaker asked about interaction with the DCS no-ring proposal.
Jonathan sees the situations as different, whereas K.K. sees possibility of
an overlap. Further discussion appears warranted.


Topic: SIP Session Timer, presented by Steve Donovan
draft-ietf-sip-session-timer-00.txt

The session timer was presented in Oslo, with consensus to proceed. The
current draft is quite mature. Discussion centered on whether to include
this in the base spec or consider it an extension. By using the
requires/supported approach, it could be made a separable extension. The
consensus was to republish with this detail and nits corrected and proceed
to WG last call as soon as possible.


Topic: Early Media in Provisional Responses (183), presented by Steve
Donovan
draft-ietf-sip-183-00.txt 0:15 Steven.R.Donovan@wcom.com

An earlier version of this draft was presented in Oslo, with consensus to
proceed. This draft really includes two different elements which are needed
for certain telephony interworking cases. One element is the addition of
MIME bodies to provisional (1xx class) messages. This appears to have broad
utility to other applications as well, but has a dependency on reliable
provisional messages. The other element is the addition of a new method to
indicate call progress. It was noted that 183 has been allocated, so a new
number would need to be selected for the proposed feature. No consensus was
reached as to whether each element should be included in base or published
as an extension. One suggestion made was to divide the document into two
discrete drafts and develop the elements separately. No conclusion was
reached as to how to proceed, and discussion was deferred to the list.


Topic: Interdomain SIP, QoS, and OSP presented by Henry Sinnreich
draft-sinnreich-interdomain-sip-qos-osp-00.txt

This document covers an interesting interdisciplinary approach to dealing
with QoS, reporting, and settlement issues for SIP sessions crossing two or
more carriers.
David Oran noted that the media path is not the same as the signaling path,
which raises the question of how a SIP proxy knows which router to go to.
This apparently is unresolved in DCS as well. Jonathan noted that mix of
protocols suggests trotting through a series of WGs, but that this is not
truly a SIP WG item because no SIP changes are proposed. K.K. suggested that
there is a large community of interest here, which led Jonathan to suggest a
joint WG meeting as an option. One speaker suggested adding these examples
to the call flows draft. Steve Donovan noted the open SIP question of when
to trigger QOS -- a SIP extension may be needed to handle this case. A
non-WG informational RFC, with review across groups, was also suggested.
Further discussion on how to continue this work was deferred to the list.

Topic: Using SIP with MPLS for QOS Reservations, presented by Mark Gibson
and Jon Crowcroft
draft-gibson-sip-qos-resv-00.txt

This draft suggests a novel use of modified SIP with a route header to probe
for and establish MPLS paths. As this is interdisciplinary with MPLS, no
consensus was reached to move forward with this as a SIP WG effort.


Topic: Usage of the SIP INFO Method such as DTMF presented by Jiri Kuthan
draft-kuthan-sip-infopayload-00.txt

This draft discussed usage of the INFO method for transporting a variety of
things including mid-call signaling, DTMF, and others, and proposed means
for enhancing reliability and in-order delivery. Discussion rapidly devolved
to a moderately heated exchange on DTMF-in-RTP vs. DTMF-in-INFO, with no
conclusion reached.


Topic: Authentication through Multiple Proxies, presented by Robert Sparks
draft-sparks-sip-multiproxy-auth-00.txt

This draft discussed approaches for allowing multiple proxies to challenge a
SIP method. It appears that this can be accomplished via a slight
clarification of the response syntax and some discussion of proxy behavior
without impacting the current SIP specification. These can be included in
the next SIP draft. However, implications of hop-by-hop vs. end-to-en
security remain to be considered.


Topic: Host Mobility Management Protocol with SIP presented by Faramak Vakil
draft-itsumo-hmmp-00.txt

This draft proposes extensions to SIP needed to support a host mobility
management protocol potentially useful in 3G wireless and other
environments. Further discussion is needed as to whether this work should be
addressed in the SIP WG.


Topic: SIP Servlet API presented by Anders Kristensen
draft-kristensen-sip-servlet-00.txt

The SIP Servlet approach is promising for development of SIP services using
Java. Discussion centered on finding an appropriate forum for further work,
as there appeared to be a general consensus (reinforced by an area director)
that the IETF is not an appropriate forum to refine software APIs. The
proposal was made an accepted to establish a new mailing list for further
discussion.

--
Dean Willis
SIP WG co-chair