Minutes, SIPPING, IETF54
Reported by Dean Willis
SIPPING Working Group, IETF 54, Session 1
Agenda discussed -- no issues
SIP-T, Jon Peterson
Slides presented include status review. SIP-T framework is
essentially complete and currently in IETF LC. Tom Taylor reports
that SG11 is working in this area and has sent some correspondence
to IETF on the topic, and is hoping to finalize their work by
November. Question for scheduling: since there is a dependency on
tel URL work, when do we need the tel URL done? Jon Peterson reports
that IESG has said that reference to tel may be informational rather
than normative.
Status of Working Group Drafts, Rohan Mahy
Three documents off to RFC editor -- NAI Req, SIP-T, and Hearing
Impaired requirements. We have been in working group last call on
call-flows for a long time and hope to conclude with next rev after
this meeting. Question: None of the emergency stuff (SOS, 911, etc.)
seems to be on the agenda as WG efforts. Is this intentional?
Rohan's answer: The IESG has indicated that this needs to go thru
ieprep. We have a joing meeting of 30 minutes for this
later. Allikson Mankin confirmed this position.
Service Flows Open Issues, Alan Johnston
Recent adds include several three-party scenarios. Open issues
include use of SIP events, join/fork, and discovery of conference
URI. There also needs to be more attention on the single-line
extension flow and use of conference package.
Conferencing Open Issues, Rohan Mahy
Design team met earlier this week. Slides present work plan for
further effort, including need for set of consistent docs, migrating
certain requirements to other groups such as MMUSIC, and isolating
those requirements which should not be met using SIP. Scope proposal
is to focus on tightly-coupled conferences controlled by a "focus"
with a one-to-one correspondence with each "member". Must evaluate
use of SIP vs. alternatives in these roles? Audience polled for
reasonableness of scope, high level of agreement indicated. Proposed
conference work plan documented in slides discussed, goal to deliver
individual documents in September time frame. Question: How is this
going to be aligned with the SIMPLE work and requirements for what
needs to be done there? Ans. The policy-setting aspects of handling
memberships to lists and subscriptions etc. is very similar to the
membership properties of a conference. Identifying common
requirements and possible generic solutions is a primary task of
SIPPING, and we think this will come together as the work proceeds.
Assorted Draft Issues, Jonathan Rosenberg
Conferencing Event Package: Open questions of scope and whether this
should be subdivided into multiple event packages.
Dialog Events Package: Recent changes defined a dialog FSM, has been
moving toward XML schemas rather than DTDs. Defined "abstract
dialog" for aggregated state monitoring of generic states
like
"busy". Several elements changed, and IANA registration
work
added. Open question: SUBSCRIBE now applies to all authorized
dialogs, is it appropriate to do a version targeted to
a specific
dialog? Question: Does the IETF really recommend using
schema or
dtd in IETF? General understanding seems to be that
schema is
preferred. Comment: There seem to have been some scenarios
where
single-call information was useful. COmment: The W3C has
moved to
discouraging use of DTDs.
Registration Events Package: Original requirement was to support
network initiated reregistration. This was generalized
to provide
information about the state of registrations. The draft
now
includes an FSM model of registration state. There has
been
discussion of the relationship between this draft and
presence
events. Author's view is that presence state may include
a
compositing of registration state with other information
under
control of a composition policy. Poll to adopt as a SIPPING
working group item generally agreed. Comments in opposition
from
Sean Olson: This is a real world application, but should
not be a
SIP working group item -- at best, it is a P-informational
sort of
thing. Counter-position from JDR: Needs to be possible
to
distinguish registration from presence. Sean: The idea
of
standardizing interface between registrar and presence
server. Counter from Georg Mayer: Since registrar's and
presence
servers may come from different sources, this DOES Noeed
to be
standardized. Question: If we're adopting this, when do
we expect
to finish this? Is it ready for WGLC? There don't appear
to be
technical issues, but further review is called for.
Message Waiting Events Package, Rohan Mahy
Dates back to Pittsburgh meeting. Three open issues.
1) Should the media types concept be replaced with message contexts?
If you receive an MP3, is that a voice mail, an
email, or an
external reference or what? Comment: the context
draft is now in
the RFCED queue. Discussion: Message context draft
addresses many
issues of presenting sender's intent. It's mature
and easy to
work toward. Comment: This is a definite improvement,
raising
question of "how is this contect list extensible,
what's the
process?" Answer: There's an IANA registration
process
documented in the context draft. Comment: this would
also shorten
the MWI draft and make it more crisp. Question:
Should we add
instant message to this package as a new context
class using IANA
process in context draft? Ans. Sounds good
so far, will discuss
on list. Poll: Who likes idea of using message context
instead of
static media lists, result generally favorable (one
objection
noted, not loud).
2) Should the syntax follow SIP instead of current restrictive
syntax, including line folding etc.? No objections
raised.
3) If forking or state agents are supported, how do the responses
get aggregated, and how is specific messaging account
targeted?
This has backward compatibility issues. No objections
raised.
Comment: There are probably scenarios where subscribe/notify is
wrong metaphor as there is a lot of overhead in maintaining the
subscription state. Is it reasonable to use otehr mechanisms?
Ans. Maybe . . . for example, SMS might work.
Content Indirection Requirements, Sean Olson
Slides discuss current requirements list. Open issues seem
minimal. Question: When you send this to the far end, you don't know
that it will be able to support the type of URL refernced. How do
you know that the reference was acceptable? Suggestion: Use scheme
parameter from caller preferences. Counter: This is not a routing
problem, it's more of an acknowledgement problem, so caller pref is
probably not right. Perhaps we should have a baseline URI mechanism?
We probably also need a way to report a refusal of
indirection. Comment: this work needs to move forward
rapidly. Comment: is there a requirement to not send an indirection
unless there is knowledge that that receiver supports the scheme,
or
is it adequate to decline an offered indirection?
Request History Requirements, Mary Barnes
Several requirments added in -02 rev, primarily relating to
integrity and privacy protection. Question: is this sufficiently
cooked to make it a working group item? Response: The concerns that
remain focus on whether implementation of this stuff becomes
required in order to interwork public services. For example, is a
voice mail server built this way going to require people to "fake"
history entries in order to interact with it? This may raise the
need for a requirement that services that uses this mechanism be
abloe to operate in its absence? Poll for adopting as a working
group item strongly favorable, with only one vocal dissenter.
Configuration and Profile Delivery Requirements, Dan Petrie
Slides presented discuss methodology of investigation and analysis
of several potential configuration delievery protocols. Conclusion
seems to be that SIP is best mechanism for enrollment and
notification and that HTTP provides best mechanism for delivery and
XML provides best container for information. Question: Do we we wish
to make this a working group item? Response generally favorable,
with two or three opposed.
Connection Reuse, Rohan Mahy
Slides review ephemeral connection behavior and
implications. Discussion requested clarification of some
points. Questions polled on readership, comprehrension, and belief
as to utility with generally favorable response. Question: Do we
need more requirements to be able to do this? Comment: We need to
analyze security implications carefully. Discussion on splitting
drafts into reqirements, motiviations, and implementation, generally
opposed. Poll on adopting as WG item, generally favorable, few
dissenters.
SIP AAA Requirements Open Issues, John Loughney
Slides discuss assumptions an background. Comment: This seems to be
focused on fairly traditional provider roles. We may need to
consider different roles that occur in SIP. Comment: Thought basic
idea was to put principal database somewhere else, so that nodes
could run a protocol back to the database and say "Is this okay"?
So
what's the rest of this stuff? Comment: This is a start. It is not
exhaustive, it doesn't go into a whole lot of things like
settlement, but needs to be done. Comment: Settlement is outside of
AAA. Comment: IETF should not get involved in charging and
billing. Response: The "accounting" here is about
recordkeeping. Question: Do we have to do all this before anybody
works on RADIUS or DIAMETER or AKA or whatever behind a SIP server?
Ans. No, that work will proceed separately. Comment: many
requirements are in the form of "A SIP server should", almost like
host requirements. This becomes a description of the sort of
additional functions that need to be built into a SIP server for
deployment in a real network. Comments: This is a major overloading
of the term AAA, and unless we really are talking "RADIUS on
steroids" we should be expressing it differently. Proposal: Rohan
mumbled something about three different scopes and asked people to
hum, then declared rough consensus on scope two and maybe doing
scope 1 later or as a strict subset of scope 2 or that a solution
for the space of scope 1 could be defined in the conext of scope 2.
SIPPING Working Group, IETF 54, Session 2
Agenda: Rosenberg and Baker talks reversed due to availability
Markup and Application Interaction, Jonathan Rosenberg
Slides review origin of user input problem with DTMF. Prior effort
has focused on use of RFC2833 for in-band DTMF, but this requires
media forking and doesn't work for a lot of apps. INFO has been used
as an alternative, but this usage is undefined and
non-standard. Key-events is a step in the right direction, but
incomplete. This is really stimulus signaling, where the user is
interacting with an application in the absence of a semantic
understanding of the application on the part of the user agent. This
lead to the "markup" draft, thence to the "app-session" draft,
thence to a largely undefined scope problem . . . .
Comment: There seems to bea at least one "energy barrier" here. If
the user thinkjs he is talking to a correspondent communicator
semantically like another person that is on one side of the barrier
(voice mail). If the user is running an application where the normal
things we do with SIP are just aspects of the application, like
playin "wuake" where some parts are doing sideband talks and others
are rendering location and others are doing movement vectors, etc
--
that is, there is a larger application orchestrating more than one
sip session, then that's something else. We may not want to deal
with these two categories in the same way.
Comment: This second category is not the same as that identified in
the "stimulus" model described above. Response: We think we've
constrained it right in the current draft.
Comment: Morphing a functional protocol into a stimulus protocol can
make some things wierd. Really, we're taking requirements from a
stimulus model and attempting to apply them in a functional model,
and that risks some complexity. Maybe we want to do something
quicker and easier to solve the basic DTMF problems. Response: Let's
look at what it will take to do it right first.
Comment: Trying to deal with multiple applications concurrently will
require a much stronger concept of focus than that required for a
simple stimulus model. We'l;l need to move there eventually.
Comment: drowned out by chatter.
Conclusion: We wish to propose a design team to tackle this. The one
thing we seem to need to do is charge the design team with coming
up
with a solution quickly for the simpler problem class and "heading
off" the info based systems soon is probably too critical to let
slide. Poll takem on forming desigtn team met with string
approval. Plea from audience: put interim findings out to list, not
work in a vacuum.
IEPREP, Rohan Mahy, Fred Baker, Henning Schulzrinne
Rohan: We were asked by ADs to have joint meeting between SIPPING
and IEPREP becauseSIP is being asked to do some things with respect
to emergency preparedness. We'll start by describing the arch of SIP
as is likely to be appropriate to IEPREP. Many people think of SIP
as a telecom protocol, but it's really an internet protocol with a
different role for intermediaries. Most intenret SIP proxies provide
message routing functions, but not QoS and other really stateful
functions. The main things in the SIP architecture are the user
agents -- gateways, ordinary phones, and application platforms like
media servers. These are responsibile for "doing the right thing"
with requests. If they need to pre-empt focus, or route a request
into a priority queue, or request a special QoS, thenm that's what
they do. They MAY use other elements to do these things, but have
the essential responsibility. Clarification question from Henning:
Are we assuming that proxies may nor may not drop call requests?
Answer: Yes. Proxies tend to drop stuff when overloaded, and may use
this as a mechanism for policy or congestion, etc. Comment, Oran:
Proxies have to be DOS resistent. If they are, then they've fixed
this problem to some degree.
Fred: Start with big picture, then go into Henning requirement's and
Dennis' telco perspective. Slides review making of calls in a hybrid
environment, with the question being "What happens when you place
a
call?" Imagine we've had a disaster -- everybody picks up the
phone. Most of us are just in the way, and we need those who can
actually help to get through. There are policies such as MLPP which
detail a prioritization scheme based on rank, etc. How does this
work? When a call comes in from a PSTN, we'd like to be able to
place that to an IP telephone, or in from an IP telephone, out to
an
IP phone or PSTN or whatever as appropriate. We must have
information that allows us to classify the call within the policy
schema. Example given of incoming call preemption. In the MLPP case,
the call is simply preempted and replaced. For IP devices, we need
to have some way to tell the device that the pending call is higher
priority than the current call. This has nothing to do with the
location of the SIP proxies, which could be anywhere. With IP,
we
also have the problem of making sure that the important calls get
the needed bandwidth if it happens to be scarce. This probably
becomes something in RSVP or something like that. Three
requirements: We need to "bypass" a busy signal, have a policy for
admission and bandwidth allocation, and exchange such values
transparently with PSTN. This requires one-to-one mapping with PSTN
representations to provide for call tunneling cases.
Rohan: The intent is for this work to become a requirements document
from IEPREP to SIPPING. The current work is light on security and
privacy requirements , and the following presentation will raise
some.
Henning: We will discuss security requirements for SIP-to-PSTN for
access top PSTN resources. Key is access to end-to-end strong
authentication and authorization. This depends not just on rank, but
on role and criticality of the specific call in question. The risk
here is not just fraud, but disruption of the performance of the
overall system. It is likely that intermediary nodes may need
to
participate in authentication/authorization roles, especially in
delegatory models. In general we need to authorize any assertion of
priority, not just assertion of identity (a given individual may
make higher or lower priority calls). This is a classic cross-domain
problem -- the principal may be in a different domain, and may not
be able to rely on local-domain authentication protocols such as
kerberos. We must also make minimal requirements on the capabilities
of a given device. For example, the party may be using an ordinary
civilian phone to try and deal with a major emergency. Question: How
does this work from PSTN? Answer (Scott): In civilian world, user
dials a special area code and PIN, requiring participation from the
local carrier. Mil phones may have special buttons. The privacy
requirementgs are also interesting -- for example, leakage of
identities of parties in high-priority calls may leak strategic
planning information, such as which ship is being launched. Other
open potential requirements include 1) priority-sensitive routing
vs. explicit routing through priority nodes 2) avoiding two stage
dialing, and 3) discovering namesapces (which may have separate
authentication concerns). Comment: Unstated metarequirement. Systems
like this need ways of being invoked regularly outside of "real"
emergencies, including full systems exercise, or the systems will
not work when actually needed. What do we assume about IP network?
Is it a custom built network, any network with a specific set of SIP
devices (major firewall issues), or "any public network, any public
device"? Clarification point: MLPP is an ITU standard and there also
numerous national standards in PSTN. Comment: The "any public phone"
scenario may actually be very critical. Process note: This is just
a
preview of the requirements document, but the final version is still
being worked in IEPREP. We need to make sure that our feedback thru
IEPREP is requirements based, not solutions. Need also to make sure
that the SIP people do not ignore IEPREP and that IEPREP doesn't
make too many assumptions.
Closing questions: Question? Is the general 911 call in
IEPREP's charter? Not yet, but then 911 is also not chartered in
SIPPING. On the other hand, IEPREP expects that they will deal with
all aspects of preferential calls. Comment: Reader did not notice
anything about speech codecs in requirements. We need to make sure
that "launch" does not sound like "lunch". Comment: In problem
statement, what are requirements for location specific information,
and how will this relate to geopriv? Fred: yes, maybe, depending on
specific circumstance. Comment: Are we developing requirements on
managing diversity, redundancy, etc. One view is that this is
system architecture and implementation, and therefore out of
scope. It might be reasonable for us to build an informational model
of how one might wish to build. A second position is that there may
be requirements that mandate reserved facilities, but that this is
still out of scope for SIP/SIPPING. Comment: The requirements can
really be divided into originating and terminating sides -- the
general ordering a launch versus n-many calling the fire
depertment. Answer: this is a question of the relative authorization
levels, and it might be that 911 calls get bumped or
vice-versa. Conclusion: We're really looking for something like
call-waiting with policy and a formalization for the specification
of that policy. We're supposed to be done with IEPREP requirements
this week, or if not very soon.
General discussion of scope and charter followed. Conclusion seems
to be that emergency calls (for the regionally challenged read
911/112 calls) are an orthogonal issue to that of the international
emergency preference service. As a result, rechartering of SIPPING
could be discussed to include Henning's drafts, and Henning's drafts
do not need to go to IEPREP. Of course if someone really wants
resource priority on an emergency call, then that would go to
IEPREP, but that is not the subject of Hennings drafts at the
moment. A similar division applies to GEOPRIV issues, where each
group deals with its own requirements.
updated
17 Jul 2002 23:30 -0500