NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00
Jonathan Rosenberg <firstname.lastname@example.org>
Joerg Ott <email@example.com>
Dean Willis <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Vern Paxson <firstname.lastname@example.org>
Transport Area Advisor:
Vern Paxson <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe
Description of Working Group:
The Session Initiation Protocol (SIP) working group is chartered to continue the development of SIP, currently specified as proposed standard RFC 2543. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main work of the group involves bringing SIP from proposed to draft standard, in addition to developing proposed extensions.
Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular:
1. Services and features are provided end to end whenever possible.
2. Extensions and new features must be general purpose, and not applicable only to a specific set of session types.
3. Simplicity is key.
4. Reuse of existing IP protocols and architectures, and integrating with other IP applications, is crucial.
SIP was first developed within the Multiparty Multimedia Session Control (MMUSIC) working group, and the SIP working group will continue to maintain active communications with MMUSIC. This is particularly important since the main MIME type carried in SIP messages, the Session Description Protocol (SDP), specified in RFC 2327, is developed by MMUSIC. The group will also maintain open dialogues with the IP telephony (iptel) working group, whose Call Processing Language (CPL) relates to many features of SIP, and the PSTN and Internet Internetworking (pint) working group, whose specification is based on SIP; and will consider input from the Distributed Call Signaling Group (DCS) for distributed telephony services.
The specific deliverables of the group are:
1. A Draft Standard version of SIP.
2. Completion of the SIP call control specification, which enables multiparty services, such as transfer and bridged sessions.
3. Completion of the SIP caller preferences specification, which enables intelligent call routing services.
4. Completion of the SIP INFO method extension, used for carrying SIP session related information.
5. Completion of the "183 response" extension, to enable early session establishment.
6. Define a MIB for SIP nodes
Other deliverables may be agreed upon as extensions are proposed.
Goals and Milestones:
INFO Method extension submitted to IESG
Early session establishment extension submitted to IESG
Caller preferences specification submitted to IESG
Call control specification submitted to IESG
Draft standard version of SIP submitted to IESG
SIP MIB submitted to IESG
No Request For Comments
Minutes, SIP Working Group at IETF 47
The SIP Working Group met in conjunction with the 47th meeting of the IETF in Adelaide, South Australia on March 27 and 28, 2000. There were two standard sessions, both of which were well attended (app. 200 persons), with very full agendas. In addition to ongoing working group efforts, thirty Internet drafts were presented and discussed. Several of these were updates on previous work. Tom Taylor recorded the official notes, and Dean Willis edited the minutes. There was a draft publication of the minutes with one revision. The following is the final version.
Minutes of SIP WG, IETF 47. Notes recorded by Tom Taylor.
1. Agenda Bashing
The proposed agenda was accepted. Presenters from Kyoto University asked to be added to the agenda. The request was denied because their draft had not been submitted in time to be published by the IETF.
Dean Willis presented a summary of status of the WG work items, followed by a brief discussion of potential charter items. There was discussion as to whether the DCS drafts would be considered for adoption by the WG. The current drafts still have RFC2026 complienace issues preventing WG adoption as work items, but these issues may soon be resolved. The general consensus seems that several of the DCS drafts are likely to be adopted once the IPS is resolved.
The WG indicated consensus to adopt several tasks as chartered WG activities, including:
1. SIP server features (standards track)
2. Call flows (informational)
3. Session Timer (standards track)
4. Reliability of provisional messages (standards track)
5. SIP-T efforts:
6. ISUP MIME types (standards)
7. ISUP mapping (undetermined)
8. Single Line Extension (undetermined)
9. Guidelines for Extensions.
As a general note regarding the management of the work of the WG: Jonathan Rosenberg is attempting to assemble teams around specific work items, with the proviso that individual participants should not be over-committed. The "single line extension" team is an example of this.
3. Summary of Current Discussion On The List
Jonathan Rosenberg summarized the status of discussion of a number of current issues.
No issues have been raised on the list, nor comments received from the DHCP WG. The fast-track procedure applied to this work appears to be acceptable to the SIP WG.
2. Content In INVITE
Discussion in late December of how to include of content such as JPEG images in INVITEs brought out a number of points:
- whether to include the actual content, include it indirectly through provision of a URI, or include it indirectly as a media stream
- location of the content, in a header or in the body
- the need to identify how the content is to be used.
Jonathan perceived no consensus on these items, due to lack of comment on specific proposals made to the list.
3. WWW-Authenticate Syntax
There is a proposal before the list, but no comments have been received.
4. tel:// vs. sip:// URLs
Jonathan emphasized the importance of the issue, discussion of which has stalled. He would like to see a new push to resolve it.
5. URL Parameters For Telephone Numbers
A couple of issues have been discussed under this heading: how to indicate that the number shown is the result of an LNP lookup, and how to indicate private dialing plans. Again, Jonathan would like to see a renewed effort to resolve these issues.
6. To Quote Or Not To Quote: Digest-URI
Robert Sparks commented that most implementations use quotes around the digest-URI. Usage for other fields is variable. He suggests that all fields be quoted.
Glare Jonathan noted that three proposals are on the table for handling of coincident re-INVITEs. Scott Petrack noted the need for a solution that works with more than two parties. Jonathan responded that SIP states are shared only on a per-call-leg basis, except possibly in the case of multicast, so multileg coincidental invites may not be an issue. [A couple of points in Jonathan's charts were skipped because they are being considered by the SIP security task force.]
8. When To Send 183 Response
Jonathan presented the rules for use of the 183 response which had come out of discussion on the list. A brief discussion followed, in which a problem with the first rule was noted and resolved.
9. Overlap Dialling
Jonathan noted that there was no easy solution to the possibility of forking for a call in which overlap dialling is being used. David Oran suggested that when the gateway rejects the first call, it should return a contact which redirects all subsequent INVITEs to the same gateway. Jonathan noted that this changed the meaning of the Contact: header slightly, but its usage remains within acceptable bounds.
10. Early Media Criticality
Jonathan noted a continuing unresolved issue of how to distinguish between critical and non-critical early media. In general Jonathan intends to put out notes to the list to stimulate further discussion of the open issues.
4. Status Of I-Ds (Jonathan Rosenberg)[charts]
4.1 Caller Preferences (draft-ietf-sip-callerprefs-01.txt)
Jonathan summarized a number of changes in the current draft. There have been no objections to the use of case-sensitive matching. The draft is due to go to the IESG, but Jonathan is looking for volunteeers to check it out first.
4.2 Supported: Header (draft-ietf-sip-serverfeatures-02.txt)
The draft has undergone a major overhaul. The one open point had to do with use of the header with ACK. This has been fixed and the draft has been forwarded to the IESG.
4.3 Reliable Provisional Responses (draft-ietf-sip-100rel-00.txt)
A number of open issues still remain.
- cumulative acknowledgements: looking for an application to justify inclusion of the mechanism
- response to PRACK: retain mechanism
- CANCEL for PRACK: disallow
We are looking to pass this document to the IESG as a Proposed Standard by mid-April.
4.4 Guidelines For Authors Of SIP Extensions
Jonathan proposed that this be a WG work item. It would eventually become a BCP, but not for another year. For now it would be a living document as the WG accumulates experience. The sense of the meeting was to adopt the work item, but there were mixed views on how quickly it should be given formal status, with some arguing for near-term RFC status. This point will be taken to the list. Jonathan has volunteered to maintain the document if the WG chooses to make it a long-term project as he proposes.
4.5 Third-Party Call Control
This document has a number of dependencies, and various models of control are possible. In general the work does not involve an extension to SIP, but only a description of the usage of its mechanisms. For this reason Jonathan does not propose that it be a WG work item, but would like people to comment on it.
5. DCS Drafts
5.1 Resource Reservation (Bill Marshall) [charts]
This draft came about through the compromise merger of draft-ietf-mmusic-qos-00.txt and draft-dcsgroup-sip-resource-01.txt. The two-stage INVITE has been discarded. SDP enhancements in support of QOS and security negotiation include two new attributes (a=qos: and a=security:), with syntax provided for confirmation that the requested attribute values have been granted. Extensions to SIP in support of the negotiation of these attributes are covered in the same document as the SDP changes, with AD approval. SIP extensions include use of a header indicating that preconditions have been met.
The question was raised, whether there was any problem with using the a=qos: attribute with provisional responses to allow the invitee to set preconditions. Bill made the point that the first user of the attribute has to know whether the other end would understand it.
5.2 Caller Identity (Flemming Andreasen) [charts]
Flemming summarized changes in the draft. Earlier work has been extended to recognize the possibility of boundaries between proxies. In geneal, rather than requiring a nounary proxy to remove calling party information, any proxy may encrypt the field and list itself as an authenticator. A new header, "Remote-Party-ID", has been defined. The set of possible operator services has been generalized.
Scott Petrack suggested that a specific tag for operator services might not be in the spirit of SIP. Jonathan agreed that an alternate approach might be possible. The basic idea, as always in SIP, is to define a small set of reusable features rather than a variety of specialized ones.
5.3 Distributing Call State (Bill Marshall) [charts]
The mechanism has changed completely since the previous draft, in an attempt to make it more general. The draft now takes care to distinguish between transaction state, connection state, and call state. The rules for including the "State" header have been simplified. There was a comment to the effect that the state information must include the information necessary to ensure that it is not used for a different call from the one which generated it.
5.4 Proxy-to-Proxy Extensions (Mike Mannette) [charts]
Mike reviewed the changes from the previous draft. LNP support has been provided and hostport is now a required field in the "Gate" header. The "Billing-Info" and "Billing-Id" headers are unchanged.
5.5 Media Authorization (B. Beser) [charts]
This draft addresses the need for a per-call mechanism to authorize the flow of media. The new draft has been changed to focus only on the client. The former "DCS-Local-Gate" header has been renamed to "Media-Auth". The content has been generalized to hexadecimal.
6. Subscribe-Notify (Adam Roach) (draft-roach-sip-subscribe-notify-00.txt)
Motivation: there is a need for a central definition of concepts which have been mentioned in various documents. The draft formalizes the methods and headers associated with subscription and notification. Distinctions are made between call-related and resource-related subscriptions, with the latter typically being of interest to third parties. Rules are set down for notifications and for duration of subscriptions. The author attempted to avoid disruption to PINT, but it might be possible to combine the PINT work with this new material.
Scott Petrack noted that PINT had spent a great deal of time working to make their mechanisms sufficiently generic. He urged Adam to review the PINT archives. Unsubscription proved to be a tricky topic, and PINT found it preferable to list events in bodies rather than in headers. Scott and Adam will discuss this further off-line.
Henry Sinnreich asked what measures had been taken to coordinate with the Instant Messaging and Presence (IMPP) WG. Jonathan replied that IMPP is addressing a different problem and had already judged SIP to be unsuitable for their purposes. He also recalled that a general subscription/notification BOF was held, but nothing came out of it because the problem was too broad.
Scott Petrack noted that PINT will change if necessary to conform to SIP.
An example subscription/notification service was presented, where the caller is rung back when the callee becomes free. There are open issues where further work is required. Jonathan proposed that another task force be set up on the Egroup mail server, to refine the problem statement.
Michael Thomas questioned whether SIP really needed an asynchronous method of completing a call when the current protocol can support a blocking approach.
7. Mobility (S. Baba) [charts] (draft-itsumo-sip-mobility-req-00.txt)
The draft provides requirements, open issues, and relevant work items in SIP and other WGs. The requirements are organized on a functional basis.
Addressing the charts, Lawrence Conroy asked what was meant by the requirement to "utilize" CDMA soft hand-off. He saw this as invisible at the IP level. The presenter pointed out that the process might involve multiple IP addresses for the same UA. This would represent a major extension to SIP.
James Polk noted that the forthcoming Location Information BOF might be relevant to this problem.
[end of first session]
8. Review Of Charter Work Items (Dean Willis) [charts]
Dean asked for comments on the proposed work items before the WG chairs reviewed them and passed the results of the review on to the list. There were no comments.
9. INFO Method, Session Timer, 183 Session Progress (Steve Donovan)
9.1 INFO Method
Work on the INFO method, draft-ietf-sip-info-method-01.txt, is basically done.
9.2 Session Timer
The Session Timer draft (draft-ietf-sip-session-timer-01.txt) underwent significant change to reflect the new "Supported" header. Some issues remain before WG Last Call:
- refreshing of the timer. Jonathan suggested that this be done by re-INVITE, rather than a new method. Agreed.
- Session-Expires header problematic in anything but INVITE -- will be allowed with INVITE only.
- Can a proxy add Required headers? -- could end up with multiple required headers if the UAC also includes one. This doesn't seem to break anything, but there is an interaction with authorization. In the absence of comment from anyone but Jonathan, this should be checked out on the list.
- The question was asked: what happens if the called UA includes Session-Expires with a re-INVITE and it contradicts the one set by the calling UA? Steve suggested that it would be up to the implementation to sort this out. The list will be invited to comment.
- agreed that this becomes an official WG work item
- submit shortly to WG Last Call.
9.3 183 Session Progress
draft-ietf-sip-183-00.txt has a lot of dependencies, resulting in improved understanding of the issues. It may be used for early media and for pre-conditions. Summarizing the extensions involved:
- full session description bodies in 18x responses
- add the 183 response
- provide the "Session" header to indicate the purpose of the session description body
The first two items are in 2543 bis already. It is proposed that the Session header draft be refined to narrow its focus, taking advantage of the 183 documentation.
10. Call Control (Robert Sparks) [charts]
10.1 Framework For Call Control Extensions
Needs to be aligned with the guidelines.
10.2 Call Transfer (draft-sparks-sip-cc-transfer-00.txt)
Proposes a new TRANSFER method (not BYE ALSO), which does not alter the original session. Open issues:
- name of the method. Jonathan interjected that he does not want to build protocols for specific services, hence the method should have a more abstract name and definition. Dean Willis suggested "Introduce".
- whether the method can carry bodies
- authentication. Dean Willis suggested an "Introduced-By" header, signed by the transferor.
10.3 Service Context -- Use of the SIP Request URI
This is an informational draft proposing the transmission of service context through use of a distinctive Request-URI. Robert provided an example application and described the advantages of the mechanism. David Oran was unclear on the intent of the work. He noted that it takes the opposite approach to that of HTML, by using the left side of the URL rather than the right. The syntax conflict could make the result different depending on the server. Dean Willis pointed out that SMTP also uses the left hand side, and that web URLs lack the @ and therefore HAVE no left hand side. Robert responded that the URL is intended to be an opaque entity bound as a whole against a particular service. David agreed that under these conditions the format was acceptable.
The authors were encouraged to submit this work for informational RFC status. This work was not adopted as a group effort of the SIP WG.
10.4 Call Flow Examples (Presentd by Robert Sparks)
The draft has had a number of updates. Please forward any further flows to Alan Johnston (email@example.com).
Jonathan noted that the document is getting too large to handle easily. He proposes to farm out subsections to volunteers to review. Ideally they should simulate the flows to validate them. Alan Johnston will coordinate the work.
There is an issue with dependencies on work in progress. The document will be partitioned so that the stable part is processed first.
11. IETF SIP MIB (David Walker) (draft-ietf-sip-mib-00.txt)
Issue: the document is 70 pages long. Can this be reduced? It covers RFC 2543 plus the INFO method and the 183 response. Items are defined within configuration, statistics, and notification groups for each of the UAC, UAS, proxy, registrar, and redirect server, except that elements common to all of these are grouped separately. (Nothing has been defined as yet to be specific to the redirect server.)
Concern: too many measurements. Discussion of this brought out the following:
- measurements should be defined only if there is a stated use for them
- they are used as a troubleshooting tool, but a message history tool would do a better job
David will send a note to the list to provoke further discussion. Comments on how measurements are used will be welcome. The note will also raise a number of other questions for comment. The current draft contains a couple of known errors.
12. BCP For SIP to ISUP Mapping (Gonzalo Camarillo) [charts]
This draft covers requirements, call flow examples, and the mapping of parameters between the two protocols. Gonzalo went over the changes to the draft:
- new name
- additional extension: umbrella REQUIRE
- refinement of scope
- a discussion of SIP bridging between ISUP networks
- corrections to the handling of overlap signalling
- added examples.
Gonzalo presented a walk-through of the overlap signalling case. There is a lot of messaging, but, unlike in the previous draft, it works. There is an open issue of how to control routing of overlap signalling in the case of a stateless proxy forwarding to loadsharing MGCs.
A question was asked: how is connection redundancy handled -- for example, UA multihoming. What if the successive messages arrive at different answers. The reply was that this issue was out of scope of the draft. Jonathan remarked that SCTP transport for SIP is a topic for the future.
Gonzalo concurrently presented a report on the status of the SIP-T work. It was noted that of the SIP-T work, the highest priority is to obtain approval of the ISUP MIME types document. This is currently planned for May 2000.
13. SIP Mapping Of MLPP (James Polk) [charts]
There is a mismatch between SIP "priority" levels and MLPP levels. The draft proposals are to add a level and add administrative hooks. Jonathan remarked that the standard is not the place to specify the administrative hooks -- they belong in an RFP.
Subsequent discussion brought out two points:
- added priority level in RFC 2543bis
- additional document describing operation of MLPP. This would cover a number of items besides SIP, so it should not be a SIP WG document.
Jonathan also wondered whether MLPP really impacts SIP except at the gateway, since it is concerned with preemption of limited call resources in the face of higher-priority demand and IP resources are not so obviously limited as circuits. Brian Rosen disagreed, pointing out that MLPP is not only about preeemption. The outcome of the discussion was consensus to discuss adding another priority level to 2543bis, or possibly adding "token" to the grammar allowing arbitrary extension. This will require list review. James Polk may submit a detailed fraft showing how the SIP priority levels can be used to implement MLPP requirements.
14. Update On ISUP MIME Types (Lyndon Ong) (draft-ong-sip-qsig-mime-00.txt)
The draft has one open issue: the amount of ISUP version information required. Followup is occuring in the SIP-T subteam and will be reviewed on the main list when ready.
15. SIP and QOS (Henry Sinnreich) [charts]
Henry presented a list of "to do" items associated with the work. He hypothesized that a new WG may be required. As evidence of this he cited the need for a framework, within which different QOS models might operate.
Radhika Roy mentioned that ITU-T Study Group 16 is also doing QOS work, and the two groups could share their results. Henry agreed that this was possible.
Patrice Calhoun asked about the relationship between QOS and OSP (Open Settlement Protocol, which appeared on Henry's charts). Henry indicated that OSP was relevant because it supports the clearing house model of settlements, and the latter differs from the AAA WG model.
Melinda Shore remarked that overall (thinking also of DCS) there seemed to be some strange QOS work going on, driven by charging models. Hooks within SIP are in scope for SIP WG discussion, but the general topic of QOS for VoIP is out of scope.
Continuing in his presentation, Henry presented call flows showing the tight coupling between signalling, QOS, and AAA.
Jonathan remarked again that ONLY changes required to SIP are within the SIP WG's scope.
Dave Oran observed that DCS covers the "push model" of QOS: policy is pushed to the enforcement point. There is a need to develop a system for the pull model, with open security issues standing in the way. Dave proposed COPS-PR for this role.
Dean Willis suggested that perhaps the Transport Area WG could tackle the larger problem. Jonathan proposed discussing the matter with the ADs.
16. SIP Through Firewalls and NATs (Jonathan Rosenberg) [charts]
Jonathan noted that the topic of firewall/NAT traversal is being covered by the foglamps BOF. The question is whether the SIP WG wants to do an Informational RFC on the specific topic of SIP operation through these barriers. Dean Willis suggested that the question of whether this work belongs in SIP is of the same order as whether MLPP does -- that is, both are enablements for SIP within specific sectors.
There was a weak hum in favour of the work item.
17. Usage of TRIP For Gateway Registration (Jonathan Rosenberg)
This was simply an alert to the topic, which had been raised in the meeting of the IPTEL WG the previous day.
18. Transferring User Control Information In SIP REGISTER Payloads
(Jonathan Rosenberg) (draft-lennox-sip-reg-payload-00.txt)
We need a way to pass scripts from the client to the server. This draft is the same as the original version a year ago, with minor changes. There are several open issues. Jonathan asked "Should this be a SIP work item?", which started a lively discussion. Radhika Roy suggested there was a relationship to and potential impact on mobility; Jonathan disagreed. Lawrence Conroy wondered how the scripts would be authenticated. Dean Willis mentioned several approaches that have been suggested.
Dean put the question: "even with the other alternatives, is it useful to do this function via REGISTER?" There was a slight hum in favour, no opposition, with most registering no opinion. The work was accepted as a WG task subject to approval on the list.
19. Finding A SIP Server With SLP (James Kempf)
The intention is to add a template to the IANA service type registry. Motivation: there are several ways to locate a SIP server through DNS -- for example, by use of a naming convention. The method presented allows location by characteristics. This is useful because different proxies in a domain can have different characteristics. The approach taken is to have one SLP abstract service type: "service-sip", with two concrete service types.
Jim presented an example: find a registrar supporting CPL.
An open issue is how to handle incoming calls. With other methods of DNS usage, one can parse down the hierarchy of server names. With SLP it may be necessary to use SIP forking or multicast.
Should this be a WG work item or an individual draft? IANA approval requires RFC documentation and approval by Eric Guttman (servloc Chair). Comments on the draft can go to Jim directly or to the list.
Jonathan noted that this is one of many possible methods, but that's OK. There is certainly no point in discussing whether this work should go forward as opposed to some other approach. The consensus was to not adopt this as a WG task at this time, but to follow the work as it matures and reconsider at a futue point.
20. CGI Interface (Jonathan Rosenberg) (draft-lennox-sip-cgi-03.txt)
The draft is being cleaned up. A couple of issues have been resolved. There are alternative methods for transfer of the CGI scripts. There appears to be no intent to make this a WG item at this time.
21. Distributed Multipoint Conferences Using SIP (Jeff Mark) [charts]
Jeff provided some examples, showing manipulation of full mesh conferences. Is there SIP interest in further such full mesh work? Jonathan noted that conference control is not part of the SIP WG mandate. The problem of topology management is overly complicated because call control should be separated from link state propagation. The latter is not something SIP is good at.
Jonathan will organize a first pass at rearchitecting the proposal, but there are other approaches to multi-party conferencing that may prove worth discussing.
SIP wg Items
SIP wg: New Drafts
SIP INFO Method
Open issues from SIP list
SIP MIB draft-ietf-sip-mib-00.txt
SIP Precedence mapping to MLPP Interworking
Distributed Multipoint Conferences
To Do Items for Interdomain SIP QoS
Event Notification in SIP SUBSCRIBE and NOTIFY
New Version of Informational Internet-Draft
Framework for SIP Call Control Extesionsd
Framework and Requirements for the Internet Intelligent Networks
BCP for SIP to ISUP mapping
Mobility Management in a SIP Environment Requirements, Functions, and Issues
Control of Service Context using the SIP Requet -URL
SIP Call Control : Transfer