2.7.16 Session Initiation Proposal Investigation (sipping)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
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: 2005-07-25

Chair(s):

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Dean Willis <dean.willis@softarmor.com>
Rohan Mahy <rohan@ekabal.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
Done  3pcc Transcoding to IESG as Info
Done  KPML to IESG as PS
Done  Conferencing Requirements to IESG as Info
Done  Conferencing Framework to IESG as Info
Done  Conferencing Call Control-Conferencing to IESG as BCP
Sep 04  Location Requirements to IESG as Info
Done  End-to-Middle Security Requirements to IESG as Info
Sep 04  Requirements on Trait-Based Authorization to IESG as Info
Done  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

Internet-Drafts:

  • draft-ietf-sipping-service-examples-09.txt
  • draft-ietf-sipping-cc-framework-04.txt
  • draft-ietf-sipping-nat-scenarios-02.txt
  • draft-ietf-sipping-dialog-package-06.txt
  • draft-ietf-sipping-conference-package-12.txt
  • draft-ietf-sipping-torture-tests-07.txt
  • draft-ietf-sipping-cc-transfer-05.txt
  • draft-ietf-sipping-qsig2sip-04.txt
  • draft-ietf-sipping-config-framework-07.txt
  • draft-ietf-sipping-cc-conferencing-07.txt
  • draft-ietf-sipping-conferencing-requirements-01.txt
  • draft-ietf-sipping-conferencing-framework-05.txt
  • draft-ietf-sipping-callerprefs-usecases-04.txt
  • draft-ietf-sipping-kpml-07.txt
  • draft-ietf-sipping-app-interaction-framework-05.txt
  • draft-ietf-sipping-e2m-sec-reqs-06.txt
  • draft-ietf-sipping-reason-header-for-preemption-03.txt
  • draft-ietf-sipping-transc-framework-02.txt
  • draft-ietf-sipping-trait-authz-01.txt
  • draft-ietf-sipping-session-indep-policy-03.txt
  • draft-ietf-sipping-uri-services-03.txt
  • draft-ietf-sipping-uri-list-conferencing-03.txt
  • draft-ietf-sipping-uri-list-message-03.txt
  • draft-ietf-sipping-uri-list-subscribe-03.txt
  • draft-ietf-sipping-multiple-refer-03.txt
  • draft-ietf-sipping-certs-02.txt
  • draft-ietf-sipping-consent-reqs-01.txt
  • draft-ietf-sipping-consent-framework-02.txt
  • draft-ietf-sipping-toip-01.txt
  • draft-ietf-sipping-spam-01.txt
  • draft-ietf-sipping-transc-conf-00.txt
  • draft-ietf-sipping-v6-transition-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3324 I Short Term Requirements for Network Asserted Identity
    RFC3351 I User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired individuals
    RFC3372 BCP Session Initiation Protocol (SIP) for Telephones (SIP-T): Context and Architectures
    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)
    RFC3665 BCP Session Initiation Protocol Basic Call Flow Examples
    RFC3666 BCP Session Initiation Protocol PSTN Call Flows
    RFC3680 Standard A Session Initiation Protocol (SIP) Event Package for Registrations
    RFC3702 I Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol
    RFC3725 BCP Best Current Practices for Third Party Call Control in the Session Initiation Protocol
    RFC3824 I Using E.164 numbers with the Session Initiation Protocol (SIP)
    RFC3842 Standard A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
    RFC3959 Standard The Early Session Disposition Type for the Session Initiation Protocol (SIP)
    RFC3960 I Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)
    RFC4083 I Input 3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)
    RFC4117 I Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)

    Current Meeting Report

    Minutes SIPPING WG at IETF 63
    SIP P2P adhoc meeting notes
    TISPAN adhoc meeting notes

    Minutes edited by Gonzalo Camarillo
    Based on notes by Flemming Adreasen and Stephen Hayes
    Meeting chaired by Dean Willis, Rohan Mahy, and Gonzalo Camarillo

    WEDNESDAY, August 3, 2005, 1030-1230

    Topic: Agenda Bash
    Discussions led by: Chairs

    There was an off-line last-minute discussion between Jonathan Rosenberg and the authors of the profile datasets. As a consequence, the presentation of the profile datasets was moved to the second SIPPING session in order to be able to present the results of this discussion to the group.

    The chairs presented the status of a number of drafts:

    o The torture tests draft has problems with the S/MIME examples. The authors will work with the security area director to fix them.

    o All the URI-list services drafts have been WGLCed already. Since they depend on the consent framework, they will not be sent to the IESG until consent is ready.

    o There was a problem with the submission of the RTCP summary draft. The authors will add a set of minor comments and resubmit after the meeting.

    o There were very few comments during the WGLC on the trait-based authorization draft. The chairs polled the room and only few people had read the draft. Among those who had read it, there was consensus that the draft was ready. The chairs will review the draft and decide whether it is ready to be sent to the IESG.

    o The SIPPING WG assigned Gonzalo Camarillo to perform an expert review on the PoC settings event package draft. He had already performed it before the meeting.

    Rohan Mahy had concerns related to congestion of non-INVITE-transaction with the multiple-MESSAGE draft. There was a discussion in the room during which it was noted that this had already been discussed one year ago. The conclusion, based on the consensus in the room, was to go ahead with the draft adding some warning text to it.

    The chairs discussed a number of individual contributions:

    o The following draft was considered to be out of scope of SIPPING: draft-sohel-sipping-s-bc-concept-arch-00.txt

    o There were discussions on the following draft: draft-elwell-sipping-redirection-reason-02.txt. The problem of adding additional reason information to responses has appeared many times in the past. The WG is interested studying the problem. We need a solution for it. The chairs will talk to the AD to decide whether or not SIPPING will tackle this work.

    o The chairs stated that there is no interest and expertise in the WG to work on the following draft: draft-ma-h323-sip-conf-requirement-00.txt.

    o There were discussions on the following draft: draft-levin-simple-interdomain-reqs-02.txt. Some people stated that this is an interesting problem, but that the solution proposed in the draft is not the right one. Discussions to continue in the mailing list. The chairs will talk to the AD to see if this type of work could fall inside the scope of the WG.

    o There was consensus in the group that the following draft is useful: draft-hasebe-sipping-exceptional-procedure-example-01.txt. The authors will continue working on it with some volunteers. The chairs will talk to the AD to see whether SIPPING can tackle this as a WG item or whether it should continue as an individual contribution. One thing that will need to be decided is whether examples are enough in all cases or whether we need normative clarifications to some RFCs.

    o The author of the following draft brought it to the attention of the
    WG in order to get feedback on it:
    draft-niemi-sipping-cal-events-00.txt

    The chairs noted that they are having a lot of problems updating the charter in the official web page. There was a suggestion to maintain an up to date charter on our supplementary page if the problems persist. There was a request for setting up a web page where WGLCs would be scheduled ahead of time so that people could allocate time for them in advance. Gonzalo Camarillo committed to find a secretary for the WG to maintain the web page.

    Topic: Session-Independent Policies
    Discussion led by: Volker Hilt
    Relevant document: draft-ietf-sipping-session-indep-policy-03.txt
    Slides presented included in the proceedings

    The author mentioned that the policy format has been aligned with the policy datasets framework. The author asked people to read the draft and send comments.

    Topic: Session-specific Policy Use Cases
    Discussion led by: Volker Hilt
    Relevant document: draft-hilt-sipping-policy-usecases-00-txt
    Slides presented included in the proceedings

    The author presented the draft and asked for comments.

    Topic: Session-specific Policies
    Discussion led by: Volker Hilt
    Relevant document: draft-hilt-sipping-session-spec-policy-03-txt
    Slides presented included in the proceedings

    The author presented the draft. It was commented that the mechanism needs to take into consideration scenarios with more than one policy server. There were discussions on the mechanism to transport policy information between the user agent and the policy server. It was concluded that more discussions on the list are needed.

    Topic: Consent Framework
    Discussion led by: Gonzalo Camarillo
    Relevant document: draft-ietf-sipping-consent-framework-02.txt
    Slides presented included in the proceedings

    The author presented the new draft, which introduces major architectural changes when compared with the previous version of the draft. The author answered questions and clarified some points that were unclear from his presentation. There was consensus in the room that this is the way to go.


    Topic: SIP-unfriendly Functions in Current Communications Architectures
    Discussion led by: Jani Hautakorpi
    Relevant document: draft-camarillo-sipping-sbs-funcs-01.txt
    Slides presented included in the proceedings

    The author presented the draft. The common reaction from people that read the draft was that the work is useful and that it should include more details on why things break in the different scenarios presented in the draft. The chairs need to talk to the AD to decide whether we want to use this document as input to other work without publishing as an RFC or whether we publish it as an RFC (when it is ready) to be able to point to the document every time we need to explain somebody why a particular way of implementing a function breaks SIP.

    Topic: SIP Event Throttles
    Discussion led by: Aki Niemi
    Relevant document: draft-niemi-sipping-event-throttle-03.txt
    Slides presented included in the proceedings

    The author explained that now the draft describes explicitly how throttles work with RLSs. It can be used without them, but it is meant to be used with RLSs. The author presented a set of open issues. There was consensus that batching functionality should not be included in this document. There was consensus in the room that this is the right direction for this work. The chairs asked whether or not this is ready to be sent to SIP, but there was no clear consensus on this point.

    Topic: SIP Event Framework Issues
    Discussion led by: Aki Niemi
    Relevant document: draft-niemi-sipping-subnot-issues-00.txt
    Slides presented included in the proceedings

    There were discussions on the technical issues presented. These discussions will continue on the list. One thing to be clarified in the draft is that the it will deal, in principle, with subscription timeouts, and not with transaction timeouts.

    Topic: Registration Event Package Extension
    Discussion led by: Paul Kyzivat
    Relevant document: draft-kyzivat-sipping-gruu-reg-event-03.txt
    Slides presented included in the proceedings

    There was consensus to have the author resubmit the draft as a WG item and WGLC it right after that.

    The first SIPPING session ended.


    THURSDAY, August 4, 2005, 1030-1230

    Topic: Agenda Bash
    Discussions led by: Chairs

    There was no additional agenda bashing besides the one in the first session.

    Topic: Real-time ToIP
    Discussion led by: Arnoud van Wijk
    Relevant document: draft-ietf-sipping-toip-01.txt
    Slides presented included in the proceedings

    The author will release a new revision of the draft (02) including a few comments received. There was consensus that revision 02 will be ready for WGLC.

    Topic: Profile Datasets
    Discussion led by: Dan Petrie
    Relevant document: draft-ietf-sipping-profile-datasets-01.txt
    Slides presented included in the proceedings

    Jonathan Rosenberg extressed his concerns with the complexity introduced to the model because of data merging. He proposed to focus on data representation and semantics, and tackle merging at a later stage in a different document. A number of people stated that merging should be available from day one. Another issue related to merging that was brought forward was the meta policy needed to implement merging. Coming up with such a meta policy may be an intractable problem in some cases. The discussions will continue on the mailing list. The chairs will talk to Allison to check whether this work is within the scope of SIPPING. There was consensus in the room that, if this work falls within the scope of SIPPING, it should be a WG item.

    Topic: Proposed Fix to HERFP
    Discussion led by: Rohan Mahy
    Relevant document: draft-mahy-sipping-herfp-fix-00.txt
    Slides presented included in the proceedings

    There was consensus in the room that this is an important problem the WG should be working on. Regarding the particular mechanism so resolve it, a number of people claimed that there may be alternatives to the mechanism proposed in this draft. Discussions to follow in the mailing list.

    Topic: TISPAN
    Discussion led by: Denis Alexeitsev
    Relevant document: draft-jesske-sipping-tispan-requirements-01.txt
    draft-jesske-sipping-tispan-analysis-00.txt
    draft-jesske-sipping-etsi-ngn-reason-00.txt
    Slides presented included in the proceedings

    There were discussions on how to proceed with these requirements. The conclusion was to form a design team to clarify the requirements so that the community can understand them better. There was consensus in the room to produce such a clarified requirements document. The design team will not work on solutions, though. Once the requirements are documented the working group will decide the best way to work on solutions for those requirements.

    Note that previous to this session, there was a TISPAN ad-hoc meeting organized by the SIPPING working group where some of the requirements were discussed.

    Topic: P-Answer-State
    Discussion led by: Andrew Allen
    Relevant document: draft-allen-sipping-poc-p-answer-state-header-00.txt
    Slides presented included in the proceedings

    There is an issue on how to indicate in a NOTIFY (related to a REFER) that the answer state is confirmed when the controlling PoC server is at the same time the PoC server of the user agent client. An option seemed to be to place a "fake" P-Answer-State P-header in the body of the NOTIFY. More discussions are needed. Folks will provide Andrew with comments on the mailing list. Once this issue is resolved, SIPPING will perform an expert review on this draft.

    Topic: Implicit Subscriptions
    Discussion led by: Jonathan Rosenberg
    Relevant document: draft-rosenberg-sipping-reg-sub-00.txt
    Slides presented included in the proceedings

    There was consensus in the room that there is a problem with implicit subscriptions that needs to be solved. However, people did not agree on where the problem is. More discussions needed in order to figure out which problems are important and which ones are perceived to be important but they are not.

    Topic: Media Privacy
    Discussion led by: Henning Schulzrinne
    Relevant document: draft-shacham-sip-media-privacy-00.txt
    Slides presented included in the proceedings

    It was stated that it is hard to determine in an automatic way whether or not a conversation is private. There are two issues: request and indication. Request seems to be solvable. More discussions needed.

    Topic: SIP User Identifiers
    Discussion led by: Henning Schulzrinne
    Relevant document: draft-schulzrinne-sipping-id-relationships-00.txt
    Slides presented included in the proceedings

    It was stated that presence can give you the mappings of IDs in a better way. There is a problem when one does not know whether or not the other domain follow these conventions. It was argued that this solution may be usable in enterprise environments. This work was considered to be outside the scope of SIPPING.

    The second SIPPING session ended. **********
    Minutes of TISPAN ad-hoc meeting at IETF 63
    Organized by the SIPPING WG

    Minutes edited by Gonzalo Camarillo
    Based on notes by Tom Taylor
    Meeting chaired by Gonzalo Camarillo

    TUESDAY, August 2, 2005, 1815-1945

    Topic: TISPAN requirements
    Discussions led by: Denis Alexeitsev
    Relevant documents: draft-jesske-sipping-tispan-analysis-00.txt
                        draft-jesske-sipping-tispan-requirements-01.txt
                        draft-jesske-sipping-etsi-ngn-reason-00.txt
                        draft-garcia-sipping-etsi-ngn-p-headers-00.txt 
    
    Slides presented included in the proceedings

    The purpose of this ad-hoc meeting was to get a common understanding of the requirements developed by the TISPAN folks. The decision about how to move forward was to be made in the SIPPING session, not during this ad-hoc.

    The following services are within the scope of the requirements:

    Anonymous Communication Rejection
    Terminating Indication Presentation
    Advice of Charge
    Call Completion on Busy Subscriber CCBS
    CCNR
    MCID
    Communication Diversion

    Issue: ACR

    There is a need to return a reason code in some scenarios. Two possibilities would be to allow Reason header fields in responses or to use warning codes in warning header fields.

    It was noted that this service would only be available if the callee supports this extension. It was noted that if new general status codes are needed, they should be defined. If eventually, we ran out of them, we could find ways to extend the status code space. If what is needed is to have more details within a given status code, Warning entries can be used for that.

    Issue: ACR override

    It was noted that this is not really about overriding policies, but about defining the policy properly. That is, the policy would be "the police can call me even if my phone is in not-disturb mode". The way the service is described at this point is confusing.

    Issue: Terminating Indication Presentation

    The called party needs to provide an identity to the calling party. There is a need to clarify whether the information needs to be verifiable or not and whether this is about response identity or the identity of the connected party. In the latter case the solution could be based on requests carrying the information, and not on responses.

    Issue: Advice of Charge

    An indication of charging info within an active session is needed. It should be available for MESSAGE requests as well as INVITE-initiated sessions. More work on the requirements is needed before solutions can be discussed.

    Issue: Communication Completion on Busy Subscriber

    There is a requirement that the caller is able to know whether or not the callee returning an error response (e.g., 486 Busy) supports the dialog event package.

    There is a number of issues with the queueing policy at the called party for sequential notifications. This may be a general issue to work on.

    It was noted that designing solutions for all the requirements may take a longer time than what TISPAN expects (i.e., the end of the year).

    The meeting ended and most of the people went to the social event. Discussions on how to move forward took place in the SIPPING session.

    ******************


    Minutes of Peer-to-peer SIP ad-hoc meeting at IETF 63
    Organized by the SIPPING WG

    Minutes edited by Gonzalo Camarillo
    Based on notes by Cullen Jennings
    Meeting chaired by Henning Schulzrinne
    Slides presented included in the proceedings

    THURSDAY, August 4, 2005, 0900-1000

    There were around 125 attendees. The goal of this ad-hoc meeting was to discuss developing scenarios where p2p technologies may be used. These scenarios include:
    1. Distributed Location Server: Use a distributed P2P system to distribute the register/location server information
    2. Configuration Storage: Store configuration details for a phone across the networks
    3. Voice Mail:
    4. Address Book Storage
    5. Reputation Systems
    6. Gateway
    7. Media Relay
    8. Media Anonymization

    People showed interest in working on the following topics:
    1. Scale: Both scaling up and down
    2. Reliability
    3. Federations
    4. Trust Models
    5. Identity
    6. Namespaces
    7. Data Storage

    All the systems described had somewhat common approaches in that they were using DHTs as the underlying approach. Attention should be paid to when it is the right time to use P2P technology and when other approaches such as DNS and Multicast can provide a better solution.

    It was commented that we should publish some of this before it all gets patented. When it comes to finding an arrangement to work on these issues in the IETF, folks may want to look at what the HIP (Host Identity Protocol) community did. The also had long and short-term goals and they formed an IETF WG and an IRTF RG at the same time.

    The feeling was that this work would not overlap with the work being done in the p2prg at this point.

    People suggested to have a full-day meeting right before the next IETF to discuss this work in depth.

    The meeting ended and folks took a half an hour break before the SIPPING session.

    Slides

    Status and Agenda Bash
    Data Sets
    Session Policies
    Consent Framework
    SIP-unfriendly Functions in Current Architectures
    Event Throttles
    Framework of Requirements for Real-time Text Conversation using SIP
    Reg Event Package Extension
    Solutions to the Heterogeneous Error Response Forking Problem (HERFP)
    TISPAN Requirements and Solutions
    OMA P-Answer-State P-header
    SUBSCRIBE/NOTIFY Issues
    Implicit Subscriptions
    SIP user identifiers
    Media Privacy
    Intercommunity
    Exceptional Procedures
    TISPAN Requirements and Possible Solutions
    Peer-to-peer SIP Ad-hoc meeting
    draft-bryan-sipping-p2p