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 b...@ua2; Alice with al...@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 protected]
- it isn't clear to me whether Bob is calling "on" the shared line (from
Bob or from [email protected])
- 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
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
