Subject: Draft minutes of Nov 7 interim meeting

From: Dean Willis <[email-masked]>
Date: Thu, 25 Nov 1999 23:34:55 -0600

The following are draft minutes. Please send corrections to
[email-masked]

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

The SIP Working Group held an interim meeting on Nov 7, 1999 in the Empire
Room of the Omni Shoreham Hotel in Washington DC, USA.

The primary purpose of the meeting was to inform the SIP working group on
the PacketCable Distributed Call Services (DCS) work. DCS is based on SIP,
with some extensions and changes to support requirements identified by the
developers. Many participants feel that the requirements identified by DCS
may need to be addressed in the SIP standard in order to increase its
utility and maintain interoperability.

The meeting format included a presentation period followed by a discussion
period. Attendees were asked to restrict questions during the presentation
period to requests for clarification as opposed to exploration of
alternatives.

Tom Taylor provided note-taking support, and his detailed notes are posted
on the unofficial SIP Working Group home at:
http://www.softarmor.com/sipwg/meets/interim-nov-1999/
along with PDF copies of all presentations. The DCS submissions to the IETF
are available from the IETF internet drafts collection at:
http://www.ietf.org/ID.html, search key "dcsgroup".

The presentations included detailed discussion of the assumptions and
service requirements underlying the DCS architecture and reviewed the DCS
utilization of and proposed changes and extensions to SIP.

Topics included:
  DCS and DQS Architecture, presented by K. K. Ramakrishnan
  DCS Call Flows, presented by Bill Beser
  DCS Resource Management, presented by Ed Miller
  DCS Authorization, presented by K. K. Ramakrishnan
  DCS Proxies, as presented by Mike Manette
  DCS Privacy, presented by Flemming Andreasen
  DCS State, presented by Poornima Lalwaney

Several hours of moderated discussion followed the presentations. Key points
follow.

Jonathan Rosenburg opened the discussion by asking whether the requirements
noted by DCS should be applied to SIP work in the IETF. There seemed to be
general consensus that the majority of requirments were generally
applicable, but that some might require further review.

Henning Schulzrinne noted that:
  -- one useful feature of SIP is that one can make progress on agreed
points while questioning others -- this is not all-or-nothing.
  -- a risk of text encoding is that everyone wants to express things their
own way.  We have to be concerned with integrity of the style.
  -- it would be nice if other applications outside cable architecture could
also use the capabilities added here
  -- we must be concerned for interoperability with other SIP applications,
running of multiple SIP-based applications on the same device, and avoid
being too special-purpose.

KK Ramakrishnan expressd general agreement with Henning's points.

Scott Petrack discussed the similarity of the DCS approach and legacy PSTN,
noting that we need to assure this emulation doesn't create large amounts of
work to break away from that model later.

Dave Oran suggested attempting to emulate the PSTN user model and meet user
expectations, rather than recreating the PSTN itself.

Jonathan Rosenburg neted that the user expectation model is a valuable basis
for developing SIP. He expressed hopes to generalize the application of some
of the various DCS concepts e.g. distributed state and to broaden the
applicability of extensions so they can be reused.

Lawrence Conroy suggested that we might be able to simplify the DCS operator
services and break-in approach, asking whether issue is just whether an MTA
is engaged in call. Someone proposd a counter-example: someone with heart
attack, necessitating an operator to actually need to know if voice is
active.  Jonathan Rosenburg responded that this could be problematic if
other media are flowing. This leaves a question: Can we rephrase the
requirment to make it more generally applicable?

Dean Willis noted security issues with operator services. Since the MTA has
to cooperate to allow eavesdropping, how does it tell an operator break-in
from a wiretap?

Dean Willis noted that SDP limitations mean the source port for a session is
not conveyed, making it hard to set firewall rules based on content of SDP
and potentially difficult to define the parameters for an operator break-in
which is not occurring on an MTA (a mid-flow tap).

Dean Willis discussed the controversiality of the DCS two-stage invite. The
current approach uses an "invite, no ring" followed by an "invite with
ring".  Dean ased if it might be feasible to used nested sessions, wehrein
the outer session establishes QoS between the endpoints, and the inner
session actually sets up the call. The idea may not have been expressed
clearly as nobody seemed to get it, and Dean agreed to think about it and
discuss it on the group mailing list someday. Someone later pointed out that
this approach suffers from the same cascade failure in forking scenarios as
does the DCS approach.

