Subject: [BLISS] Comments on draft-ietf-bliss-shared-appearances-04 by implementor

From: "Dale Worley" <[email-masked]>
Date: Fri, 04 Dec 2009 17:16:23 -0500

I've been sitting on the following notes written by Carolyn Beeton.  She
has the distinction of having implemented a Shared Appearance Agent
(draft-anil-03, IIRC), so I think that her comments in regard to the
machinery are particularly relevant.

Dale

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

>From Carolyn Beeton:

    Overall discussion of appearance number and handling of multiple calls

I think the notion that an appearance number can be known to map to a
known physical button on a UA breaks down pretty quickly (e.g. scenarios
in section 10.3, 10.9, 10.12, 10.15).  So I think we should give up on
that one right away, and instead recommend even more strongly than the
current draft does that "the appearance number is readily apparent to
the user" (which is currently mentioned in the Intro).

Also, I think that trying to hold too firmly to the old key system
model is a mistake.  In the old system, if one set had seized the line,
no-one else could.  That is not the case in SIP, and I think that to,
for example, prevent a call from ringing at a set with one button for
the shared AOR because some other set is currently on a call, is a
huge mistake.  (This scenario is described in the examples at the end
of section 7.1.4)

And I think that expecting users to be able to figure out which call to
pick up or join is unreasonable without a lot of help from the UA, and
displaying call information (e.g. From user) is not sufficient.  If you
think of a help desk application, and Alice wants Bob to pick up a call
she has placed on hold, she needs to be able to tell him which call.
She shouldn't have to figure out which appearance number her button
happens to map to, and hope that he can figure it out on his set too.
"appearance 2" does not map to a physical button labelled "line 2".
On one set it might be physically in a different place from line 2 on
another set (e.g.

     x x   vs x                    
     x x      x   

- is line two the second one in the first row or the first one in the
second row?)  And she shouldn't have to announce the calling user's name
or number, if a unique one is even available.  Therefore it seems to me
to be a requirement that the UAs mark each appearance instance clearly,
by number.

Note that since I recommend exposing the appearance number to the user, I
also recommend starting at "1", not "0" - I don't think this is explicitly
called out anywhere in this spec, though most places seem to assume
"0" except maybe in section 10.2 which seems to show "1" for a first
incoming call.

All of this is very important in a Call Group scenario where more than
one call is likely to be active or on hold at the same time.  You don't
want to guess when you're taking a call off hold - is this the president
or my wife?

Abstract:
    - missing something like "This feature allows several sets to share a
      common AOR, and pick up or join calls within the group." i.e. what does
      the feature DO.

Introduction    
    - para 4: typo "typically each appearance or an AOR" ==> "of"  
    - para 4: recommend splitting the paragraph before "In addition..."
    - "appearance number": its purpose is to identify active calls to
      facilitate sharing between users (e.g. passing a call from one
      user to another).  If a telephone has enough buttons/lamps, calls
      could be presented on the nth button.  If not, it may still be
      desirable to present the call state, but the appearance number
      should be displayed so that users know which call, for example,
      is on hold on which key.

3.  Usage Scenarios    
    - "The differences relate to the user interface considerations of
    the device." ???

3.2 Call Group
    - it said above that it would not use the term "line appearance".  
    - "share the line appearances of each other" - these phones are not
      sharing appearances "of each other": they are all sharing the
      shared AOR.
    - "A shout"... sounds very unprofessional. 
    - "Another phone can request to be added, joined, or bridged to
      an existing appearance": here "appearance" really means a call.
      Are "added, joined, or bridged" three words for the same thing or
      three different things"?
    - What happens in this model if a phone selects a busy line?

