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

[Alan Johnston <[e-mail]>]

Dale,

Thanks for forwarding these excellent comments from Carolyn on the
draft.  My apologies in not replying sooner.

There are a couple of issues that are raised below that I will start
separate threads for discussion.

See my comments below.

- Alan -


On 12/4/09 4:16 PM, Dale Worley wrote:
> 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.

Agree - comments from implementor are always invaluable.


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

I disagree.  If we make a requirement that a UA must render the actual
appearance number, and not imply it by location, convention, or other
method, then we are basically saying this extension doesn't apply to
most telephone sets using this feature today!  We could add text to
explain more carefully and more forcefully why the UA should render the
number.  Also, I think that this extension goes about as far as we can
go in the IETF in terms of user interface.


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

I think the draft confuses two cases which we need to clearly separate.

1. A UA which understands shared appearances, but for some reason only
supports a single appearance number.

2. A UA which does not understand shared appearances.

The handling of #1 should be as section 7.1.4 says.  The handling of #2
should be as you describe above.  You have comments on this later, but
basically this appearance-unaware UA can still make and receive calls
like a normal UA sharing an AOR with other UAs.  The difference is it
will not know what appearance number any given incoming and outgoing
call is, and the *human* will not be able to help another *human* using
one the appearance aware UAs do something with this call.  The SIP part
will work just fine, assuming it supports Join and Replaces.


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

This is a UI issue.  We have a requirement that the appearance number
sequence is preserved and rendered.  How this is done is out of scope,
in my opinion.


  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.

If there is strong interest in this, we could include a non-normative
appendix or something showing example button maps and arrangements, but
I think this is overkill.  This feature must adapt to users and existing
sets and usability requirements, not the other way around.  Besides,
anything new will not use hard buttons but use soft keys, so none of
this applies.


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

If we decide to require the appearance number to the user, then starting
at 1 would make sense.  It probably makes sense anyway, unless someone
has an objection.

However, I'm still not convinced we want to do this.  I don't think this
was a requirement in the anil draft, and no one has put it forward as a
requirement until now.


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

Done.

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

I like this text so I included it.

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

The protocol and messaging wouldn't be different in all these examples -
the difference is the UI of the device.


> 
> 3.2 Call Group
>     - it said above that it would not use the term "line appearance".

Clarified that we still use this old terminology in this non-normative
section.


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

I've heard this requirement called 'shout control' ;-)


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

Same thing, different words.

>     - What happens in this model if a phone selects a busy line?

It fails.  I think some sets give 'dialtone' if the line is seized and
some other tone if it is not available.

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

Reworded.

>     - REQ-5 what about large numbers of shared AORs?


Each AOR is a different group.  This draft doesn't talk about devices
that have multiple AORs and how this should be handled.

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

The issue is that some phones need to know the appearance number in
order to alert properly.  Otherwise, the call can seem to "jump" from
one place to another which can confuse users.  This is why we use the
Alert-Info header field.


>     - REQ-12.  Why not? (why not allow UAs outside the group to select
>       or manipulate app numbers).

Security.  How is the authenticated?  Who has access?  What is the
policy?  It is much easier to say that only those who are a part of the
group may perform operations on the appearance number.


  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?

No, the appearance numbers are released, and can even potentially be
moved between calls.


>     - REQ-13 - how is this different from any normal SIP call on hold etc? 

I don't follow.  Hold does leak information - the other side knows from
signaling that you are on hold.  The other side doesn't need to know
which appearance you are using, as this could imply that other
appearances are in use.


>     - REQ-14 - this point isn't really developed anywhere else in the spec

Yes it is - the whole <exclusive> mechanism is to meet this requirement.

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

It will work for one and fail for the other.

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

It must be in the NOTIFY as it is just part of the dialog state.  It
must be in the INVITE to avoid cases where the NOTIFY might get lost and
the UA does not know which appearance to render for the call.

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


The consensus of the group was that we do not want to force a PUBLISH
before every call with this feature.  Instead, only UAs that have a UI
requirement will PUBLISH first.  Others can just place calls normally.

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

Older versions of this draft said specifically that, but others felt
that having to wait to render an INVITE until a NOTIFY is received was
bad. (Think about low bandwidth or high latency links).  Group consensus
was to make the Alert-Info a MUST.  We could revisit this, but we have
discussed this extensively in the past.

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

Good catch!  It should say 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.

Here's the text from the current version:

   User Agents which implement call pickup, joining and bridging MUST
   support sending an INVITE with Replaces [RFC3891] or Join [RFC3911].
   All User Agents supporting INVITE MUST support receiving an INVITE
   with a Replaces [RFC3891] or a Join [RFC3911] header field.

