OK, this looks good to me.
Thanks
Brian
On 2008-10-08 03:42, Alan Johnston wrote:
> Brian,
>
> Some suggested text below.
>
> Thanks,
> Alan
>
> Brian E Carpenter wrote:
>> 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.
>>
>>
> How about if we paraphrase text from RFC 3665 and RFC 3666 to say:
>
> " This document does not prescribe the flows precisely as they are
> shown, but rather the flows illustrate the principles for best
> practice for the transfer feature. The call flows represent
> well-reviewed
> examples of SIP usage to implement transfer with REFER,
> which are best common practice according to IETF consensus."
>>> 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" ;-)
>>
>
> I agree - I say this about Replaces in the Security Considerations section:
>
> An INVITE containing a Replaces header field should only be accepted
> if it has been properly authenticated and authorized using standard
> SIP mechanisms, and the requestor is authorized to perform dialog
> replacement. Special care is needed if the replaced dialog utilizes
> additional
> media streams compared to the original dialog. In this case, the user
> MUST authorize the addition
> of new media streams in a dialog replacement. For example, the same
> mechanism
> used to authorize the addition of a media stream in a re-INVITE could
> be used.
>
>
>> 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
