Notes SIP WG Session 2, IETF 49

Reported by Tom Taylor


This is the record of the second SIP WG session. [NOTE: the Chairs' perception of the outcome of the many hum votes may be different from mine as recorded below, since I sat in the audience - PTT]

A. Official Work Items ===================

1. Caller Preferences (draft-ietf-sip-callerprefs-03.txt)

Jonathan Rosenberg [jdrosen@dynamicsoft.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 -- good 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 [huitema@microsoft.com] expressed the opinion that the design was poor. Rohan Mahy [rohan@cisco.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 [rsparks@dynamicsoft.com] pointed out how this is not really a problem. The manyfolks-sip-resource draft adds complications.

What to do with this work? Henning Schulzrinne [schulzrinne@cs.columbia.edu] 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 [dean.willis@softarmor.com] suggested that this material is within the scope of chartered work, since it deals with call control.

Hum acceptance that work in third party call control should continue.

4. REFER (draft-ietf-sip-cc-transfer-02.txt)

Robert Sparks [rsparks@dynamicsoft.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. Assuming the work is not modified by general review, the Chairs are aiming to wrap it up by mid-January.

5. SIP-H.323 Interworking (draft-agrawal-sip-h323-interworking-reqs-00.txt)

Alan Johnston [alan.johnston@wcom.com] 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. 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 [wtm@research.att.com] presented the status of the various drafts originated by the DCS group.

draft-ietf-sip-manyfolks-resource-00.txt

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 [sdonovan@dynamicsoft.com] 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.

draft-ietf-sip-privacy-00.txt

This draft also depends on 183. 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 back. Bill responded that the context is different in this case: it is not something a proxy trusts another for, 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.

draft-ietf-sip-state-00.txt

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.

draft-ietf-sip-call-auth-00.txt

Matt Holdrege [matt@ipverse.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 [mramalho@cisco.com] 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.

draft-dcsgroup-sip-arch-03.txt

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).

draft-dcsgroup-sip-proxy-proxy-03.txt

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 [alan.johnston@wcom.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. There was a request to add FAX call flows. 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.

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.

draft-vemuri-sip-t-context-01.txt

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

draft-ietf-sip-100rel-02.txt

A hum indicated continued Working Group interest in this extension.

draft-ietf-sip-srv-00.txt

Henning may be able to push out an update shortly. A hum indicated high interest. This document is an editorial extraction of material from the main protocol document.

draft-ietf-sip-mib-01.txt

It may be possible to take this work to Last Call in January. Henning indicated that they are doing an implementation of the MIB.

draft-ietf-sip-guidelines-01.txt

This document is ready for Working Group Last Call to BCP. A hum indicated good interest.

draft-ietf-sip-rfc2543bis-02.txt

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. Jonathan sees a need for an annotated specification giving motivations and implications. Annotations would be informational.

============

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 general degree of interest.

2. Session setup with media authorization (draft-hamer-sip-session-auth-00.txt)

Louis-Nicolas Hamer [nhamer@nortelnetworks.com] 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.

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. It failed the hum test for level of WG interest.

3. SIP Common Gateway Interface (draft-lennox-sip-cgi-04.txt)

Jonathan Lennox [lennox@cs.columbia.edu] provided a brief status update. 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

[I'm sorry, I forgot to note who presented. I expect it was Gerhard Gross -- PTT]

Three drafts were presented: draft-gross-sipaq-00.txt, draft-gross-cops-sip-00.txt, and ???

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 [huitema@microsoft.com] 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.

7. draft-rosenberg-sip-entfw-00.txt

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.

8. draft-rosenberg-sip-app-components-00.txt

Interest.

9. draft-rosenberg-sip-conferencing-models-00.txt

Some interest.

10. draft-johnston-sip-osp-token-01.txt

Ready for moving forward. Interest medium.

11. SIP Authentication using CHAP-Password (draft-byerly-sip-radius-00.txt)

Bryan Byerly [byerly@cisco.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.

Some interest.

12. Call Diversion Header (draft-levy-sip-diversion-01.txt)

Bryan Byerly [byerly@cisco.com] 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.

Low interest.

13. Route/RR Hiding (draft-byerly-sip-hide-route-00.txt)

Bryan Byerly [byerly@cisco.com] presented. Henning noted that route hiding needs to be done bidirectionally.

Low interest.

14. Peer-to-Peer Third Party Call Control (draft-mahy-sip-peer-3pcc-00.txt)

Rohan Mahy [rohan@cisco.com] 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 [matt@ipverse.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.

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. Future: Informational RFC, coordinating with the SIP-T framework.

Good interest.

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.

Tom Taylor +1 613 736 0961 taylor@nortelnetworks.com