Brian,
Thanks for your review of the document. See my answers and comments
below marked with AJ>
Thanks,
Alan
Brian E Carpenter wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sipping-cc-transfer-10.txt
Reviewer: Brian Carpenter
Review Date: 2008-10-06
IETF LC End Date: 2008-10-10
IESG Telechat date: (if known)
Summary: Almost ready
Comments:
This looks almost ready but I have some questions for clarification.
I have not reviewed the call flows and examples in detail.
4. Requirements
I'm not sure why the RFC2119 upper case keywords are used in
this section; it isn't specifying either a protocol or operational
practices.
AJ> You are correct - when these requirements were written (about 5
years ago), this was common but perhaps it is not now. I'm fine with
removing the RFC 2119 keywords.
5. Using REFER to achieve Call Transfer
A REFER [RFC3515] can be issued by the Transferor to cause the
Transferee to issue an INVITE to the Transfer-Target.
Conversely, I found it hard in sections 5 through 11 to figure out
what was normative and what was illustrative. Does that "can be"
imply that there may be another method?
AJ> Yes - there are many approaches to achieve a call transfer with
SIP. It can be done using 3PCC, re-INVITE, or a B2BUA. However, only
the usage of REFER requires SIP extensions and conventions - hence this
document.
I found no MUSTs, two SHOULDs,
one NOT RECOMMENDED, and one MAY. There are some lower case
"shoulds" - are they normative?
AJ> Here are the lower case shoulds and one lower case must:
Section 5:
"If the nature of
the Contact URI is not known or if support for the target-dialog
extension is not known, the REFER should be sent inside the existing
dialog. A Transferee must be prepared to receive a REFER either
inside or outside a dialog. "
Section 6:
"The participants in a basic transfer should indicate support for the
REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to
INVITE, and OPTIONS messages. Participants should also indicate
support for Target-Dialog in the Supported header field."
Section 7.3:
" The Contact URI of the Transfer Target SHOULD be used by the
Transferor as the Refer-To URI, unless the URI is suspected or known
to not be routable outside the dialog. Otherwise, the Address of
Record (AOR) of the Transfer Target should be used. That is, the
same URI that the Transferor used to establish the session with the
Transfer Target should be used. In case the triggered INVITE is
routed to a different User Agent than the Transfer Target, the
Require: replaces header field should be used in the triggered
INVITE. (This is to prevent an incorrect User Agent which does not
support Replaces from ignoring the Replaces and answering the INVITE
without a dialog match.)"
AJ> I'm OK with making these shoulds normative and the one must.
Are the call flows normative? If so,
I think this should be stated explicitly in section 5.
AJ> No, the call flows are not normative - there are too many
variations to do this.
[I-D.ietf-sip-gruu] seems to me to be a normative reference.
It's the only mechanism offered to solve the problem of knowing whether
a "Contact URI is routable outside a dialog" and it's used in 6.1
and 7.3 and listed as "supported" throughout the examples.
AJ> No, it is not the only way. See Section 5:
" One way that a Transferor could know
that a Contact URI is routable outside a dialog is by validation
(e.g. sending an OPTIONS and receiving a response) or if it satisfies
the properties described in the GRUU specification
[I-D.ietf-sip-gruu]."
Also, note that this spec doesn't require the GRUU specification and
mechanism, but just GRUU properties in the Contact URI. The working
group has discussed this a few times and each time agreed to not make
GRUU mandatory or normative to this document.
≠≠≠≠____________________________________________________________
Minor questions:
4. Requirements
1. Any party in a SIP session MUST be able to transfer any other
party in that session at any point in that session.
Does "at any point" include session establishment and teardown?
AJ> No, once either side has sent a BYE, the session is dead and there
is no way to perform a transfer.
5. Using REFER to achieve Call Transfer
...
The media negotiated between the transferee and the
transfer target is not affected by the media that had been negotiated
between the transferor and the transferee.
I have a small concern about privacy issues there. For example, could the
Transfer-Target find itself in a video session after a transfer, both
unexpectedly and unintentionally from the user's point of view?
AJ> Are you concerned about being in a video session with one party
then suddenly being in a video session with another party? Or are you
concerned that an audio call could suddenly add video after a transfer
without getting the user's permission? If the latter, this is an issue
that we should have dealt with in Replaces RFC 3891. RFC 3891 tends to
assume that the same media types are in both the replaced and replacing
sessions. It does talk about rejecting the INVITE if the replacing
media type is incompatible, but this doesn't cover a case of adding a
new media type. The solution to this would be for the recipient of the
INVITE with Replaces alert the user of any new media types before
accepting them, or only accept the same media types as the replaced
session and declining any new media types. The new media types could
then be explicitly turned on by either party using a re-INVITE which
would trigger normal authorization policies and procedures.
≠≠≠≠____________________________________________________________
Typo at the end of section 11.1:
(This might easily be missed in editing.)
If the
gateway supports more than one truck group,
s/truck/trunk/
