Re: [BLISS] Comments on draft-ietf-bliss-shared-appearances-07

Dale,

Thanks for your excellent comments on the draft.  The document is much
better as a result.

I have made nearly all the changes you suggested in the
draft-ietf-bliss-shared-appearances-08 version, except the ones that
I've included some comments and discussion below.

Thanks again!

- Alan -

On Wed, Apr 13, 2011 at 2:46 PM, Worley, Dale R (Dale)
<dworley@avaya.com> wrote:
> I've finally gotten the cycles to go over draft-ietf-bliss-shared-appearances-07.  We consider this work to be seriously important for the use of SIP in the business telecom market, and want to see Shared Appearances standardized.  Unfortunately, I'm too pressed for time to have examined these items a second time, so please forgive the mistakes in my queries.
>
> Dale
> ----------------------------------------------------------------------
> section 1:
>
> This paragraph is awkward:
>
>   This document looks at how this feature can be implemented using
>   standard SIP [RFC3261] in conjunction with SIP events
>   [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for
>   exchanging status among user agents, and the SIP dialog state event
>   package [RFC4235] to exchange dialog state information to achieve the
>   same.
>
> Perhaps:
>
>   This document looks at how this feature can be implemented using
>   standard SIP [RFC3261] in conjunction with SIP events
>   [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903]
>   (carrying the SIP dialog state event package [RFC4235])
>   for exchanging status among user agents.
>
> section 1:
>
>   The appearance number relates to the
>   user interface for the telephone - typically each appearance of an
>   AOR has a visual display (lamp that can change color or blink or a
>   screen icon) and a button (used to select the appearance).
>
> Might be better as:
>
>   The appearance number relates to the
>   user interface for the telephone - typically each appearance of an
>   AOR has a visual display (lamp that can change color or blink or a
>   screen icon) and a button (used to select the appearance) - where
>   each appearance number is associated with a different dialog to/from
>   the AOR.
>
> section 1:
>
>   If a telephone has enough buttons/lamps, calls could be
>   presented on the nth button.
>
> Would be clearer as:
>
>   If a telephone has enough buttons/lamps, the appearance number could be
>   the positional sequence number of the button.
>
> section 4.1, REQ-14:
>
>   Exclusivity means that the UA
>   requesting it desires to have a private conversation with the
>   external party and other UAs must not be allowed to be joined or
>   taken.
>
> is not correctly phrased.  Correct to:
>
>   Exclusivity means that the UA
>   requesting it desires to have a private conversation with the
>   external party and other UAs must not be allowed to joined or
>   take the call.
>
> section 4.2:
>
>   While an Appearance Agent can be
>   part of a centralized server, it could also be co-resident in a
>   member User Agent who has taken on this functionality for a group.
>
> "who" should be "which".
>
> section 4.2, step 5:
>
>       For outgoing calls, the operation depends on the implementation.
>       If the user seizes a particular appearance number for the call,
>       the UA publishes the 100 Trying state dialog information without
>       an appearance number and waits for a 200 OK before sending the
>       INVITE.
>
> This appears to be incorrect.  I think the correct version is:
>
>       For outgoing calls, the operation depends on the implementation.
>       If the user seizes a particular appearance number for the call,
>       the UA publishes the >>"trying"<< state dialog information >>with
>       the<< appearance number and waits for a >>2xx<< before sending the
>       INVITE.
>
> section 4.2, step 7:
>
>       For outgoing calls, if the user does not wish to seize an
>       appearance (such as during a consultation call or if a UA is
>       fetching 'service media' such as music on hold
>       [I-D.worley-service-example]), the UA also publishes this prior
>       to sending the INVITE.
>
> "this" should be clarified (what exactly is published to indicate lack
> of interest in receiving an appearance number?)
>
> And I think that the question is not "does not wish to seize an
> appearance" but rather "does not want an appearance number assigned",
> as a UA can make a call without "seizing" (as defined in section 5),
> but will have a number assigned automatically.
>
> section 4.2, step 9:
>
>       The Appearance Agent may not have full access to the complete
>       dialog state of some or all of the UAs in the group.  If this is
>       the case, the Appearance Agent will subscribe to the dialog state
>       of individual UAs in the group to obtain this information.
>       Normal notifications will be sent every time the dialog state
>       changes, including calls placed, answered, placed on and off
>       hold, and hangups.
>
> This is hard to read until you realize that "may not have full access"
> means "may not have back-door access".  A better phrasing would be:
>
>       The Appearance Agent may not have direct access to the
>       complete dialog state of some or all of the UAs in the group.
>       If this is the case, the Appearance Agent will subscribe to the
>       dialog state of individual UAs in the group to obtain this
>       information.  In any case, the Appearance Agent will send
>       normal notifications (via the subscriptions established by the
>       UAs in step 1) every time the aggregate dialog state of the AOR
>       changes, including when calls are placed, answered, placed on
>       and off hold, and hung up.
>
> section 5:
>
> Somewhere near the beginning of section 5, it seems like a description
> of the intended properties of appearance numbers is needed.  In
> particular:
>
>    Appearance numbers are non-negative integers.
>
>    When an appearance number is requested to be assigned, generally
>    the assigned number is the smallest nonnegative integer that is
>    not currently assigned as an appearance number to a dialog for
>    this AOR.
>
> This rules out, e.g., having the appearance numbers be a dialog
> sequence number that increments throughout the history of the AOR.
>
> BTW, is the latest decision that appearance numbers start with 0,
> rather than 1?

No, the decision was that appearance numbers start at 1.  I think I
have found all the cases of appearance zero and removed them from the
document now.

>
> A word seems to be missing:
>
>   [...] initiating a dialog, in order to appear as >>if<< it was
>   already initiating a dialog.
>
> The following sentence uses "confirmed", and several later sentences
> use "confirmed by the Appearance Agent".  But there is no definition
> of this "confirming" operation:
>
>   The appearance number is confirmed prior to sending the INVITE.
>
> The import of this sentence is unclear:
>
>   This is a user interface only issue.
>
> The sentence is also awkwardly phrased, as one would probably want to
> construct "user-interface-only issue".  Less awkward would be:
>
>    This is an issue only for the user interface.
>
> or
>
>    This is only a user interface issue.
>
> But given that there are protocol actions involved, it's not clear why
> that sentence is stated, or even exactly what "this" refers to.
>
> section 5.2.1:
>
> There is a lot that is not clear in this paragraph, and also a lot of
> stealthy description of protocol actions hidden in a paragraph that is
> ostensibly about a data item.  In addition, it does not state that
> every <appearance> element is the child of a <dialog> element (nor
> does the schema).
>
>   The <appearance> element is used to convey the appearance number.
>   The appearance number is a positive integer.  When sent in a
>   publication in state Trying to the Appearance Agent, it is used to
>   request an appearance number.  When sent by the Appearance Agent, it
>   indicates that the appearance number is associated with a dialog.
>   The UA generating the to-tag and from-tag parameters treats them from
>   a local perspective.  In other words, if the UA sent out a request
>   within the dialog, the to-tag parameter would match the remote tag,
>   and the from-tag parameter would match the local tag.
>
> Better would be:
>
>   The <appearance> element is used to convey the appearance number of
>   the dialog described by the <dialog> element which is its parent,
>   on the UA(s) [for the AOR?] specified by the "entity" attribute.
>   The appearance
>   number is a positive integer.  When sent in a PUBLISH with parent
>   <dialog> with state attribute "trying" by a UA to the Appearance
>   Agent, the UA is requesting assignment of the given appearance
>   number to the current or future dialog with the given dialog
>   identifiers.  When an <appearance> element is sent by the
>   Appearance Agent in a NOTIFY, it indicates that the appearance
>   number has been assigned to the specified dialog.
>
>   Note that a <dialog-info> element describes the contained <dialog>s
>   "from the point of view of the UA" (named by the "entity" attribute),
>   regardless of whether the containing request is sent by the UA or
>   the Appearance Agent.  In particular, if the UA sent a request
>   within the described dialog, the "To" header URI would match the
>   <remote> <identity> value and the to-tag parameter would match the
>   remote-tag attribute.  Similarly, the "From" header URI would match
>   the <local> <identity> value and the from-tag parameter would match
>   the local-tag attribute.
>
> But this leads to the point that there is no clear, separate
> description of the fundamental protocol action, viz., the UA sends a
> PUBLISH to the Appearance Agent to request an appearance assignment
> and the Appearance Agent sends a NOTIFY back to the UA with the final
> assignment.

This UA behavior is described in Section 5.3.  I would prefer to leave
it there rather than move it to this section.

>
> Also, this says that the appearance number is a "positive integer"
> whereas appearance numbers are non-negative integers.
>
> section 5.2.2:
>
>   The <exclusive> element is a boolean used to indicate whether the UA
>   will accept Join or Replaces INVITEs for this dialog.  For example,
>   some shared appearance systems only allow call pickup when the call
>   is on hold.  In this case, the <exclusive> element should be used to
>   explicitly indicate this, rather than implicitly by the hold state.
>
> could be clarified as:
>
>   The <exclusive> element is a boolean, which when true, indicates
>   that the UA is willing to accept an INVITE with a Join or Replaces
>   header targeted to the dialog described by the <dialog> element
>   that is the parent of the <exclusive> element.  For example, some
>   shared appearance systems only allow call pickup when the call is
>   on hold.  In this case, the <exclusive> element should be set to
>   "true" when the call is held and "false" when the call is not held,
>   rather than having the "exclusive" value implied by the hold state.
>
> BTW, is there a default value for "exclusive"?  The schema doesn't
> show one.

I clarified that it is false, the same as if it is not present.  I
also described what it means if a <joined-dialog> or <replaced-dialog>
element is not present.

>
> Expanding this sentence would help:
>
>   It is important to note that this element is a hint, and that the
>   UA must take additional steps to ensure that INVITE with Join or
>   Replaces is not applied to the dialog.
>
> section 5.2.3:
>
>   Only the UA which is performing the actual media mixing
>   should include this element in publications to the Appearance Agent.
>
> This is not exactly correct, as the UA may be doing 3pcc to a mixing
> agent.  What we want is:
>
>   Only the UA which is the common endpoint of the mixed dialogs (and
>   thus controlling the mixing operation) should include this element
>   in publications to the Appearance Agent.
>
> section 5.3:
>
> Should probably add:
>
>   User Agents which implement call pickup, joining and bridging MUST
>   support sending >>and receiving<<< an INVITE with Replaces
>   [RFC3891] or Join [RFC3911].
>
> and omit the last sentence of the paragraph.  Or else, the
> requirements are more complex than I understand them to be.

No, I believe the text is correct.  There are three cases that need to
be supported by the spec.
1. A fully functioned UA that sends and receives INVITE
Joins/Replaces.  It has buttons for "pickup" and "bridge".
2. A UA that only received INVITE Join and Replaces.  It does not have
"pickup" or "bridge" buttons, but these features will work if another
UA initiates them.
3. A UA that only monitors the appearance group, and never receives an
INVITEs (e.g. never registers against the AOR).  This UA will never
"ring", but does show the status of appearances, and has "pickup" and
"bridge" buttons that will work.

It is this #3 case that support for receiving INVITE Replaces and Join
is not needed.

>
> These two sections probably ought to be combined to clarify the
> operations that are intended:
>
>   A UA MUST send dialog package PUBLISH requests in the following
>   situations:
>
>   [...]
>
>   In all these cases, the INVITE SHOULD NOT be sent until the 200 OK
>   response to the PUBLISH has been received, except for an emergency
>   call, when a UA MUST never wait for a confirmed seizure before
>   sending an INVITE.  Instead, the emergency call MUST proceed
>   regardless of the status of PUBLISH transaction.
>
> viz.:
>
>   In the following cases, before sending the INVITE, a UA MUST send a
>   dialog package PUBLISH request to the Appearance Agent containing
>   the forthcoming dialog state changes and receive the 2xx response:
>
>   [...]
>
>   An exception is an emergency call, when a UA MUST never wait for a
>   confirmed seizure before sending an INVITE.  Instead, the emergency
>   call MUST proceed without waiting for the PUBLISH transaction.
>
> section 5.3, item 1:
>
> I think "i.e." here should be "e.g.".
>
> section 5.3:
>
> It's not clear why this sentence using receipt of the 100 as a
> criterion, as the receipt of the 100 does not provide any additional
> dialog information:
>
>   If no dialog identification information is present in
>   the initial PUBLISH, the UA MUST PUBLISH again after receiving the
>   100 Trying response.
>
> I believe that what is wanted is "[...] the UA MUST publish again
> promptly after the Call-Id and from-tag are established."
>
>   This publication state is refreshed as described in [RFC3903] during
>   the early dialog state or the Appearance Agent may reassign the
>
> I think you want "This publication [published?] state MUST be
> refreshed as described in [RFC3903] or the Appearance Agent may
> reassign [...]"
>
> It's not clear why PUBLISH refreshes are not required after transition
> to the confirmed state, as RFC 3903 states that published data are
> soft-state with specified expiration time.  If this I-D intends to
> handle expiration differently from RFC 3903, this needs to be
> specified clearly.

I added some text to explain this.

>
> Shouldn't the following SHOULD be a MUST?
>
>   A user may select an appearance number but then abandon placing a
>   call (go back on hook).  In this case, the UA SHOULD free up the
>   appearance number by removing the event state with a PUBLISH as
>   described in [RFC3903].
>
> section 5.3.1:
>
> The first sentence would be clearer as:
>
>   There are cases where two separate dialogs at a UA are not mixed
>   but share the same 'context'.
>
> The last sentence of the paragraph would be clearer as:
>
>   These cases are best handled by not assigning an appearance number
>   to a newly-created dialog when it shares a context with a
>   pre-existing dialog.  (But if the pre-existing dialog is
>   terminated, its appearance number should be reassigned to the
>   newly-created dialog.)
>
> This sentence could be clarified:
>
>   If
>   the Appearance Agent policy does not allow calls without an assigned
>   appearance number, a 400 response with the reason phrase "Appearance
>   Number Conflict" will be received, and the UA will republish either
>   selecting/seizing an appearance number or send the INVITE without
>   publishing, in which case the Appearance Agent will assign one.
>
> as:
>
>   If the Appearance Agent policy does not allow calls without an
>   assigned appearance number, a the UA will receive a 400 response
>   with the reason phrase "Appearance Number Conflict", and the UA
>   must either republish selecting/seizing an appearance number or
>   send the INVITE without publishing, in which case the Appearance
>   Agent will assign an appearance number.
>
> See also comments below about using 400 as a response code.
>
> section 5.3.2:
>
> This explanation probably needs to be fleshed out.  I can't visualize
> what is expected to be published:
>
>   When an INVITE is generated to attempt to bridge or take a call (i.e.
>   contains Join or Replaces with a dialog identifier of another dialog
>   in the shared appearance group), the appearance number of the joined
>   or replaced call SHOULD be published.  The publication MUST contain
>   the appearance number of the dialog to be joined or replaced and the
>   dialog identifier in the 'joined-dialog' or 'replaced-dialog'
>   elements.
>
> section 5.3.3:
>
> This paragraph contains a vicious passive construction, which
> describes what is to be done but does not describe what is to do it:
>
>   If Alice is the transferee, the triggered INVITE from the REFER
>   should be treated as a consultation call, and should not use a new
>   appearance number.  When the transfer completes, the appearance
>   number associated with the dialog with Carol is moved to the dialog
>   associated with David.
>
> The last sentence should be "When the transfer completes, Alice's UA
> publishes new state associating the appearance number of the former
> dialog with Carol with the new dialog with David."
>
> This paragraph isn't clear whether the incoming INVITE-with-Replaces
> has no appearance number associated, or whether the AA should tag it
> with the same appearance number.  It seems from the rest of the I-D,
> that the new dialog should have no appearance number until the dialog
> that is replaced is terminated, and then Alice's UA should assign the
> old appearance number to the new dialog.  But that is not stated
> clearly.
>
>   If Alice is the target, the incoming INVITE should not have a new
>   appearance number assigned.  Instead, it should reuse the appearance
>   number associated with the dialog being replaced.  If the Appearance
>   Agent does assign a different appearance number, when the transfer
>   completes, Alice should release that appearance number and use the
>   original appearance number associated with the dialog with Carol.
>
> section 5.4:
>
> The specification requires the use of a particular reason phrase,
> "Appearance Number Conflict".  Making the reason phrase significant is
> contrary to all previous SIP usage.  Wouldn't it be better to allocate
> a specific 4xx response code?
>
> section 6:
>
> The schema gives the extension namespace as
> "urn:ietf:params:xml:ns:sa-dialog-info-info" instead of
> "urn:ietf:params:xml:ns:sa-dialog-info."
>
> The indenting of the XML schema is irregular.
>
> section 7:
>
>        appearance-param = "appearance" EQUAL *DIGIT
>
> is probably intended to require at least one digit, which would be:
>
>        appearance-param = "appearance" EQUAL 1*DIGIT
>
> section 8:
>
> The design of the UI is strongly affected by the expected appearance
> numbers.  My belief is that the intended design is that the appearance
> nubmers will be small non-negative integers.  (See the item regarding
> describing appearance numbers per se at the beginning of section 5.)
> But there needs to be some stated policy regarding appearance numbers
> that cannot be rendered by the UA.  Is the UA allowed to reject them?
> Section 8.1.1 appears to allow rejection, but this fact is a
> significant protocol action that should not be buried in an apparently
> non-normative section about user-interface design.

No, a UA is not allowed to reject an appearance number.  I removed the
confusing text.

>
> section 8.2:
>
> "sip+rendering=no" should be "+sip.rendering=no" in two places.
>
> section 9:
>
> Two uses of "interop", which should be "interoperation".
>
> section 12 (Security Considerations) should reference or include this text
> from 5.3, as it is a life-safety consideration:
>
>   [For an emergency call, a] UA MUST never wait for a confirmed
>   seizure before sending an INVITE.  Instead, the emergency call MUST
>   proceed regardless of the status of PUBLISH transaction.
>
> section 10:
>
> I see three different descriptions of how to determine if SA is
> available for a particuar AOR:
>
>    section 4.2, REQ-1
>
>           [A UA] attempts a dialog state subscription to the AOR.  If the
>           subscription fails, loops back to itself, or returns an error,
>           it knows there is no State Agent, and hence no Appearance Agent
>           and this feature is not implemented.
>
>    section 5.3
>
>       Upon initialization, the UA MUST subscribe to the dialog event
>       package of the AOR and refresh the subscription per the SIP Events
>       Framework.  If the SUBSCRIBE request fails, then no Appearance Agent
>       may be present and this feature is not active for this AOR.
>
>    section 10
>
>       UAs can automatically discover if this feature is active for an AOR
>       by looking for the 'shared' Event header parameter in a response to a
>       dialog package SUBSCRIBE to the AOR, so no provisioning for this is
>       needed.
>
> It would also be useful in practice if some hints were given for
> interoperation with UAs that implement previous versions of this
> work.  This probably can be limited to methods to detect which version
> a particular UA implements.

Which version?  Earlier versions of this document?  Earlier versions
of the SIPPING document?  I'd really rather not do this.  If a UA
supports certain specifications (e.g. dialog event package, Join, or
Replaces), it should be possible to figure out which pieces of the
spec will work and which won't, but detailing them doesn't seem very
useful.

>
> section 11.8:
>
> The description says that a call from one UA in a group to another UA
> in the group would only use one appearance number.  This is not
> uniform with the rest of the SA architecture and is not the behavior
> of traditional key phone systems.  Are you sure you want to present it
> this way?

Hmm.  I've seen systems that do operate this way.  It might be
possible to allow either policy in the Appearance Agent, but first
we'd need to figure out how to make this work.  For a call between two
UAs in a group, there is just one dialog between them.  It seems that
allowing this one dialog to use two appearance numbers would break a
bunch of things.  For one thing, the XML would need to allow multiple
<appearance> elements, or have the same dialog appear twice in the
XML, each time with a different dialog.  Neither seems very good.

>
> section 11.13:
>
> Another passive:
>
>   Whenever Bob's dialog state changes, a NOTIFY is sent to the
>   Appearance Agent who then notifies the other other UAs in the
>   group.
>
> should be:
>
>   Whenever Bob's dialog state changes, Bob sends a NOTIFY to the
>   Appearance Agent who then notifies the other other UAs in the
>   group.
>
> You probably want to change "who" to "which".
> ----------------------------------------------------------------------
> _______________________________________________
> BLISS mailing list
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>