In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:
http://softarmor.com/sipping -- Additional SIPPING Web PageNOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Dean Willis <dean.willis@softarmor.com>
Rohan Mahy <rohan@cisco.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: sipping@ietf.org
To Subscribe: sipping-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/sipping/index.html
Description of Working Group:
The Session Initiation Protocol Project INvestiGation (SIPPING)
working group is chartered to document the use of SIP for several
applications related to telephony and multimedia, and to develop
requirements for any extensions to SIP needed for those applications.
Such requirements will be referred to the SIP working group for
development of any new SIP method or Guiding principles for
the performance of SIPPING's work will include:
1. Documenting the requirements of specific chartered tasks.
2. Documenting the usage of SIP to solve real problems that need
to be solved in a standardized way.
3. Looking for commonalities among the chartered tasks and ongoing
SIP-related development, as commonalities may indicate for general,
reusable functionality in SIP.
4. Describing the requirements for any extension determined to and
handing them to the SIP WG.
5. Developing procedures and requirements for configuration and
delivery of SIP User Profiles
Besides performing needed specification of several applications
of SIP, SIPPING can be seen as also working out use cases that
clarify the role of SIP in the Internet, and help to ensure that
Occam's razor is appropriately applied to SIP usage.
The security of all the deliverables will be of special importance.
The technology for security will be keyed from the SIP Security
specification within RFC 3261, and additional SIP specifications
as they apply.
The specific tasks for SIPPING will be:
1. PSTN and/or 3G telephony-equivalent applications that need
a standardized approach
- informational guide to common call flows
- requirements from 3GPP for SIP
- framework of SIP for telephony (SIP-T)
- call transfer and call-forwarding
- AAA application in SIP telephony
- mapping between SIP and ISUP
2. Messaging-like applications of SIP
- support for hearing-/speech-impaired
- development of usage guidelines for subscribe-notify (RFC 2848,
SIP events) to ensure commonality among applications using them,
including SIMPLE WG's instant messaging.
3. Multi-party applications of SIP
- the working group will review a number of technical pieces
including call transfer, subscribe-notify, SIP features
negotiation, and session description protocol (SDP) capability
negotiation, and will develop requirements
and a framework for multi-party conferencing with SIP.
4. SIP calling to media
- the working group will develop a requirements draft
approach to SIP interaction with media servers. An example is
whether a voicemail server is just a box that a caller can send an
INVITE to.
5. SIP URI-List services
- the working group will develop requirements for
SIP list services mechanisms enabling a client to request that a
server distribute a specific SIP request to a list of recipient
URIs. The working group will develop a mechanism to transport this
list of recipient URIs (a URI-list) from a SIP client to SIP server
in conjunction with the request (a request-contained list). The
working group will also specify mechanisms (presumed not to be SIP
mechanims)for storing, modifying, or retrieving a URI-list stored
on a server (stored URI-lists). The working group will specify the
use of URI-lists with various SIP request types for which list
services are appropriate with both stored and request-contained
URI-lists. The working group will also develop requirements and
specifications for a positive opt-in mechanism by which list
servers can prevent amplification of attacks and relay abuses.
At a later time, the working group and chairs may request
of the Area Directors that new tasks be added to the charter.
Such additions to the charter will require IESG approval.
The group will work very closely with SIP working group.
The group will also maintain open dialogue with the IPTEL working
group, whose Call Processing Language (CPL) is related to the task
areas in a number of areas. The group will also coordinate closely
with SIMPLE, AAA, and MMUSIC (SDP development).
SIPPING will also ensure compatibility with the work done
by the now concluded PINT working group. SIPPING will encourage
active participation from the Distributed Call Signaling (DCS) Group
of the PacketCable Consortium for distributed telephony services, 3GPP,
3GPP2, and several ITU-T study groups.
Goals and Milestones:
Done
Submit Internet-Draft on SIP-Telephony Framework to IESG for
consideration as a BCP
Done
Submit Internet-Draft on ISUP-SIP Mapping to IESG for
consideration as Proposed Standard
Done
Submit Internet-Draft on Requirements for use of SIP to support
telephony for the Hearing-Impaired to IESG for consideration as
an Informational RFC
Done
Submit SIP 3rd party call control to IESG for consideration as
BCP
Done
Submit Internet-Draft on 3G Requirements to IESG for
consideration as an Informational RFC
Done
Submit Internet-Draft on Mapping ISUP Overlap Signaling to SIP
to IESG for consideration as a Proposed Standard
Done
Submit Internet-Draft on Usage Guideline for Events
(Subscribe-Notify) to IESG for consideration as an
Informational RFC
Done
Submit Internet-Drafts Basic and PSTN Call Flows to IESG fro
consideration as BCPs
Done
Requirements for Content Indirection in SIP
Done
Submit Message Waiting SIP event package to IESG for
consideration as PS
Done
Using ENUM with SIP Applications to IESG for consideration as
an Informational RFC
Done
Requirements for Reuse of Connections in SIP
Done
Submit Internet-Draft on T.38 Fax Call Flows to IESG for
consideration as a BCP
Done
Requirements for SIP Request History
Done
Submit Internet-Draft on Requirements for AAA Application in
SIP Telephony to IESG for consideration as an Informational RFC
Done
Sip Interworking with QSIG
Jun 04
3pcc Transcoding to IESG as Info
Jul 04
KPML to IESG as PS
Aug 04
Conferencing Requirements to IESG as Info
Aug 04
Conferencing Framework to IESG as Info
Aug 04
Conferencing Call Control-Conferencing to IESG as BCP
Sep 04
Location Requirements to IESG as Info
Sep 04
End-to-Middle Security Requirements to IESG as Info
Sep 04
Requirements on Trait-Based Authorization to IESG as Info
Oct 04
Configuration Framework to the IESG as a PS
Oct 04
Submit Requirements and Framework for Exploders to the IESG as
PS
Oct 04
Submit Opt-in/Opt-out Mechanism for Exploders to the IESG as PS
Oct 04
Submit URI List Transport Mechanism to the IESG as PS
Nov 04
Submit I-D on Ad-Hoc Conferencing using URI lists to the IESG
as PS
Nov 04
Submit I-D on MESSAGE Exploders to the IESG as PS
Nov 04
Submit I-D on Multiple REFER to the IESG as PS
Nov 04
Submit I-D on Subscriptions to Ad-Hoc Resource Lists to the
IESG as PS
Dec 04
Event Filtering Requirements to the IESG
Dec 04
Caller Preferences Use Cases
Dec 04
SIP Service Examples
Dec 04
Session Policy Requirements to IESG as Info
Jan 05
Session Independent Policy Mechanism to the IESG as PS
Feb 05
Transcoding with Conf Bridge to IESG as Info
Feb 05
Transcoding Framework to IESG as Info
Mar 05
Session Specific Policy Mechanism to the IESG as PS
Apr 05
Review charter with Area Directors and recharter or conclude
Agenda bashing -- agenda accepted.
Published 3 RFCs since IETF 59 -- 3824, 3725, 3680.
3 docs in ed q - msg waiting, early media, and early
session disp.
3 with AD: 3gpp r5 reqs, qsig to SIP, 3pcc transcoding.
Pre-WGLC drafts - cc transfer, torture tests (need volunteers
for this; disappointing take up on the mailing list call).
transcoding framework (gonzalo will find cycles to finish
it). sos draft is waiting feedback from URI mailing list;
waiting for feedback outside the WG.
cc framework, reason header for premption - waiting for
RP.
Allison: Ted has concerns regarding sos draft based on his
early review.
Ted's concerns are encapuslated in a draft and are not
being discussed in any wg.
New milestones - jul '04: KPML. Need to close open issues
this week and wglc next. Aug '04: Conf. reqs and cc conf -- Alan
will take the lead on this. Location reqs has been merged
with location solutions and will be 1 document.
...
Dec '04: event filtering, caller prefs usecases, svc. examples.
Gonzalo: the WG is looking for more editors, current ones
are running out of cycles. Looking for new eds to work with
senior eds so the former can get a brain dump of the latter
on how to write successful drafts. session policies is one of
the first ones tried.
Jan '05: session indep. policies.
...
march '05: either recharter or close down the WG.
--
REFER issues:
draft-olson-sipping-refer-extensions has 2 controversioal
extensins to REF. Nothing has happened with this draft.
Need to move it forward.
Orit: removed all the controversial things; two things
left: adding norefersub and suppress the implicit subs. and
allow Refer-To to contain feature parameters...next step:
become a SIP
Rohan called for any objections on sending this to SIP WG.
No one objected, but Rohan asked the attendees to look it
once over in the next couple of weeks.
App interaction, Jonathan Rosenberg.
Revised app interaction; mostly small cleanups. One major
issue: if I want to refer someone to a web site for a credit
card the refer needs to provide a context for a dialog. For
subs we use event-header parameter; used something similar
for this called "context" and a Require token.
Other changes: added motivational text from KPML; not been
synched up with latest KPML rev.
Had a normative ref. for SIP identity; does not need a
normative ref; infor. suffices.
app needs to understand the capabilities of the device --
what markup it supports -- before interaction. Use of
Reg EVent for this.
Authorizing REF/SUB - cannot be automatic w/o sips.
Softened the wording about the ap being in the dialog
path.
Updated exmaples to use TLS and added needed IANA params.
Next steps: No open issues beyond KPML synchup; ready for WGLC.
Asked for comments/concerns: None raised.
KPML, Martin Dolly.
Received many comments at the Boston interim meeting.
editorial cleanup following those comments. Aligned with
app-interactions.
Added GRUU text in doc; removed concept of "leg",
beefed up security, added 502 to KPML status code.
removed refs to mscml; expanded abstract and many other
changes.
Issue 1: One of the issues was privacy of user input --
one app subs to digits to get the CC number; don't want next app
to get the credit card number.
Options: among 4 options ranging from who cares, do not
quarantine (buffering of digits), matter of local policy,
flush buffer.
Rohan: split this in two separate decisions: can we
get away with who cares or do no buffering? Feedback
from WG has been that we do care about buffering since
we do not want to constantly re-enter digits.
Cullen: do no quarantining (no buffering).
Jonathan: Need to understand use cases where a second
app needs to get access to the digits?
<Discussion ensused regarding use cases for this...the
discussion veered towards KPML being a digit transport
protocol or an app interaction protocol; some of the behavior
being asked of it now reflects the latter. No option chosen;
more discussion on wg list>.
Issue 2: explanatory content between app interaction
and KPML-03. KPML-04 has solved this by keeping all
non-normative text in app-inter and keep all normative
protocol text in KPML.
Jonathan: No open issue here; some of the opening para
from app-inter really belongs to KPML and I have no
problem putting it there.
<Discussion went back to Issue 1; Cullen supports
"do no quarantine" and others support "flushing buffers".
Eric gave an example on why "do no quarantine" will not
work...discussion ensued and Dean summarized the options
as being retaining digits
1: From the beginning of current dialog
2: From last stable transition state
3: From the moment of the SUBS processing forward
Dean asked the participants to hammer out something by
Friday WG meeting).
Dialog package, Rohan Mahy
Hold issue: lots of folks wanted a passive/active flag or
other indicator they could use for hold. Proposed adding
a new callee-caps feature tag for "interactivity". Lots
of controversy. 4 options:
0. remove all hold-related params from document and do
separate docs for these params.
1. have one parameter: "i am paying enough attention to
send a BYE".
2. (a) parameter for don't know how to send BYE, (b) i am
not rendering media from any of the m lines in the current
SDP.
3. 2+(c): A UA paired up with another more active SIP UA.
The 3rd one is a relationship where you want to know
the buddy's name and this goes beyond what we want to
express in caller-caps.
Rohan's proposal: Option 2. Proposed names for the two
params: "byless" used when UA cannot reasonably
determine when to send a BYE or is unable to send a BYE.
Jonathan: how do you determine how this parameter gets
set?
Cullen: We should put words like "it is expected that
this device will not send a BYE".
Jonathan: Prefer a very explicit defnition so that
implementors know what the behavior is.
The second param is called the "rendering" param; default
setting is "unknown". If the value is "no" --> On hold.
Jonathan: again, what does rendering mean? Does a TiVO
box qualify if it is saving data to disc?
Two other open issues: how do you handle the case when
a phone is picked but an INVITE has not been sent out yet.
Also, what is the lifetime of the dialog that is in
terminated state?
Keith: you are trying to invent things that are not part
of the dialog, but are part of the UI. WHich one are
we doing?
Rohan: Currently, the doc describes dialog state.
Jonathan: We specifically decided not to go to UI modeling
back when I was editing the document. These things are
definitely in the UI domain. You are making all kinds of
assumptions of the UI based on perception of a dialog
state.
Cullen: The use cases in the doc for this I-D are around
UI. We could do another package for UI and you subs to
two packages. This doc should meet both UI and dialog
state.
Jonathan: If we are going down this line, we need to
properly consider all possible cases.
<Dean asked the participants to take this offline and
discuss it further.>
Event throttles, Aki Niemi
merged req draft w/ solution draft. incorprated wglc comments.
wglc summary: should client be able to dictate the buffer
policy of the notifier? COnclusion: No. Uneeded complexity
and uneeded behavior.
What buffer policies and packet treatment should we
define? FIFO, LIFO? Conclusion: event pkg. specific and
only two make sense: Last In Out Trash Others for full state
and Merge for partial state.
Cleaned up overview of operations.
Open issues: only one left: REQ7...should we add more
recommendations or is this reasonable enough?
Should we make this a WG item?
Jonathan: It's getting better compared to older revs.
Event packages have always said that event packages must
thorttle NOTs, but does not specify how. The general
problem you are solving is not consuming too much bandwidth
over air interface. The message will still grow linearly
and this solution will not buy you much.
Other problem is: what data is interesting to me as a
watcher. WHat can you throw away without impacting the
information coming to me.
Gonzalo: the reqs to this I-D are already WG item. This
doc has reqs and solution.
Jonathan: This is effectively as an extension to rfc3265.
Since it defines a new mechanism for throttling.
Dean: The WG processed the reqs and a reasonable solution
would require an extension to rfc3265. Should we punt
this over to SIP to deal with there. We will keep it in
sipping until we have clear requirements and we decide
what we are trying to do.
Reqs and framework on consent based communications in SIP.
Reqs: amplification request attack -- one request goes to
multiple destinations. Have we captured all the existing
reqs or is something missing?
Miguel: I want to send a message to be distributed to all
URIs, and if one fails then what happens. Other case is
you want to distribute to as many as possible and if some
fail, no problem.
??: Can we turn off messages from a relay we are not
interested in?
Rohan: The reqs need a lot more motivation and scenarios
around them.
Cullen: Like where this is heading; we need some verbiage
on how long the consents lasts and how assertive are the
identities in the framework (i.e. if From contains sip:A
can I be sure that it is indeed from A).
Open issue: Target URI. Contents of a permission
document does not include a target URI right now.
Should we include it? Proposal: yes, as an optional
element.
Open issue: description of the permissions being requested.
The CONSENT request neds to describe the permissions
being requested. Use a header field, send a
template (e.g. a MESSAGE) using a require header, use an
XML body. Proposal: XML body.
Hisham: We need to restrict the domain of this document.
ARe we exploding a request or specifying that contact me
over video and not audio...
Jonathan: In favor of doing this work and considering the
scope beyond only URI exploder.
Rohan: This is young enough that we should do this one
more time as an individual; but the WG should keep in mind
while reviewing this I-D on if it should become a WG agenda.
Dean: We're going to solve this problem: (a) are the reqs
enough, b: are the solutions adequate to serve as a baseline
going forward.
Jon: we need to delineate the workings of this draft with
normal SIP forking.
Dean: polled on if this series of drafts should be a WG item.
The poll indicated yes.