So it sounds like we are all on the same page, that we are talking about
only one AOR, the shared appearances AOR. So lines or alternative AORs
are not mentioned in this document.
See my comments below.
Thanks,
Alan
Francois Audet wrote:
Ok, I think we are on the same page then.
I was thinking something along the lines of having a "terminology
section" (like most drafts) including something like:
Seizing: An appearance can be seized by communicating an
artificial state of "trying" prior to actually initiating a dialog,
in order to appear as it was already initiating a dialog.
Selecting(or Not-Seizing): An appearance is merely selected
(i.e., not seized) if there is no such communication of
artificial state of "trying" prior to initiating a dialog:
i.e., the state is communicted when the dialog is actually
initiated.
So, using this terminology, selecting is a UI operation that has no
protocol implications on the wire. I think we already cover this in the
draft, but don't talk about the UI.
From the protocol perspective, there are four options when it comes to
appearances:
1. The UA seizes the appearance prior to sending the INVITE - this is
the old fashioned mechanism and requires the PUBLISH prior to the INVITE.
2. The UA just sends the INVITE and the Appearance Agent assigns the
appearance number for it. The UA will update its UI once it knows the
appearance number.
3. The UA does not want to assign an appearance number for a call using
the shared AOR. This is the consultation call case. The PUBLISH must be
sent before the INVITE so the Appearance Agent does not assign a new
appearance number by mistake.
4. The UA is going to take or join another appearance, so it wants to
reuse the existing appearance number. Again, a PUBLISH must be sent
before the INVITE so the Appearance Agent does not assign a new
appearance number by mistake. Also, the joined-dialog or
replaced-dialog elements tell the Appearance Agent that a take or join
is in progress, so it does not reject the PUBLISH with a 409 due to the
appearance number already being in use.
I'm not attached to using the term "selected". I would just
like the distinction to be clear so when developpers read
the procedures (and more importantly the example), they
know which parts are optional.
It's perfectly fine with me if at the end of the day,
a phone can be described as "Support Appearance Seizure: yes or no"
instead of "Appearance: Seizure vs Selection".
OK, but even UAs that do no seize appearances must be able to handle
scenarios 2-4 above, some of which involve sending the PUBLISH prior to
the INVITE.
-----Original Message-----
From: Hutton, Andrew [mailto:[email protected]]
Sent: Thursday, July 16, 2009 09:18
To: Audet, Francois (SC100:3055); Alan Johnston
Cc: [email protected]
Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:
Seize vs Select
Hi All,
See below.
Regards
Andy
-----Original Message-----
From: Francois Audet [mailto:[email protected]]
Sent: 15 July 2009 17:19
To: Hutton, Andrew; Alan Johnston
Cc: [email protected]
Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:
Seize vs Select
I disagree. I think we need some clarification.
[Andy H] OK Clarification is always a good thing.
We have decided already that the act of "fake publishing" a "trying"
state is OPTIONAL in this draft. This feature is really when
a vendor
wants to mimic traditional behavior of a key system.
[Andy H] I Agree.
Other people view this as an archaic limitation instead. Even in
"pre-sip" implementations, many TDM PBXs have given up already
on "seizing" lines when you press the button (the "seizing" only
occurs when the call is actually made).
[Andy H] I Agree.
So, we wisely opted to make this optional in the spec. The problem
is that we have a bit of lack of clarity in a few places about what
that means.
Getting to specifics, if you look at example 10.4 of the spec.
If you use a "selection model" instead of a "seizing" model, then
messages F1-F6 do not occur. And neigther would messages F10-F11.
[Andy H] I Agree.
(Note that if the Appearance agent had subscribed to HelpDeksk's
dialog state, then there would be NOTIFY instead of F10: that is
the subject of another discussion).
If we agree on this, I can volunteer to provide text if Alan wants
it. But I'm not sure if "selection" is the proper term. An
alternative
would be to say the line is "Seized" or "Not Seized".
[Andy H] I agree except that I object to is any discussion about line
selection as we will not be able to agree on what is meant by a "line"
we went over this many times already it is an an appearance
index which
is "seized" or "not siezed" and not a line which many people relate to
an AOR.
-----Original Message-----
From: Hutton, Andrew [mailto:[email protected]]
Sent: Wednesday, July 15, 2009 00:55
To: Audet, Francois (SC100:3055); Alan Johnston
Cc: [email protected]
Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:
Seize vs Select
Hi,
If "select" is a local action in the UA to choose a "line" to
use and this determines the what is in the from header then
this is I believe out of scope for this draft which should
not mention selecting lines or AOR's as this is a different
feature. The SA draft is limited to sharing appearances of
the same AOR.
Also if "select" is a local action at the UA that is just UI
behaviour then probably no need to mention it at all.
Regards
Andy
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf
Of Francois Audet
Sent: 14 July 2009 22:28
To: Alan Johnston
Cc: [email protected]
Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize
vs Select
I changed "select" to "select/seize" globally in the
document. I'm
not sure it helps readability, but I think we need both terms.
Here is an explanation what I meant with "seize" versus "select".
I might have been using a definition of "selection" that is
different
>from what you had in mind.
In my mind, I was equating "seizing" with the concept of actually
reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the
Appearance agent of the call state "premptively".
In contrast, I was using the term "selection" to mean the
local action
(on the phone) of choosing which "line" to use (i.e., the "From"
header). This is local because it does not require any
publication of
state to the appearance agent. The user presses a line key, no
signalling comes out immediately (and user probably hears
dial tone).
When the call is eventually made, it uses that line that was
"selected"
as the originator (i.e., the From header).
I am proposing that if we use these definitions, then it
makes it much
clearer throughout the document what we are talking about.
There are
lots of cases where we mean "selection or seizing" (because the
PUBLISH/ SUBSCRIBE is optional), and in other cases, we
really mean the
"seizing".
So, for example, in 10.4, messages F1-F2 are actually a
"seizing", not
merely a "selection".
Anyways, just think about it.
I think there are people who would want to implement the
"line seizure"
concept, and people who would NOT want to implement it. If
it's clear
what "seizure" means, then it makes it obvious in the text
what is the
optional part.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