4.1.  Requirements 

    - REQ-3 worded quite differently from the others "Calls
      can be joined"...  maybe "A UA must be able to join (bridge or
      conference) or pick up an existing call"
    - REQ-5 what about large numbers of shared AORs?
    - REQ-7 typo "learn the appearance status of the the group" -
      delete second 'the'
	     -  I think it means "the status of all appearances of the group 
            (shared AOR)" 
    - REQ-9.  Really? the importance of the appearance number is that users
      can tell each other which call to join or pick up.  Do they need to be
      able to tell each other which call they are answering? (maybe)
    - REQ-12.  Why not? (why not allow UAs outside the group to select
      or manipulate app numbers).  I'm thinking there might be some app
      which wants to call "line 2".  Also, don't we want to require that
      NOTHING (including one of our UAs) manipulate the appearance number
      once it's set?
    - REQ-13 - how is this different from any normal SIP call on hold etc?    
    - REQ-14 - this point isn't really developed anywhere else in the spec
    - REQ-16: I don't understand "ringdown".  If appearance number
      corresponds to a physical button, then how can this work?  What if
      two users press the same button at the same time?

4.2.  Implementation

    4: "UAs receive the appearance number to use in rendering the
       incoming call in a NOTIFY from the Appearance Agent and in the
       INVITE itself."  Why in two places?  This increases the complexity.
       Or is it in the NOTIFY just because all NOTIFYs with dialog state
       changes will include it?  In which case, why mention it specially?

    6: "if the user does not select an appearance or does not care" - why
       allow this?  Why not require PUBLISH with appearance number
       before seize?  If the UA can "learn" appearance number as the
       call progresses, why can't it "learn" it for incoming calls also?
       Then we wouldn't need to INVITE to include Alert-Info, which
       simplifies all implementations as it removes a big tie between
       the Proxy and the AA (all that is left is status updates).

5.2.3 <joined-dialog>

    - "Only the UA which is performing the actual media mixing
       should include this element in notifications to the Appearance
       Agent."
    - what notifications?  default impl does not have notifications from
      UA to AA? (should it read publications?)

