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

Alan Johnston <alan.b.johnston@gmail.com> Thu, 07 July 2011 18:39 UTC

Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: bliss@ietfa.amsl.com
Delivered-To: bliss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98D81F0C55 for <bliss@ietfa.amsl.com>; Thu, 7 Jul 2011 11:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.499
X-Spam-Level:
X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yeejq-N2BUb7 for <bliss@ietfa.amsl.com>; Thu, 7 Jul 2011 11:38:59 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B77EC1F0C67 for <bliss@ietf.org>; Thu, 7 Jul 2011 11:38:59 -0700 (PDT)
Received: by gyd5 with SMTP id 5so591886gyd.31 for <bliss@ietf.org>; Thu, 07 Jul 2011 11:38:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bb3neTcb20W3m6azvlYh5wzs6vs60NlVmQtX57m3AgA=; b=uqy9sVPhl05QJSSlqMzcUhtAT759KX3d9gDiUFvMpVjsMfPBS+xxr7i6ZrzosmVbZN wLqpiEhgRt7D9WyIq3gu4eCfaL1K8/+2JA5cLzC2fvTn3Pou/i5G6O7ebaNFEUlSVYU3 G2jK+NVZpYWaqU8YyzRBKpm+QsiaJQG6wezqY=
MIME-Version: 1.0
Received: by 10.150.14.6 with SMTP id 6mr401240ybn.20.1310063938986; Thu, 07 Jul 2011 11:38:58 -0700 (PDT)
Received: by 10.151.114.1 with HTTP; Thu, 7 Jul 2011 11:38:58 -0700 (PDT)
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F573C@DC-US1MBEX4.global.avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B222B1F573C@DC-US1MBEX4.global.avaya.com>
Date: Thu, 7 Jul 2011 13:38:58 -0500
Message-ID: <CAKhHsXEb2hbdOmxv=FbR-k5skg34N6Uamd=dfENVMOahdTb=BQ@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "bliss@ietf.org" <bliss@ietf.org>
Subject: Re: [BLISS] Comments on draft-ietf-bliss-shared-appearances-07
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2011 18:39:01 -0000

Dale,

Thanks for the reply.  See a few comments below.

- Alan -

On Wed, Jul 6, 2011 at 3:02 PM, Worley, Dale R (Dale) <dworley@avaya.com>; 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:HelpDesk@example.com.
>
> 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
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>