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

["Worley, Dale R (Dale)" <[e-mail]>]

(Despite the Subject: line, which is the Subject: of the message I am
replying to, all text references in my new text are to the -08 version.)

Only the items which have an ongoing discussion:

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

OK.

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

OK.  I think I wrote my original objection when I was reading 5.2 (and
noticing that it was discussing actions) but had not yet read 5.3.

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

OK.  I guess there's no place to specify it in the schema.

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

Ah, yes.  Every UA has to support Join/Replaces so that other UAs'
pickup and bridge operations work.

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

OK -- and the Appearance Agent can use SUBSCRIBE/dialog to get the
needed information.

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

OK.

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

The techniques that are implemented in practice are generally
draft-anil-sipping-bla-03 and draft-anil-sipping-bla-04.  In the real
world, we will need to handle mixed systems that include phones that
implement draft-anil-sipping-bla-03, draft-anil-sipping-bla-04, and
draft-ietf-bliss-shared-appearances.
 
> > 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.

I'm not sure I see how you are looking at this.

My mental model is what was implemented in really primitive key
systems.  You could pick up the handset, push "line 1", connecting to
a circuit that went to the switch.  Then dial the common directory
number; the switch would connect that incoming circuit with a
different outgoing circuit to the same phone.  "line 2" would ring.
You could put line 1 on hold, then push the line 2 button to connect
the handset to the other line back to the switch, and answer the
incoming call.

As far as I know, the dialog event package is aligned with this model
because the <dialog> elements don't actually describe *dialogs* but
rather *dialog ends*.  If you call from a phone to itself, the dialog
will appear twice in the phone's <dialog-info>, and the two <dialog>
elements will have swapped local-tag and remote-tag values relative to
each other.

This seems to be what is illustrated in the dialog event in F19 in
section 11.8, although in that case, the two dialog ends are on two
different phones and they are combined in the overall dialog event
info for sip:[e-mail].

INVITE/Replaces and INVITE/Join use the same model, the Replaces and
Join headers don't specify a dialog, they specify a dialog end.  E.g.,
if you have a looped dialog from a phone to itself, the
INVITE/Replaces/Join specifies *which* end of the dialog is to be
replaced/joined.  Similarly for testing whether to generate a 482
Merged Request result; if the same dialog is already present on the
phone but with reversed tags, that is OK.

Within this context, I would expect in the example of F19 that one
<dialog> element would have <sa:appearance>1</sa:appearance> and the
other to have <sa:appearance>2</sa:appearance>.  Indeed, it would take
special code for the "incoming" side of the switch/proxy/B2BUA to
notice that although appearance 1 of HelpDesk is in use, the incoming
call we are assigning an appearance to has the same Call-ID (but
swapped tags) as the call on appearance 1, and so should be assigned
the same appearance.

Since I look at the <dialog> elements, the appearance numbers,
etc. as corresponding to dialog ends, I would expect failures if two
different dialog ends had the same appearance number.

But it's possible that either model can work.  The consequences need
to be examined with some care, I think.  In any case, the RFC should
specify one system or the other (and be clear about it), rather than
permitting either.

Dale