Thanks Alan, there are clearly no show stoppers here,
just a few points where you can consider clarifying the
text.
> AJ> No, the call flows are not normative - there are too many
> variations to do this.
I definitely suggest saying that in the text in a slightly more
formal way.
> 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.
The latter. It might be worth a small note in the Security section; I can
see that it's a generic issue with Replaces, but it seems especially
acute in the case of a transfer to a 3rd party, and the UA should at
least warn the user. ("Smile, you're on TV" ;-)
Brian
On 2008-10-07 04:25, Alan Johnston wrote:
> 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/
>
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