Dean Willis pointed out that the behavior of DCS proxies is to blocking of
3xx responses in the proxy. This prevents passing back multiple contact
points to the oroginator, thereby breaking a number of services including
UAC controlled parallel search and menu selection of redirected contact. In
fact, it pretty much breaks the entire redirect model. In discussion, it was
pointed out that this approach arose from a privacy concern for hiding of
forwarding. Jonathan Rosenburg suggested that the privacy requirement is OK,
but that the solution shouldn't prevent other capabilities. Dean Willis
suggested that use of a proxy that actually proxies, raher than redirects
the call, is needed to assure privacy of forwarding, and that end points
with this requirement should simply refrain from using redirects for
forwarding.

Dean Willis suggested that the group consider using the draft-antti tel: URL
syntax to express telephone numbers and LNP status rather than adding LNP as
a DCS-specific parameter.

Discussion then shifted to the on point at which billing begins.

Henning Schulzrinne discussed issues with the DCS aproach:
  -- per-minute billing doesn't encourage net-friendly behaviour like
silence suppression.
  --  Routers will have to capture packet volumes.
  -- It may be desirable to support uses such as use of packet connection
for baby monitor.  Hence a held resource charge plus a packet volume charge
might be the appropriate structure.  This makes the bill-upon-answer issue
disappear.
  -- Two-stage setup shouldn't be driven by a desire to preserve the PSTN
billing structure.
  -- The separation of reservation from commitment is valid.  It applies on
a per-stream rather than per-session basis.
  -- there is a simpler way than two-phase to achieve user requirements if
one gets rid of billing model preconceptions.

Jonathan Rosenburg questioned the DCS requirement to establish QoS prior to
answer response in order tot prevent first-utterrace clipping. He pointed
out that such clipping occurs in the PSTN today.  He suggested that there
may be enough "slack" in the network to support best-effort called party
greeting before QOS kicks in.  Bill Marshall counterpointed that this might
mean that the first few packets are delivered with significantly more delay
than the others, hence
requiring adaptability in the playout buffer, and that this could be
problematic given that DOCSIS delay adds 20 ms to best-effort latency.
Jonathan responded that designing application layer protocols around layer 2
is a questionable approach.

An attendee noted that dropping each proxy out of the signalling path after
the first phase may block the operation of some call features.  How does a
proxy get back "in" when required?  Bill marshall answered that the UA has
to explicitly call upon the proxy for further service.  This leaves open the
qustion: how does the endpoint know when to call in the proxy?  e.g. user
requires a specific proxy to be present at all stages of a call.

Mike Manette clarified the requirements and proposed solutions -- two-phase
invite addresses the call defect issue; direct 200 OK (proxy bypass) and QoS
transmission addresses clipping.  There was general agreement that these are
separate issues.

The group then discussed concerns with the call state model. It may imply
some dependence on UA reliability for the operation of some features such as
malicious call trace. Mike Manette stated that the DCS group assumption was
that endpoint reliability is an engineerable item.  Some parties expressed
concern that this reintroduces the telco-supplied phone model, or that
people might not realize the implications of buying a cheap phone.  KK
proposed that a service provider could offer a state recording service.
someone summarized that the phone should be able to
keep state of active calls, but it may be easier for a network resource to
keep history. Jonathan Rosenburg described this as a different fate sharing
problem. There seemed to be general interest in the room toward expanding
the DCS state model into a generalized cookie model.

Henning Schulzrinne comment on trust and privacy, noting that it might be
more efficient to certify UA-supplied info rather than always overwriting
it, with an underlying assumption that People are usually honest.  KK
responded that this is not a fundamental decision and could change if good
reason given.

Wrap up:

Jonathan Rosenburg suggested that the group first agree on requirements,
then debate solutions. The DCS group has made the first part easy by
breaking the requirements apart. Jonathan again argued that we should avoid
special-case solutions to the extent possible, but that the solutions
proposed by the DCS group should be given first consideration, as much of
the work has aleady been done. The attendees expressed a strong consensus in
favor of this approach. Several implementor groups agreed to offline talks,
and numerous calls for list discussion of vaios topics were voiced.

Open questions:

1) Can the operator services requirements be restated so as to make them
more generally applicable to SIP-inititated sessions? What are the relevant
security requirements?

2) Can the tel: URL syntax be used to meet DCS' needs for expressing phone
numbers and LNP contexts?

3) Can we refine the statement of the requirements sufficiently to determine
the general applicability of each?

4) Can we develop a reasonable compromise solution to the requirements
addressed by two-stage invite without the liabilities presented by the
two-stage invite process?

--
Dean Willis
SIP WG cochair