So, you must support receiving Replaces or Join, and if you support
pickup, join, and bridging, you must support sending them.

I think this meets your requirements.

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

I'm confused.  MOH happens in the middle of a call.  I don't place or
receive a MOH call, do I?

The use case for not using an appearance number is from the consultation
call feature requested by Andy Hutton - you can find discussion about in
on the list or in the minutes of previous meetings.

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

PUBLISH is used to reserve the appearance number while the call is being
setup/processed.  Once it is established, the appearance number is in
use until the call goes away.  To tie the life of the appearance number
to the publication lifetime would be bad.  If a PUBLISH fails, does my
call get dropped?  Or would my appearance be reassigned?  If the set
dies while on the call, the call will die, and the appearance number
will be released.  Mechanisms to ensure the liveness of a call are
defined elsewhere with SIP and outside the scope of this draft.


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

I agree and have made the change.  Of course, a UA that doesn't claim to
support this mechanism won't, but that's OK.


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

No, this relates to seizure (current draft terminology) - the
pre-selection of an appearance number *before* sending the INVITE.  A UA
with hard buttons will require seizure.  A UA with a more flexible
display can allow a user to place a call and then update the display
(either during trying, alerting, or connection) with the assigned
appearance number when it is known via the NOTIFY.

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

Good catch!  Here's what the text should say:

"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 send the
INVITE without publishing, in which case the Appearance Agent will
assign one."

So, either a new PUBLISH will be sent, this time with an appearance
number, or just the INVITE will get sent and an appearance number will
be assigned.



>       - wouldn't it be better to have an explicit "don't care" value?

I think this mechanism works just fine, with the clarification above.

>       - why would AA not allow calls w/o assigned appearance number?

Some implementations do it one way, others another way.  Personally, I
think it complicates the whole system to allow calls without appearance
numbers using the *same* AOR.  Why not just use a different AOR, and the
whole problem is solved?  However, others wanted this in there, so it is
here.

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

Another good catch!  Here is what it should say:

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


> 
>  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")?

It does mean to the dialog, so I changed it to say that - it doesn't
mean anything is added to the INVITE message.


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

Do we need to force an Appearance Agent to always assign an appearance
number?  Is this needed for interop?  I don't think this contradicts
anything in Section 5.4.

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

You are describing a UA that understands shared appearances, since it
has both shared and non-shared keys.  This deals with a Plain Old SIP UA
(POSU?) that only understands RFC 3261.  I changed it to:

"Note that if the appearance group has appearance-unaware UAs making
calls, the Appearance Agent will still allocate appearance numbers for
INVITEs sent by those UAs."


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

Calls by this POSU will result in NOTIFYs to anyone subscribed to the
dialog package.  If the AA allocated an appearance, it will be shown.


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

Yes, but with which appearance number?  The fact it got a 409 says that
its appearance state view is out of date. This why we refresh the state
immediately.

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

Consultation calls are the case where this PUBLISH no appearance is
used.  It requires a very specific, very complicated UI to do.  Most UAs
won't support this.  I think it is reasonable for an AA to have a policy
that says all calls made/received using the shared AOR must have an
appearance number.  Otherwise, just use a different AOR.

I deleted this last sentence in this paragraph as it is incorrect:

"In general, the dialog state will not be shared with the other UAs in
the group."


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

No, this is what it should (and now does) say:

"If an INVITE is sent by a member of the group using the shared AOR or
sent to the shared AOR and no appearance number is available, the proxy
MAY reject the INVITE with a 403 Forbidden response code."

So both cases are covered.  I think it is reasonable for an AA to fix an
arbitrary limit, say the number of buttons on the key sets in the
office, and reject INVITEs when all are in use.

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

No, this is a UA that supports and understands this mechanism, but for
some reason only supports a single appearance.  Think of this as a
policy on the UA.


>         
>     7.1.2 Dual Appearance UAs
>     - so, and?  do we expect them to reject all but "0" and "1"? or just "0"?

Now this one is clearly confusing.  I think this is actually a POSU that
can only do PSTN-style call-waiting (i.e. flash hook).  In this case,
I'd say that it can only handle two calls at a time due to its user
interface.

This section needs rewriting, but I'll wait to see if others have an
opinion on this.

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

I've given this thought, and concluded that I don't know what this means
either.  I've removed it.

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

Why not? They might support dialog package and send INVITE Join or
Replaces but not implement this specification.

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

