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.
|Mar 02||  ||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|
|Apr 02||  ||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|
|Jun 02||  ||Submit Internet-Draft on T.38 Fax Call Flows to IESG for consideration as a 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 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 Internet-Draft on Usage Guideline for Events (Subscribe-Notify) to IESG for consideration as an Informational RFC|
|Nov 02||  ||Review charter with Area Directors and recharter or conclude|
Current Meeting Report
Minutes, SIPPING Working Group, IETF 53
Chairs announce "Note Well" 2026 provisions.
* SIP-T and ISUP-SIP -- ready to resubmit after blackout
* SIP Overlap Dialing -- should be ready for WGLC next month.
* Requirements for Deaf -- Hum on objections, none noted, will move to last call.
* E164 and ENUM to discuss in ENUM WG
* cc-transfer -- depends on refer, replaces, has security concerns
* Fax -- new comments from ITU from group review, informal liaison reported, formal channels expected to be exercised soon. ITU has essentially combined and cleaned up T.38. They want to reference this doc, and are happy with it being a a BCP instead of informational. They wish to further request collaboration and notification of changes. They also suggest splitting fax and modem into two separate documents.
* Call Flows BCP -- needs updates to torture tests, do we need some bis-specific torture tests? We also need volunteers for formal review on a section-by-section basis, target WGLC for last of May.
Service Examples Draft, Alan Johnston:
* Updated for bis in this release.
* Open issues with getting setup info for transfers, etc. Suggest doing the development of the SIP events package proposed in draft-rosenberg-sip-call-package.
* Several issues with Replaces resolved, especially around transfer of call. Main one is use of Require: replaces to verify capability of foreign node.
* Join: Some primitive with a function like the draft-mahy-join-and-fork "Join" header required to complete single-line-extension.
* Caller Prefs: How should we demonstrate this stuff in call flows?
Multiparty Apps Framework Discussion, Rohan Mahy:
* The "new" cc-framework is an attempt to bring together categories and descriptions and working groups status of various drafts across SIP, SIPPING, and individual contributions.
* Question to group: Is this approach "what we are looking for". General response seems favorable, and the document editor will proceed.
Conferencing Requirements, Orit Levin and Henning Schulzrinne:
draft-levin-sip-for-video: Objectives are a BCP guide for building "multimedia" conferencing apps, with similar user interface and clear migration path from voice-only connections using basic non-extended SIP UAs.
Stuff in many WGs: * Call control in SIPPING * Capabilities exchange/declaration in MMUSIC * T.120 and other app integration in MMUSIC * Media control in AVT * Conferencing and Floor Control models in SIPPING/SIP
Media Control is viewed as critical open issue. Where should work be done?
Comment from audience: Sounds like exactly the original charter of the MMUSIC working group. Only difference is requirement that simple SIP client be able to participate in session. Also suggestion that "control channel" is just another media in the session, and should be treated as such by the system.
Comment from audience: The control channel is sort of like but not completely like media.
Suggested approach: do a framework draft, maps requirements to solutions using existing drafts andapproaches as possible, closely related to multi-party application framework.
Question from audience: presumes certain boundary around "what a conferencing application is", presumably from classic conferencing model. What about other approaches, such as collaborative editing models?
Requirements for Conference Control, Henning Schulzrinne: Suggest focus on media-independent control for range of conference models with core property of single "media choke point". Functional taxonomy presented in slides. List of floor control primitives in slides.
Comment from audience: Group membership management is very similar to authorization policy for subscription in Events structure.
This problem space seems to have commonalities with SIP: asynchronous event functions and synchronous command functions to "the conference" (as opposed to commands to participants).
Work division model proposed in slides.
Comments from audience:
* Shouldn't split asynchronous events from synchronous commands.
* This work spans a lot of groups but isn't in any specific one.
* Must make efforts to mesh well across many groups
* Missing something in the problem statement: We have not addressed of graph building, leaving us with star and mesh, neither of which scales. Media transmission along a graph is something we're not treating well. Once we can do that, if can think about controlling and eventing along the graph. Suggestion we decide the problem along these lines.
-- Response: This is a big effort. With the scoping suggested, we have a constituency. Don't want to repeat the last 10 years of MMUSIC.
* Request to get decision on work plan made soon. Chair position: There is clearly interest. We have to work out issues of scope and jurisdiction.
Request History Requirements, Mary Barnes:
Several examples presented of SIP call diagrams in which there may not be enough information in current SIP to make appropriate state analyses in various nodes.
Issues from mailing list discussed in slides.
* the general problem is not one of information loss. Propagating information upstream is oen of the problems. The second piece is "telling someone why they got a request". this is much more like caller pref sand identity issues.
* need to decide when to throw information away.
* may be important problem here, but where? we're getting into the identity issue again. We should work on this and try to find general problem. there is a profound slippery slope problem.
* discussion that there is a big difference between the lack of information at a random proxy, and the failure of a specific one.
* It's the systems that manage identities, not the endpoints, that need to have knowledge.
* Need to clearly delineate between "what happened to the request" and "what you want the next hop to do".
Hum for continue working: loud. Open issue with splitting it into two pieces.
SIP Telephony Device Requirements, Dan Petrie:
tries to formulate requirements for phone-like devices on fixed and wireless (not 3G) networks. Includes requirements for device configuration.
1) Configuration discovery -- maybe inside of SIP?
2) UA enrollment -- inside of SIP
3) Configuration retrieval -- outside of SIP
4) Configuration change notification -- may be SIP?
5) configuration change upload (phone to server0 -- outside of sip
Discussion: Use of SIP for configuration discovery and change notification.
Comment from audience: seems to be a lack of understanding and analysis of other protocols for doing this. Plea for simplifying the administrator role by reducing number of configuration mechanisms.
Comment: Didn't we decide not to do this two years ago? What has changed? Ans. We have now clarified between data transfer (not SIP) and SIP identity-related discovery and notification issues.
Comment: there has been some analysis of SNMP as not adequate.
Comment from AD: there ARE other conifguration protocols. This would be a very hard sell. chair action: defer to list. Hum for in/out of scope slightly weighted towards in scope.
Tel: URL enhancement work, Jon Peterson
Work is probably moving to iptel group. Please read rfc2806 bis and comment ASAP.
Emergency Services discussion, Henning Schulzrinne, Mike Pierce:
SIP Resource Priority, Henning Schulzrinne:
Establish priority when competing for terminating UA resources. This is not "network priority", more like an SMTP priority flag. Open issue: Do we need an Accept tag?
Comment: IEPREP group is working on requirements. We should hold up priority header until IEPREP has considered more requirements. At least we should let IEPREP look at it and see if it applies.
Comment: There are probably privacy and security requirements for use of this header needed to prevent SPAM. Security requirements in draft are probably not adequate.
Comment: Needs to be discussion of WHO will be looking at this header.
SOS, Henning Schulzrinne:
Issue on IANA considerations for reserving names such as "SOS@domain".
Comment: happy to have a BCP saying "SOS is a reserved word" but this is not a solution for e911 and we have to be careful that this is understood.
Comment: We should use MAYDAY or PANPAN instead of SOS.
User Application Control: Bert Culpepper: Assumptions and requirements given in slides.
1) What should the mechanism be: Is it SIP?
2) IS SIP Events framework appropriate?
3) If so, what should payload format be?
Comment: If we require people to subscribe, we need to tell them WHERE to subscribe
Comment: Would like to express higher-level semantics than just key scan-codes. For example "jump left three feet and shoot" instead of "4,4,4,5"
Comment: This is much more like a markup problem. Maybe we could provide a standard DTD for keys, or perhaps dynamically loaded for custom mappings.
Comment: Is a stop-and-wait protocol adequate?
Comment: Mechanism should be more extensible than just keys, but this is a good starting point. Comment: We don't want to reinvent X or VNC.
Comment: Two sets of requirements: delivery, and content. These should be dealt with seperately.
Comment: Previous questioner asserted difficulty with knowing semantics, but a markup approach could solve this.
Comment: There may not be a human at the UA, so if you don't have semantic awareness at the UA, you prevent useful interaction.
Comment: Current model of markup does not solve two-directional question of "what the device possesses" as well as the "what are the semantics".
Chairs: hum for interest? High level of general interested indicated. Feed changes in requirements into Bert.
PUBLISH Requirements, Robert Sparks:
Covers Donovan's requirements draft. Slides review requirements from Donovan draft. Review Stucker draft proposing solution to those requirements. Presents discussion of requirements abstracted from protocol proposals 1) Binding to SIP identities, and 2) Getting the information to the node responsible for the application associated with the SIP identity.
Question: Do we agree we need to meet these requirements?
Comment: Calling it a "publish" mechanism is semantically leading and should be avoided.
Comment: What are the kind of issues that would help us decide whether this needs/not to be SIP. Is it a single server or a server farm? Does it need to be reliably available to more than one place? Comment" this is same as REGISTER problem.
Comment: Skeptical if there is such a thing as a "generic upload requirement". Generally, this is more like an operation against a network object. This is consistent with SOAP or RPC. Comment: We should look at what we know, determine the specific requirements, and go from there.
Comment: Whether stuff uploaded is merged with an application or used en-bloc is up to the application, but a generic mechanism should be doable.
* No Issues
Accounting/AAA Systems, Bernard Aboba:
Slides describe requirements of real-world accounting requirements, including reliability, security, current issues with RADIUS.
Current issues with RADIUS include:
- backoff unspecified
- failover unspecified
- application layer acknowledgement missing
- undefined proxy behavior
- no error messages prevent intelligent failure response
- transport security has no confidentiality, known attacks
- replay protection only in post-processing
- no object security, MITM open
Alternatives discussed including SNMP, DIAMETER
Question: Why couldn't we use Web Services model and XML over secure transport? Answer: accounting semantics are undefined. It could be done, but hasn't yet.
Chair: We had this conversation in order to help us understand AAA requirements.
Question: There are existing systems usually in place (RADIUS). Why are we being blocked from working with them?
Proposal from chairs: Should we be able to do capacity planning and non-usage sensitive billing? Consensus yes. Is time sensitive billing in scope? Chair's
Question: We have real requirements -- why are we arguing about which grid-box from RFC 2975 we're going to try and fill?
Question: Time-sensitive billing is a requirement from 3G. Whether it is interdomain is option. Are we talking about the other two A's?
Comment: We should at least consider what has been accomplished with a non-IETF protocol in real-world billing systems.
Question: DIAMETER seems to be the implicit assumption. RADIUS may be obsolete, but should we, instead of arguing requirements, just do a standards-track spec for using DIAMETER and an informational track for using one or more of the existing protocols like RADIUS?
Allison: There will be resistance to any RADIUS solution on an RFC track. Why not just use SNMPv3? Chair comment that that doesn't appear to be a good fit for people are doing.
Question: When will DIAMETER exist? Spec editor reports that major issues are done, a few editorial and security considerations remain for documentation, otherwise ready to go.
Observation: RADIUS is widely deployed in accounting for dialup internet access. Many providers combine dial=up with VoIP and have incentive to use same accounting infrastructure. It would be useful for us to document any vulnerabilities of RADIUS that apply to SIP that did not apply to dialup. Response: If you're doing dialup, you're probably not in usage sensitive billing or at least don't have the same requirements as VoIP.
Comment: It is clear that we are driving while looking in rear-view mirror, trying to retrofit VoIP billing on RADIUS. It is clear that we have to look at record format (XML), secure transport (TLS), and look forward instead of backward.
Comment: We should keep in mind that we have a lot of work to do with things like record transfer and post-processing stuff independent of record formats and the like.
Other DCS Drafts:
Slides report status and background. Need to update for sipchange process as ind. informational (P-header, no options tag)
DCS architecture draft:
Slides report status. Similar sipchange issues.
Chairs poll for reading of drafts, and for concerns on informational publishing. Comment that we need to know if there are any
property claims, answer "probably".
Question? Will we apply sipchange? yes.
Poll for consensus to proceed -- no objections raised.
Report on 3GPP Ad-Hoc from 20Mar02 (Miguel Garcia):
Path header: current two drafts seem reasonable. Privacy: Several problems, no clear resolution yet. Dialed URL: (Target Address-of-Record): P-header approach seems feasible in the short term, may be able to use history or other mechanism in the future. EdNote: This could also be considered as something like a "display name" for the request-URI. 3GPP XML Body: Moving most content to P-headers. Security items as resolved in SIP.
Event Packages Procedure (Rohan Mahy):
Chairs: Do we need a separate guidelines document for the authors of SIP Events?
Question: Do we have a template that somebody to use to pre-screen their work for completeness? ENUM put together a template for service field definition. Is the stuff in the sip-events RFC adequate? Chairs poll for sufficiency: strong consensus, current guidance is adequate.
Call and Conference Package (Jonathan Rosenberg):
Slides review proposal from drafts and changes including examples, bis-alignment, addition of direction attribute, removal of To- headers in favor of explicit coding, removal of floor control. Next steps: at least one implementation known. Need to make sure scope is right and data formats have all information we need. Will split document into two packages (dialog and conference). Propose adding this effort as SIPPING WG item.
Comment: AS we start defining XML event packages, it looks like the world has moved on beyond DTD definitions into schema-based definitions. We should make a similar evolution in schema definition. Chairs: This is reasonable. Comment: This framework is needed for distributed call control and the work is supported by the speaker. Several confirming comments made.
Comment from chair (Rosen): Do we want to do this definition in SIPPING or is this something that should be done in SIP? This is a "piece" of the problem. It would be really nice to have a bigger view. Have we finished the requirements? Response: It's nice to understand big picture, but also nice to make incremental progress. Chair (Mahy) we need to follow procedure, but we have some requirements, can we proceed? Author: It would be nice to have some discussion of requirements on data format. This should be reflected one-to-one in the result document, so can be done in conjunction instead of as a separate effort. This is really a "piece of framework". General discussion follows. Poll for call-info package, none opposed. Poll for conference info package: none opposed.
Future Work (chairs):
Proposals in slides.
3PCC BCP: Never an extension because it was doable in straight SIP, mostly. This has been greatly improved in bis with o/a and update. So the proposed work is to discuss questionable alternatives and recommend best practices from the known alternatives. This is not intended to say that 3PCC itself is a better practice than distributed. Poll for adoption: no objections.
Message waiting: Poll for adoption as WG item: no objections. Question: package seems to want to do more than voice message waiting. Author response: will adjust to workgroup consensus. Question: Where do we document interworking this with ISDN?
Content indirection and reason codes: Will continue requirements development.
Opaque URI usage: Proposal to do informational draft on guidelines for use of opaque URIs.
MSURI draft: Propose to either roll into Opaque URI or publish as individual informational or do as WG effort. Comment: We haven't really as a group figured out how to do this osrt of thing. Would like to see something that steps back, looks at broad requirements, before delving into solutions. The usage of URIs as service indicators is one of the biggest architectural problems we face. Counter: This is too large an approach, and we need a solution today. Comment: It is important to define a framework for discovery. Comment: Unless there is someone pushing to do this analysis, the result is likely useless. It is better to proceed by just allowing people to document different approaches and label them with applicability statements. We don't know how big the problem space is, and it is likely to be very large. Comment: we need to define a schema. Comment: we need to do requirements, not jump into solutions. Comment: we need services, concern that if we stall on URI conventions that we'll have problems. Eric Burger volunteers to do framework. Comment: Suggest researching requirements and publishing msuri as an individual in the meantime. Chair comment: would like to see framework or requirements first. Poll: SIPPING WG to develop guideline document on use of URIs. Result - one opposed.
NAT Scenarios Draft: Should we do it as WG efforts? Comment: Dealing with NATS is an enormous tar pit. There are many options that apply to different scenarios. Discussion on scope follows. Comments: it would be good to bidirectionally align this with the "unsafe" framework document. Poll: Adopt this as wg item leading to informational rfc: None opposed.
Emergency Services Discussion (Mike Pierce):
Slides review status of emergency services draft and relation to IEPREP work. Proposal from chair: Can authors work with authors of resource priority header on SIP requirements and move other work to ieprep? Answer: That is how the authors are currently proceeding.
How do we deal with the approval policy for 3PCC stuff like accepting REFERs, etc. Ans: should be in usage drafts, if not send text.
Device Requirements: We didn't get to this the other day. Where do we stand on it? Comment: There has been some discussion that there may be other venues for operational discussions, such as SIP forums. Comment: Ideal world would be: IETF realized long ago that device configuration is a problem that will be universally faced and have developed a "plug-in" framework (like MIBs) for doing so. This didn't happen. Comment: discussed taking current config document and adding discussion and applicability of things like SNMP, ACAP, etc. Comment: The OAM area has committed to reading the document and working with the author and other interested parties. Comment: This is "right now" problem. We have all the tools we need. We need to write down an interop doc. Comment: We have a split between framework and content. Can we go forward with the definition of the data independent of the delivery mechanism? Request from chair: Can we continue this as individual work, discussed on SIPPING list, until more clarity?. No opposition. Comment: SIP end devices are a whole industry, managed by housewives to sysadmins with massive systems. Please think about it.
Settlement: Idea to generate discussion. There might be an opportunity to define a generic challenge-response settlement architecture framework. Comment: How about a response code that says "Payment required -- here's an invoice" something like a 401/407 challenge, with the re-INVITE to contain payment information. Comment: This screams for requirements development in the SIPPING process, need to scope the problem, describe some scenarios, and send text.
AAA: Earlier presentation did not explore large solution space now available. What we can we do if we bring in web services and similar technologies? Consider reviving interdomain settlement/osp drafts earlier "out of scoped" in SIP. Chair request: List discussion on proposal and approach -- "how can we get something done within IETF?" Question: Do you see this work diverging into user-service/provider and provider/provider channels? Response: Mostly between providers. The important thing is the trust function or clearinghouse that enables any-any business relationships.
SIP Plug & Play
3GPP ad-hoc report
Call and Conference Package
SIP Telephony Device Requirements
End Point Configuration Framework
End Point Configuration Data Requirements
SIP Resource Priority
Multimedia Conferencing Requirements for SIP Based Systems
Generic Request History Capability - Requirements
Requirements for Conference Control