Subject: [BLISS] Expert Review requests on Shared Line Appearance

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 19:09:12 -0500

This is my expert review on draft-ietf-bliss-shared-appearances-02.

Overall, document is in good shape and has no major issue. It would benefit
from removing a lot of the "historical" or "discussion" material that is
not relevant anymore.

Also, I make some recommendation on how to make the Call flow examples clearer.

This review also highlights the need for up-issuing draft-alexeitsev-bliss-alert-infor-urns
(which is also needed by external standards bodies).

---------------------

Section 1:

4th paragraph.
NIT: incomplete sentence "...what gives this feature its.".
NIT: s/lamp that can change color or blink/e.g.. a lamp that can change color or blink, or
an screen icon

Section 4.2:

p. 9, 2nd full paragraph: s/not discussed in this draft but instead is left as a 
research project for future standardization/outside the scope of this draft

p. 10, bullet 5: Reword as follows:
   5.  For outgoing calls, the operation depends on the implementation.
       If line seizing is supported, the UA publishes this information and
       waits for a 200 OK before sending the INVITE.
(In other words, some implentations may allow for the user to "select" the appearance
by pressing the button, but not seize the line. For that same reason, I'm changing "select"
to "seize" in a few places in the document).

Section 5.3:

p. 13, bullet 1: Reword as follows (this is same as previous point):

   1.  When the user selects a particular appearance number for an outgoing 
       and wishes to seize the apperance and appearing "off-hook" (if the UA's
       user interface uses this methaphor).

2nd paragraph after numbered items:  s/UA selects/UA seizes

This section needs to describe that either a PUBLISH model or a SUBSCRIBE model can 
be used for the state/appearance information to be sent to the Appearance Agent.
Currently, it appears written for the PUBLISH model only. The SUBSCRIBE model, as 
illustrated in section 10.13, is very useful for cases where the Appearance Agent
is a stand-alone UA that does not share state/appearance information with the
Proxy/B2BUA. This section also needs to describe that when the SUBSCRIBE model is used,
the NOTIFY message is sent to "seize" a line (there is no need for a PUBLISH in this case).
(I'm assuming I'm right: let's discuss if not).

Section 8:

Remove Editor's note.

Section 9:

Delete first paragraph.

Clarify the UA also REGISTERs to the AOR. Discuss the security implications, i.e.,
you either use the same shared username/password, or you use a different username/password
for HTTP digest, per user. Perhaps the security considerations can be described in section 15.

Section 10:

General:

The call flows are confusing because Alice is both the end user AOR, as well as the
shared apperance AOR. This makes it very difficult to follow the call flows.

I would like all the call flows to use Alice and Bob as the Endpoint, and the shared
AOR to be, say, [email-masked] (or something similar). See below for details.

Section 10.1:

p. 22, 2nd paragraph: delete "or Appearance Agent" at end of paragraph.

Figure 1 and Call Flow: I would like to also see Bob's registration, to
illustrate the idea that Alice and Bob share the same AOR for both 
registration and subscription.

Something like this:

   Registrar     Appearance Agent          Alice           Bob
   |                    |                    |              |
   |                    |                    |              |
   |<--------------------------- REGISTER F1<|              |
   |                    |                    |              |
   |>F2 200 OK ----------------------------->|              |
   |                    |                    |              |
   |                    |<----- SUBSCRIBE F3<|              |
   |                    |                    |              |
   |                    |>F4 202 Accepted -->|              |
   |                    |                    |              |
   |                    |>F5 NOTIFY -------->|              |
   |                    |                    |              |
   |                    |<-------- 200 OK F6<|              |
   |                    |                    |              |
   |<--------------------------- REGISTER F7---------------<|
   |                    |                    |              |
   |>F8 200 OK -------------------------------------------->|
   |                    |                    |              |
   |                    |<----- SUBSCRIBE F9---------------<|
   |                    |                    |              |
   |                    |>---------F10 202 Accepted ------->|
   |                    |                    |              |
   |                    |>--------F11 NOTIFY -------------->|
   |                    |                    |              |
   |                    |<-------- 200 OK F12--------------<|

The, in the call flows, all the To headers for REGISTER 
and SUBSCRIBE are <sip:[email-masked]> instead of 
<sip:[email-masked]>.

I REALLY think this will make the spec much more readable.

Question: Why is "202" used for responding to SUBSCRIBE instead of "200"? If
202 is used, I think it deserves an explanation in the document.

Section 10.2

Again, all the AOR in "To" headers should be <sip:[email-masked]>
(e.g., F7 & F8). This will help reader's understanding.

Alert-Info in F7 should not use a <file://ring.pcm> example. 
Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns.
For example:
	Alert-Info: <urn:alert:tone>;alert=normal;appearances=1

Section 10.3

In first paragraph, s/selecting/seizing.

It would be useful to show the content of the NOTIFY messages going to Alice
(e.g., F4).

I'm a bit confused by this example. It shows Bob making a call NOT using an 
appearance (i.e., From: Bob instead of From: sharedline). And then both Alice
and Bob are notified of Bob's state instead of the sharedline? Why is that
a shared appearance scenario???

Section 10.4

Title: s/Pre-Selection/Seizing

Again, use sip:[email-masked] when appropriate. 
It would be nice to see the content of message 7.

Section 10.5

Again, use sip:[email-masked] when appropriate. 
It would be nice to see the content of message 7.

Section 10.7

Are messages F32-F35 necessary when line seizing is NOT used?
I think the answer is "no, they would not be used if there is no
line seizing". If so, I'd like to see a note explaining it.

Section 10.9

Are messages F32-F33 necessary when line seizing is NOT used?
I think the answer is "no, they would not be used if there is no
line seizing". If so, I'd like to see a note explaining it.

Section 10.10

Are messages F22-F23 necessary when line seizing is NOT used?
I think the answer is "no, they would not be used if there is no
line seizing". If so, I'd like to see a note explaining it.

Section 10.13

If the Appearance Agent subscribes to Bob's dialog-event package (as
in this example), is the expectation that Bob would never really use 
PUBLISH, and rather, would always use NOTIFY? I am assuming that the
answer is yes.

