Gonzalo Camarillo <firstname.lastname@example.org>
Dean Willis <email@example.com>
Rohan Mahy <firstname.lastname@example.org>
Transport Area Director(s):
Allison Mankin <email@example.com>
Jon Peterson <firstname.lastname@example.org>
Transport Area Advisor:
Allison Mankin <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
In Body: (un)subscribe
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
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:
Submit Internet-Draft on SIP-Telephony Framework to IESG for
consideration as a BCP
Submit Internet-Draft on ISUP-SIP Mapping to IESG for
consideration as Proposed Standard
Submit Internet-Draft on Requirements for use of SIP to support
telephony for the Hearing-Impaired to IESG for consideration as
an Informational RFC
Submit SIP 3rd party call control to IESG for consideration as
Submit Internet-Draft on 3G Requirements to IESG for
consideration as an Informational RFC
Submit Internet-Draft on Mapping ISUP Overlap Signaling to SIP
to IESG for consideration as a Proposed Standard
Submit Internet-Draft on Usage Guideline for Events
(Subscribe-Notify) to IESG for consideration as an
Submit Internet-Drafts Basic and PSTN Call Flows to IESG fro
consideration as BCPs
Requirements for Content Indirection in SIP
Submit Message Waiting SIP event package to IESG for
consideration as PS
Using ENUM with SIP Applications to IESG for consideration as
an Informational RFC
Requirements for Reuse of Connections in SIP
Submit Internet-Draft on T.38 Fax Call Flows to IESG for
consideration as a BCP
Requirements for SIP Request History
Submit Internet-Draft on Requirements for AAA Application in
SIP Telephony to IESG for consideration as an Informational RFC
Sip Interworking with QSIG
3pcc Transcoding to IESG as Info
KPML to IESG as PS
Conferencing Requirements to IESG as Info
Conferencing Framework to IESG as Info
Conferencing Call Control-Conferencing to IESG as BCP
Location Requirements to IESG as Info
End-to-Middle Security Requirements to IESG as Info
Requirements on Trait-Based Authorization to IESG as Info
Configuration Framework to the IESG as a PS
Submit Requirements and Framework for Exploders to the IESG as
Submit Opt-in/Opt-out Mechanism for Exploders to the IESG as PS
Submit URI List Transport Mechanism to the IESG as PS
Submit I-D on Ad-Hoc Conferencing using URI lists to the IESG
Submit I-D on MESSAGE Exploders to the IESG as PS
Submit I-D on Multiple REFER to the IESG as PS
Submit I-D on Subscriptions to Ad-Hoc Resource Lists to the
IESG as PS
Event Filtering Requirements to the IESG
Caller Preferences Use Cases
SIP Service Examples
Session Policy Requirements to IESG as Info
Session Independent Policy Mechanism to the IESG as PS
Transcoding with Conf Bridge to IESG as Info
Transcoding Framework to IESG as Info
Session Specific Policy Mechanism to the IESG as PS
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
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
Allison: Ted has concerns regarding sos draft based on his
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.
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
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
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
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,
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
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
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
Keith: you are trying to invent things that are not part
of the dialog, but are part of the UI. WHich one are
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
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
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
Rohan: The reqs need a lot more motivation and scenarios
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
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
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.