Subject: [SIP] Comments on draft-ietf-sip-cc-transfer-04

From: William Marshall <[email-masked]>
Date: Mon, 21 May 2001 14:29:18 -0400 (EDT)

I have completed a review of draft-ietf-sip-cc-transfer-04, and have
a few problems/issues that I'd like to raise with it.

1.  The Referred-By header defined in draft-ietf-sip-cc-transfer-04
looks like a subset of the Remote-Party-ID header defined in
draft-ietf-sip-privacy-02.  I see no reason why two separate
headers need to be defined for the same purpose; I recommend
cc-transfer utilize the Remote-Party-ID header instead of defining
its own.

2.  There are some substantial technical issues with section 4.5,
Unattended Transfer with Consultation Hold.

First, there needs to be normative behavior specified for a UAS that
receives a REFER-generated INVITE, so it doesn't respond with a
486-Busy if the intention was a consultation transfer
(assuming the transfer target is still off-hook from the consultation).

The UAS also needs to respond to all INVITEs other than the REFER-
generated INVITE with a 486-Busy until the REFER-generated INVITE arrives.
How does the transfer target know to do this?  Something in the BYE?
Is the length of the interval purely implementation-specific?  I think
the draft should give some normative behavior for the first, and guidance
for the proper interval.

As this involves non-2543 handling in the transfer-target, I believe
a Require: header is needed on the consultation call; this draft
should define the tag value.

3.  Section 4.5.3 mentions some of the complications with proxies and
consultation calls, but not all of them; I believe there are still 
open issues.

One basic assumption made in this situation is that the Contact
header value from the consultation call is usable by the Transferee
to reach the same endpoint.  Such a globally-reachable Contact
is not required anywhere else - it is only necessary that the Contact
value be understandable to the last proxy that inserted itself into
the Record-Route header.  

As a consequence, I believe the Refer-To header may need a Route
header attached to it for proper handling of the REFER-generated
INVITE.  However, the Route headers for the existing call legs
are only partially applicable to the new Transferee-initiated
session.  How should the Route header be calculated for a REFER?

There are certainly situations where the backup proposal, Accept-Contact,
will not reach the desired transfer-target, and a Route header is the
only workable solution.  One such case is time-of-day routing, where
the transfer-target is removed as a valid translation of the destination
between the time of the consultation and the time of the transfer.

Remainder are mainly editorial, and easily fixed.

4.  Section 4.5.3 makes reference to the Accept-Contact header,
which is (I believe) only defined in 2543bis-03.  Normative definition 
of this should appear in the cc-transfer draft, avoiding the dependency 
on 2543bis.

5.  There are a number of editorial nits that need to be fixed in
the draft before submission to IESG.  
  a. The reference to draft-ietf-sip-cc-01 should be removed, since 
	that draft is no longer available.  Since it is an informative 
	references, rather than a normative one, the relevant information 
	can be included in the main body of the draft without adding it 
	to the list of references.
  b. section 2 should be removed
  c. two paragraphs starting "Open Issue" should be deleted from 3.6.2.1
  d. section 5 issues have been resolved technically, so should be resolved 
	in the text and removed

Bill Marshall
[email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 21 May 2001 16:59:47 -0400

Bill - Thanks for digging though this. I'm assuming (based on 
the last section of your feedback) that you did this as a nit-review
assignment?

I am in the midst of  splitting the draft, incorporating Replaces
and reworking the callerprefs usage in the application half of the 
split. I'll work through these comments while I'm in there.

Rakesh - Has anyone else been assigned to review this draft?
As I mentioned when Rohan completed the nits review - this
document is not ready for a last call nit pass - it is being
split into two documents, and each of those will need nit
pressure when they are done. This work will certainly benefit
from what Bill and Rohan have put into it, but if there is
something actually ready to go into last call, spend the
resources there.

RjS

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Monday, May 21, 2001 1:29 PM
> To: [email-masked]
> Subject: [SIP] Comments on draft-ietf-sip-cc-transfer-04
> 
>

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 22 May 2001 12:29:56 +0100

> cc-transfer utilize the Remote-Party-ID header instead of defining

This seems an excellent idea. One of the objects in the privacy draft was to
provide a generic capability for transport of identity information - now
that we have the capability, it makes sense to use it.

Regards,

Mark Watson
Nortel Networks

---

From: William Marshall <[email-masked]>
Date: Tue, 22 May 2001 09:04:50 -0400 (EDT)

> the last section of your feedback) that you did this as a nit-review

Actually, it was done based purely on the Last Call Calendar on the
SIP Supplemental Page (and my volunteering to be a reviewer by attending
the working sessions at last IETF meeting).  No formal assignment.

I've been a little puzzled by the dates on the calendar, though, and the 
lack of formal announcements on the mail list about last calls.  (e.g.,
is draft-ietf-sip-guidelines-02 in last call right now?  Does session-timer
go to IESG today?)

Bill Marshall
[email-masked]