I am also assuming that it would even be the case for the line
seizing mechanism. Is this correct?

If this is the case, it would be useful to section 10 (before the 
individual call flows) that all the sections expect 1.13 use a model
where the Appearance agent does NOT use a subscription model, but a 
publish model instead. And then add a note that if a subscription model
was used instead, there would be NOTIFYs instead of PUBLISHes, as per 
section 10.13.

Section 11.1

First line: delete "also".

Section 12 Appendix A

This whole section should not be an Appendix and should be moved to the core 
document; it seems this section is necessary for REQ-9.

Alert-Info should not use a <file://ring.pcm> example. 
Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns.
For example:
	Alert-Info: <urn:alert:tone>;alert=normal;appearances=1

(I think that "tone" one is the default, so we can get rid of the OPEN issue.
Need to add draft-alexeitsev-bliss-alert-infor-urns to References. Also need
to up-issue that draft and move it forward).

Section 13: Appendix B

I think it is time to remove this whole Appendix B. This whole section was useful
reference when we were discussing various options, but now, it is totally out of
place since the choices have been made.

Section 15: Security Considerations

See comment on section 9.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 26 Jun 2009 15:41:45 +0100

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. It is the glare and recover scenarios that make this
feature so hard to implement and the draft says very little about
failure scenarios.

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.

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.

4th Para.
"...gives this feature its" - Should this be "..its name" ?

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.

Section 3.2.

Replace "SIP Telephony devices" with "SIP UA's" for consistency with
other sections.

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.

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".

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.

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.

Bullet 7. What does the UA publish in this scenario?

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.

Section 5.2.4

Replace "convey" with "to convey".

Section 5.3.

1st Para. "defined in this draft". Please add a reference to the section
that defines this.

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.

3rd Para. "or returns a 482 Loop Detected" why is this singled out is it
just one of many possible failure cases.

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.

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.

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.

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.

Section 10.1. 

I think the REGISTER from bob needs to be shown.

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 ?.

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). 

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.

Section 10.9. 

It is not explained how Bob indicates in the PUBLISH that he does not
want an appearance number assigned.

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".

Section 12 Appendix A. 

I think this should become part of the main specification and included
in the normative section.

Section 13 Appendix B.

I think this should be removed to reduce the size of the document.

Regards
Andy

---

From: Alan Johnston <[email-masked]>
Date: Tue, 30 Jun 2009 16:27:00 -0500

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:
> 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

Yes, we need to include more failure and race conditions in the call 
flows.  Your INVITE Replaces suggestion will be included - other 
suggestions?

> 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.

> parameters....". Can we now remove the discussion on different

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.

> "...gives this feature its" - Should this be "..its name" ?

Yes.

> the different identities is not part of this feature.

Agreed.

> Replace "SIP Telephony devices" with "SIP UA's" for consistency with

Agreed.

> for consistency with section 3.3.

Yes.

> I don't think it is a requirement that the UA's "learn about each

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.

> 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.

> incoming call until it receives this leading to all kind of race and

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.

> Appearance Agent" is incorrect because it is actually a publish which is

You are correct.

> Replace "convey" with "to convey".

Right.

> 1st Para. "defined in this draft". Please add a reference to the section

I will reference Section 11.1.

> subscribe" should replace the statement about regular intervals with a

How about:

Upon initialization, the UA SHOULD subscribe to the dialog event package 
of the AOR and refresh the subscription per RFC 3265. 

> 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.

> 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.

> 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.

> considerations that may be different depending on their particular type

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?

> 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.

> I think the REGISTER from bob needs to be shown.

OK. 

> is one glare condition that I worry about what would happen if all other

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.

> 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.

> introduces some glare conditions that we need to explain how to get out

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.

> 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 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.

> 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.

> I think this should be removed to reduce the size of the document.

I am sympathetic to reducing the size.