Andy,
Thanks for this detailed review. See my comments below.
I also have a few questions for the chairs, which are summarized here:
1. How to proceed with Appendix A which defines a new Alert-Info
header field parameter?
2. Should we remove Appendix B on alternative approaches?
Thanks,
Alan
Hutton, Andrew wrote:
Hi All,
These are my review comments on draft-ietf-bliss-shared-
appearances-02.
Overall I think the draft covers most of the requirements but needs
some
editorial work to remove some of the unnecessary sections and text. I
also think that it is necessary to explore some scenarios in more
detail
especially the glare conditions. For example in 10.7 (appearance
pickup)
what happens if the pickup fails and the already published state
needs
to be cancelled.
If the INVITE with Replaces fails (presumably because the dialog has
gone away or been marked exclusive), then the UQ will need to
PUBLISH again this failure. I agree a call flow showing this would
be useful. This would apply equally well to the INVITE Join case as
well.
It is the glare and recover scenarios that make this
feature so hard to implement and the draft says very little about
failure scenarios.
Yes, we need to include more failure and race conditions in the call
flows. Your INVITE Replaces suggestion will be included - other
suggestions?
The inclusion of the appearance number in the incoming INVITE
(appendix
A) is I believe a must have to make this work and should be a
mandatory
part of the main specification.
I agree it is also very important. I'd like to hear from the chairs
how we should proceed on this - I doubt that BLISS is chartered to
do a SIP extension such as a header field parameter. Will we need
to discuss this in DISPATCH? If so, it would be good to get started
on this now.
My detailed comments are as follows.
Section 1
3rd Para.
"Different approaches will be discussed including the use of URI
parameters....". Can we now remove the discussion on different
approaches.
This text is currently in Appendix B of the document. I agree it is
not critical to an implementor, however, it is the kind of thing
that BLISS is chartered to do. I'd like to hear the opinions of the
chairs and others on this. I'm fine with either including or
removing Appendix B.
4th Para.
"...gives this feature its" - Should this be "..its name" ?
Yes.
Section 3.1
"An assistant can make outgoing calls using the identity of either
the
executive or their own". This should be removed as making calls with
the different identities is not part of this feature.
Agreed.
Section 3.2.
Replace "SIP Telephony devices" with "SIP UA's" for consistency with
other sections.
Agreed.
Possibly replace "Another phone can request to be added to an
appearance
resulting in a conference call" with "Another phone can request to be
added joined or bridged in with the existing appearance". Again
this is
for consistency with section 3.3.
Yes.
Section 4.1.
REQ-4 contains the statement "UAs registering against the group AOR
should be able to learn about each other and join the appearance
group".
I don't think it is a requirement that the UA's "learn about each
other".
We were trying to say that UAs should not have to be configured with
information about other UAs in the group - I'll restate this
requirement.
Section 4.2.
4th Para. Contains the statement "The next section discusses normal
SIP
operations used to implement parts of the shared appearance feature".
This refers to the bulleted list below which appears to contain many
statements that I would not include in "normal SIP operations" and
should be part of the normative section.
You are correct that this should not be described as "normal SIP
operations", so I'll get rid of that. The steps in this list are
already repeated in normative language starting in Section 5.3.
Bullet 4 contains the statement "UAs receive a notification from the
Appearance Agent indicating the appearance number to use in rendering
the incoming call". I think it is a must that the incoming INVITE
contains the appearance number otherwise the UA cannot render the
incoming call until it receives this leading to all kind of race and
glare conditions.
This bullet should also mention the Alert-Info parameter as well.
If we make it mandatory, we will need to address which one has
precedence over the other, i.e. if Alert-Info says appearance 1
while the NOTIFY for the same early dialog says appearance 2. I'd
vote for the NOTIFY having precedence.
Bullet 7. What does the UA publish in this scenario?
It is described in Section 5.3:
A UA wanting to place a call but not have an appearance number
assigned publishes before sending the INVITE without an 'appearance'
element but with the 'shared' event package parameter present.
Perhaps a forward reference to this section would make this clearer.
Section 5.2.1.
The statement "When sent in a notification in state Trying to the
Appearance Agent" is incorrect because it is actually a publish
which is
used.
You are correct.
Section 5.2.4
Replace "convey" with "to convey".
Right.
Section 5.3.
1st Para. "defined in this draft". Please add a reference to the
section
that defines this.
I will reference Section 11.1.
3rd Para. "Upon initialization and at regular intervals, the UA
SHOULD
subscribe" should replace the statement about regular intervals
with a
reference to RFC 3265.
How about:
Upon initialization, the UA SHOULD subscribe to the dialog event
package of the AOR and refresh the subscription per RFC 3265.
3rd Para. "or returns a 482 Loop Detected" why is this singled out
is it
just one of many possible failure cases.
I thought it was a likely error case. We don't want an
implementation that gets an error at this stage to give up on the
entire shared appearances feature.
4th Para. "User Agents MUST support sending an INVITE with a Join
[RFC3911] header field to initiate bridging". Why is this a MUST
strength requirement it should be optional for the UA to support
bridging so a MAY would seem to be appropriate.
I'm worried that if we made it less than a MUST, implementors will
just skip it and the resulting feature will be very weak. I think
that only UAs that do line appearance monitoring don't need to
support Join.
4th Para Note. "Note that the Join operation can be implemented
outside
the UA, for example, in a B2BUA. This is why UAs must support
sending
Join header fields even if they do not necessarily support receiving
them". I think this can be removed and as previous comment I don't
think
this is a reason for mandating that a UA can initiate bridging.
This is badly worded. What is meant is that a UA can request to be
joined to another call even though it is not necessarily capable of
doing the mixing if another UA requests it. Handling this kind of
asymmetric feature is something we've done very very badly in SIP,
I'm afraid. I'll try to reword this text.
Section 7 (User Interface Considerations). I don't think we need this
section the purpose of the draft is to promote interoperability
between
SA implementations. Those implementing this will be well aware of
the UI
considerations that may be different depending on their particular
type
of UA.
I think this section is useful. Perhaps it would tie in better if
we had introduced these phones in Section 3.1. What do others think
about this section?
Section 8.3.
1st Para. "This type of UA will be detected by the Appearance Agent
by
the absence of the ma event parameter in SUBSCRIBE or PUBLISH
messages"
I think the event type is "shared" not "ma" also if the UA does not
support SA then I assume it will not PUBLISH to the appearance agent.
Yes, ma is from an older draft. A non SA UA would not likely
PUBLISH but it may still SUBSCRIBE.
Section 10.1.
I think the REGISTER from bob needs to be shown.
OK.
Section 10.2
2nd Para. "then the Appearance Agent will need to resolve the
situation
by moving either Alice or Bob's dialog to a different appearance".
This
is one glare condition that I worry about what would happen if all
other
appearances are busy ?.
Hmm. This would imply an upper limit to the number of appearances
in the group. We once had a requirement and scenarios for this but
they were removed as people thought they didn't fit the feature. Of
course, a hard phone with lamps and buttons might run out of button
and lamp positions, but this should be addressed in Section 7.
The diagram seems to imply that the INVITE (F7/F8) is not sent to Bob
until after the NOTIFY's have been sent but I don't think this is the
case and it would therefore seem better to move the sending of the
INVITE to before the NOTIFY (F2/F4).
Why? The INVITE can not be forwarded with the appearance number
until the appearance agent knows about it and processes it. In
processing the appearance number allocation, I would expect it to
immediately send NOTIFYs - for it to delay would not give a good
user experience for this feature. As such, I prefer showing the
NOTIFYs arrriving first. They are effectively happening in
parallel, although we have no way of showing that on the figure.
Some text perhaps could explain this.
Section 10.7.
The PUBLISH (F32) indicating the dialog to be replaced is sent before
the INVITE/replaces (F38) is this the correct order and if so it
introduces some glare conditions that we need to explain how to get
out
of.
Yes, this order is critical, otherwise the Appearance Agent will
probably reject the INVITE. I agree we should show the case where
the PUBLISH succeeds but the INVITE Replace or Join fails.
Section 10.9.
It is not explained how Bob indicates in the PUBLISH that he does not
want an appearance number assigned.
How about adding this:
He indicates this in his PUBLISH F32 by the inclusion of the
'shared' event parameter with no <appearance> element. This PUBLISH
is sent before the INVITE to Alice to ensure no appearance number is
assigned by the Appearance Agent.
The NOTIFY (F32) contains the dialog identifiers for the dialog with
alice but since the INVITE (F34) has not yet been generated it is
likely
that Bob's UA will not know this information so it cannot be
included in
the NOTIFY with state "trying".
This is the same thing we are doing in 10.4 and other places in this
specification. If any dialog information is available, it should be
included in the publish. This is described in Section 5.3:
Note that when a UA selects an appearance prior to establishment of a
dialog (#1 and #2 in above list), not all dialog information will be
available. In particular, when a UA publishes an attempt to select
an appearance prior to knowing the destination URI, minimal or no
dialog information may be available. For example, in some cases,
only the local target URI for the call will be known and no dialog
information. If no dialog identification information is present in
the initial PUBLISH, the UA MUST PUBLISH again after receiving the
100 Trying response.
Section 12 Appendix A.
I think this should become part of the main specification and
included
in the normative section.
Unless I am mistaken, I don't think that the BLISS WG can do this
work, so we will likely have to spin this off into a separate
document and reference it normatively in this document.
Section 13 Appendix B.
I think this should be removed to reduce the size of the document.
I am sympathetic to reducing the size.
Regards
Andy
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
