2.8.18 Session Initiation Proposal Investigation (sipping)

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 Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Interim Joint Meeting - Session Initiation Protocol (sip)/Session Initiation Proposal Investigation (sipping)

Last Modified: 2004-07-13

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
  • - draft-ietf-sipping-service-examples-07.txt
  • - draft-ietf-sipping-mwi-04.txt
  • - draft-ietf-sipping-dialog-package-04.txt
  • - draft-ietf-sipping-conference-package-05.txt
  • - draft-ietf-sipping-torture-tests-04.txt
  • - draft-ietf-sipping-3gpp-r5-requirements-00.txt
  • - draft-ietf-sipping-cc-transfer-02.txt
  • - draft-ietf-sipping-qsig2sip-04.txt
  • - draft-ietf-sipping-config-framework-04.txt
  • - draft-ietf-sipping-cc-conferencing-04.txt
  • - draft-ietf-sipping-conferencing-framework-02.txt
  • - draft-ietf-sipping-session-policy-req-02.txt
  • - draft-ietf-sipping-callerprefs-usecases-02.txt
  • - draft-ietf-sipping-kpml-04.txt
  • - draft-ietf-sipping-early-media-02.txt
  • - draft-ietf-sipping-app-interaction-framework-02.txt
  • - draft-ietf-sipping-e2m-sec-reqs-03.txt
  • - draft-ietf-sipping-early-disposition-03.txt
  • - draft-ietf-sipping-reason-header-for-preemption-01.txt
  • - draft-ietf-sipping-transc-3pcc-01.txt
  • - draft-ietf-sipping-transc-framework-00.txt
  • - draft-ietf-sipping-sos-00.txt
  • - draft-ietf-sipping-location-requirements-01.txt
  • - draft-ietf-sipping-trait-authz-00.txt
  • - draft-ietf-sipping-session-indep-policy-00.txt
  • - draft-ietf-sipping-uri-services-00.txt
  • - draft-ietf-sipping-uri-list-00.txt
  • - draft-ietf-sipping-uri-list-conferencing-00.txt
  • - draft-ietf-sipping-uri-list-message-00.txt
  • - draft-ietf-sipping-uri-list-subscribe-00.txt
  • - draft-ietf-sipping-multiple-refer-00.txt
  • Request For Comments:
    RFC3351 I User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired individuals
    RFC3372BCPSession Initiation Protocol (SIP) for Telephones (SIP-T): Context and Architectures
    RFC3324 I Short Term Requirements for Network Asserted Identity
    RFC3398 PS Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
    RFC3485 PS The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
    RFC3578 PS Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)
    RFC3665BCPSession Initiation Protocol Basic Call Flow Examples
    RFC3666BCPSession Initiation Protocol PSTN Call Flows
    RFC3702 I Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol
    RFC3680StandardA Session Initiation Protocol (SIP) Event Package for Registrations
    RFC3725BCPBest Current Practices for Third Party Call Control in the Session Initiation Protocol
    RFC3824 I Using E.164 numbers with the Session Initiation Protocol (SIP)

    Current Meeting Report

    Notes, SIPPING 1, IETF 60 by V. Gurbani

    Notes, SIPPING Session 1, IETF 60

    Reported by Vijay Gurbani


    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

    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
    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,
    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
    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
    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
    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
    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

    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.

    1735: Meeting adjourned.


    Event Notification Throttles
    Requirements and Framework for Consent-Based Communications in SIP
    KPML Updates Open Issues
    Dialog Package
    URI List Index
    Location Conveyance in SIP
    End-to-middle Security in SIP
    Multiple Dialog Usage
    A Framework for Session Initiation Protocol User Agent Profile Delivery
    A Schema for Session Initiation Protocol User Agent Profile Data Sets
    Update on SIP Conferencing
    Session-Specific Policies
    Scope of Operation in the Session Policy
    Session-Independent Policies
    App Interaction
    Reg Event Package Extensions