The *human* won't be able to, but the SIP protocol pieces will still be
there and still work, right?

>     - We can't prevent UAs which don't support shared appearances from
>       registering to the group AOR

Correct, and we don't want to prevent normal SIP call control things
from happening as well.

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

This is up to the policy of the Appearance Agent.  Perhaps we should
call this out and other AA policy issues in an earlier section.


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

Here's what this should say:

"A UA that has no knowledge of appearances must will only have
appearance numbers for outgoing calls if assigned by the Appearance Agent."

If an outgoing call does not have an appearance, it won't be able to be
handled like any other call within the group by the UAs that support
this extension.

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

Good catch!  No, this is old text that we need to get rid of.  We now
assume that the AA knows dialog state, or if it doesn't it does a
SUBSCRIBE to the UAs, but this is independent of if the UA is appearance
aware or not.

>     - "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 deleted this as it doesn't matter anymore.

>        - I think this will need to be provisioned (and so should be mentioned
>          in 9. Provisioning Considerations)

No, it actually doesn't matter. This UA will just seem to the AA as a UA
that never seizes appearance numbers and never cares about the dialog
states of others, and hence doesn't subscribe.

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

Sure, but there is no semantics associated with the format of Contact
URIs - they are just used for routing.

  What if a UA
>       registers to two shared AORs?

Then it is two separate instances of this of this feature, and operate
completely independently.

>     - subscription flow is triggered by UAs SUBSCRIBEing to "dialog;shared" events
>       (AA does nothing on startup)

What subscription flow?  You are correct saying the AA does nothing on
startup except ensure it knows dialog states of its UAs.


>     - F3 to F6 (pg 22): delete one of the "also"s (probably the second one)
>     - CSeq numbers are awfully high!

It is 21 bits, which is less than 31 bits, so its OK.

>     - F4: Allow-Events is just "dialog"? not "dialog;shared"?

The ABNF for Allow-Events in RFC 3265 does not allow Event parameters.

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

It is an error condition.  I don't understand the correlation to showing
the appearance number.


>     - is "appearance" going to start at 1?  should this be mentioned somewhere?

We need to decide this.

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

No, the INVITE can be received before the NOTIFYs and processed
independently due to the Alert-Info.

I could change the order to emphasize this.

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

Already fixed.

>     - F4: the AA creates a unique dialog id

Is there a question here?

>     - F21, 23: NOTIFYs are sent to all members of the group (everyone
>       SUBSCRIBEd to the group AOR)

Yes.

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

You are correct - this requires a very specialized UI to do this.
Personally I don't think it is worth it, but others do.

>     - F4: appearance is 0 here.  Are they going to start with 1 or 0? or does
>       0 mean something special?

0 means nothing 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.

Alerting, and it will contain the To tag, allowing call control
operations to be performed.

>     - F18, 20: these are "confirmed".

Correct.

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

Good catch!  This paragraph has not been edited in a long time and was
full of mistakes.  I made the changes you suggested.  I removed the
reference to "dialog-id" - that was actually an ID inside the dialog
XML, and this was only an issue when we had UAs sending NOTIFYs to the
AA who was trying to just forward them.  Now we have an event state
compositor model, this isn't an issue anymore.

> 
> 10.5 Outgoing Call without using an Appearance Number
>     - example use case: music on hold call?

No, consultation 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...

That is different.  If the UA doesn't publish, the AA assigns an
appearance.  In this case, the UA is asking the AA not to assign an
appearance.  As a result, this call won't be able to really be part of
the shared group.  That is why the AA might refuse it.

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

No, the dialog state will still be shared - to not include this dialog
in dialog package notifications would be a major behavior change by the
ESC.  So these messages are there as shown.

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

Good catch!  Fixed.

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

See this paragraph in 5.4 that explains why Alice needs to PUBLISH
(which I edited a little to make it clearer):

"Note that this information is provided to the Appearance Agent so that
it can provide proper appearance assignment behavior.  If the INVITE
Join or Replaces was sent without publishing first, the Appearance Agent
might assign a new appearance number to this INVITE, which would be a
mistake.  With Join, the publication has the 'joined-dialog' element to
prevent the Appearance Agent from generating a 409 Conflict response due
to the reuse of an appearance number.  For Replaces, the purpose of the
'replaced-dialog' is to prevent a race condition where the BYE could
cause the appearance number to be released when it should stay with the
replacing dialog."

> 
> 10.8 Calls between UAs within the Group
>     - what is this trying to show?

In the case of an intra-group call, only one appearance number is used.
 Someone could get this wrong and think that two appearances might be used.

