Current Meeting Report
Jabber Logs

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: -- Additional SIPPING Web Page
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/29/2002

Brian Rosen <>
Dean Willis <>
R. Mahy <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
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.

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
APR 02  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
APR 02  Submit Internet-Draft on Call Transfer using REFER to IESG for consideration as a BCP
MAY 02  Submit Internet-Draft on Common Call Flows to IESG for consideration as a BCP
MAY 02  Using ENUM with SIP Applications to IESG for consideration as an Informational RFC
MAY 02  Submit Internet-Draft on Requirements for AAA Application in SIP Telephony to IESG for consideration as an Informational RFC
Done  Submit SIP 3rd party call control to IESG for consideration as BCP
JUN 02  Submit Internet-Draft on Multi-Party/Conferencing Framework to IESG for consideration as an Informational RFC
JUN 02  Submit Internet-Draft on T.38 Fax Call Flows to IESG for consideration as a BCP
JUN 02  Submit Internet-Draft on 3G Requirements to IESG for consideration as an Informational RFC
JUL 02  Submit Internet-Draft on Mapping ISUP Overlap Signaling to SIP to IESG for consideration as a Proposed Standard
AUG 02  Submit Message Waiting SIP event package to IESG for consideration as PS
Done  Submit Internet-Draft on Usage Guideline for Events (Subscribe-Notify) to IESG for consideration as an Informational RFC
OCT 02  Submit Call Info SIP event package to IESG for consideration as PS
OCT 02  Submit Conf Info SIP event package to IESG for consideration as PS
NOV 02  Review charter with Area Directors and recharter or conclude
  • - draft-ietf-sipping-conferencing-models-01.txt
  • - draft-ietf-sipping-isup-05.txt
  • - draft-ietf-sipping-sipt-04.txt
  • - draft-ietf-sipping-e164-01.txt
  • - draft-ietf-sipping-overlap-03.txt
  • - draft-ietf-sipping-call-flows-01.txt
  • - draft-ietf-sipping-service-examples-02.txt
  • - draft-ietf-sipping-realtimefax-00.txt
  • - draft-ietf-sipping-cc-framework-01.txt
  • - draft-ietf-sipping-3pcc-02.txt
  • - draft-ietf-sipping-nai-reqs-02.txt
  • - draft-ietf-sipping-sigcomp-sip-dictionary-03.txt
  • - draft-ietf-sipping-mwi-00.txt
  • - draft-ietf-sipping-content-indirect-01.txt
  • - draft-ietf-sipping-nat-scenarios-00.txt
  • - draft-ietf-sipping-dialog-package-00.txt
  • - draft-ietf-sipping-conference-package-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

    Current Meeting Report

    Minutes, SIPPING WG IETF 55
    Edited by Dean Willis
    Meeting Notes by Vijay Gurbani
    Meetings in Atlanta, GA, USA
    Two Sessions:
        Wednesday, November 20 at 1530-1730
        Thursday, November 21 at 1300-1500
    CHAIRS:    G. Camarillo 
        Dean Willis <>
        R. Mahy <>
    Wednesday, November 20 at 1530-1730: Salon III
    Agenda Bash
    No issues.
    Status and Charter, Chairs
    New co-chair Gonzalo Camarillo introduced.
    Status report given by Rohan Mahy.
    Discussion: Scope and home of filtering work. Conclusion to pursue rate 
    limiting in SIPPING as a generic topic and that individual event 
    packages should specify their own filtering requirments.  Group agreed to 
    consider a framework draft for rate limiting, and Aki Niemi 
    volunteered to attempt a first draft.
    Registration Event Package Open Issues, Jonathan Rosenberg
    Statuess: In IETF LC.  One change: add shortened event to the state 
    Issue:  default expiration matching default registration expiration 
    (default lifetime: 3600 sec, same as default registration time).  Made 
    people nervous due to race conditions/synchronization problem.
    Proposal: change to 4200s. No opposition shown
    Issue: XML vs sipfrag: why convert reg msg to XML? 
    Discussion: Extensive on pros and cons and costs.
    Poll: XML vs anythying else. Consensus: XML.
    SIP-T Related Issues, Jon Peterson
    Status Current work done; SIP-ISUP is in authors 48 right now. Overlap I-D is 
    still in progress; not a general solution -- there is
    Issue: Overlap:.What should we do?  SG11 is considering using this from the 
    Discussion: Wide ranging discussion of requirement and rationale for 
    overlap and whether the overal draft should ve published and if so on what 
    track. OPtion of letting ITU deal with it raised. Noted that if done in 
    IETF, we will have serious security concerns.
    Conclusion: There doesn't seem to have been any conclusion.
    Topic: New directions for SIP-T:
    Issue: SDP mapping: draft by Gonzalo on early media and other SDP 
    mapping aspects: code mapping and absence of SDP (in case of  3PCC).
    Q.931->SIP mapping:
    Discussion: widely implemented without a standard, not sure  what value a 
    standard will add to it.
    Issue:  Privacy-identity mapping for SIP-T:
    Discussion: SG11 already looking at this.  We are looking at the 
    P-Asserted-Identity version, not the long- term identity we discussed in sip 
    yesterday. Suggestion that we at least do the privacy mapping for long term 
    identity and that this could be informational. Suggestion that we make this 
    an explicit non-goal and that we minimize "educational" I-Ds.
    Conclusion; Jon Peterson will attemp Privacy-mapping I-D. Group will not do 
    any Q.931 work until at least next meeting. SDP mapping will go to list for 
    Poll: Consensus: do people agree on working on document on how to use 
    existing tools on providing early media in SIP?  A document that 
    explains how to use UPDATE and other tools to do early media?. Result: 
    consensus to do this work.
    Poll: Should we do 3PCC/SDP interworking with PSTN - No one hummed. 
    Discussion inidicated that there is no clear understanding of the 
    problem and we need to get a individual I-F writeup.
    Message Waiting Package Open Issues, Rohan Mahy
    Changes since last version reviewed.
    Discussion: Suggested that a couple of things are complex enough to be 
    non-trivial and not important enough to be useful.  Given that we do any 
    other events stuff
    shall we align it with event style description rather than having a 
    restrictive count only description?
    Poll: Continute with text body: No objection.
    Concluion: Document will be revised to account for new 
    Transfer  and Service Flows Open Issues, Alan Johnston
    Topic: Transfer
    Changes since last version reviewed with slides.
    Issue: A Refer-To URI needs to allow the transferee to reach the 
    transfer target.  One way is to put Route header in a Contact, but this is
    illegal as per rfc3261.
    Discussion:  This problem keeps popping up in many places; in 
    conferencing it happens as well.  Better not to solve it here, but  
    rather do it in a separate I-D.
    Poll: Any voluntters? None.
    Remaining work: close open issues, track REFER as it completes, add
    uses showing Referred-By.
    Request History Open Issues Mary Barnes
    Slides presented are available in proceedings.
    Discussion: It might be possible to use this in conjunction with  Jiri 
    Kuthan's SIP diagnostics.  Maybe we can use this work to apply in that 
    Issue: ABNF issues:
      explicit counter: plain counters do not work due to forking
      options: indexiing using a dot delimiter to reflect the depth of
      <went through an example; see viewgraphs>
    Forking: need to add more scenarios
    Privacy: if you need privacy, use 
    Security: primary concern is in regard to a rogue app/proxy 
    challenging  HI entries.
    Discussion:  You are already assuming some level of trust in these 
    intermediaries; i.e. they are proxying the request in the first place. It 
    strikes me as a "sips" kind of thing; then you can guarantee that no rogue 
    element has put anything in since all are trusted. Proposal:  Maybe you can 
    use the Auth-ID body draft.
    Idea is not to assume a weird trust relationship b/w all 
    intermediaries.  What you get is some optional information in a signed 
    auth-ID body that asserts that proxy A retargetted to location Y.  Maybe we 
    should allow proxies to add bodies (they add headers). Comment : This is 
    hard to spec right.  Maybe we can start with writing
    reqs so we can spec it right.
    Poll; Ready for WGLC? Resolved to take to list, not enough people had read
    Poll: Do we feel that the reqs have sufficiently been presented in public 
    that we are ready to ask SIP to consider a mechanism?  Even split 
    between waiting before implementing a solution and asking SIP to 
    Diagnostics -- Jiri Kuthan
    Status: Narrowed the scope due to the discussion of mailing list; scope now 
    is diagnostics of SIP routing only.
    Proposal: Let the UAS be talkative and disclose what they know about 
    circumstances under which a request failed. Proxy Hints: disclose 
    aggregated processing logic; mirror hints upstream  so that 
    troubleshooters located upstream can see it
    Issues: privacy concern.
    Proposal is to use sipfrag and include the diagnostic in sipfrag.
    Discussion: Might be better to  have a standardized way of doing this to 
    make it easier to implement and deal with. However,  we have the same 
    problem with email processing; the email server sends error messages that 
    say where the message died.
    Proposal: Reqs developed for history would apply to this quite well.  We 
    should start with that and see how far it gets us.
    Conclusion: We should start working on requirments..
    Thursday, November 21 at 1300-1500: Salon III
    Evaluation of IEPREP requirements on SIP, Chairs, Henning 
    Changes since last rev discussed.
    Issue: What should the process be? Does this draft cearly define
    requirements for extensions to SIP that can be taken to SIP WG?
    Conclusion: We will scheduel a WG review ASAP. We will not crosspost
    to IEPREP, but will ask a volunteer (Kimberly?) to take any
    discussion needed to IEPREP
    Status report on Conferencing design team, Alan Johntson
    Status New smaller design team formed to try and get back on schedule and 
    docs agree with each other. Each team member now responsible for one or 
    more docs. First out will bea revised framework document that will 
    include terminology. There are drafts of several documents, 
    agreements on terminology and scope, and progress seems good.
    Poll: Anyone have problems with this approach?
    Suggestion that docs be out a month to six weeke before next IETF.
    Status report and open issues from Hearing Impairment design team, 
    Gonzalo Camarillo
    Slides presented are available in proceedings.
    Goals: Going beyond the reqs for the deaf; we are working on 
    invocation of services that involve media manipulations including codec and 
    language transcoding. Want to be opes aware.
    Deliveries: transcoding services invocation in SIP and the source and sink 
    attributes for SIP (2 I-Ds).
    Possible future deliveries: labeling of transcoded media streams, caller 
    prefs extensions. We have to think about these two before finalizing them.
    Issues: invocation in the B2BUA model as opposed to 3pcc model which is 
    seen as  quite complete. We use Route header field as if the B2BUA was a 
    proxy. We did not feel comfortable with this approach. Maybe we can  use 
    something else like message encapsulation or REFER. Current decision is 
    REFER: more opes friendly and has security built in. Disadvantage:  more 
    signaling. But generality wins.
    Discussion: the work may not have taken into consideration other 
    requirements about transcoding. Consenus that these can be added as they are 
    brough up on list.
    Poll: is plumbing draft (draft-camarillo...sink-00) needed? 
    Discussion that it might overlap with conferencing and be able to reuse 
    conference work or be input to conferencing work.
    Conclusions: co-ordinate with conf DT on overlap and ask SIPPING WG to 
    advise on further path.
    App Interaction Design TeamT, Jonathan Rosenberg
    Small team -- 4 members.
    What are we doing? Stimulus with SIP -- the way in which users interact 
    with apps using media, markup and dtmf. Team is making good progress on 
    understanding the nature of dtmf in these networks, but there is a 
    general problem here: event reporting.
    Produced 3 documents (framework, KPML, and interaction) and inherited one on 
    interaction requirements.
    Issue: infamous SIP vs HTTP debate -- who carries the information? 
    Document clarifies difference between rfc2833 and using SIP or HTTP
    to carry these. It deliniates the UI from the app. Comment: If you have 
    markups that assume HTTP they will use it; if you have markups that 
    assume SIP, then they will use SIP. The language construction is 
    Issue: Focus determination for KPML: when a user enters a digit, which KPML 
    amongst the ones from various apps does it apply to. Current draft says 
    send it everywhere -- same as PSTN does. Architectural solution: have a 
    central controller model which runs a super app and make decisions for the 
    user. Is this adequate?  Any other ideas?
    No discussion noted.
    Issue: Error reporting for App-Info: what if App-Info URI is invalid?
    Options: no error reporting, only send App-Info in requests (where a error 
    response can be generated), error reporting URI (infinite recursion 
    No discussion noted.
    Issue: indicating script termination -- should we or not?
    Discussion: This is complicated, and overlaps with IMAP issues
    Comment: A lot of it is problem statement: we want to do what HTTP does, but 
    get started in some other way.
    Issue: Barge-in ==> framework has feature that allows IVR barging to be 
    pushed to endpoint. Problem is how to detect when its OK to start
    playing media again? Need some media synch. Markup bits don't work; PT 
    changes may work; others?
    Further discssion referred to list.
    Discussion about potential new work in QSIG and Q.931 
    Jon Peterson
    Discussion Some interest in going forward with this in Yokohama IETF. Not a 
    lot of discussion since then on list. As per yesterday's SIPPING
    WG, we would also prefer to do some SIP->Q.SIG mapping.
    John Elwell has released a new version of I-D since Yokohama; changes:  use 
    of P-Asserted-Identity in mapping to CLIP/CLIR and strengthened 
    security text following the SIP-ISUP draft.
    Not a SIPPING WG item yet, any comments?
    Keith: Minor nit: it is QSIG, not Q.SIG.
    Poll: Any objections to make this a WG item? No objection noted.
    FYI and Discussion on iCal usage in SIP, Pekka Pessi
    Slides presented are available in proceedings.
    Status: iCalendar is a calendaring information exchange format based on 
    vCalendar. iTIP is an abstract protocol for interaction between 
    calendar UAs. It has methods like PUBLISH, REQUEST, REPLY, CANCEL,  ADD, 
    iCalendar use with SIP: off-line invitations, describing SIP 
    tele-conferences,  indicating schedule and timezone, notifications for 
    schedule, conference, etc.
    Procedure :Map iTIP to SIP ==> iSIP. iSIP is very similar to iTIP.
    Open issues: does iSIP fit in calsch? It does not change how SIP is used.
    Submit new draft using standard iCalendar format?
    Specify iSIP apps separately: iCalendar for on-line conf?
    Discussion: Why do we have to carry this in SIP?
    Answer: SIP brings SIP addressing
    Discussion: One model is that this is some MIME type and I don't care. Then 
    why do we have to define a mapping if we are carrying an object?
    Answer: It is an object and you don't have to do anything in SIP. 
    However, some protocols provide optimizations for carrying the object. Do we 
    want to do that here?
    Further discussion referred to list due to end of allotted time.
    Meeting adjourned.


    iSIP: iTIP over SIP and Using iCalendar with SIP
    Request History Capability - Requirements & Solution
    Media Transcoding Design Team