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.
| Nov 01 | Submit Internet-Draft on T.38 Fax Call Flows to IESG for consideration as an Informational RFC | |
| Nov 01 | Submit Internet-Draft on 3G Requirements to IESG for consideration as an Informational RFC | |
| Dec 01 | Submit Internet-Draft on Common Call Flows to IESG for consideration as an Informational RFC | |
| Dec 01 | Submit Internet-Draft on SIP-Telephony Framework to IESG for consideration as an Informational RFC | |
| Jan 02 | Submit Internet-Draft on Call Transfer using REFER to IESG for consideration as an Informational RFC | |
| Jan 02 | Submit Internet-Draft on Requirements for AAA Application in SIP Telephony to IESG for consideration as an Informational RFC | |
| Feb 02 | Submit Internet-Draft on ISUP-SIP Mapping to IESG for consideration as an Informational RFC | |
| Feb 02 | Submit Internet-Draft on Hearing-Impaired Support with SIP to IESG for consideration as an Informational RFC | |
| Mar 02 | Submit Internet-Draft on Usage Guideline for Events (Subscribe-Notify) to IESG for consideration as an Informational RFC | |
| Apr 02 | Submit Internet-Draft on Multi-Party/Conferencing Framework to IESG for consideration as an Informational RFC | |
| Apr 02 | Review charter with Area Directors and recharter or conclude |
Current Meeting Report
Minutes, SIPPING WG, IETF 52
------------------------------------------------------------------------
Reported by Dean Willis and Alan Johnston 14Jan02
Agenda accepted as proposed.
Review of draft-tsvarea-sipchange-00.txt requested by ADs
Sip Telephony Framework, ISUP, and Overlap Dialing:
Consensus recorded on proposal for usage of tel URI and further work on trunk groups. RFC2806bis work is continuing. Consensus recoreded to stary with single-dialog approach to overlap dialing
Use of telephone Numbers and Number Portability:
Consensus recorded on not attempting to negotiate media or session types using SRV. Using ENUM in SIP is orthogonal to LNP info. Some dicsussion on whether telurl (Lu) wildcard work is in scope, general consensus is that it is not. Direction indicated on Yu number portability draftis to merge requirements into Campbell e-164 draft, move syntac into SIP WG. We will need rules to eliminate repeated NP dips.
Conferencing framework:
Direction is that framework will cover setups, teardowns, transfers, parks, holds, picks, barge-in and like functions, but will NOT deal with floor control or "in media" sorts of control. REFER primitive and Transfer usage should continue. Consensus recorded to carry on conferencing framework as WG effort.
Call Flows:
Work is proceeding. Assistance is needed with proofreading sip-call-flows for last call.
Publish requirements:
Question: Should we do this in SIP? Argument for: propsoed mechanism appears to work, fits negotiation model, andfulfills requirement of "do no harm". Extended discussion was generally neagtive on concept, but inconclusive. AD recommended consideration of gepriv issues. Consenus o furtehr develop requirements draft. However, there needs to be a sense of urgency, as much SIMPLE work may be contingent on this.
Redirection:
General consensus that some sort of istory mechanism that addresses mapping from ISUP and can be abracted above ISUP is needed. There may be issues with loading too much state into this, primarily bonding between servcie and application. Need to recoginze that decision to expose routing rationale lies with each routing service, as well as user and node execting operation. There may be privacy issues. It may be reasonable to report operations visible at SIP protocol level, but not to bring in application information. General consensus recorded to consider further.
end of Session 1
Session 2: Thursday, December 13, 2001, 1300-1500, Room Grand D
1300 Agenda Bash Chairs
Covered redirect session yesterday.
1305 Changes in Requirements for Hearing Impaired Users and Work Planning Arnoud van Wijk Guido Gybels Nathan Charlton Read:
draft-charlton-deaf-req-00.txt draft-vanwijk-sipping-deaf-req-00.txt
#1 Adopt draft as WG? No one opposed.
#2 Content identification requirement. Need a model - options - SDP, SIP header, assumption, ignore?
Sean Olson - Clarification - automated solution? Perhaps not sip or sipping. Tom Taylor - Identify functions first and information flows - architecture
Brian Rosen (not as chair) - Need lexicon, then can say who applies it. Then labeling it is easy. We have no expertise Jonathan Rosenberg - Legal liabilities huge. Mark Watson - Can't be reliable - source can lie. Also, more requirements analysis would be good - could be sipping Henning Schulzrinne - Content (W3C) fits in SDPng, Can deduce technical information, comfortable with that. Otherwise, need human to identify. Nathan Charlton - Does requirement stay in this document Brian - Yes, leave it in. Keith Drage - make more requirements clearer.
#3 - little feedback
Brian - lets all read draft and get it done
Mark - reqs can be generalized and very useful.
1315 3GPP Requirements Discussion Miguel Angel Garcia-Martin Read:
draft-garcia-sipping-3gpp-reqs-02.txt
Session release (6.14)
Dave Oran - Which of 3 t hings? reclaim state, reclaim media, get billing to reflect actual media stopped. All 3 have been tied together. Think of independent and get better solution Cullen Jennings - B2BUA feature transparency - don't understand the issue.
Miguel - need to understand all headers Dean - Not into requirements Jonathan - requirements are mixed, how do I bill for IP to IP phone calls on per minute basis - that is requirement Miguel - support all billing models - this is not only one. Rohan Mahy - Is B2BUA transparent or not - addressed in SIP WG and could impact requirements Dieder Meir - No resolution on list, B2BUA is not defined properly Henning - Stand in for UA to do things (BYE) - can deal with as a requirement Brian - I like it Christian Huitema - not specific to 3GPP - coupling of signaling and media should also work when not tight coupling between them. Miguel - agreed Jonathan - B2BUA - like SIP/H.323 - not fully standardized - is compliant to SIP. Requirement is for support of wide range of billing options - nothing to do with BYE. Why not correlate loss of call indicator with record. Why isn't that requirement Miguel - maybe? Dean - requirement clear Jonathan - No - draft already talks about implementation, not requirements
Brian - work document into requirements, or take as input and break up into multiple and send to SIP. Generalize the problems. What do you want? Miguel - Work on draft Brian - not saying this draft will be sent to SIP, turn into requirements then decide if this is sufficient. Hope it isn't. Jonathan - timing issues? Brian - Agreed - keep overload small. Hard to say today if stay together.
Rohan (not as chair) - Generic for prepaid services, not bearer but no money left. Dean - As identify each requirement and track and prioritize Brian - take to list. Objections to using this document (some did object) Christian - these are not SIP requirements Guiseppe - dropping SIP call due to non-SIP event - don't widen scope too far. Dieder - requirements are bundled, what if LAN cable disconnected, proxy wants to re-authenticate. generalizing in wrong direction. Just want proxy to release session. Dave - Is doc something we should start from? No clear path from this document. Suggest - design team to write alternative document. Separate three pieces mentioned before. Rohan - Answer to 3gpp requirements, another document Keith - Must make sipping work, need process, otherwise wasting time Brian - Agreed, we need better process. Jonathan - false idea that SIP proxies have notion of calls or sessions - don't know. Not a general requirement in SIP. Guiseppe - SIP* comment Jonathan - everyone wants 3GPP to succeed - that was threat. Brian - No more discussion
Inbound (MT) - home proxy stores path and adds as service route
Robert Sparks - Yesterday started to describe solution in bis. Will be discussed on list in coming weeks.
Outbound (MO) - visited proxy stores path on reg, appends as service route
Dave - Cached in first hop proxy, use preloaded routes in UA? Miguel - Risky, could bypass proxies Dave - Yes, and don't get media resources. Need to specify cached routes and preloaded interaction Keith - Other interaction issues as well Cullen - Combined with ASP requirements as well - useful. Dean - I first raised two years ago (polite applause)
Remote proxy service (6.15)
proposals: Path, preloaded route, loose routing parameter, relaxed loose routing, Service-Route Jonathan - Is it a specific proxy or a general service provider's proxy - makes a big difference in solution
Additional signaling information proposals: another body, another protocol, or new headers
Jonathan - syntax not important. What are semantic? Cell-ID location info and hence is geopriv issue Rohan - Yes Miguel - Need solution by March. Security in 3GPP will protect this information - no issue Keith - headers only used by trusted proxy. Dean - Local information - need standards track RFC. Non standard header means not using SIP. Every header needs an RFC based on SIP change procedures Andy Zmolek - If only 3GPP cares, why not SIP INFO Rohan - information is proxy to proxy, not UA, so INFO not appropriate Henning - process question - could register header with IANA, didn't need document. Has this changed? Allison Mankin (AD) - Headers come with rules/sematics. Can extend an IANA process if rules/semantics well understood. Henning - If you receive and don't understand, ignore - this was designed into SIP Allison - No, leads to unpredictable actions Henning - No supported mechanisms, doesn't know, your concern is valid. Gave "Powerball" header example. Dave - Now worried. 1. If header defined, nothing breaks, 2. If one element understands, causes problems. Do we want to stop people doing stupid things? Allison - Benefit for review of ideas. Dave - Are we trying to make it so one can break protocol? My company uses "stupid" SIP headers. Want to IANA register. Make sure that no other ones collide. Rohan - Out of time. Greg Sullivan - Same happened with Radius - didn't anticipate proxys. Mary Barnes - 3GPP Ad Hoc? Dean - Yes at 2200 after Plenary in Fountainbleu room
1400 Assured Services (former MLPP) Discussion Mike Pierce, Jim Polk, Henning Schulzrinne Read: draft-pierce-sipping-assured-aervice-00.txt
draft-polk-sip-resource-00.txt
Mike presentation
Henning - preempt in SIP doesn't really make sense. Dave - Nit in Approaches slide - mean authorization not authentication. Notify of what? Privacy concerns (colorful Bill/Monica/Hillary example) Mike - Only event, not who did the preempting - no privacy concerns Christian - Like call waiting tone on phone? Look at presence implications Don Chou - works like this in PSTN, need solution to preferential treatment. James Polk - different tones for different preempts. Dean - what needs to be addressed by changes in SIP? Mike - listed in Issues slide.
Dean - Resource header solution - do we want to work on it? Humm - legitimate requirement - yes Do we want to work on it - weaker humm. Good approach - no consensus
Brian - security will be done in SIP with help from security experts. Henning - Requirements are far outside sipping? Does this disappear Brian - We need a header for this. Need to mark. But, some document needed to build system. Suspect sipping does this. Need BCP on how system is put together. Only need header and security issues. Allison (not as AD) - Many different functionality's - agree that each one individual is good, not just lump them all together. Keith - Need mention on restriction on using this in some cases - international call example
Henning header presentation.
Brian - Like diffserv code point for signaling. Only marking signaling for now. Dave - no reflexivity or transitivity Brian - No
1430 Call Transfer Changes Robert Sparks Read:
draft-ietf-sip-cc-transfer-05.txt
Rohan - I'll get Replaces moving as SIP WG item Agreed to keep REFER moving, and add security plus additional flows to Transfer - no objections
1450 Changes in Media Server URI Draft Eric Burger Read:
draft-burger-sipping-msuri-01.txt
Andrew Zmolek - Either semantics work or they don't. Just write BCP and be done. Don't need discussion. No consensus on moving forward with this draft - humms Jonathan - need to solve bigger problems in sipping. How do we talk to automaton. Need requirements. could decide to put SOAP into SIP message, maybe. Now working on framework for conferencing/cc Sean Olson - Doesn't belong in IETF - only a convention. Not ready for BCP since we don't have experience yet. Dan Petrie - Should be Informational or RFC. Shardra Vijay - Needs to be mentioned in framework document at least. Sean - Doesn't have to be in a document Andrew - There are pitfalls. Dave - Don't need this for interoperability - things can talk to eachother. But, is useful for detecting cases where you expect one thing but another happens. Brian - there is a service invocation issue as Jonathan said. Dave - Agreed. Sean - Can interoperate without it. Ben - misrepresent RFC3087. Conventions can be built at higher layer. Rohan - Don't need to do configuration of entities Brian - provisioning is evil. Jonathan - Is this a W3C problem - very generic? There is precedent. They are working on the issue. Isn't it a similar problem. Should look there to borrow their approaches Dean (not as chair) - Naming conventions Brian - need more discussion later. Out of time.
1500 Wrap
Slides
3GPP requirements to SIP
User Requirements for SIP in support of...
Redirection Capabilities in SIP
Assured Service
SIP Call Flows Changes and Plan
Mapping of ISUP Overlap Signalling to SIP
Proposal for Multiparty/Call Control/Conferencing in SIP
SIPPING Principles
Resource priority
Transfer / REFER
'draft-stucker-sipping-publish-00'
User Requirements for SIP in support of...
Redirection Capabilities in SIP