2.8.19 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:

       Additional SIPPING Web Page

Last Modified: 2003-07-01

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
  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
Mar 03  Submit Internet-Draft on Call Transfer using REFER to IESG for consideration as a BCP
Mar 03  Using ENUM with SIP Applications to IESG for consideration as an Informational RFC
Apr 03  Submit Call Info SIP event package to IESG for consideration as PS
Apr 03  Requirements for Reuse of Connections in SIP
Jun 03  Submit Internet-Draft on T.38 Fax Call Flows to IESG for consideration as a BCP
Jun 03  Submit Conf Info SIP event package to IESG for consideration as PS
Jun 03  Requirements for SIP Request History
Jun 03  Event Package for User Configuration Profiles
Aug 03  Submit Internet-Draft on Multi-Party/Conferencing Framework to IESG for consideration as an Informational RFC
Done  Submit Internet-Draft on Requirements for AAA Application in SIP Telephony to IESG for consideration as an Informational RFC
Oct 03  Sip Interworking with QSIG
Nov 03  Review charter with Area Directors and recharter or conclude
Nov 03  Submit Internet-Draft Torture Tests to IESG for Consideration as Informational
  • - draft-ietf-sipping-e164-03.txt
  • - draft-ietf-sipping-service-examples-04.txt
  • - draft-ietf-sipping-realtimefax-01.txt
  • - draft-ietf-sipping-cc-framework-02.txt
  • - draft-ietf-sipping-3pcc-04.txt
  • - draft-ietf-sipping-mwi-03.txt
  • - draft-ietf-sipping-content-indirect-03.txt
  • - draft-ietf-sipping-dialog-package-02.txt
  • - draft-ietf-sipping-conference-package-01.txt
  • - draft-ietf-sipping-pstn-call-flows-02.txt
  • - draft-ietf-sipping-basic-call-flows-02.txt
  • - draft-ietf-sipping-torture-tests-00.txt
  • - draft-ietf-sipping-req-history-04.txt
  • - draft-ietf-sipping-aaa-req-03.txt
  • - draft-ietf-sipping-3gpp-r5-requirements-00.txt
  • - draft-ietf-sipping-cc-transfer-01.txt
  • - draft-ietf-sipping-connect-reuse-reqs-00.txt
  • - draft-ietf-sipping-reg-event-00.txt
  • - draft-ietf-sipping-qsig2sip-02.txt
  • - draft-ietf-sipping-ua-prof-framewk-reqs-00.txt
  • - draft-ietf-sipping-config-framework-00.txt
  • - draft-ietf-sipping-cc-conferencing-01.txt
  • - draft-ietf-sipping-conferencing-requirements-00.txt
  • - draft-ietf-sipping-conferencing-framework-00.txt
  • - draft-ietf-sipping-session-policy-req-00.txt
  • - draft-ietf-sipping-callerprefs-usecases-00.txt
  • Request For Comments:
    User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired individuals (RFC 3351) (33894 bytes)
    Session Initiation Protocol (SIP) for Telephones (SIP-T): Context and Architectures (RFC 3372) (49893 bytes)
    Short Term Requirements for Network Asserted Identity (RFC 3324) (21964 bytes)
    Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping (RFC 3398) (166207 bytes)
    The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) (RFC 3485) (80195 bytes)
    Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) (RFC 3578) (26667 bytes)

    Current Meeting Report

    Minutes, SIPPING WG, IETF 57
    Notes by Tom Taylor, AC Mahendran, and Hisham Khartabil
    Minutes edited by Dean Willis
    Chat room moderation by Brian Rosen
    Meetings chaired by Gonzalo Camarillo, Rohan Mahy, Dean Willis
    Session 1, July 14, 2003 1930-2200
    Topic: Agenda
    Agenda accepted as previously posted. 
    Topic: Announcements and Status
    Chairs mentoin the SIP device reqts ad hoc 10-11 am Thur room J241/1, and 
    that the QoS promotion scheme draft will be discussed in Friday's TSVWG 
    Slides presented reviewing status of working group documents. 
    Topic: SIP to QSIG Mapping
    Relevant document: 
    Slides presented
    Discussion led by John Elwell
    Issue: We need more qualified reviewers for this work. A hand-poll taken in 
    the room indicated about a dozen people claiming to be familar with QSIG.  We 
    discussed possibly working with external SDOs on this. Discussion 
    indicated that ECMA is the likely SDO. John Elwell took the action item of 
    providing a list of ECMA contacts to Allison Mankin.
    No conclusion.
    Actions: Francois Audet to formally review document.
    Topic: Dialog Package
    Relevant document:
    Slides presented:
    Discussion led by Jonathan Rosenberg
    Status: Went through WGLC.  Minor comments incorporated.  Unable to 
    restrict a particular XML type in XML -- has only the accompanying text to 
    provide the constraint.
    Issue: extensions proposed (Sean Olson).  Question: what to do with them?  
    Extend scope of main package, reject them, or document them 
    Issue: "on hold".  Not clear what "on hold" means, since media can flow 
    anyway. Suggestion that this isn't a dialog state.
    Conclusion: Rough consensus that we are not ready to advance the dialog 
    package at the present time.  Concerned parties instructed to discuss and 
    report back to Thursday mtg.
    Topic: Discussion of Configuration Issues
    Relevant documents:
    Slides presented:
    Some open issues w/ profiles.  No discussion. No conclusion on 
    framrework or profiles.
    Issue: potential conflict between XCAP package (SIMPLE work item) and 
    sip-config. XCAP fits into framework: config retrieval, change notif, 
    config upload. Differences in many details. Do they share the same 
    requirements?  Do they share the same solution?  Should they be 
    Proposal to unify led to comment that config is a much more general 
    problem -- it may not be reasonable to use SIP for notifications in view of a 
    more general model coming perhaps out of netconf.  This may reflect the 
    views of a number of people in the IETF at large.  We will need to have a 
    clear explanation of scope.
    Key point: all of the entities involved have SIP addrs.  Fairly tightly 
    Proposal: merge or reorg the two drafts.  Need an author w/more cycles.  
    Poll indicated rough consensus in favour, with some hums opposed. Locus of 
    work to be discussed w/ ADs, noting two different areas are involved.
    Conclusion: Chairs to discuss with ADs.
    Topic: Session Policy and Middle Box Issues
    Relevant Document:
    Discussion led by Jonathan Rosenberg
    Issue: Dynamic vs static policies
       -- Allison: not necessarily either/or
       -- Jonathan just concerned to eliminate unnecessary reqts
       -- CALEA an arg against dynamic policies
    Rohan volunteers to work on mechanism if he has some help.
    Questions on reqt for enforcement of policy.  Audience asked to review text 
    and submit desired changes.
    No conclusion.
    Editors note: 3GPP is expecting some results here.
    Topic: URI Leasing and GRUUS
    Relevant document:
    An informal group met prior to this meeting. They noted that embedded 
    route headers prevent proxy application of policy and user services, and 
    that  leasing has a couple of other advantages.  This groups 
    conclusion is that leasing seems to be the way to go.  There appear to be 
    some open issues wrt GRUU grants. The author will add requirement that 
    leasing be stateless to the requirements doc.
    Conclusion: Agreed that requirements shall address stateless leasing. 
    Consensus that work will continue with leasing model at this time.
    Topic: Firewall and NAT Traversal
    Relevant Document:
    Slides presented in:
    Status report
    ice-01 addresses concerns raised in IETF 56
       -- backward compatibility
       --- case that breaks bkwd compatibility is multihomed host. alt 
    framework vs. alt attribute being taken into off-line discussion
    ice-01 has ~50 pages of example flows -- proposed replacement of 
       -- ice algorithm works out
       -- troublesome case is v4-v6
       -- need add call flow between ice and non-ice hosts
    Question from chair: if Jonathan adds the required cases, is this a 
    sufficient replacement for what we have now in the 
    sipping-nat-scenarios document? Consensus is that it is adequate, 
    provided that we add text to allow alternate approaches (such as ALG, 
    MIDCOM) and add cases for MSRP relay. Francois Audet volunteered to send 
    text relating to alternate approaches.
    Process open issues:
    1. Do we proceed, and if so, in which WG? 
       -- main ice behaviour -- mmusic?
       -- SDP extensions -- mmusic
       -- preconditions -- if people care, would go to sip  (poss mmusic)
       -- usage scenarios -- repl sipping-nat-scenarios -- sipping
    Conclusion: Hums indicated a consensus to do core ICE behavior and SDP 
    changes in MMUSIC, usage scenarios in SIPPING, and preconditions work in SIP 
    if needed.
    Chairs are to discuss division of work with ADs.
    Topic: Adding Realm Identifier for Private Addresses
    Relevant Document:
    Slides presented in:
    Notes: Adds explicit realm identifier for private (i.e. "local") 
    addresses into SDP.  Useful in case both endpoints have a priori 
    knowledge that they are in the same 
    realm -- can avoid ICE. Need to configure realm only if multiple media 
    terminations behind the same NAT which will communicate with each other. 
    Proposes SDP attribute.  Configuration mech out of scope of current 
    Discussion on network toplogy and applicability indicated that some 
    additional clarity is needed.  How does this relate to 
    Conclusion: Requires further list dicussion.  Burden of proof is on 
    Francois to say it is worth varying from general application of ICE.
    Topic: Open Issues from Conferencing Design Team
    Relevant documents:
             draft-ietf-sipping-cc-conferencing  SIP
    Slides presented in:
              pres-levin-conf team-update-ietf-57.ppt
    Discussion led by Orit Levin 
    Status: Conceptual issues resolved: basic conf by SIP, adv would use XCON 
    (they hope).  Design team work is almost complete and they welcome 
    general comments.  If XCON forms a working group, it may be possible to 
    reduce the scope of 
    draft-ietf-sipping-conferencing-requirements to "just the SIP 
    Open issues with 
    draft-ietf-sipping-conferencing-requirements: Focus discovery.
    Open issues with 
    draft-ietf-sipping-cc-conferncing: add details for selected msgs in 
    presented call flows, or move into sip draft for mechanisms.
    Open issues with 
    draft-ietf-sipping-conference-package: Needs another rev e.g. re sidebar 
    conversations Looking to future draft on implementation of sidebar
    Topic: Open Issues from Transcoding/Deaf Design Team
    Relevant Document:
    Slides presented in:
    Discussion led by Gonzalo Camarillo.
    Status: Resuming design team meetings. Transcoding has dependencies which 
    may be isolated in a separate draft.
    No conclusion.
    Topic: Report from Energency Calling Design Team
    Slides presented in:
    Discussion led by Gonzalo Camarillo
    Status: Scenarios doc to appear within a couple of weeks.
    Topic: Requirements for SIP Service Configuration
    Note: This has some bearing on 3GPP's use of SIP.
    Proposal: Extend config framework to include service info.
    Open issue: Which server to contact for data manipulation (XCAP)?
    Open issue: Download conference-factory URI for automatic conf creation
    No conclusion.
    Session 2, Thursday, July 17, 2003,  1300-1500
    Topic: Agenda and Status
    Review requested for new digest-AKA draft. 
    Topic: Open Issues from Application Interaction Design Team
    Relevant Documents:
    Slides presented in:
    Discussion led by Jonathan Rosenberg
    KPML DTMF reporting problem
    -    INFO ( Cannot work within call dialog)
    -    NOTIFY w implicit subscription
    -    Explicit subscription from application
    -    HTTP
    -    New method?
    -    MESSAGE
    Design team reluctantly chose MESSAGE!
    -    Continue to hammer out the open issue
    -    Adopt the framework and KPML as SIPPING items.
    a) Hum on "This is interesting work and that we should adopt the 
    framework" - Accepted.
    b) Hum on "All who believe KPML should be accepted as WI" - accepted.
    c) Chairs will ask the AD to adopt framework and KPML as WG items.
    d) The KPML reporting issue will be discussed more on the mailing list.
    Topic: Early Media
    Relevant document:
    Discussion led by Gonzalo Camarillo
    Changes since last rev include clarifying which features are specific to 
    early media and which ones to SIP and other editorial changes.
    To be done: Align application server model section with app design team
    No conclusions.
    Topic: Conveying Tones in SIP
    Relevant document:
    Discussion led by Rohan Mahy
    Issue:  How to provide tones?
    Options discussed include
       1) In RTP
            a. Speech codec - poor choice
            b. Using audio/tone AVT payload
            c. Using audio/telephone-event AVT payload
        2) Referenced externally by URI with Alert-info or 
        3) In a SIP header (proposed back in Nov 2000)
        4) In the session description
        5) In SIP body
            a. Use Content-Disposition: Render
    If in a body, What body types are available?
        1) Traditional
            a. Wav, au, mp3
        2) Audio/tone
        3) Audio/tone-info+xml
        4) Many more..
        5) XML based:  Audio/tone-info+xml
    -Use of midi was suggested by Henning.
    Conclusions: The issue on tones will be discussed more on the list.
    Topic: Network Announcements
    Relevant document:
    Discussion led by Eric Burger.
    Open Issues:
        1) Early media:
            Punt. No definitions for early media
            Makes 487/409 problem go away.
        2) Media on hold
            Punt. Local matter
        3) Multiple media streams
            Punt. Netann is about objects not streams
            Only composite objects for multimedia
        4) VoiceXML keyword without value
            Generate 404 with explanation.
    Poll taken for adoption as a working group item indicated little 
    support. However, the work is not seen as being in opposition to 
    chartered work.
    Conclusions: The draft will be submitted for publication as an 
    individual contribution.
    Topic: Event Filtering and Throttling
    Relevant document:
    Slides presnted in:
    Discussion led by Aki Niemi
        1) Updated model. A throttle defines minimum time period between two 
        2) Updated use cases
        3) Refined requirements
        4) Aligned language with model
    Open issues:
        1)  Should use cases be more elaborate?
            Proposal: No
        2) Are Requirements are solid enough?
           Seem to be.
        3) Is scope for work well defined?
            Seem to be.
    -    It was suggested that it would be worth noting in the draft about the 
    type of buffering needed (like LIFO, FIFO etc)
    Conclusion:  Chairs will recommended to the ADs to adopt this draft as WG 
    Topic: DPNSS to SIP Interworking
    Relevant document:
    Slides presented in:
    Discussion led by Ranjith Mukundan
    Difference between DPNSS MIME and QSIG/ISUP MIME
        1) Similar to RFC 3204 (MIME for ISUP/QSIG
        2) Mandates single binary coded octet message length field
        3) Specifies message buffering option
        4) Mandates single DPNSS call per SIP dialog
    - Henning indicated that this doesn’t work with the MIME model.
    - Some were skeptical about the usefulness of doing this work. 
    - There was a feeling that the group did not have enough expertise to take on 
    this work.
    - Gonzallo indicated that solving the MIME type is reasonable but the 
    translation work is a tough thing to do.
    Conclusions: This will NOT be taken as WG item and it will proceed as an 
    individual contribution.
    Topic: Discussion of End-to-Middle Security
    Relevant document:
    Slides presented in:
    Discussion led by  Kumiko Ono
        1) End-to-end encryption may conflict with some features provided by 
        2 )Use cases:
            a. Logging services (IM logging, other logging)
            b. Hotspot service
            c. Connecting to home SIP server via partially trusted proxy
         3) Session-policy
         4) Transcoding
    Proposed Mechanism:
    -    Allows a UA to disclose data to selected intermediaries
    -    End-to-middle encryption uses S/MIME CMS Enveloped data for 
    -    People felt that this is a very interesting WI.
    -    Jonathan R said that we need to add more use cases to explain the 
    problem of addressing data for intermediaries by user-agent.
        1) There was consensus in the room that work has enough interest in the 
        2) There was consensus that the requirements on end-to-middle & 
    middle-to-end security should to be taken on as WG item.
    Topic: Phone-related Status and Presence
    Relevant document:
    Slides presented in:
    Discussion led by Jonathan Rosenberg
    -Difference between human presence vs device presence. 
    - Rohan said that states like dialing/ringing etc are not applicable to 
    device or user; these are particular to a call/dialog. Some of the raw data 
    is useful, but presence may not be right place for it.
    - Henning: Information like line-state etc are not too useful as 
    presence information.
    a) Hum on "Dealing with presence issues of phone" as useful work 
    indicated a consensus..
    b) Jonathan proposed to develop more use cases for the draft.
    c) Is this a SIMPLE or SIPPING activity? Chairs to discuss with SIMPLE 
    Topic: Session Diagnostics in SIP
    Relevant document:
    Slides presented in:
    Discussion led by Alan Johnston
        1) Delivery of RTCP summary reports to third parties
            a. Logging is main motivation
        2) Three alternatives
            a. Forking RTCP to multiple locations
            b. Carrying in SIP header in BYE
            c. Event package (preferred)
    1)  Should RTCP be transferred to third parties? 
    2) What is the purpose of this? If this is for fault management or 
    performance management, this is not needed. SNMP management tools should be 
    3) How does this compare to RMON?
    Conclusions: This will be deferred to this to the list. Alan is asked to 
    investigate RMON work and provide some comparison here.
    1) John Elwell volunteered to provide a list of ECMA contacts for QSIG to 
    SIP work o Allison Mankin.
    2) Chairs to discuss netconf and XCAP reconciliation proposals with ADs.
    3) Francois Audet volunteered to review the qsig2sip document and 
    respons on-list.
    4) Francois Audet volunteered to send text relating to alternate 
    approaches such as ALG and MIDCOM for the ICE usage scenarios 
    5) Chairs to discuss moving some ICE work into MMUSIC and SIP with ADs.
    6) Chairs to discuss  adding 
    draft-rosenberg-sipping-app-interaction-framework-00 and  
    draft-burger-sipping-kpml-02 as WG items with ADs.
    7) Chairs to work withs AD to add charter item(s) for 
    end-to-middle and middle-to-end security requirements.
    8) SIPPING chairs to discuss phone-presence with SIMPLE chairs and ADs to 
    dtermine where thiswork belongs.
    9) Alan Johnston was asked to consider how RMON work relates to 
    proposed RTCP summary work and report to the mailing list.


    SIPPING WG Status
    QSIG-related drafts
    Update on SIP Conferencing Status
    User Profile Framework draft-ietf-sipping-config-framework-00.txt
    Transcoding/deaf Design Team
    Event Throttle Requirements draft-niemi-sipping-event-throttle-reqs-02
    Event Throttle Requirements draft-niemi-sipping-event-throttle-reqs-01
    Issues and Status in App Interaction Team
    Network Announcements with SIP
    Identifying intra-realm calls with explicit addressing realm identifier attribute
    RTCP Summary Report Delivery to SIP Third Parties
    SIP Configuration Issues: IETF 57, SIPPING
    Conveying Tones in SIP: IETF 57, SIPPING
    MIME media types for DPNSS Objects in SIP
    End-to-middle Security in SIP