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 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-27

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Dean Willis <dean.willis@softarmor.com>
Rohan Mahy <rohan@cisco.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
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
DEC 02  Requirements for Content Indirection in SIP
FEB 03  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
AUG 03  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-conferencing-models-01.txt
  • - draft-ietf-sipping-e164-02.txt
  • - draft-ietf-sipping-overlap-04.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-03.txt
  • - draft-ietf-sipping-sigcomp-sip-dictionary-05.txt
  • - draft-ietf-sipping-mwi-02.txt
  • - draft-ietf-sipping-content-indirect-03.txt
  • - draft-ietf-sipping-nat-scenarios-00.txt
  • - draft-ietf-sipping-dialog-package-01.txt
  • - draft-ietf-sipping-conference-package-00.txt
  • - draft-ietf-sipping-pstn-call-flows-01.txt
  • - draft-ietf-sipping-basic-call-flows-01.txt
  • - draft-ietf-sipping-torture-tests-00.txt
  • - draft-ietf-sipping-req-history-02.txt
  • - draft-ietf-sipping-aaa-req-02.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-00.txt
  • - draft-ietf-sipping-ua-prof-framewk-reqs-00.txt
  • - draft-ietf-sipping-config-framework-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

    Current Meeting Report

    Minutes, SIPPING Working Group, IETF 56
    edited by Dean Willis
    Session 1, Monday March 1700, 1930-2200
    Scribe: Vijay Gurbani, Mary Barnes
    Chat coordinator: Al with the Hat
    Chairs called meeting to order.
    Agenda agreed as:
    1930 Agenda Bash
    1935 Status -- Chairs
    Call Control Issues
    1945 Service Examples, Alan Johnston
    1955 Call Control -- Transfer, Allan Johnston
    2005 Caller Preferences Use cases, Jonathan Rosenberg
    NAT and Policy Issues
    2015 Persistent Connection Management Requirements, Vijay K. Gurbani
    2035 SIP Network Address Translation, Jonathan Rosenberg
    2045 Session Policy Requiments, Jonathan Rosenberg
    2055 URI Leasing, Jonathan Rosenberg
    Design Teams
    2105 SIP Conferencing Design Team, Alan Johnston
       Web Page for the Design Team
    2135 Application Server Interaction Design Team, Jonathan Rosenberg
       Web Page for the Design Team
    2140 Transcoding Design Team, Gonzalo Camarillo
       Web Page for the Design Team
    2145 Emergency Calls Design Team, Jon Peterson
       Web Page for the Design Team
    2150 Limiting Notifications Rate, Aki Niemi
    2200 Wrap
    Topic: Service Examples, Alan Johnston
    Moving well. Author wishes to add some text discussing how to 
    implement some servcies and discussing trade-offs and expects that draft 
    will be complete before next meeting
    Topic: cc-transfer, Alan Johnston
    Slides presented, included in proceedings.
    This version had few changes: added a section on use of Referred-By 
    header.  Added selected message details.  Added many more call flows on 
    attended transfer and unattended transfer.  Added a security 
    consideration section.  No known open issues with the I-D. Group polled on 
    readiness for WGLC: No objections noted.  Audience asked if there was any 
    overlap or dependency on globally-routable contact URI work. Author 
    belives there is currently no dependency, but that if the GRURI work 
    completes, it would be nice to reference it from this draft.
    Topic: Status report: Chairs
    Slides presented, included in proceedings.
    We have 3 RFCs which have been published, considering the amount of work we 
    had on our plate.  2 on IESG queue; bunch of individual I-D. 3 in here that 
    are ready for WGLC.  A lot of work is blocked on other stuff -- call 
    control, ICE, work going on in midcom, etc.
    Note chairs believe that formal expert review is not required for all 
    individual drafts. Current policy is to announce the draft to the list, and 
    ask the participantst to verify that the draft does not conflict with WG 
    efforts. Under the current process, we do a formal expert review for 
    P-headers or when asked to do so by IESG/ADs.
    It may be useful for us to split things into smaller groups -- some I-Ds 
    document usage of SIP, others talk about services 
    (cc-conferening, cc-transfer).  It may be appropriate to let some of this 
    work proceed without supervision of the WG.  We may end up doing this in 
    Vienna in order to get up to speed.  Will like to get comments on the 
    mailing list or after session on if this is okay.
    Topic: Caller-Preferences Use Cases, Jonathan Rosenberg
    Slides presented, included in proceedings.
    Poll: Useful, interest in accepting as WG document? Strong consensus 
    recorded. AD suggested that these use cases be packaged with 
    CallerPrefs drafts.
    Topic: ICE, Jonathan Rosenberg
    Slides presented, included in proceedings.
    Provides general methodology for using address-fixing protocols to get SIP 
    through NAT.
    Question: What is the impact if some sort of underlying mobility 
    function causes node address changes? Does ICE resolve? Ans: Unknown, but we 
    think it should work if the frequency of address changes is lower than 
    Question: Does having STUN server on every node open up the network to 
    denial-of-service attacks on NAT translation? Ans: No -- at least, no more 
    than port-scanning already would.
    Poll: Who read: fairly large number.
    Question: Muxing STUN and media -- is that required? What is the 
    implication of demux? Ans: It seems to be feasible to use 
    magic-cookies in the TUN level to work it out.
    Comment: This DOES require widespread deployment to be useful, can we get 
    that? Ans: If it works, people will implement it.
    Question: What are implications if only one end supports?  Ans: We fall 
    back to what we have now. Question: IS it easier to fix the NAT than to fix 
    the SIP? Ans. Debatable.  There's a lot of $39 NAT boxes out there.
    Poll: How many people would be interested in implementing? (several) Will 
    one volunteer to write the preconditions (document things like like SDP 
    changes, requirements in SIPPING) Yes-- Cullen Jennings.
    Poll: Would you like this work to be documented in SIPPING, along with 
    fallback to previous modes? Ans: Loud response, a few dissenters. 
    Proposal: Cullen to work on preconditions, Jonathan to work on 
    furthering ICE draft, WG to request authorization to pursue as WG 
    Topic: Session Policy Requirements, Jonathan Rosenberg
    Slides presented, included in proceedings.
    Slides presented reviewed scenarios. Poll: Do we want to work on this? 
    Brian Rosen reports that he really needs this for dealing with 6Mb/s 
    streams and managing admissions policy dynamically. Another comment made 
    that this approach could obviate the need for some B2BUAs. Comment that we 
    should add requirements to do this without "new headers" and it shoud work 
    with e2e encryption (req #1 in presentation). Poll: who thinks we should 
    take this work on as a baseline for requirements? Strong consensus 
    reported, none opposed.
    What happens when a service provider wants to insist on some aspects of a 
    session (media flows through a realy, video not be used, etc.) So far this 
    has been done with SDP modification.  Well known problems: does not work 
    with data encryption, requires proxies to have knowledge of session 
    descriptions, proxy complexity increases, ...
    Solution: 3GPP does this -- they use 488 as a response code to list 
    codecs which are acceptable.  This has some drawbacks as well.
    Do we want to work on this problem?  That is the real issue for us to 
    decide now.
    Many people approached the mic and agreed to the requirements being 
    Keith Drage suggested that we resolve the requirements before 
    proceeding with a solution, and that consideration of various 
    solutions (such as Jonathan's proposal) should be deferred until the 
    requirements are agreed.
    Poll: who thinks we should take this work on as a baseline for 
    requirements? Strong consensus reported, none opposed.  Chairs will 
    request approval as a WG item from ADs.
    Topic: URI Leasing, Jonathan Rosenberg
    Slides presented, included in proceedings.
    Material introduced from slides.
    Question: This allows for temporally scoped URIs. Can we give an example of 
    where this would be useful? Ans. Assume a conference call running over a set 
    time. Discussion that current document may be a bit complex in this area. 
    The word "temporal" is probably misapplied in this context and the author 
    would like to withdraw it. This all comes down to embedded route headers vs. a 
    lease-and-preference model. Perhaps we need to step up a level and ask what 
    the top-level requirements really are? The draft proposes three 
    explicit. There may be also "without hiding state in the domain name" and 
    some others.
    Comment: Leasing seems to imply temporal scoping. Huh? Long 
    discussion . . .
    Comment: It seems that all of the given requirements could be met by 
    relaxing a single restriction in 3261.
    Conclusion: More list discussion on requirements needed.
    Topic: App Interaction Design Team, Jonathan Rosenberg
    Slides presented, included in proceedings.
    Minimal activity since last meeting. We should develop use cases 
    illustrating the requirements. Jonathan Rosenberg requested that 
    proposed use cases be sent to him via email.
    Topic: Persistent Connections, Vijay Gurbani
    Slides presented included in proceedings.
    Basics presented. Discussion ensued.
    Question: What is the requirement difference between signaled 
    persistence and simply configuring persistence?
    Assertion: Reuse is only important in the client-server case.
    Assertion: This sounds like my kids discussing bedtime. There is really 
    only reason to close a TCP connection -- to recover resources. 
    Therefore, the interesting thing, is not how do connections come up, but 
    figuring out which connection to kill if we need to kill one.
    Assertion: the mechanism here is equivalent to "just doing the right 
    thing" with TCP, so we should fix it operationally, not by changing the 
    Poll:  Should we change the SIP spec to encourage leaving TCP 
    connections open unless they need to be closed? Strong consensus 
    reported. Proposed that we do minimal bug fixes in SIP, and do a 
    separate document with an operational focus on "how to" reuse TCP, 
    initially as a discussion and possibly leading into a BCP. No 
    objections noted. Vijay Gurbani may volunteer to lead on a usage 
    Topic: Conferencing Design Team, Alan Johnstson
    Requirements, Framework, and Call Control ready for WG adoption. 
    Conference Policy is splitting into two and should be ready shortly. Media 
    policies work requirements progressing, work on policy manipulation is 
    ongoing, and the policy work needs a new home. MMUSIC is not going to 
    adopt this in their new charter.
    Question: This policy work is related to data manipulation in SIMPLE, can we 
    combine it? Ans: Probably not. One is data manipulation, the other is 
    policy RPC.
    Open issues recapped in slides.
    Discussion of absolute vs. relative time in focus. Why not have 
    absolute time? Ans. Simplifies timeing coordination on focus.
    Comment: We do have requirements for realtime transitional controls for 
    things like camera-follows-speaker. SOAP and ACAP don't combine to meet 
    this requirement. Ans: This is for more persistent policy, not 
    floor-control. Floor-control remains a media problem.
    Poll: Do we wish to, as proposed, adopt the requirements, framework, and 
    call control drafts as wg efforts? Strong consensus, no objections.
    Question: Is discovery in-scope? It could be a furball.
    Request: Make focus migration happen sooner rather than later. This will be 
    required for three-way to more-way migrations. This is also important from a 
    fault recovery standpoint. The call-control is easy, just a REFER 
    series, but handling the policy migration is more interesting.
    Discussion: Policy group needs working group home.  Rohan: mmusic will NOT be 
    chartered to do this; so it is either us or a new BOF.  Will work it out 
    with the ADs later.  We have not been told that we have to stop working on 
    Open issues: conference policy protocol, floor control, 
    Proposed: Adopt Reqs, framework, and call control I-Ds as WG 
    documents.  Poll taken, and strong consensus reported.
    Open reqs: discovery, focus role migration, cascading and camera 
    Topic: Hearing impaired media transcoding, Gonzalo Camarillo
    Work proceeding, no surprises.  Author reports little  
    progresssince last IETF and  believes that now that we have media policy I-D 
    and session policy reqs, we will make more progress for the next IETF.
    Topic: Emergency calling design team, Jon Peterson
    Work proceeding, will try to have face-to-face meeting here. Two cases -- 
    regular 911 calls, and PSAP access-link replacement. Can we divide these two 
    cases so that there is something available for "today's PSTN PSAP"?
    Topic:  Event Throttling Requirements, Aki Niemi
    Notification rate limiting is the "common factor" among most of the event 
    filtering discussions. Issues: Is the model accurate and 
    appropriate? Do we need both the leaky bucket and the strict throttle? Is it 
    ok to leave handling of quarantined notifications out of scope? Is this 
    work useful?
    Discussion: It may be important to have a different throttling 
    mechanism for "aggregated/filtered" notifications than for simply 
    prioritized or decimated notifications. The current work does not really 
    consider notification volume/size, just counts. Discussion about the 
    difference between quarantine and gating/throttling functions. One can 
    define a five-token multibucket scenario that's fairly complete. Is this too 
    complicated to be practical? Volutneers to review reqs -- Jonathan, David 
    Oran, and Tomn Taylor volunttered. Poll for adoption: none opposed. 
    Question: Is there standardization required to be able to rate limit?
    Event Throttle Requirements, Aki Niemi
    Aki went through the model and the requirements (see slides). Issues: Is the 
    model accurate and appropriate? Do we need both leaky-bucket and the 
    strict throttle models, or is only one of them enough?
    Observation from floor: Quarantining and throttling are not the same 
    thing. One introduces delay the other control rates.
    Rohan: Jonathan, Dave Oran and Dean will review the I-D and the  WG will 
    receive an update from them before this becomes a WG document.
    Session 2, Wednesday March 19, 1530-1730:
    Scribes: Paul Kyzivat, Vijay Gurbani
    Chat coordinator: Brian Rosen
    Session called to-order by chairs. Agenda agreed as follows:
    1530 Agenda Bash
    Security Related Issues
    1535 Role-based Authorization Requirements, Jon Peterson
    1545 Request History, Mary Barnes
    1605 SIP Endpoint Service Charging Requirements, Wolfgang Beck
    1615 SIP User Agent Configuration - Dan Petrie
    1625 Issues in Dual Stack Environments, Hakan Persson
    1635 SIP-AAA Requirements, Gonzalo Camarillo
    Media Related Issues
    1645 Early Media, Gonzalo Camarillo
    1710 Network Announcements, Eric Burger
    1720 Considerations on the IPREP Requirements, Jon Peterson
    1730 Wrap
    Topic: Role-Based Authentication, Jon Peterson
    Slides introduce concept. Question: Can you show some use cases? Assume two 
    previously unassociated carriers in a federation wish to exchange calls. One 
    carrier issues an authorization object, which the caller hands to the 
    other carrier, allowing the call to proceed. Other examples followed.
    Discussion from floor:  Are we proposing replacing identity with  roles?  
    Jon responded that this could encompass identity, but maybe not. 
    suggested from floor that we add more in doc explaining 
    relationship between identity and roles, agreed to by author.
    Request: Somebody asked for more use cases. Was also concerned whether all 
    stated  requirements were self consistent.
    Observation from floor: Jiri Kuthan suggested that this was a 
    replacement/alternative for  network asserted identity.
    Observation from floor:  Somebody suggested that Role wasn’t exactly the 
    right term to use.
    Topic: Request History Rqmts and Solution, Mary Barnes
    Slides presented, included in proceedings. Mary Barnes presented current 
    status of both documents. Both  requirements and solution have had two new 
    versions since last meeting,  now up to -02. Mary explained changes. Of 
    note - separating out security  requirements, to separate document.
    Remaining open issue is security, which is work-in-progress, which a 
    seperate security solution draft expected soon.
    Consensus that requirements document is roughly complete and should be 
    referred to SIP WG for action. Chairs need to refer to AD for 
    Topic: SIP Endpoint Service Charging Requirements, Wolfgang Beck
    Slides presented included in proceedings.
    Introduces requirements and a model for third-party trust assignment with 
    SIP. Possibly combinable with 
    Proposal: this should be two drafts, one around charging and another about 
    Comment: this seems to be limited to a fixedSIP architecture as 
    currently written.
    Comment:  the evaluation of the requirements presented in the draft would be 
    greatly aided by the inclusion of use cases.
    Comment: reading the document indicates a specific business model 
    in-mind. Work here should be network agnostic and not make 
    assumptions about who is paying (like caller always pays) etc.
    Question from chairs: Are we interested in trying to gather 
    requirements to support an endpoint based charging model (i.e., not 
    billing from intermediaries). Consensus that we would like to see the work 
    more completely illustrated, including use cases, before considering its 
    Topic: Config Framework, Dan Petrie
    Slides presented included in proceedings.
    Open Question: Should HTTPS be a SHOULD or MUST strength 
    reequirement: Ans. MUST implement, SHOULD use. Open Question: Is HTTPish 
    preferred to LDAP or ACAP?
    Open Question: Is this related to NETCONF work?
    Discussion: There are issues here that cannot be fixed with HTTPS pixie 
    dust. You need a separate mechanism of top of HTTPS to verify the 
    identity of the node requesting configuration. Of course, this needs to be 
    configured in. So there is a bootstrapping problem.
    Open question: device identity parameters: User-agent header? New 
    header? No decision made.
    Open question: How to indicate profile type? Accept-header or event 
    header parameter or request-URI? Comment: this is the same problem as 
    SIMPLE's buddy list management and should use the same mechanism. 
    Further discussion taken to the list.
    Dan Petrie presented. Identified changes from prior version.
    There were comments about strength of use for HTTPS for content 
    indirection in here. General sentiment seemed to be that HTTPS should be 
    MUST implement, SHOULD use. Other protocols other than http/https are also 
    Henning Schulzrinne said https isn’t enough. Said there were both 
    confidentiality issues as well as way to ensure the client gets the right 
    data. In absence of client cert, which you can’t assume during config, 
    presents difficult problems – how to bootstrap.
    Dan acknowledged this problem, and said he has already proposed to do work to 
    deal with that. Further discussion went on. Rohan asked that
    this go to list.
    Dan requested input on list for where device identification should go – in 
    User-Agent header or somewhere else.
    Discussion of profile type – where to indicate in subscription. 
    Jonathan Rosenberg thought you could subscribe to a different request uri 
    for each kind of thing. Rohan Mahy disagreed. Was sent to the list for 
    Jonathan suggested this is similar to SIMPLE problem regarding 
    buddylists, and the two works should be synchronized.
    Topic: Dual-Stack Issues, Hakan Persson
    Slides introduce problem and recaps several solutions. The "contact" 
    problem seems to be addressable in part by dual-interfaced 
    record-route and in part by ICE. The document will be revisited by the 
    author exlporing usage of these techniques and, if the solution is 
    satisfactory, can become a usage document illustrating the solution to the 
    problems it has already raised.
    Topic: AAA Req, Gonzalo Camarillo
    Slides presented included in proceedings.
    Currently in WGLC. Poll: Any issues that have been missed? No new 
    issues. Attendees encouraged to follw WGLC.
    Topic: Early Media, Gonzalo Camarillo
    Slides presented included in proceedings.
    Open issues: There appear to be three ringback states from ISUP, and only 
    two codes (180, 183) available in SIP. Not all protagonists are present and 
    the author proposes to hold a conference call for resolution. Debate 
    ensued anyhow, trying to capture essence of the issue. Francois, 
    Flemming, Rohan,  others agreed to send use cases illustrating the issues 
    they need solved. Poll: should we add a flag? No clear consensus
    Topic: Network Announcements, Eric Burger
    Slides presented included in proceedings.
    Open Issue: Media on Hold? What does a media server do when it gets put on 
    hold? This seems to be application specific, not a SIP protocol 
    Open Issue: 409 Result code proposal? Suggestion from audience Can we TRY 
    not to use things that are used in HTTP to mean something different? 
    Sugggestion: Could we use a standard response code and a Reason field? 
    Conversation deferred to list with emphasis on 6xx vs 4xx debate.
    Open Issue: Multiple Media Streams:?  What do do then, to play multiple 
    things? Eric asserted this isn’t an issue if the target uri is a 
    composite object. He wanted to know if that is the predominant use case. And 
    if not, how would the multiple streams be synced? Brian Rosen wondered why it 
    isn’t good enough to pick one stream. Confusion reigns, deferred to list.
    Open issue: IS everything in this draft consistent with WG usage? We need to 
    be sure we're aligned with conferencing and early media work? Author asked to 
    work with Alan Johnston on conferencing alignment, and Gonzalo 
    Camarillo on early media.
    Topic: IEPREP Considerations, Jon Peterson
    SIPPING asked to provide formal response to the IEPREP 
    considerations, widely discussed on mailing list. Open Issue: SHOULD we 
    address this here? As there is already work in SIP on the priority 
    header? Should we do it here?
    Jon Peterson presented. Said this work was in response to requests by area 
    directors for comments on RFC3478. This is Jon’s private attempt at 
    comments, based on some discussion on list.
    Jon raised privacy issues. Henning said there are fundamental 
    tradeoffs between privacy and proxies, and that therefore it is 
    necessary to offer endpoint with options for either.
    Keith Drage asserted that either there is an error in the IEPREP 
    requirements that ought to be fixed there, or else it should be dealt with by 
    SIP in responding to the requirements, so there is no need for SIPPING 
    draft in this instance. Allison Mankin agreed, said the area directors 
    could deal with this aspect now, and don’t  need any more input.
    Rohan observed that SIP already adopted a mechanism that relates to this. :
    Meeting concluded.


    SIP Service Examples
    SIPPING Conferencing Design Team
    Media Transcoding Design Team
    Early Media
    Request History Capability - Requirements & Solution
    Network Announcements with SIP
    Requirements for Persistent Connections in SIP
    Event Throttle Requirements
    User Profile Framework