5.3 UA

    - OPEN ISSUE #2 (pg 11): "Replaces and Join support is a SHOULD".
      Without these, we just have another BLF implementation... I think
      Replaces at least should be a MUST.

    - point 2. on pg 12: UA must PUBLISH when "the user has requested
      that an appearance number not be used for an outgoing call" -
      I think this would also be used for Music on Hold calls (we don't
      want them rendered at other sets!), but in this case it wouldn't
      be requested by the user...

    - para at top of pg 13: "This publication SHOULD be refreshed
      during the early dialog state... one it has transitioned to the
      confirmed state, no publication refreshes are necessary"  Does
      this conform to the PUBLISH spec?  The shorter refresh during
      early is forced by the OK response to the PUBLISH, but how is a
      longer refresh once confirmed communicated?  Also, why are we not
      worried about sets dying while they are on a call?

    - para 2 on pg 13: "A UA SHOULD render the appearance number to
      the user or display appearance status information to the user in
      a way that preserves the appearance order." I think this should
      be a MUST.

    - para 3 on pg 13: "A UA that does not need to select a particular
      appearance number (or doesn't care) would just send an INVITE as normal"
      (i.e. without PUBLISHing first)
      - and the AA will assign one.  But I don't see why we allow this.  It
        muddies the appearance number waters even more.  How will the user be
        able to tell someone else how to pick this call up?

    - para 4 on pg 13:  "If the Appearance Agent policy does not allow
      calls without an assigned appearance number, a 409 Conflict response
      will be received, and the UA will republish either selecting/seizing
      an appearance number or without one, in which case the Appearance
      Agent will assign one."  
      - so second PUBLISH with same info is handled differently... is this
        good?  AA must remember previous requests... 
      - wouldn't it be better to have an explicit "don't care" value?
      - why would AA not allow calls w/o assigned appearance number?

    - para 5 on pg 13: "When an INVITE is generated to attempt to
      bridge or take a call... the appearance number of the joined or
      replaced call SHOULD be used".  Really?  i.e. in 10.7 (Appearance
      Pickup), the INVITE from Alice to the Proxy at F38 should have
      Alert-Info header? I don't think so...

 5.4 Appearance Agent

    - para 5: "An Appearance Agent SHOULD assign an appearance number
      to an outgoing INVITE if a PUBLISH has not been received
      selecting/seizing a particular appearance number."  
      - but we won't put Alert-Info headers in outgoing INVITEs?  does it
      mean dialog here (i.e. "to the dialog for an outgoing call")?
      - why is this a SHOULD?  if it doesn't assign an appearance number,
        should it then do what is described in the 2nd para on pg 15?

    - para 6: "Note that if the appearance group has non-shared
      appearance UAs, the Appearance Agent will still allocate appearance
      numbers for INVITEs sent by those UAs."
      - why? if I press a not-shared line key for the group AOR, and
        place an outgoing call there, why should it be assigned an
        appearance number, so that the next INCOMING call would ring on
        app 2 of the shared AOR keys?
      - is the AA supposed to send NOTIFYs telling group members that this
        appearance number is being used? even though I didn't press a shared
        line key?

    - para 1 on pg 15: "A 409 Conflict response is returned if the
      chosen appearance number is invalid, and an immediate NOTIFY should
      be sent to the UA containing full dialog event state."
      - why send a NOTIFY as well?  409 is a legit error if two users
      press the line key at the same time... one will get 409, and its
      UA can resend with another appearance number... no need to send
      full NOTIFY... (NOTIFY will happen anyway because of the first
      user's seize; no special logic should be required)

    - para 2 on pg 15: Can you give some examples of why an AA might
      have a policy of not allowing PUBLISH without an appearance number?
      The most common use case I have encountered would be a Music
      On Hold call, which should not be shared with other members of
      the group.  This spec also mentions consultation calls (I'm not
      so sure about that).  Why would they be refused?

    - para 5 on pg 15: "If an INVITE is sent and no appearance number
      is available, the proxy MAY reject the INVITE with a 403 Forbidden
      response code."
      - INVITE sent by whom and to whom?  It sounds like it means an INVITE
        incoming to a set (i.e. "an INVITE is received and...").  
      - "No appearance number is available"... what is the limit? INTMAX?

7. User Interface Considerations
    
    7.1.1 Single Appearance UAs
    - regular SIP mechanisms for rejecting a second call will not kick in
      because the set is not really "busy"
    - these sets are not really suitable for shared lines... for example, they
      could not place a call if anyone else in the group was busy
        
    7.1.2 Dual Appearance UAs
    - so, and?  do we expect them to reject all but "0" and "1"? or just "0"?

    7.1.4 Shared Appearance UAs with Variable Appearance Number
    - even with the fanciest set, it will still be necessary for Joe to shout
      to his colleague, "pick up the call on line 2", and he needs to know
      what "line" it is (even though it isn't a line at all...)
    - "Thought should also be given to how an appearance number that has no 
      call associated with it should be rendered..." ?huh? you mean one that
      is reserved for some other set?  why render it at all until there's a
      call?

    7.1.4 2nd para (which shouldn't really be part of 7.1.4)
    - point 4: typo "Multiple appearnce UAs should continue " ==> appearance
    - UAs should strongly consider displaying the appearance number
      directly beside the lamp, to facilitate communication (e.g. pick
      up line 2)

8 Interop with non-Shared Appearance UAs

    - "It is desirable to allow a basic UA that does not directly support
       shared appearance to be part of a shared appearance group."
       - is it?  they won't be able to pick up calls on hold or join calls.
       Calls they make will be visible to others in the group (if implemented
       the way described here), but they won't be able to tell anyone WHICH
       call...
    - We can't prevent UAs which don't support shared appearances from
      registering to the group AOR
    - This part is "desirable", not required - if not implemented, then
      non-shared registrations to shared AORs will not consume appearances and
      will not function as shared appearances - I think this model is fine too

8.1 Appearance Assignment
    - it's not clear to me why a UA that is registered to the group AOR
      but is not shared should be using appearances at all.  Is the intent
      that it could still put calls on hold, which others could then
      pick up?  But that user could not tell the others which call to
      pick up...  and especially if the non-shared UA does not support
      Join or Replaces, then there was really no point in consuming
      an appearance (and perhaps, according to examples in the spec,
      preventing another set with only one appearance from alerting for
      an incoming call at all!)

8.3 UAs Supporting Dialog Events but Not Shared Appearance
    - presumably the AA will SUBSCRIBE for dialog events from these sets?
      (that being the point of the section) - which it does not normally do
    - "This type of UA will be detected by the Appearance Agent by the
       absence of the 'shared' event parameter in SUBSCRIBE or PUBLISH
       messages."
       - the UA won't send SUBSCRIBE ever (since it doesn't support
       this spec).  So how will the AA detect the absence of the
       'shared' event?
       - I think this will need to be provisioned (and so should be mentioned
         in 9. Provisioning Considerations)

10.1 flow for Registration and Subscription
    - Bob REGISTERS with contact bob@ua2; Alice with alice@ua1; but in
      practice the part before the @ might be the group AOR?  What if a UA
      registers to two shared AORs?
    - subscription flow is triggered by UAs SUBSCRIBEing to "dialog;shared" events
      (AA does nothing on startup)
    - F3 to F6 (pg 22): delete one of the "also"s (probably the second one)
    - CSeq numbers are awfully high!
    - F4: Allow-Events is just "dialog"? not "dialog;shared"?

10.2 Appearance Selection/Seizure for Incoming Call
    - para 2: "if Carol answers both Alice and Bob and keeps both dialogs
      active, then the Appearance Agent will need to resolve the situation
      by moving either Alice or Bob's dialog to a different appearance."
      ===> which means that the whole appearance number thing is mucked up,
      unless you require the UA to SHOW it
    - is "appearance" going to start at 1?  should this be mentioned somewhere?
    - what is the point of the NOTIFYs at F2 and F4? since all the sets are
      going to be ringing, and the INVITE will have the appearance number in
      it?  Are UAs really supposed to wait for a NOTIFY before they present
      the call? 
    - F4 and all dialog;shared events in the doc: missing the "sa:"
      prefix on the end tag (e.g. "<sa:appearance>1</appearance>" should
      read "<sa:appearance>1</sa:appearance>")
    - F4: the AA creates a unique dialog id
    - F21, 23: NOTIFYs are sent to all members of the group (everyone
      SUBSCRIBEd to the group AOR)

10.3 Outgoing Call without Appearance Pre-Selection
    - it's pretty hard to map this scenario onto one where sets have buttons
      which are called "line 1" or "line 2".  Doesn't Bob have to pick one?
      And if he doesn't, how do we tell him what appearance number he got, so
      that he can "shout or IM" to someone else to tell them to pick up the
      call after he holds it? (or to join the call)
    - F4: appearance is 0 here.  Are they going to start with 1 or 0? or does
      0 mean something special?
    - F10, F12: what are these?  the state in F4 is "trying"; would these be
      "early"?  Do we need to know that the far end is ringing?  Instead of
      (or maybe as well as) F6, one at least of these should be spelled out.
    - F18, 20: these are "confirmed".

10.4 Outgoing Call with Appearance Pre-Selection
    - note that all subscribers receive the NOTIFY marking the appearance as
      "seized" (F3, F5).  This could be spelled out in the "F1 to F4"
      discussion by saying 
      "The Appearance Agent notifies Alice (and all other appearances 
      *, including Bob*) of the same event..."
    - probably should NOT say "by forwarding the NOTIFY payload provided by
      Bob".  For one thing, it wasn't NOTIFY content - it was PUBLISH content.
      For another, it isn't being forwarded, it is being sent as a partial
      update to all subscribers.
    - typo "loose the appearance" ==> "lose the appearance"
    - F2: Allow-Events is just "dialog"?
    - if the AA changes the dialog id, this would presumably show up in F3/F5.
      Would Bob be expected to use it in F10?

10.5 Outgoing Call without using an Appearance Number
    - example use case: music on hold call?
    - what's the use case for refusing such a request?  After all, we allow
      outgoing calls that didn't do this PUBLISH step at all...
    - isn't the point of not using an appearance number that the other sets
      won't see it?  so no F3, F5, F14, F16, etc... 

10.6 Appearance Release

    - "Bob publishes the termination of the dialog and the Appearance
    Agent de-allocates the appearance number used." but this is not shown in
    the callflow.  Bob does not need to publish the termination of the dialog,
    because the AA is aware of it from the Proxy. (PUBLISH on termination is
    not listed in section 5.3 where it describes when UAs must PUBLISH)

10.7 Appearance Pickup
    - what if Alice doesn't PUBLISH?  regular SIP rules must handle the INVITE
      w REPLACES contention.  F42/F44 will still happen...  What value does
      the PUBLISH add?  is the Proxy supposed to reject the INVITE?

10.8 Calls between UAs within the Group
    - what is this trying to show?
    - it isn't clear to me whether Bob is calling Alice or [email-masked]
    - it isn't clear to me whether Bob is calling "on" the shared line (from
      Bob or from [email-masked])
    - if so, why isn't the regular PUBLISH-to-seize stuff happening?
    - is the NOTIFY at F2/F4 to show that app=0 is in early state for Bob's
      outgoing call? or that app=1 is in early state for the incoming call?
    - why is only one NOTIFY frame called out in detail?  and it isn't F16
      (which is an ACK). don't know which one it is...  It shows
      <state>connected</state> - I thought it would be "confirmed" not
      "connected"

