2.7.14 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 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-19

Chair(s):
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: www.ietf.org/mail-archive/working-groups/sipping/current/maillist.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 header. 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 other ongoing SIP-related development, as commonalities may indicate need for general, reusable functionality in SIP.

4. Describing the requirements for any extension determined to be needed, and handing them to the SIP WG.

5. Develop 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 a SIP security specification developed (in progress now) by the SIP Working Group.

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

- support for T.38 fax

- requirements from 3GPP for SIP usage

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

- 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 an initial design or framework for multi-party conferencing with SIP.

4. SIP calling to media servers

- the working group will develop a requirements draft for an 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.

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) related to the task areas in a number of ways. 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
Mar 04  Submit Call Info SIP event package to IESG for consideration as PS
Mar 04  Submit Conf Info SIP event package to IESG for consideration as PS
May 04  Submit Internet-Draft on Call Transfer using REFER to IESG for consideration as a BCP
May 04  Submit Internet-Draft Torture Tests to IESG for Consideration as Informational
Jun 04  Event Package for User Configuration Profiles
Dec 04  Review charter with Area Directors and recharter or conclude
Dec 04  Submit Internet-Draft on Multi-Party/Conferencing Framework to IESG for consideration as an Informational RFC
Internet-Drafts:
  • - draft-ietf-sipping-e164-04.txt
  • - draft-ietf-sipping-service-examples-06.txt
  • - draft-ietf-sipping-cc-framework-03.txt
  • - draft-ietf-sipping-3pcc-06.txt
  • - draft-ietf-sipping-mwi-04.txt
  • - draft-ietf-sipping-dialog-package-04.txt
  • - draft-ietf-sipping-conference-package-03.txt
  • - draft-ietf-sipping-torture-tests-03.txt
  • - draft-ietf-sipping-aaa-req-04.txt
  • - draft-ietf-sipping-3gpp-r5-requirements-00.txt
  • - draft-ietf-sipping-cc-transfer-02.txt
  • - draft-ietf-sipping-reg-event-00.txt
  • - draft-ietf-sipping-qsig2sip-04.txt
  • - draft-ietf-sipping-config-framework-02.txt
  • - draft-ietf-sipping-cc-conferencing-03.txt
  • - draft-ietf-sipping-conferencing-requirements-00.txt
  • - draft-ietf-sipping-conferencing-framework-01.txt
  • - draft-ietf-sipping-session-policy-req-01.txt
  • - draft-ietf-sipping-callerprefs-usecases-01.txt
  • - draft-ietf-sipping-kpml-02.txt
  • - draft-ietf-sipping-event-throttle-reqs-00.txt
  • - draft-ietf-sipping-early-media-01.txt
  • - draft-ietf-sipping-app-interaction-framework-01.txt
  • - draft-ietf-sipping-e2m-sec-reqs-01.txt
  • - draft-ietf-sipping-early-disposition-01.txt
  • - draft-ietf-sipping-reason-header-for-preemption-00.txt
  • - draft-ietf-sipping-transc-3pcc-00.txt
  • - draft-ietf-sipping-transc-framework-00.txt
  • - draft-ietf-sipping-sos-00.txt
  • - draft-ietf-sipping-location-requirements-00.txt
  • - draft-ietf-sipping-trait-authz-00.txt
  • Request For Comments:
    RFCStatusTitle
    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

    Current Meeting Report

    Minutes, SIPPING WG, 59th IETF

    Notes by Brian Rosen, Spencer Dawkins, and Cyrus Shaoul
    Minutes edited by Gonzalo Camarillo
    Meetings chaired by Gonzalo Camarillo, Rohan Mahy, and Dean Willis

    Session 1, Monday, March 1, 2004, 0900-1130

    Topic: Status
    Slides presented: pres-sip-ietf59-chairs.ppt
    Discussions led by: Chairs

    The draft tracker in the supplemental web page is up to date.

    Issue: we are not open to new ideas and it takes a long time to finish the drafts we are already working on.
    Discussion: Use deadlines.
    Discussion: Force people to help others (e.g., review documents) before they get their work in the charter. Note that this may make it even more difficult for newcomers to bring their work to SIPPING.
    Conclusion: Chairs will be working on these issues. In addition, they will organize an interim meeting before the 60th IETF.

    Topic: Session Policies
    Relevant documents:
    • draft-hilt-sipping-session-indep-policy-00.txt
    • draft-hilt-sipping-session-spec-policy-00.txt
    • draft-ietf-sipping-session-policy-req-01.txt
    Slides presented: pres-ietf59-hilt-session-policy.ppt
    Discussions led by:  Volker Hilt

    Issue: Session independent policy data and configuration data will use the same delivery mechanism.
    Conclusion: XCAP package, the configuration framework, and the session independent policy work need to be aligned. Once they are aligned, we will be able to consider taking the session independent policy work as a WG item.

    Issue: Two possible models for the session specific policy work: piggyback model and re-direct model.
    Discussion: Both models will most likely need some type of end-to-middle or middle-to-end security.
    Conclusion: More work needed before we can decide which model to choose.

    Topic: The Dialog Package
    Relevant document: draft-ietf-sipping-dialog-package-04.txt
    Slides presented: pres-mahy-sipping-ietf59-dialog-pkg.ppt
    Discussions led by: Rohan Mahy

    Issue: callee-caps feature tag for interactivity.
    Discussion: Media feature tags are usually static. Interactivity has to do with the application, rather than with the media.

    Topic: End-To-Middle
    Relevant documents:
    • draft-ietf-sipping-e2m-sec-reqs-01.txt
    • draft-ono-sipping-end2middle-security-01.txt
    • draft-ono-sipping-smime-keyreuse-00.txt
    Slides presented: pres-sipping-ono-IETF59-e2m.ppt
    Discussions led by: Kumiko Ono

    Issue: We need to find use cases where e2m security is needed.
    Discussion: Emergency may not be a good use case, because proxies may need the information for routing, and the UA does not know those proxies in advance.
    Location outside emergency calls would be a good use case.
    Open question: Should we allow proxies to remove bodies that were only addressed to them?

    Topic: Real-Time Text Conversation Using SIP
    Relevant document: draft-manyfolks-sipping-toip-01.txt
    Slides presented: pres-ietf59-wijk-toip.ppt
    Discussions led by: Arnoud van Wijk

    Issue: what is special about text gateways that is not covered by the transcoding and conferencing frameworks?
    Conclusion: Authors will send scenarios to XCON.

    Topic: Q.SIG SIP Call Transfer
    Relevant document: draft-rey-sipping-qsig2sip-transfer-00.txt
    Slides presented: pres-ietf59-rey-qsig2sip-xfer.ppt
    Discussions led by: Jean-Francois Rey

    Conclusion: The WG can address SIP-related open issues, but will not take this work as a WG item. There is a lack of expertise and interest.

    Topic: S/MIME Certificates in SIP
    Relevant document: draft-jennings-sipping-certs-02.txt
    Slides presented: pres-sipping-jennings-IETF59-Certs-v2.ppt
    Discussions led by: Cullen Jennings

    Issue: is this the same thing as identity?
    Discussion: we need to compare both approaches, because we do not want two mechanisms to do the same thing.
    Discussion: we need a deployabe solution.

    Topic: RTCP Summary Report Event Package
    Relevant document: draft-johnston-sipping-rtcp-summary-02.txt
    Slides presented: pres-ietf59-johnston-rtcp.ppt
    Discussions led by: Alan Johnston

    Conclusion: the authors should explain the difference between this work and RMON.

    Topic: State Update
    Relevant documents:
    • draft-jennings-sipping-connected-00.txt
    • draft-elwell-sip-state-update-00.txt
    Slides presented: pres-sipping-elwell-update-ietf59.ppt
    Discussions led by: John Elwell

    Conclusions: we need more requirements to underand how this related to security and identity.

    Session 2, Wednesday, March 3, 2004, 1300-1500

    Topic: Application Interaction Design Team and Registration Event Package
    Relevant document: draft-ietf-sipping-app-interaction-framework-01.txt
    Slides presented: pres-sipping-jdr-ietf59.ppt
    Discussions led by: Jonathan Rosenberg

    Issue: Matching REFERs to associated components.
    Conclusion: we need an explicit correlator.

    Issue: The current version of the draft, which is in AUTH48, does not allow adding path information.
    Discussion: adding a URI to contact, use "unknown" XML elements...
    Conclusion: Jonathan posts a concrete proposal to the list.

    Topic: KPML
    Relevant document: draft-ietf-sipping-kpml-02.txt
    Slides presented: pres-ietf59-sipping-burger-kpml.ppt
    Discussions led by: Eric Burger

    Issue: should the draft use GRUUs?
    Conclusion: yes, it should use GRUUs.

    Topic: SIP Conferencing Design Team
    Relevant documents:
    • draft-ietf-sipping-cc-conferencing-03.txt
    • draft-ietf-sipping-conference-package-03.txt
    • draft-ietf-sipping-conferencing-requirements-00.txt
    • draft-ietf-sipping-conferencing-framework-01.txt
    Slides presented: pres-ietf59-sipping-johnston-conf.ppt
    Discussions led by: Alan Johnston

    Conclusion: we need to understand how to use nicknames not only in conferences, but in a wider range of situations.

    Topic: Transcoding Design Team
    Relevant document: draft-camarillo-sipping-transc-b2bua-01.txt
    Slides presented: pres-ietf59-sipping-camarillo-transcoding.ppt
    Discussions led by: Gonzalo Camarillo

    Conclusion: Consensus on WGLCing draft-ietf-sipping-transc-3pcc-00.txt

    Issue: should we invoke the transcoder as if it was a conference (current approach) or using Route entries?
    Discussion: no consensus on which is the best approach.

    Topic: Location Conveyance Requirements
    Relevant document: draft-ietf-sipping-location-requirements-00.txt
    Slides presented: pres-ietf59-sipping-polk-location.ppt
    Discussions led by: James Polk

    Issue: Location for emergency calls. Should it be included even if it may be wrong?

    Topic: SIP Emergency
    Relevant documents:
    • draft-ietf-sipping-sos-00.txt
    • draft-schulzrinne-sipping-emergency-arch-00.txt
    Slides presented: pres-ietf59-sipping-henning-emergency.ppt
    Discussions led by: Henning Schulzrinne

    Conclusion: Continue discussions in the mailing list.

    Topic: Exploders and Multiple REFER
    Relevant documents:
    • draft-camarillo-sipping-exploders-02.txt
    • draft-camarillo-sipping-uri-list-01.txt
    • draft-camarillo-sipping-adhoc-management-00.txt
    • draft-hiller-uri-list-index-00.txt
    • draft-levin-simple-adhoc-list-01.txt
    • draft-camarillo-sipping-multiple-refer-00.txt
    • draft-camarillo-sipping-transac-package-00.txt
    Slides presented: pres-ietf59-sipping-camarillo-exploders.ppt
    Discussions led by: Gonzalo Camarillo

    Conclusions: update uri-list draft so that it defines a general mechanism to transport uri lists using headers or URI parameter. Each application will choose where to place the uri list. Write documents explaining how to use uri lists at least for conferencing and presence. Make ad-hoc management a general mechanism that works with different resources. Clarify the requirements (Cullen Jennings will work together with Gonzalo Camarillo on clarifying them).

    Discussion: We will decide whether or not to tackle multiple-REFER when the drafts above have been updated and understood.

    Topic: REFER Extensions
    Relevant document: 
    • draft-olson-sipping-refer-extensions-01.txt
    • draft-mahy-sip-remote-cc-01.txt
    Slides presented: pres-ietf59-sipping-audet-refer.ppt
    Discussions led by: Francois Audet

    REFER Extensions:
    Discussion: we need use cases for each extension to understand their appropriateness.
    Conclusion: tackle each extension separately. Their maturity levels are different.

    REFER for Call Control:
    Discussion: REFER may not be the right tool for this.
    Conclusion: Authors look at the MBUS work done in MMUSIC.

    Ad-Hoc Meeting on E2M and M2E Security, Session Policies, and Location

    Topic: For which applications do we need e2m and m2e security? We need use cases.

    e2m: location conveyance (Non-emergency location based call routing), logging services, and session policies.
    Open question: how does identity fit here?

    m2e:  request history, identity, and Session policy (in piggyback model).
    Open question: if proxies cannot insert bodies, how do we secure request history?

    Topic: Session Policies
    Conclusion: we want to have session independent policies, and they should be aligned with the configuration framework.

    Discussion: Mechanisms for session specific policies can get complicated. We need to agree which requirements we want to meet and which ones we do not want to meet. Three levels:
    1. Request
    2. Response
    3. Asynchronous (this may be implemented using session independent policies)
    Open question: how do UAs disclose session information (e.g., IP addresses being used) to the policy server? Is it SIP using the piggybacking model, SIP using the re-direct model, or a different protocol?

    Action Items
    • Chairs to organize an interim meeting before 60th IETF.
    • Chairs to think of solutions to increase efficiency and newcomer participation.
    • Chairs to WGLC draft-ietf-sipping-transc-3pcc-00.txt.
    • Jonathan Rosenberg to post a concrete proposal on reg-event to the list.

    Slides

    Agenda
    RTCP Summary Report Delivery to SIP Third Parties
    Interworking between SIP and QSIG for call transfer
    S/MIME Certificates
    Instance Identifiers Requirements
    Name that User
    Real-Time Text Conversation Using SIP
    SIP Session Policies
    End-to-middle Security in SIP
    Configuration Framework
    Basic Network Media Services with SIP
    The Dialog Package
    State update
    App Interaction
    Keypad Stimulus Protocol
    Location Requirements
    Extended REFER
    Update on SIP Conferencing
    Transcoding Exploders
    Emergency calling