NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 13-Oct-00
Joerg Ott <email@example.com>
Brian Rosen <firstname.lastname@example.org>
Dean Willis <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Transport Area Advisor:
Allison Mankin <firstname.lastname@example.org>
To Subscribe: email@example.com
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
Request For Comments:
The SIP INFO Method
Draft Minutes of SIP WG, IETF 49
Reported by Tom Taylor. Edited by Brian BAscom, Dean Willis
The SIP Working Group met in two sessions, on Monday afternoon and Tuesday morning. In addition, informal meetings were held on some open issues from the list particularly including early media, on conferencing, on networking appliances, and on security. The Working Group sessions were chaired by Dean Willis [firstname.lastname@example.org], Brian Rosen [Brian.Rosen@MARCONI.COM], and Joerg Ott [email@example.com].
First Session =============
1. BOF Announcements
The chairs drew the meeting's attention to the PRIM/SIMPLE BOFs scheduled for Monday afternoon, and announced the other BOFs mentioned above (except for the meeting on open issues, which was arranged later).
2. Agenda bashing
The agenda presented by Dean Willis was accepted.
3. Open Issues On the List
Jonathan Rosenberg [firstname.lastname@example.org] presented.
Problem: RFC 2543 contains no information on how to route in the reverse direction.
A meeting of interested parties was held at the bakeoff. A consensus was reached as indicated in the list: -- proxies can only use SIP URLs -- a proxy MAY insert any SIP URL it wishes so long as the URL routes back to that proxy -- the proxy SHOULD insert a URL that routes to the correct user in each direction -- the UAS reflects Record-Route including parameters in the 200 OK -- the methods by which the UAC and UAS build routes was specified -- a proxy may modify a Record-Route URL in a response -- there will be no transport param in the Record-Route URL: preferences obtained by SRV or similar means -- there will be no special handling for RFC 2543 clients not inserting Contact.
Robert Sparks [email@example.com] commented that he had had concern during discussion about the transport issue, because it relies on SRV environment which is mot yet deployed to get transport preferences. It would be nice to have an interim solution. Henning Schulzrinne [firstname.lastname@example.org] responded that it is possible to issue a hint, but he worried that the interim method, too, may fail because of lack of awareness that it has to be configured.
(b) Meaning of Call-ID
What is meaning of a call with an existing Call-Id but a new From? It could indicate -- a new party to an existing call -- the new party replaces the existing party -- no special meaning. There is an issue with the first position: it uses Call-Id as a conference identifier. This is not always workable (e.g. in the merge case, where two separate calls are joined).
Proposal: Call-Id has neither conference nor replacement semantics. Define formal ways for conference, replacement.
Henning was concerned that we thereby lose the distinction between call-leg and call, which could be useful in future. Rohan Mahy [email@example.com] was concerned that we need more than the call/call-leg distinction gives us, and replaces isn't enough. There was further discussion, but the issue was not resolved.
(c) Tag issues
How is the tag computed? With what scope of uniqueness? The tag is used to: - reject incoming requests for a previously rejected call - differentiate multiple 200 OK responses to INVITE - identify a new call as re-INVITE for a pre-crash call.
Solutions: make tag unique to the UA instance (for crash protection) or unique within a call (otherwise). However, there is a problem when a call made by a UA returns to it. For crash recovery, we need two tags, each a function of the UA identity, to go into the To and the From header respectively. Incoming calls with an apparently new Call-Id but containing either tag are old calls.
Henning was concerned about over-specification within the standard. Further discussion resulted in agreed text, which will describe construction of the tag if crash-survival is not a requirement, plus a "MAY" clause for crash-survival.
More problems: what happens if there was no tag to start with, but the evolution of the call results in one being needed later. From tags are mandatory in rfc2543bis, as are To tags in the response. The issue is that there can be problems with older rfc2543 clients, and that these need to be handled gracefully.
Another question: suppose the UAC receives a BYE after a crash and reboot. This will have an apparently new Call-Id, but a familiar tag. Should the response be 200 OK or 481? Jonathan suggested that the UAC issue a 200 OK to ensure that the call is cleared. Christian Huitema [firstname.lastname@example.org] said to use 481 -- admit you don't know about the call and let the far end recover. Adam Roach [Adam.Roach@Ericsson.com] cited a need to distinguish methods in choosing the response. The basic concern is that 481 doesn't necessarily clear the call. Jonathan argued that, based on the principle of transaction independence, a 481 response on a re-INVITE fails that transaction but not the complete call. Despite this argument, the general view was that 481 means the call is dead. Jonathan's concern was that we are breaking a general model: call state shouldn't be determined by 400-class response. However this interpretation of 481 has already been implemented. The final consensus: 481 means the call is dead.
(d) SDP semantics
Which messages must SDP appear in, which must it not appear in? Jonathan looked to establish a general (probably complicated) procedure or restrict SDP to a finite set of possibilities. Henning asked that the meeting deal with 183 in a separate discussion. He proposed a "latest SDP prevails" model.
Itamar Gilad [ItamarG@tlv.radvision.com] urged that the WG get rid of SDP in ACK. Jonathan replied that some people depend on it for H.323 interworking. Christian Huitema suggested that the standard distinguish between acknowledged and unacknowledged messages. He proposed a rule that SDP can only be sent in messages which can be acknowledged. Robert Sparks noted some cases where re-INVITE does not work (e.g.) third party call control, especially with preconditions. Henning proposed that third party call control be handled as a special case, that it shouldn't shape the core specification. He had no issue with SDP in ACK for special cases. Gonzalo Camarillo [Gonzalo.Camarillo@lmf.ericsson.se] was concerned with ther effect on the transaction state machine if ACK is delayed waiting for SDP from the other side. Henning argued that 200 OK retransmissions are not such a big deal. Against Christian's insistence that it should be possible to acknowledge SDP, Henning pointed out that SDP in the ACK can be acknowledged negatively by issuing a BYE if it is unacceptable. The issues remained unresolved.
(e) Early Media
Many issues - can't change once started -- re-INVITE can't be issued while INVITE is in progress - can't easily get transferred while on hold - can't put early media on hold - difficult to reconcile with forking - the actual early media transmitted may not match the response code - requires PRACK - eliminates possibility of sequential searches.
However, we need some kind of indication for ISUP mappings. Possibilities: - live with it based on current wide deployment - deprecate, define separate billing-related signalling.
Itamar Gilad [missed his point] Adam Roach pointed out requirements beyond the PSTN e.g. resource reservation. Henning argued that early media breaks the session model, hence will continually break new methods and our material assuming that model. It is really desirable to preserve that model. He proposed a 283 response. Further discussion was deferred because of lack of time.
(f) mid-Call Redirect
Is a 302 response to re-INVITE allowed? What does it mean? What to do with Route headers?
The UAC can abandon the route set completely or partly reuse it. Abandoning could confuse proxies not in the original path. There is a problem if the new contact is not a UAS. In general, how to handle routes?
First question: is this a valid possibility? Henning suggested that we preserve simplicity, even if the documented procedure won't always work. Adam Roach made the specific suggestion to disallow a 302 response to a re-INVITE: mid-call redirection can be done by other means. The meeting agreed with Adam's proposal.
(g) IPv6 in SIP
Jonathan outlined a syntax problem with IPv6 addresses and gave three proposals for resolution. The meeting accepted the third proposal.
4. WG Working Methods
Jonathan Rosenberg reported that Scott has told the Chairs to be more restrictive on work item admissions. They plan to redraft the charter to scope the work to be done.
Henning noted that the difficulty comes about because the same group is handling both 2543bis and extensions. The preferred organization would have separate group(s) for extensions. Possibly there should be a split between PSTN-related and other work. Working Group management requires a solid draft progression plan with tracking.
Tom Taylor [email@example.com] wondered whether 2543bis should go back to MMUSIC, given changed conditions since last year's breakout. Henning responded that there were advantages to keeping 2543bis out of MMUSIC: more meeting time for both endeavours, and MMUSIC can concentrate on other work items. Dean Willis noted that some design teams set up last year continue to function, while others have faded.
Jonathan (continuing his remarks) observed that we need a project manager to run the WG, leaving technical experts to make their contributions. Also the Working Group needs more technical involvement -- other people besides Jonathan to write drafts. Finally, the WG needs more meeetings. Brian Rosen responded that the chairs are looking at the possibility of interim meetings.
Rohan Mahy noted that design teams stall because the same people are involved in multiple issues. The teams should consolidate and focus on priority issues. Dean Willis saw the need for more resources. Henning said no: the group needs a roadmap with priorities, so it can achieve solid progress on specific issues. He agrees with the need for aWG secretary and schedule tracker. Rohan Maky said the starting point should be currently chartered items. Christian Huitema took a quick census of those reading the list daily, and just a few hands were raised. He went on to say that the fact that most people don't read the list daily indicates overload. Henning noted the huge volume of FAQ questions. He made the proposal that there should be no more responses to newbies: the should be referred to another list.
The Chairs requested a hum on whether to create multiple WGs or reorganize the current one. The results were fairly even. Matt Holdrege [firstname.lastname@example.org] said we should make sure we write good specification if we want to reduce FAQ questions. Adam Roach made the final observation that not we are not likely to gain by splitting the WG, because the new groups would tend to have a common membership.
A. Official Work Items
1. Caller Preferences (draft-ietf-sip-callerprefs-03.txt)
Jonathan Rosenberg [email@example.com] reported on status. Judged by hum vote to be ready for last call -- good interest in implementation.
2. Session Timer (draft-ietf-sip-session-timer-04.txt)
Jonathan Rosenberg reported on status. There was a query: why not put in the main 2543bis specification? Jonathan responded that the group is trying to minimize the main specification. The draft was judged ready for last call -- high interest in implementation.
3. Third Party Call Control (draft-rosenberg-sip-3pcc-01.txt)
Jonathan Rosenberg reported on status. The authors propose to make this an Informational RFC, not a WG work item. The original draft had a retransmission problem with due to delay in returning ACK. Christian Huitema [firstname.lastname@example.org] expressed the opinion that the design was poor. Rohan Mahy [email@example.com] spoke in favour of progressing the work. Jonathan presented an alternative proposal: use re-INVITE -- but it can result in re-invite loops and assumes a single media stream. There was another proposal on the list: delayed ACK on re-INVITE but not too delayed. This still leaves a problem with UAs which respond to hold with hold. Robert Sparks [firstname.lastname@example.org] pointed out how this is not really a problem. The manyfolks-sip-resource draft adds complications.
What to do with this work? Henning Schulzrinne [email@example.com] wondered whether work on third party call control should be done together with work on the REFER method and possibly also PHONECTL. The Working Group should look at bigger picture, then decide whether to do all or particular items. Dean Willis [firstname.lastname@example.org] suggested that this material is within the scope of chartered work, since it deals with call control.
Poll -- " is the WG interested in doing this work" received loud positive response. The discussion will be passed to the list.
4. REFER (draft-ietf-sip-cc-transfer-02.txt)
Robert Sparks [email@example.com] presented status. The work is chartered. The draft was deemed close to Last Call until a timing issue came up: REFER can time out before the requested action completes. Various solutions have been proposed:
(1) two step -- immediate acceptance by the receiver of the REFER request, with a subsequent return request indicating the outcome of the requested action;
(2) REFER receiver accepts the request immediately and provides URL where the referor may subscribe to receive progress notifications;
(3) delay final response to the REFER request until the requested action completes or until half the timeout has expired, then if necessary send back a URL where the referor may subscribe to progress notifications.
Comments on these alternatives were invited. Robert and Jonathan agree with third approach. Adam B. Roach [Adam.Roach@Ericsson.com] argued that implementors would be stuck with implementing alternative (2) in any event, so it alone should be used. Rohan Mahy agreed, pointing out that subscription is optional -- it wouldn't be done for blind transfer. UAs that care to monitor progress would already have the complexity to do (2). Jonathan noted that this is fine for client, but he was concerned that the server shouldn't have to support presence in order to do transfer.
The discussion will be passed to the list. Polls indicated high level of interest , and assuming the work is not modified by general review, the Chairs are aiming to wrap it up by the end of January.
5. SIP-H.323 Interworking (draft-agrawal-sip-h323-interworking-reqs-00.txt)
Alan Johnston [firstname.lastname@example.org] presented status. The requirements draft is pretty well complete. The authors are looking to do an informal Last Call mid-January, with the intention of creating an Informational RFC in January. Hoping to get the material added as an Informational appendix to H.323.
The authors are also working on an interworking standard draft. They aim to present it at the March IETF, turning it into an Informational RFC after that.
6. DCS (various as listed below)
William Marshall [email@example.com] presented the status of the various drafts originated by the DCS group.
4. Bill Marshall reported on the various DCS drafts. In general, all drafts have been slightly clarified and updated to use current all control approaches. There is a general timing issue in that many of these drafts refer to 2543-bis features such as early media, provisional reliability, the 183 method.
Procedures have been added to deal with the case where neither endpoint can guarantee bidirectional QOS on its own. The authors are looking for Last Call, but the draft has a dependency on the 183 return code. Henning pointed out that if the WG is really waiting for 2543bis to document 183, it may wait a while. Jonathan Rosenberg responded that a separate draft is expected which will cover the use of 183 and PRACK for early media, and this may provide the necessary documentation. Steve Donovan [firstname.lastname@example.org] noted that, contrary to intent, 183 is not currently defined in 2543. Bug noted -- this needs to be fixed in bis draft right away. Jonathan suggested that at worst the WG can have a three-line 183 draft. The exact procedural resolution will be taken to the list. Gonzalo Camarillo [Gonzalo.Camarillo@lmf.ericsson.se] suggested that it is not clear-cut that we are ready to have Last Call on the resources draft, because some third party call control issues need to be ironed out. That will be discussed on list. Consensus is to remove dependency on 2543-bis and take to standards-track.
This draft also depends on manyfolks and 183(bis). The authors have identified additional SIP headers which need to be obscured to protect privacy. The document must be updated to follow through on procedures. The presenter was asked why the draft proposes to add Via hiding, which was removed from the base specification. Bill responded that the context is different in this case: it is not something requested by a previous proxy in a chain, but instead a unilateral action at a proxy. By hum: belief that the draft is not ready for Last Call. Jonathan suggested that we have one anyway to provoke comment. The WG chairs will consult with the ADs on action going forward, as further discussion is needed.
By hum, agreed to take this document to Last Call. Hum also indicated some implementation interest. Jonathan raised one objection in principle: this creates a second way to do the same thing, since state can put in URI parameters. Henning also thinks this should be reviewed. Others feel the issue was resolved when the draft was accepted as a work item. The Chairs ruled that the draft is going to Last Call, and Jonathan's objection can be discussed within that context.
Matt Holdrege [email@example.com] was concerned that the problem addressed by this draft has not been completely thought through.
As with the privacy draft, hum did not favour Last Call. As with privacy, there have not been enough comments on the list. Michael Ramalho [firstname.lastname@example.org] underlined this concern. The Chairs will ensure it is disposed of. Jonathan asked for raised priority. The Chairs agreed. Henning suggested that the Chairs direct list attention to current issues each week. Consensus on readiness for submission to IESG as individual effort on informational track with WG concurrence.
This draft is targeted to become an Informational RFC. Jonathan noted that publication as an Informational RFC can proceed despite 183 dependence. There was a solid hum in favour of moving forward (i.e. WG concurrence with publication).
There was Working Group concurrence by hum with publication of this draft as an Informational RFC. Christian Huitema pointed out an open procedural issue: IANA registration of the new option tag and header field names per section 4.4 of 2543bis needs to be completed.
6. Call Flows (draft-ietf-sip-call-flows-02.txt)
Alan Johnston [email@example.com] presented, reporting on changes from the previous issue. There have been a number of reviewers. The question now is what to do with document. Consensus reached to put test messages in a separate draft. There was a request to add FAX call flows and add text saying that 2543 takes precedence in case of conflict. Jonathan wants the word "telephony" removed. Henning called for volunteers to harness the document for capture of implementation outcomes for movement of SIP toward Draft Standard. Hum favoured Last Call to publish as an Informational RFC.
Alan noted that call transfer flows were added. He is looking for PBX feature type flows -- call park and pickup, 3WC, ...
Laurence Conroy suggested a need for service descriptions simply to let people see what the flows are about. Brian Rosen was very concerned that this not turn into a de facto service definition document.
6. Alan Johnston discussed the service examples draft. Strong consensus on importance of work, and on NOT "definining standards services" in this forum. Discussion: more centrex-like and PBX-like call flows are needed.
7. SIP-T Update
Jon Peterson [Jon.Peterson@Level3.com] presented. He began with a quick description of SIP-T: not extension of SIP, but a set of practices for interfacing SIP with PSTN. The scenarios covered are PSTN-SIP-PSTN and PSTN-SIP.
Since the previous issue, the authors have added information about content negotiation. A decision is needed on what to do with encapsulated ISUP when passing signalling to an untrusted party: encrypt it or strip it? The authors are considering whether to create a new SIP-T umbrella draft; they probably will.
The ISUP MIME draft has passed Working Group Last Call. It has been amended since the last IETF, with the addition of Content-Disposition "signal" and IANA language for ISUP variants. A hum indicated strong support for finishing this work.
Related work is still in progress: LNP & Freephone indicators in the tel: URL (draft-yu-tel-url-01.txt), and updates to the SIP-ISUP interworking draft (draft-ietf-sip-isup-00.txt).
8. Other Work Items
IESG review ongoing, anda hum indicated continued Working Group interest in this extension.
Henning may be able to issue an update early in 2001. A hum indicated high interest. This document is an editorial extraction of material from the main protocol document.
It may be possible to take this work to Last Call in January, to finalize for IETF 50. Henning indicated that they are doing an implementation of the MIB.
This document is ready for Working Group Last Call to BCP, with only minor changes made. A hum indicated high interest.
The bis document has been picking up minor material on the fly. The authors are looking to do a more formal review of organization and content, possibly split into two drafts (spec and discussion) in Feb 2001 timeframe. Jonathan sees a need for an annotated specification giving motivations and implications. Annotations would be informational. Very high level of interest indicated.
B. New drafts
1. SIP support for deaf and impaired (draft-gearhart-sip-deaf-req-00)
Arnoud van Wijk [Arnoud.van.Wijk@eln.ericsson.se] presented.
Motivation: business is highly telephone-oriented. The deaf deserve equivalent communications support. SIP multimedia is ideally suited for this purpose.
Arnoud presented different communications scenarios, then went on to a selected list of requirements. He followed up with example call flows: deaf caller to hearing callee and vice versa. He finished off with figures on the potential market: 10% of people are deaf or hard of hearing. Most products are also of value to the hearing market.
Progress of this work is up to the list. Hum indicated a strong degree of interest on further developing such requirements as a WG effort.
2. Session setup with media authorization (draft-hamer-sip-session-auth-00.txt)
Louis-Nicolas Hamer [firstname.lastname@example.org] presented.
Most proposals assume pre-established relationships. This draft does not. Thus it is especially applicable to mobile applications. The draft proposes a new method to identify the authorizing entity in a token. Several comments on need to converge the multiple media authentication mechanisms under consideration.
Jonathan objected to creation of an additional method and to the basic premise of the document. Progress of this work is up to the list. as the level of interest was inconclusive.
3. SIP Common Gateway Interface (draft-lennox-sip-cgi-04.txt)
Jonathan Lennox [email@example.com] provided a brief status update on sip-CGI and registration-payload: "still trucking". Registration payload has high level of consensus on interest.. The draft is in the RFC queue (Informational track).
4. SIP Register Payload (draft-lennox-sip-reg-payload-01.txt)
Jonathan Lennox presented. The basic idea is to be able to upload user control information (CPL, CGI) to proxy servers and to retrieve it for editing. The proposed solution is to put it into the REGISTER message body. Use Content-Disposition to indicate its presence -- Content-Type is not sufficiently abstract. Modify handling behaviour via Accept, Accept-Disposition.
Jonathan presented an example. He reported that there are still some details to work out. The work seems easy enough to finish. There are already a number of implementations. A procedural note: RFC 2183 requires new Content-Disposition types to be defined in Standard or Experimental RFCs.
The suggestion was made that the authors may want to generalize the approach to deal with other types of content.
By hum, the meeting judged this to be important work.
5. SIP and AAA
Two drafts were presented: draft-gross-sipaq-00.txt and draft-gross-cops-sip-00.txt.
The presentation included an architectural diagram showing the scope of the proposals. This was followed by a flow walkthrough. Someone commented that this is a system type study -- not directly a matter of SIP. It should therefore move to different group. Christian Huitema [firstname.lastname@example.org] also questioned competence of SIP group to evaluate the subject matter of the draft.
The hum indicated medium interest in QOS and AAA Usage and medium interest in COPS usage for SIP. The other draft was reserved for consideration as part of a later discussion.
6. SUBSCRIBE/NOTIFY (draft-roach-sip-subscribe-notify-02.txt)
Adam Roach [Adam.Roach@Ericsson.com] presented. Work on SUBSCRIBE/NOTIFY has been proceeding on a separate list. There have been a number of changes since the last draft.
Open issues: event agents, generic event throttling mechanism.
The question is whether there should be a formal BOF, or whether this should be a SIP WG deliverable. Hum indicated a high level of interest in the work.
Jonathan Rosenberg presented. The problem is that posed by the pervasiveness of firewall/NAT in enterprise and NATs in the home. The draft presents an ugly short-term workaround. Scott Bradner asked about its relationship to midcom. The difference is that the draft proposal requires no relationship. Christian Huitema questioned the SIP-specificity of the solution. Hum of interest high.
WG interest high.
WG interest moderately high.
22. Stephen Thomas discussed draft-johnston-sip-osp-token-01.txt. Several changes made. There are multiple implementations that have been baked off. Suggest publication as standards-track individual effort. Moderate to high WG interest.
11. SIP Authentication using CHAP-Password (draft-byerly-sip-radius-00.txt)
Bryan Byerly [email@example.com] presented the problem: the current SIP authentication format is not compatible with RADIUS. Jonathan Rosenberg suggested it might be easier to change proxies and RADIUS than all existing SIP clients. This needs to be combined with other AAA work. Low level of interest.
12. Call Diversion Header (draft-levy-sip-diversion-01.txt)
Bryan Byerly [firstname.lastname@example.org] presented. The proposed header indicates from whom the call was diverted and how many diversions it has undergone in total. The draft is aimed at allowing third-party UAs to provide customized features. Medium interest, discussion deferred to list.
13. Route/RR Hiding (draft-byerly-sip-hide-route-00.txt)
Bryan Byerly [email@example.com] presented. Henning noted that route hiding needs to be done bidirectionally. Mode discussion probably needed on the list. Level of interest expressed was low.
14. Peer-to-Peer Third Party Call Control (draft-mahy-sip-peer-3pcc-00.txt)
Rohan Mahy [firstname.lastname@example.org] presented. Current 3pcc reproduces the centralized model. The draft aims for a distributed approach instead. The basic idea is to use Refer-To URLs with a method parameter. SUBSCRIBE/NOTIFY would be used for status reporting back to the referror. There are a number of open work items. Good level of interest.
15. REPLACES Header (draft-biggs-sip-replaces-00.txt)
Low interest. Still could get pulled into ongoing discussions.
16. AAA Requirements (draft-calhoun-sip-aaa-reqs-01.txt)
Matt Holdrege [email@example.com] presented. He reviewed the process followed by the AAA requirements group, which led to choice of DIAMETER in other contexts. There should be a formal SIP requirements effort to support the appropriate choice for SIP. Good support.
26. Matt Holdredge discussed draft-calhoun-sip-aaa-reqs-01.txt. This has significant implications for 3GPP. Further work is needed in requirements gathering. Level of interest high.
17. ISUP/SIP Mapping (draft-ietf-sip-isup-00.txt)
Gonzalo Camarillo [Gonzalo.Camarillo@lmf.ericsson.se] presented. This is now a Working Group item. There have been some changes from the last issue. There seemed to be little controversy. Future: Informational RFC, coordinating with the SIP-T framework. Good interest by the WG.
The Chair asked if any other drafts should be measured for interest. None were put forward. The Co-chairs are looking to set up a new work organization. They will report and discuss on the list.
SIP for Networked Appliances
Interdomain SIP Usage with AAA and QoS
Session Setup with Media Authorization
SIP Telephony Call Flows
SIP Telephony Service Examples
Peer-to-Peer 3rd party call control
"manyfolks" and "dcsgroup" drafts
Subscribe / Notify
SIP-H.323 Interworking Requirements
SIP Authentication using CHAP-Password
Diversion Indication in SIP
SIP Record-Route / Route Hiding
SIP-T Status Update
SIP Common Gateway Interface