10.9 Consultation Hold with Appearances
    - how is this going to work in practice?  If Bob only has one key for the
      shared line, how can he call Alice on the shared line if Carol is on
      hold? this describes how the UA might do it, but I don't see how a user
      would do it...
    - "Note that if Carol hangs up while Bob is consulting with Alice, Bob
       can decide if he wants to reuse the appearance number used with Carol
       for the call with Alice." -- how the heck would you model that for
       a user?

10.10 Joining or Bridging an Appearance
    - what is the difference between the NOTIFYs at F27/29 and F40/42?  trying
      vs confirmed? is the one at F27/29 really necessary?
       
10.11 Appearance Allocation - Loss of Appearance
    - typo "frees up the appearance using NOTIFYs R24 and F26" should be F26 -
      actually, should be F14 and F16!
    - what is the line between Proxy and AA showing after Appearance selection
      times out?  Isn't it the AA's PUBLISH server which will detect the
      timeout?  Why is the Proxy involved?
    - "After retransmitting the NOTIFY F26 [should be F16] to Bob, the
      subscription is terminated" - does "retransmit" mean "transmit"
      or are there two NOTIFYs? (I expect not...) Does the NOTIFY have
      subscription-state="terminated"? (not sure if this is even legal if
      the other end didn't send SUBSCRIBE with Expires=0) Shouldn't the
      subscription be terminated when the PUBLISH receives a fatal error
      (i.e.  timeout), and is there any point in sending a NOTIFY then?

10.12 Appearance Selection Contention
    - this is a fine example but also shows why expecting a hard mapping
      between appearance number and physical button on the set is
      unsupportable (i.e. Alice did not press the 3rd button for the
      appearance, she pressed the 2nd one...).  The UA must be required
      to display the appearance number somewhere.

10.13 Appearance Agent Subscription to UAs
    - maybe it's just because I'm used to the anil draft, but this does not
      make clear whether the AA SUBSCRIBEs to "dialog" or "dialog;shared".  I
      think it is just "dialog", i.e. the events will not contain any
      appearance number info.  But since F5 and F9 are not spelled out, I'm
      not sure.
    - I would think that Bob should still PUBLISH - the UA behaviour should be
      exactly the same, and the AA's subscription to it should be completely
      independent (because anyone can subscribe for "dialog" events any time,
      can't they?)
    - F5 is the AA SUBSCRIBEing for "dialog" (I think)
    - F9 is Bob SUBSCRIBEing for "dialog;shared"
    - this section should follow 10.15

10.14 Appearance Pickup Race Condition
    - ?? Bob (shared user) on call with Carol; Bob presses hold; "Alice
      attempts to pick up the call but Bob hangs up before the pickup can
      complete" - I think it means Carol hangs up (based on the flow at F38).
      Rather important distinction...
    - a UA is not required to PUBLISH when a call is released, (see 10.6)
      so why would a failed call be any different?  The Proxy knows
      that the call failed, so I would expect a dotted line after F47
      and then a NOTIFY from the AA to Bob and Alice

11 Incoming Appearance Assignment
    - this section is pretty rough
    - "For the dialog package parameter approach" - unclear.  Are two ways
      really described here?  I think one way is NOTIFY independent of the
      INVITE, and the second way is INVITE with Alert-Info (and also NOTIFY!)
      but this paragraph is not very clear
    - missing period at the end of the 2nd para
    - here it implies that "appearance=0" means the first instance - as it
      does in most places, except in section 10.2

14. Security Considerations
    - section should appear before section 12