>     - it isn't clear to me whether Bob is calling Alice or [e-mail]

Doesn't matter - the point is that the result of the INVITE/200/ACK is
that there is a dialog up between Alice and Bob.

>     - it isn't clear to me whether Bob is calling "on" the shared line (from
>       Bob or from [e-mail])

If he calls From: Bob, then nothing in this specification applies.   It
isn't [e-mail] either.  It must be From the shared AOR,
which in this example is [e-mail]. All calls in this
document are From the shared AOR.  I put a note at the start of this
section saying this:

"Note that in these examples, all INVITEs sent by a UA in the group will
be From the shared AOR (sip:[e-mail] in this case), and all
INVITES sent to the group will have a Request-URI of the shared AOR.
Any other requests would not apply to this feature and would be handled
using normal SIP mechanisms."

>     - if so, why isn't the regular PUBLISH-to-seize stuff happening?

Bob didn't seize a particular appearance - he just took appearance=1
that was assigned by the AA.

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

It would show appearance=1 is in an early state for Bob's call.

>     - why is only one NOTIFY frame called out in detail?

I don't show all the messages in this section - way too much work!

  and it isn't F16
>       (which is an ACK). don't know which one it is... 

It is F19.  It is shown because it shows two views of the dialogs -
Alice's and Bob's, and they both reuse the same appearance number.

 It shows
>       <state>connected</state> - I thought it would be "confirmed" not
>       "connected"

Good catch!  It should say 'confirmed'.



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

It is a special user interface.  Personally, I don't like it but others
do, so it is in there.

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

Again, no idea at all, but apparently some people do this!


> 
> 
> 10.10 Joining or Bridging an Appearance
>     - what is the difference between the NOTIFYs at F27/29 and F40/42?

F27 is after the INVITE Join is answered, so it will be confirmed.  F40
is after Bob re-INVITEs Carol to add 'isfocus' to tell her he is mixing,
so the difference would be in the feature tags.


  trying
>       vs confirmed? is the one at F27/29 really necessary?

If the AA was trying to save messages, it could hold off sending F27-29
and just send F40-43.

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

Fixed.

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

Well, the timeout is that the Proxy doesn't tell the AA that the dialog
went to confirmed state (200 OK answer).  So, I'll remove the line.

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

I think the correct behavior per RFC 3265 is that the NOTIFY would get
retransmitted for 32 seconds, then the dialog declared dead and the
subscription terminated.

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

No, Alice pressed the 2nd one, and she failed to get dialtone (or
whatever the UI indication of successful seizure was).  As a result, she
presses the 3rd button, and gets dialtone (or wahtever).  I can't see
any problem in this.


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

It doesn't matter in this direction.  I clarified it to say that it is
just Event:dialog

  I
>       think it is just "dialog", i.e. the events will not contain any
>       appearance number info.

That is correct.  A side effect is that in this case Bob will still have
to PUBLISH to seize an appearance.

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

Got it in one!  Also, there are problems with sending a 409 to a NOTIFY.

>     - F5 is the AA SUBSCRIBEing for "dialog" (I think)

Correct.

>     - F9 is Bob SUBSCRIBEing for "dialog;shared"

Correct.

>     - this section should follow 10.15

Why?  I don't see an dependencies.

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

Good catch!  You are correct.

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

That's a good question.  There might be cases where the UA wants to
release and appearance number, for example if the user selected it by
mistake.  Or, think about a phone with a row of appearance buttons.  If
the user runs their finger over all of them, that might cause the UA to
PUBLISH for a whole bunch of appearances.  Without a way for the UA to
cancel, all those appearances would be held for the expiration time of
the PUBLISH.  With a mechanism, the UA could cancel each one as the next
one was pressed.

I'll leave this in for the moment to see what others think of this.


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

I agree.  This text was written when the Alert-Info was optional, not
mandatory as it is now.  I have moved this non-normative text to section
4.2 where it now says:

"To best meet REQ-9, the appearance number for an incoming INVITE needs
to be contained in the INVITE, in addition to being delivered in the
dialog package NOTIFY.   Otherwise, if the NOTIFY is delayed or lost, a
UA in the group might receive an incoming INVITE but might not know
which appearance number to render during alerting.

This specification defines an extension parameter for the Alert-Info
header field in RFC 3261 to carry the appearance number:

Alert-Info: <urn:alert:tone:normal>;appearance=0"


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

Right - we need to decide on this.

> 
> 14. Security Considerations
>     - section should appear before section 12

Done!

Whew!

> 
> 
> _______________________________________________
> BLISS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bliss
>