[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select

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:andrew.hutton at siemens-enterprise.com] Sent: Thursday, July 16, 2009 09:18 
To: Audet, Francois (SC100:3055); Alan Johnston
Cc: bliss at ietf.org
Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select 

Hi All,

See below.

Regards
Andy


-----Original Message-----
From: Francois Audet [mailto:audet at nortel.com]
Sent: 15 July 2009 17:19
To: Hutton, Andrew; Alan Johnston
Cc: bliss at ietf.org
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:andrew.hutton at siemens-enterprise.com] Sent: Wednesday, July 15, 2009 00:55 
To: Audet, Francois (SC100:3055); Alan Johnston
Cc: bliss at ietf.org
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: bliss-bounces at ietf.org [mailto:bliss-bounces at ietf.org]
On Behalf 
Of Francois Audet
Sent: 14 July 2009 22:28
To: Alan Johnston
Cc: bliss at ietf.org
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
BLISS at ietf.org
https://www.ietf.org/mailman/listinfo/bliss