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

[Alan Johnston <[e-mail]>]

Dale,

Thanks for the reply.  See a few comments below.

- Alan -

On Wed, Jul 6, 2011 at 3:02 PM, Worley, Dale R (Dale) <[e-mail]> wrote:
> (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.

This is correct.

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

Right.

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

I am now coming around to agreeing with you.  You should be able to
call yourself, and the only way this could work is if a different
appearance number is used for each leg (end) of the dialog.

I'll write some text to describe this, and update the example accordingly.



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