Subject: [BLISS] MLA with Floor Control

From: Alan Johnston <[email-masked]>
Date: Thu, 13 Mar 2008 09:18:30 -0500

All,

In this week's WG meeting, a number of people expressed concern about 
the use of PUBLISH to select appearance numbers as was proposed.  Others 
also object to the use of NOTIFY as well.  Rohan made the suggestion to 
treat an appearance number as a shared resource and use floor control 
and the Binary Floor Control Protocol (BFCP) to do selection.

I have done some preliminary thinking about how we could manage 
appearance numbers as a floor and utilize BFCP (RFC 4582) to request and 
learn appearance numbers.   We should discuss these options on the list 
and use the resulting consensus in the next version of the document.  I 
will leave my opinions out of this initial email but will express them 
in the resulting followup discussion.

This design would not modify the dialog event package - it would remain 
as is and would contain dialog identifiers.  Normal dialog state  
information would be published to an event state compositor (ESC) and 
notifications would be sent by the ESC - none of this would be 
appearance aware.

Each floor would have a floor ID associated with it.  A simple solution 
would be for the floor ID to be the appearance number, so in this usage 
of BFCP, only non-negative integers would be used as floor IDs.

A UA in the group wishing to learn the holder of an appearance number 
would query the floor control server and receive a response from the 
floor control server.   Each floor would contain the owner which would 
be the GRUU of the dialog to which the floor is associated with.  This 
GRUU could be used be used to lookup the dialog identifiers in the 
dialog package notification so that UAs could perform call control 
operations such as INVITE Join, INVITE Replaces, etc.

A UA in the group making a call would first request a floor from the 
floor control server.  If the floor was unavailable, the UA would try 
again.  The floor control server would be configured to not do floor 
request queuing.   Once a floor was obtained, an INVITE could be sent 
and the dialog information published.

An incoming call to the AOR would somehow be known to a moderator 
client.  The moderator client would use some predetermined logic (first 
available, for example) and request an available floor from the floor 
control server.  The INVITE would then be forked to the UAs in the 
group.  The INVITE would need to carry the appearance number, such as an 
appearance parameter on an Alert-Info header field as defined in the 
current draft.  (I don't know of any way a UA could learn the floor 
number from the floor control server unless there is a command to list 
all floors in use and find the one that is not associated with any dialog.)

With this design, UAs would implement a BFCP client and a SIP UA.  The 
ESC would not need any extensions.  The BFCP server would not need any 
extensions.  The moderator client would be a special piece of software 
that could coordinate with the forking proxy to learn of incoming calls 
and provide an appearance number to insert into the Alert-Info header 
field.

When a call ended, the UA would release the appearance number to the 
floor control server which would then be free to assign the appearance 
number for future incoming or outgoing calls.

UAs would need to publish their dialog state to the ESC and subscribe to 
the ESC to learn dialog IDs of other UAs.  UAs would also need to 
establish a BFCP connection over TCP (by sending an INVITE to the floor 
control server using RFC 4583).  We would need to define how the UA 
learns the SIP URI of the floor control server.

Of course, this needs further analysis but it would be useful to get 
feedback before more work is put into this approach.

Thanks,
Alan

_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Mohsen Soroushnejad" <[email-masked]>
Date: Thu, 13 Mar 2008 22:24:06 -0700

Hi Alan -

Thanks for leading the discussion on this draft.

the use of PUBLISH to select appearance numbers as was proposed.  Others
also object to the use of NOTIFY as well.<<
If you don't mind, please provide a synopsis of what these concerns were at
the meeting w.r.t  PUBLISH and NOTIFY usage.

In addition to BFCP discussion, I like to see discussions on:

- Extending NOTIFY usage (why not a NOTIFY 2.0?)
- Extending PUBLISH usage (why not a PUBLISH 2.0?)
- Hey, let's use INFO -- I know I get shot for saying this....;-)

My initial reaction w.r.t. goal of BLISS (i.e., interoperability on running
code) is that by adding yet another protocol that a SIP UA must support (i.e.,
BFCP), we're pushing it to the next decade, if not further. Is this a
necessary price to pay?

I look forward to discussions on the list.

Best Regards,
Mohsen

---

From: Venkatesh <[email-masked]>
Date: Thu, 13 Mar 2008 22:34:33 -0700

Alan, Rohan, et al:

I second Mohsen's suggestion. I think it makes sense to find out what the
disagreements were with using either using NOTIFY's or PUBLISH. If either of
them violates the RFC, what would it take to augment the RFC to accomodate
these flows assuming that the changes being requested are reasonable enough
and does not drastically break anything else? Finally, the proposal below
looks like an overkill to me in terms of what it is trying to achieve and is
probably going to be left with little implementations.

Thanks
Venkatesh

On Thu, Mar 13, 2008 at 10:24 PM, Mohsen Soroushnejad <[email-masked]>
wrote:

> If you don't mind, please provide a synopsis of what these concerns were
> at the meeting w.r.t  PUBLISH and NOTIFY usage.
>
> My initial reaction w.r.t. goal of BLISS (i.e., interoperability on
> running code) is that by adding yet another protocol that a SIP UA must
> support (i.e., BFCP), we're pushing it to the next decade, if not further.
> Is this a necessary price to pay?
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 18 Mar 2008 17:53:55 -0500

I also have the same opinion.
 
This seems completely overkill to me. 
 
I think we should step back and try to see if there is no alternative to implementing MLA. Seems to me we are diving head-first in über-complexity.
 
I personally think it would be a lot simpler to have each Line Appearance being a AOR that one can Register with and subscribe to it's presence and/or dialog package.
 
The Presence server could "compose" the presence status of the AOR. Similarly, if dialog information is also needed, then a sort of Dialog status server could also "compose" the Dialog state for the aggregate of UAs.
 
For example.
 
Say we have 5 lines (line1, line2, line3, line4, line5).
 
If my phone is able to make/receive calls for line1, line2, line3, then it will register all 3 lines. If I have a line appearance on my phone (LED or whatever), I can also subscribe to either Presence or dialog package for these 3 lines (as appropriate). That way, if some other phone picked up line 2, then I'll see the status on the phone. (Some server would "compose" the presence/dialog status).
 
For answering calls on various line appearance, it's a no-brainer (call just forks). This is the most common usage.
 
For transfering/conferencing/manipulating calls on various lines, REFER, Replaces, Pickup, Retrieve, etc. and other existing mechanism should just work as is.
 
Furthermore, this sort of approach will actually allow existing phones with no inherent support for MLA to work in an environment where MLA Is used. For example, the same line appearance could be used on a MLA-supporting phone (multiple line) and a normal phone that has only one appearance.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Venkatesh
	Sent: Thursday, March 13, 2008 22:35
	To: Mohsen Soroushnejad
	Cc: [email-masked]; Rohan Mahy
	Subject: Re: [BLISS] MLA with Floor Control

	Alan, Rohan, et al:
	
	I second Mohsen's suggestion. I think it makes sense to find out what the disagreements were with using either using NOTIFY's or PUBLISH. If either of them violates the RFC, what would it take to augment the RFC to accomodate these flows assuming that the changes being requested are reasonable enough and does not drastically break anything else? Finally, the proposal below looks like an overkill to me in terms of what it is trying to achieve and is probably going to be left with little implementations.
	
	Thanks
	Venkatesh

	On Thu, Mar 13, 2008 at 10:24 PM, Mohsen Soroushnejad <[email-masked]> wrote:

		Hi Alan -

		
		If you don't mind, please provide a synopsis of what these concerns were at the meeting w.r.t  PUBLISH and NOTIFY usage.

		 
		My initial reaction w.r.t. goal of BLISS (i.e., interoperability on running code) is that by adding yet another protocol that a SIP UA must support (i.e., BFCP), we're pushing it to the next decade, if not further. Is this a necessary price to pay?

		Best Regards,
		Mohsen

			All,

			

			

			

			
			Thanks,
			Alan

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 18 Mar 2008 16:36:24 -0800 (PST)

Hi Francois,

The problem I think you are missing here is that we are trying to satisfy
requirements to generate two very different user experiences:

A feature typically associated with every major PBX where pressing an
unused "line button" on a single shared appearance gives me a dial tone. 
If someone else starts to compose a number at the same time, the relative
order of the calls for this appearance can be different and that is OK
because these "line buttons" are typically not labeled distinctly, they
all have the same name.

A feature typically associated with most Key Telephone Systems where
pressing the button "line2" on two phones results in an error tone for
whoever is slightly later.  This feauture, while extremely irritating,
allows folks to yell out "Hey, Neil, call for you on line 3".  Each button
has a distinct name.

I have personally used these two very different features on my desk in a
production office setting at different jobs.

This second feature requires exclusive access to a shared resource (use of
the "line 2" identifier).  This is the definition of floor control.

If you just want to implement feature 1, you don't need exclusive access
and therefore you don't need floor control.

We have a working protocol that is pretty easy to implement.  Since a
shared line system with exclusive access needs very close proximity, we
can probably assume that all the phones with shared access are on the same
subnet.  We don't need to do anything fancy for NAT traversal of BFCP
among the members of one of these groups.  As for whining about "another
protocol", we had a lot of phone vendors implement STUN in a short period
of time, because it is easy and it added value.  I don't think BFCP is any
different here.

Now let me say a few words about why I think PUBLISH is such a bad idea. 
What are the semantics of PUBLISH here?  This feature depends entirely on
a specific composition policy for the feature to work.  This is the first
event package I can think of where the composition policy is normative.
There is also an interoperability problem. How is the UA that implements
feature 1 supposed to find out that its compositor is using the feature 2
composition policy?  It can't tell.  It will get an error for the PUBLISH,
but the phone will still let the user dial and will keep sending PUBLISH
requests that will continue to be discarded.  You want to model two
features here, but the proposed PUBLISH approach requires that the
compositor and all the publishers have the same policy, and you are
providing no way to tell what the policy is.  This is a massive
opportunity for things to go wrong.

Finally, I think the PUBLISH error message semantics are wrong.  If I have
a presence agent that is spewing presence that makes no sense (the chair
sensor at my office is stuck and reports that I am the office, when I am
clearly yacking away on my phone in another country), a good compositor
should *ignore* the publications instead of sending an error, since the
chair source of presence is no longer credible.  What you want a
compositor to do is not composition, it is arbitrating exclusive access. 
These are very different.

thanks,
-rohan

> I think we should step back and try to see if there is no alternative to
> implementing MLA. Seems to me we are diving head-first in über-complexity.
>
> I personally think it would be a lot simpler to have each Line Appearance
> being a AOR that one can Register with and subscribe to it's presence
> and/or dialog package.
>
> The Presence server could "compose" the presence status of the AOR.
> Similarly, if dialog information is also needed, then a sort of Dialog
> status server could also "compose" the Dialog state for the aggregate of
> UAs.
>
> For example.
>
> If my phone is able to make/receive calls for line1, line2, line3, then it
> will register all 3 lines. If I have a line appearance on my phone (LED or
> whatever), I can also subscribe to either Presence or dialog package for
> these 3 lines (as appropriate). That way, if some other phone picked up
> line 2, then I'll see the status on the phone. (Some server would
> "compose" the presence/dialog status).
>
> For answering calls on various line appearance, it's a no-brainer (call
> just forks). This is the most common usage.
>
> For transfering/conferencing/manipulating calls on various lines, REFER,
> Replaces, Pickup, Retrieve, etc. and other existing mechanism should just
> work as is.
>
> Furthermore, this sort of approach will actually allow existing phones
> with no inherent support for MLA to work in an environment where MLA Is
> used. For example, the same line appearance could be used on a
> MLA-supporting phone (multiple line) and a normal phone that has only one
> appearance.
>
>
>
> disagreements were with using either using NOTIFY's or PUBLISH. If either
> of them violates the RFC, what would it take to augment the RFC to
> accomodate these flows assuming that the changes being requested are
> reasonable enough and does not drastically break anything else? Finally,
> the proposal below looks like an overkill to me in terms of what it is
> trying to achieve and is probably going to be left with little
> implementations.
>
> 	Thanks
> 	Venkatesh
>
>
> support (i.e., BFCP), we're pushing it to the next decade, if not
> further. Is this a necessary price to pay?
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 19 Mar 2008 17:13:42 +0000

Hi All,
 
I am also of a similar opinion to Francios, Venkatesh and Mohsen and in particular I like what Francios is saying below as it seems to simplify the solution somewhat and one thing we need is simple solutions with little optionality.
 
It may be that the BFCP does something similar to what we need but I would prefer a pure SIP based solution.
 
When will the BLISS-MLA design team conference calls get started again ?
 
Regards
Andy

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Audet
	Sent: 18 March 2008 22:54
	To: Venkatesh; Mohsen Soroushnejad
	Cc: [email-masked]; Rohan Mahy
	Subject: Re: [BLISS] MLA with Floor Control

	 

	 
	For example.

	 

		Alan, Rohan, et al:

		Thanks
		Venkatesh

			Hi Alan -

			

			 

			Best Regards,
			Mohsen

				All,

				

				

				

				
				Thanks,
				Alan

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 19 Mar 2008 17:21:49 -0500

I don't think "let's replicate a 50-year old key-system design" is a good approach.

These systems worked like this because back then pressing on the button would actually
switch the physical line. It's increadibly archaic.

If some manufacturer wants to sell a SIP phone that looks like a 1960's desk phone,
good luck to them. I'm okay with that.

But I really think that it would not be the IETF's job to create an arcane protocol
to mimimic a 1960's phone behavior.  Especially iritating features.

I believe the behavior your are looking for, including irritating arcane "features"
(i.e., somebody "seizing" the line before the other one) can be implemented without
a new protocol such as BFCP or a gazillion PUBLISH/NOTIFYs.

The two guys in your example are both registed with "line2" as AOR. Call comes in for
line2, and is forked to the two guys. Normal SIP. Guy 1 answers and gets the call. Guy 2 
answers slighly later and gets the error tone because the call has already been answered.
Again, plain Jane SIP.

Also, if the two guys actually want to see the line "status", they can subscribe to the
presence (or dialog package) of AOR "line2" and display it on the line appearance.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Tuesday, March 18, 2008 17:36
> To: Audet, Francois (SC100:3055)
> Cc: Venkatesh; Mohsen Soroushnejad; [email-masked]; Rohan Mahy
> Subject: RE: [BLISS] MLA with Floor Control
> 
> Hi Francois,
> 
> The problem I think you are missing here is that we are 
> trying to satisfy requirements to generate two very different 
> user experiences:
> 
> A feature typically associated with every major PBX where 
> pressing an unused "line button" on a single shared 
> appearance gives me a dial tone. 
> If someone else starts to compose a number at the same time, 
> the relative order of the calls for this appearance can be 
> different and that is OK because these "line buttons" are 
> typically not labeled distinctly, they all have the same name.
> 
> A feature typically associated with most Key Telephone 
> Systems where pressing the button "line2" on two phones 
> results in an error tone for whoever is slightly later.  This 
> feauture, while extremely irritating, allows folks to yell 
> out "Hey, Neil, call for you on line 3".  Each button has a 
> distinct name.
> 
> I have personally used these two very different features on 
> my desk in a production office setting at different jobs.
> 
> This second feature requires exclusive access to a shared 
> resource (use of the "line 2" identifier).  This is the 
> definition of floor control.
> 
> If you just want to implement feature 1, you don't need 
> exclusive access and therefore you don't need floor control.
> 
> We have a working protocol that is pretty easy to implement.  
> Since a shared line system with exclusive access needs very 
> close proximity, we can probably assume that all the phones 
> with shared access are on the same subnet.  We don't need to 
> do anything fancy for NAT traversal of BFCP among the members 
> of one of these groups.  As for whining about "another 
> protocol", we had a lot of phone vendors implement STUN in a 
> short period of time, because it is easy and it added value.  
> I don't think BFCP is any different here.
> 
> What are the semantics of PUBLISH here?  This feature depends 
> entirely on a specific composition policy for the feature to 
> work.  This is the first event package I can think of where 
> the composition policy is normative.
> There is also an interoperability problem. How is the UA that 
> implements feature 1 supposed to find out that its compositor 
> is using the feature 2 composition policy?  It can't tell.  
> It will get an error for the PUBLISH, but the phone will 
> still let the user dial and will keep sending PUBLISH 
> requests that will continue to be discarded.  You want to 
> model two features here, but the proposed PUBLISH approach 
> requires that the compositor and all the publishers have the 
> same policy, and you are providing no way to tell what the 
> policy is.  This is a massive opportunity for things to go wrong.
> 
> Finally, I think the PUBLISH error message semantics are 
> wrong.  If I have a presence agent that is spewing presence 
> that makes no sense (the chair sensor at my office is stuck 
> and reports that I am the office, when I am clearly yacking 
> away on my phone in another country), a good compositor 
> should *ignore* the publications instead of sending an error, 
> since the chair source of presence is no longer credible.  
> What you want a compositor to do is not composition, it is 
> arbitrating exclusive access. 
> > I think we should step back and try to see if there is no 
> alternative 
> > to implementing MLA. Seems to me we are diving head-first 
> in über-complexity.
> >
> > I personally think it would be a lot simpler to have each Line 
> > Appearance being a AOR that one can Register with and subscribe to 
> > it's presence and/or dialog package.
> >
> > status server could also "compose" the Dialog state for the 
> aggregate 
> > of UAs.
> >
> > For example.
> >
> > If my phone is able to make/receive calls for line1, line2, line3, 
> > then it will register all 3 lines. If I have a line 
> appearance on my 
> > phone (LED or whatever), I can also subscribe to either Presence or 
> > dialog package for these 3 lines (as appropriate). That 
> way, if some 
> > other phone picked up line 2, then I'll see the status on 
> the phone. 
> > (Some server would "compose" the presence/dialog status).
> >
> > For answering calls on various line appearance, it's a no-brainer 
> > (call just forks). This is the most common usage.
> >
> > For transfering/conferencing/manipulating calls on various lines, 
> > REFER, Replaces, Pickup, Retrieve, etc. and other existing 
> mechanism 
> > should just work as is.
> >
> > with no inherent support for MLA to work in an environment 
> where MLA 
> > Is used. For example, the same line appearance could be used on a 
> > MLA-supporting phone (multiple line) and a normal phone 
> that has only 
> > one appearance.
> >
> >
> >
> > 	I second Mohsen's suggestion. I think it makes sense to 
> find out what 
> > the disagreements were with using either using NOTIFY's or 
> PUBLISH. If 
> > either of them violates the RFC, what would it take to 
> augment the RFC 
> > to accomodate these flows assuming that the changes being requested 
> > are reasonable enough and does not drastically break anything else? 
> > Finally, the proposal below looks like an overkill to me in 
> terms of 
> > what it is trying to achieve and is probably going to be left with 
> > little implementations.
> >
> > 	Thanks
> > 	Venkatesh
> >
> >
> > 		If you don't mind, please provide a synopsis of 
> what these concerns 
> > were at the meeting w.r.t  PUBLISH and NOTIFY usage.
> >
> > running code) is that by adding yet another protocol that a SIP UA 
> > must support (i.e., BFCP), we're pushing it to the next 
> decade, if not 
> > 		On Thu, Mar 13, 2008 at 7:18 AM, Alan Johnston 
> <[email-masked]>
> > wrote:
> >
> >
> > 			All,
> >
> > 			the use of PUBLISH to select appearance 
> numbers as was proposed.
> > Others
> > 			appearance numbers as a floor and 
> utilize BFCP (RFC 4582) to 
> > request and
> > 			group.  The INVITE would need to carry 
> the appearance number, such 
> > as an
> > 			all floors in use and find the one that 
> is not associated with any
> > dialog.)
> >
> > 			UAs would need to publish their dialog 
> state to the ESC and 
> > subscribe to

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 19 Mar 2008 16:50:01 -0700

I agree with Francois that we might be going to far down the path of
emulating 1960's technology.  I ran Francois' last post past our HCI guru
and he was in complete agreement.

What we are missing from 'normal sip' which I think is useful:

* being able to yell an appearance# across the room
* being able to pick up/join a call based on that #

Then we have the requirements that I don't think we need to support to give
people the same workflow:

* selecting a particular appearance before a call is placed
* binding an appearance to a 'line button'
* using the appearance numbers to represent a resource limit.

If somebody wants to make a hard phone that has appearance buttons, the
appearance light would not turn on until an appearance was acquired. If we
wanted to do a very lightweight solution(the first 2 requirments) this could
just be done in INVITE messages and INVITE responses by plugging an app
server which adds a header for appearences.  This could be done as a
redirect or spirals.

-Derek

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 19 Mar 2008 17:07:02 -0700

Mutating the semantics of NOTIFY/PUBLISH to make them close enough will
require a document in the SIP working group and will likely take as much or
more time to be deployed than an entirely new protocol.

If you have a 3265 engine that properly does etags, composition-plug-ins
etc. is is highly optimized to those semantics; changing the semantics will
require a lot of effort. It will also require a client to support different
semantic for the same SIP primitive.  It would be better to add a new
primitive for SIP for this type of resource acquisition/allocation.  This
sounds scary, but it's really what people are proposing when they talk about
'extending the semantics a little.' Its just disguised as an extension to an
existing mechanism.

In this case I think adding a new protocol is easier/cleaner than modifying
the semantics of the existing SIP mechanisms. BFCP and REST seem like good
candidates here.  BFCP has closer semantics built in(timers), REST has
broader applicability for endpoints.

That said, I agree with Francois that we may have gone overboard with
requirements; we might be able to use SIP cleanly with reduced requirements.

-Derek

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 19 Mar 2008 17:08:10 -0700

Francois,

Inline.

> switch the physical line. It's increadibly archaic.

I agree.

> to mimimic a 1960's phone behavior.  Especially iritating features.

Well, I thought that was part of the requirements identified for the  
BLISS MLA feature.  If you are flexible about the user interface, I  
think you can deliver a better user experience and I don't think you  
need any new mechanism other than the core dialog package.  I believe  
this also holds for "feature 1" as I described it below.

> a new protocol such as BFCP or a gazillion PUBLISH/NOTIFYs.

The problem is when "seizing" the line to make outbound calls.  This  
requires exclusive access to "the line".  Note that exclusive access  
to "the line" is also needed before alerting as well, in case someone  
tries to get a dial tone and dial at the same moment that a proxy  
forwards a call to the UAs.  This requires some new mechanism.

thanks,
-rohan

> Also, if the two guys actually want to see the line "status", they  
> cseizan subscribe to the

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 19 Mar 2008 19:09:44 -0500

More comments below.
 
	From: [email-masked]
	Sent: Wednesday, March 19, 2008 16:50
	To: Audet, Francois (SC100:3055)
	Cc: Rohan Mahy; [email-masked]
	Subject: Re: [BLISS] MLA with Floor Control

	
	Then we have the requirements that I don't think we need to support to give people the same workflow:

This is really easy if you have one registration per "line" (I prefer to use AOR for each
of these lines: if it's "Line 1" or "Sales" or "Shipping", or "The Boss" or "The secretary"
is just flexible implementation details.

Pressing the key just selects the proper context (which active registration is used).

Note that incoming calls can be dealt with the same way. If the request URI points
to "Line1", you can flash the appearance or whatever.

Again, this in inherent with the approach where an appearance is just an AOR.

Again, using an AOR as is instead of binging a line number to an AOR avoids this problem.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 19 Mar 2008 19:22:00 -0500

This is getting interesting... 

Below.

> Sent: Wednesday, March 19, 2008 17:08
> Cc: Rohan Mahy; Venkatesh; Mohsen Soroushnejad; [email-masked]
> > I don't think "let's replicate a 50-year old key-system 
> design" is a 
> > good approach.
> >
> > These systems worked like this because back then pressing on the 
> > button would actually switch the physical line. It's increadibly 
> > archaic.
> 
> I agree.

Cool.

> > If some manufacturer wants to sell a SIP phone that looks like a 
> > 1960's desk phone, good luck to them. I'm okay with that.
> >
> > But I really think that it would not be the IETF's job to create an 
> > arcane protocol to mimimic a 1960's phone behavior.  Especially 
> > iritating features.
> 
> Well, I thought that was part of the requirements identified 
> for the BLISS MLA feature.  If you are flexible about the 
> user interface, I think you can deliver a better user 
> experience and I don't think you need any new mechanism other 
> than the core dialog package.  I believe this also holds for 
> "feature 1" as I described it below.

Ok, looks like we are again in agreement.

> > (i.e., somebody "seizing" the line before the other one) can be 
> > implemented without a new protocol such as BFCP or a gazillion 
> > PUBLISH/NOTIFYs.
> 
> The problem is when "seizing" the line to make outbound 
> calls.  This requires exclusive access to "the line".  Note 
> that exclusive access to "the line" is also needed before 
> alerting as well, in case someone tries to get a dial tone 
> and dial at the same moment that a proxy forwards a call to 
> the UAs.  This requires some new mechanism.

I remember seeing on the radio a chef relating a story about his roastbeef recipe where
he would cut the four corners of a roast beef before putting it in the oven. Somebody 
asked why he was shaving off the four corners. Does it improve the flavor? The chef couldn't 
give an answer. Since the chef had learned about cooking roastbeef from his mother,
he asked the elderly women and he discovered the reason was because his mother's 
pot was oval and a normal roast wouldn't fit in it if the corners weren't cut.

This is the same thing. 

The reason why one wanted to "seize the line" for an outgoing call back then was
because it was a physical piece of wire. It was a physical limitation of the
system.

Being able to have multiple people use the same line for an outgoing call actually
seems like a feature to me, not a bug. Yet another reason why ditching the old
key system is good.

Of course, if a manufacturer wants to sell retro-feeling equipment, then you could
monitor the dialog package or presence of the shared AOR, and just not allow it to make
outgoing calls if the identity is in use.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Mar 2008 21:05:35 -0400

kibitzing...

> seems like a feature to me, not a bug. Yet another reason why ditching the old

There is a tradeoff...

If multiple extensions can place outgoing calls from the same line, then 
the line doesn't have "binary" status, so it can't be indicated as 
active or not with a light. And you can't "conference in" by picking up 
on the same line.

While I am not into it myself, I can see how someone can build a 
"business process" around the specific way in which lines are managed by 
the phones, and then be very upset if they can't get that same user 
experience.

Now you can come up with some very nice UIs that provide better user 
experience, if you have a suitable display instead of just a bunch of 
lights. (E.g. an entry for the "number" (AOR that people call), and a 
variable length drop down list of active calls, showing the callerid of 
the caller, how long it has been active, and which extensions are 
currently connected to it.) But that is *different*, and requires a 
device with richer UI.

	Paul

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 19 Mar 2008 18:07:01 -0700

Inline.

> > > arcane protocol to mimimic a 1960's phone behavior.  Especially
I also worry that we are designed a protocol from an old user interface,
rather than the operations we wish to support. I'm asking usability people
what they think people *actually* need to do, and I encourage others to do
the same.

> seems like a feature to me, not a bug. Yet another reason why ditching the

Oddly, in MLA you do end up using the same line for outgoing calls; you just
end up using different appearances.  My assertion is that you don't need to
know which appearance  until the call is established(hand-waving away early
media/forking) and that we can design a simple mechanism around this.  There
are reasons for different outgoing calls having different appearances; each
call should be able to be "shout-controlled" independently.

---

From: "Bill Mitchell" <[email-masked]>
Date: Thu, 20 Mar 2008 00:12:01 -0700

I'm also interested in whether people really use and/or need the "shout across the room for line X" capability.  I'll try to get some data points around any end-user "business practices" that depend on the key system behavior.  Generally if a feature already exists, however archaic it may be, someone always seems to find creative uses.

The shout-control functionality does mandate seizure of an appearance before placing a call, and typically even before dialing.  Rohan mentioned an inbound-call-while-dialing example, but let me add the step by step details:
* User presses line key 1 on a phone and begins to dial digits. Assume phone doesn't seize an appearance.
* MLA AOR receives inbound call.  Server finds appearance 1 is free and allocates it to the call. 
* Server forks inbound call to all phones in the MLA group, with appearance 1 indicated in the INVITE. 
* To maintain the shout-control functionality, the inbound call must map to the same line key on all the phones. Phones typically have a basic mapping like appearance 1 to line key 1.
* Now phone is overbooked on line key 1. 
>> Phone could support multiple calls per line key, or play line key hopscotch and move outbound call to a different line key. Neither option is ideal.

Regards,   -Bill

From: [email-masked] on behalf of Derek MacDonald
Sent: Wed 3/19/2008 6:07 PM
To: Francois Audet
Cc: Rohan Mahy; [email-masked]
Subject: Re: [BLISS] MLA with Floor Control

Inline.

	
	Below.

	

	Cool. 

	> > arcane protocol to mimimic a 1960's phone behavior.  Especially

I also worry that we are designed a protocol from an old user interface, rather than the operations we wish to support. I'm asking usability people what they think people *actually* need to do, and I encourage others to do the same.

	
	This is the same thing.

Oddly, in MLA you do end up using the same line for outgoing calls; you just end up using different appearances.  My assertion is that you don't need to know which appearance  until the call is established(hand-waving away early media/forking) and that we can design a simple mechanism around this.  There are reasons for different outgoing calls having different appearances; each call should be able to be "shout-controlled" independently.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Mar 2008 14:57:38 +0100

Why is that appearance# not just a very limited local number plan
involving this small set of terminals?

If so, how is this problem different from the call pickup problem that
has been discussed in the past, at least on sipping? In other words, is
this an MLA problem or some other service.

Regards

Keith 

> Sent: Thursday, March 20, 2008 12:10 AM
> To: Derek MacDonald
> 	Then we have the requirements that I don't think we 
> need to support to give people the same workflow:
> 	
> This is really easy if you have one registration per "line" 
> (I prefer to use AOR for each of these lines: if it's "Line 
> 1" or "Sales" or "Shipping", or "The Boss" or "The secretary"
> Note that incoming calls can be dealt with the same way. If 
> the request URI points to "Line1", you can flash the 
> appearance or whatever.
>

---

From: "Jay S. Grzenda" <[email-masked]>
Date: Thu, 20 Mar 2008 10:22:13 -0400

Bill et al,

Our market research has shown that the "shout across the room for line
X" (aka: park and page) is still common in the SMB market, especially
for "non-office" (e.g. retail, warehouse) installations.
"Office-centric" businesses are more inclined to transfer calls directly
to the recipients (rather than "shout"). 

One possible solution to the Line Seizure contention is a full
client/server implementation, where the server "owns" the Line
Appearances. The UAs (or clients) SUBSCRIBE to the server for event
notification of the status of the lines. The server tracks the line
statuses internally and allocates them to UAs as
first-come-first-served. 

The key difference is that the outbound Line Siezure case is handled by
having the UA place a SIP call to the server:
  1) User presses line key 1.
  2) UA places a "seizure" call (INVITE to the line identifier) to the
server.
  3) If line 1 is "in use", server returns 486 Busy and terminates call.
  4) If line 1 is available, server tags it as in use, and notifies the
subscribed UAs. 
  5) If a destination number is not included in the INVITE (line seizure
case), the server:
     - accepts the call
     - plays dialtone
     - collects DTMF digits against a dialplan.
     - uses 3pcc to connect the UA call to the service provider using
the collected digits as the dialed number.
  6) If a destination number is included in the INVITE, the server
proxies the request to the service provider.

The inbound call is handled in a similar manner:
  1) The server tags the line as "ringing" and notifies the subscribed
UAs.
  2) User presses line key to answer the inbound call. This sends an
INVITE (with no SDP) to the server requesting the line.
  3) The server receives the INVITE from the UA and uses 3pcc to connect
the inbound line call to the UA call.
  4) The server tags the line as "in use" and notifies the subscribed
UAs.

The majority of the work is in developing the server. It needs to be a
UA for the line-seizure calls, and handle 3pcc negotiations as a
stateful proxy. It also needs to track the status and access lists for a
given number of lines.

This helps alleviate the issues with Req-8 (appearance contention) in
the draft, but but probably hinders Req-5 (scaling for large numbers).

Regards,
	-Jay

Jay Grzenda
Principal Engineer - Allworx Corp
www.allworx.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bill Mitchell
Sent: Thursday, March 20, 2008 3:12 AM
To: [email-masked]
Subject: Re: [BLISS] MLA with Floor Control

I'm also interested in whether people really use and/or need the "shout
across the room for line X" capability.  I'll try to get some data
points around any end-user "business practices" that depend on the key
system behavior.  Generally if a feature already exists, however archaic
it may be, someone always seems to find creative uses.

The shout-control functionality does mandate seizure of an appearance
before placing a call, and typically even before dialing.  Rohan
mentioned an inbound-call-while-dialing example, but let me add the step
by step details:
* User presses line key 1 on a phone and begins to dial digits. Assume
phone doesn't seize an appearance.
* MLA AOR receives inbound call.  Server finds appearance 1 is free and
allocates it to the call. 
* Server forks inbound call to all phones in the MLA group, with
appearance 1 indicated in the INVITE. 
* To maintain the shout-control functionality, the inbound call must map
to the same line key on all the phones. Phones typically have a basic
mapping like appearance 1 to line key 1.
* Now phone is overbooked on line key 1. 
>> Phone could support multiple calls per line key, or play line key
hopscotch and move outbound call to a different line key. Neither option
is ideal.

Regards,   -Bill

Inline.

On Wed, Mar 19, 2008 at 5:22 PM, Francois Audet <[email-masked]>
wrote:

	Below.

	

	Cool. 

I also worry that we are designed a protocol from an old user interface,
rather than the operations we wish to support. I'm asking usability
people what they think people *actually* need to do, and I encourage
others to do the same.

	> > I believe the behavior your are looking for, including
irritating
	> > arcane "features"

	I remember seeing on the radio a chef relating a story about his
roastbeef recipe where
	he would cut the four corners of a roast beef before putting it
in the oven. Somebody
	asked why he was shaving off the four corners. Does it improve
the flavor? The chef couldn't
	give an answer. Since the chef had learned about cooking
roastbeef from his mother,
	he asked the elderly women and he discovered the reason was
because his mother's
	pot was oval and a normal roast wouldn't fit in it if the
corners weren't cut.
	
	This is the same thing.
	
	The reason why one wanted to "seize the line" for an outgoing
call back then was
	because it was a physical piece of wire. It was a physical
limitation of the
	system.
	
	Being able to have multiple people use the same line for an
outgoing call actually
	seems like a feature to me, not a bug. Yet another reason why
ditching the old
	key system is good.

Oddly, in MLA you do end up using the same line for outgoing calls; you
just end up using different appearances.  My assertion is that you don't
need to know which appearance  until the call is established(hand-waving
away early media/forking) and that we can design a simple mechanism
around this.  There are reasons for different outgoing calls having
different appearances; each call should be able to be "shout-controlled"
independently.

	Of course, if a manufacturer wants to sell retro-feeling
equipment, then you could
	monitor the dialog package or presence of the shared AOR, and
just not allow it to make
	outgoing calls if the identity is in use.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 20 Mar 2008 08:03:50 -0700

Hi Francois,

The justification I heard from vendors about preserving seizure  
behavior is related to training the end-users who use this feature.   
The argument goes that these users re so accustomed to the 2nd button  
on phone1 being the same call as the 2nd button on phone2 that they  
would be unable to use the feature if the user experience is any  
different.

I know that the four-person consulting office I worked in (which had  
one main number which rolled over to 5 other lines) would have been  
fine with a different user interface as long as we had some shorthand  
identifier to yell over the half walls in our office.  However, I can  
imagine that a lot gets lost in translation from the end-user, to a  
group that does purchasing, to the distributor, to the vendor.  I can  
believe the distributor telling the vendor, or the purchasing group  
telling the distributor that they need phones that act "just like this".

If you believe that emulating seizure is a requirement, then I think  
BFCP is a reasonable way to implement that feature.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 20 Mar 2008 08:08:25 -0700

On Mar 19, 2008, at 6:05 PM, Paul Kyzivat wrote:

> If multiple extensions can place outgoing calls from the same line,  
> then the line doesn't have "binary" status, so it can't be  
> indicated as active or not with a light. And you can't "conference  
> in" by picking up on the same line.
>
> "business process" around the specific way in which lines are  
> managed by the phones, and then be very upset if they can't get  
> that same user experience.

...and that upset "someone" may not be the actual end user.

> Now you can come up with some very nice UIs that provide better  
> user experience, if you have a suitable display instead of just a  
> bunch of lights. (E.g. an entry for the "number" (AOR that people  
> call), and a variable length drop down list of active calls,  
> showing the callerid of the caller, how long it has been active,  
> and which extensions are currently connected to it.) But that is  
> *different*, and requires a device with richer UI.

my personal favorite UI for handling calls in the environment I  
described in my mail to Francois is that when I receive an incoming  
call for a specific person, I can single-step transfer the call to  
the personal parking lot of the person who should take the call.

thanks,
-rohan

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Mar 2008 15:38:19 +0000

Catching up on this whole thread, it seems to me that the discussion
revolves around two aspects: "shout-control" and "line seizure".

For shout-control, I believe the proposal from Francois of using
separate AoRs, rather than a single AoR with multiple appearances, can
be made to work and can be mapped to current UI practices if that is
desired. Shortened forms of the AoR can be used to make them more
user-friendly.

For line seizure, I have to ask why is the IETF worried about this? I
just did an experiment on my desk SIP phone, and yes, I can obtain dial
tone, but all the time I have had the phone I don't recall using that
feature. I either select a number from my address book or pre-dial the
digits, and then I hit "go" (the way people have been doing it on cell
phones for the last decade or more). When I hit "go" my phone can choose
an AoR that is free, and that then gives me the "appearance number" that
I can shout across the room. There is, of course, a race condition,
whereby two phones hit "go" at the same time and attempt to use the same
AoR, or an incoming call arrives on that AoR at the same time as an
outgoing call. If you have some agent at the proxy policing the
one-call-per-AoR rule, it can reject an outgoing call request when the
race condition occurs and the UA can try again on a different AoR.

Defining new protocol just so that I can have this dial tone thing and
anchor my call to an appearance before I actually dial does not seem a
compelling feature to me. If it is really required, then what about an
empty INVITE request that somehow gets put into some wait state until a
complete INVITE request arrives? This would be rather like the horrible
overlap sending work-around from the days we were doing PSTN
interworking, but quite frankly dial tone is a PSTN thing.

John

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Rohan Mahy
> Sent: 20 March 2008 15:08
> To: Paul Kyzivat
> >> The reason why one wanted to "seize the line" for an 
> outgoing call  
> >> back then was

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Mar 2008 12:03:16 -0500

> There is a tradeoff...
> 
> If multiple extensions can place outgoing calls from the same 
> line, then the line doesn't have "binary" status, so it can't 
> be indicated as active or not with a light. And you can't 
> "conference in" by picking up on the same line.
> 
> While I am not into it myself, I can see how someone can 
> build a "business process" around the specific way in which 
> lines are managed by the phones, and then be very upset if 
> they can't get that same user experience.

Yeah, sure, it's doable. I do not believe that adding the concept
of a Line number to do this is required to do this, or even
desireable.

> Now you can come up with some very nice UIs that provide 
> better user experience, if you have a suitable display 
> instead of just a bunch of lights. (E.g. an entry for the 
> "number" (AOR that people call), and a variable length drop 
> down list of active calls, showing the callerid of the 
> caller, how long it has been active, and which extensions are 
> currently connected to it.) But that is *different*, and 
> requires a device with richer UI.

Agreed.

My point is that we shouldn't bastardize the protocol with all this
complex extra protocol (Line numbers, BFCP, NOTIFY/PUBLISH-storms, etc.)
just do do this.

The basic "single-lamp" based approach is doable without any of this.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Mar 2008 12:05:47 -0500

> my personal favorite UI for handling calls in the environment 
> I described in my mail to Francois is that when I receive an 
> incoming call for a specific person, I can single-step 
> transfer the call to the personal parking lot of the person 
> who should take the call.

Yeah exactly. You don't need BFCP for that.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Mar 2008 12:16:46 -0500

Bingo.

I agree with John 100%.

Aping legacy key systems (or PBXs) should really be a non-goal for BLISS.
It's a loosing battle.

"Equal" means they won't upgrade to SIP (and I'd argue that in fact, it
won't be "Equal" but "Almost-as-good"). We have to do "Better" if we want
to be successful.

> On Behalf Of Elwell, John
> Sent: Thursday, March 20, 2008 08:38
> To: Rohan Mahy; Paul Kyzivat
> Cc: [email-masked]
> Catching up on this whole thread, it seems to me that the 
> discussion revolves around two aspects: "shout-control" and 
> "line seizure".
> 
> For shout-control, I believe the proposal from Francois of 
> using separate AoRs, rather than a single AoR with multiple 
> appearances, can be made to work and can be mapped to current 
> UI practices if that is desired. Shortened forms of the AoR 
> can be used to make them more user-friendly.
> 
> For line seizure, I have to ask why is the IETF worried about 
> this? I just did an experiment on my desk SIP phone, and yes, 
> I can obtain dial tone, but all the time I have had the phone 
> I don't recall using that feature. I either select a number 
> from my address book or pre-dial the digits, and then I hit 
> "go" (the way people have been doing it on cell phones for 
> the last decade or more). When I hit "go" my phone can choose 
> an AoR that is free, and that then gives me the "appearance 
> number" that I can shout across the room. There is, of 
> course, a race condition, whereby two phones hit "go" at the 
> same time and attempt to use the same AoR, or an incoming 
> call arrives on that AoR at the same time as an outgoing 
> call. If you have some agent at the proxy policing the 
> one-call-per-AoR rule, it can reject an outgoing call request 
> when the race condition occurs and the UA can try again on a 
> different AoR.
> 
> Defining new protocol just so that I can have this dial tone 
> thing and anchor my call to an appearance before I actually 
> dial does not seem a compelling feature to me. If it is 
> really required, then what about an empty INVITE request that 
> somehow gets put into some wait state until a complete INVITE 
> request arrives? This would be rather like the horrible 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Rohan Mahy
> > >> limitation of the system.
> > >> outgoing call actually seems like a feature to me, not a 
> bug. Yet 
> > >> another reason why ditching the old key system is good.
> > >
> > > There is a tradeoff...
> > >
> > > then the line doesn't have "binary" status, so it can't 
> be indicated 
> > > as active or not with a light. And you can't "conference in" by 
> > > picking up on the same line.
> > >
> > > managed by the phones, and then be very upset if they 
> can't get that 
> > > same user experience.
> > 
> better user 
> > > experience, if you have a suitable display instead of 
> just a bunch 
> > > of lights. (E.g. an entry for the "number" (AOR that 
> people call), 
> > > and a variable length drop down list of active calls, showing the 
> > > callerid of the caller, how long it has been active, and which 
> > > extensions are currently connected to it.) But that is 
> *different*, 
> > call for a specific person, I can single-step transfer the 
> call to the 
> > personal parking lot of the person who should take the call.
> > 
> > thanks,
> > -rohan
> >

---

From: "Bill Mitchell" <[email-masked]>
Date: Thu, 20 Mar 2008 12:52:51 -0700

We've got a variety of options currently on the table. I'm going to take
a stab at enumerating them, without a discussion of their merits:

1A) Single AoR for the MLA Group. Clients send PUBLISH & compositor
sends NOTIFY
    to accomplish a bidirectional exchange of dialog state. Floor
control
    accomplished with separate mechanism (ie  BFCP)  between client & a
distinct
    floor control server

1B) Single AoR for the MLA Group. Compositor sends NOTIFY to inform
clients of
    dialog state.  Server is responsible for monitoring call activity
and
    composing dialog state. Floor control managed accomplished with
separate
    mechanism (ie  BFCP) between client & a distinct floor control
server

2) Single AoR for the MLA Group. Clients sends PUBLISH & Appearance
Agent sends
   NOTIFY for bidirectional exchange of dialog state with integrated 
   floor control  (this option is the current MLA draft)

3) Separate AoR for each appearance within the MLA group. Compositor
sends
   NOTIFY to inform clients of dialog state. Server responsible for
monitoring 
   call activity and composing dialog state. Floor control via an INVITE
based
   mechanism. 

4) "Alternative Features" - utilizing other features such as call
forking, 
   call park, and simple SUBSCRIBE/NOTIFY for dialog info, to provide
   similar or better end-user experience with alternative work flows
that
   do not require MLA.

Are there other options, or corrections to the above?

Along the same lines, I think it would be useful to define evaluation
criteria. Here's a first draft of a list

1) End-user experience across a variety of use cases
    - 3 use cases listed in the MLA draft.  Other suggestions welcome.
2) Resource requirements on client
3) Resource requirements on server
4) Efficiency & robustness of call flows

-Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Francois Audet
Sent: Thursday, March 20, 2008 10:17 AM
To: Elwell, John; Rohan Mahy; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [BLISS] MLA with Floor Control

Bingo.

I agree with John 100%.

Aping legacy key systems (or PBXs) should really be a non-goal for
BLISS.
It's a loosing battle.

"Equal" means they won't upgrade to SIP (and I'd argue that in fact, it
won't be "Equal" but "Almost-as-good"). We have to do "Better" if we
want
to be successful.

---

From: Venkatesh <[email-masked]>
Date: Thu, 20 Mar 2008 13:27:23 -0700

John:

The MLA call flow document accomplishes this by having the UA send out a
NOTIFY as against INVITE. This keeps the specifics of MLA in the State Agent
rather than needing changes in a proxy for originating call legs. Glare
conditions were resolved by making the State Agent reject a NOTIFY with a
4xx response. The main objection I've seen to the proposal has been that a
non 2xx response for a NOTIFY results in the UA terminating a subscription
per RFC 3265; where as we expect the subscription to continue for this
specific application.  RFC 3261 allows a UA to 'reject' a mid-call request
*without* altering the state of an established session. I would like to
propose that we consider incorporating the capability in the event
notification framework as well? If not for *all* responses, providing this
capability for a specific response code (say 491) would do the job as
well.... It would also enable MLA application providers to use existing
mechanisms to provide bulk of the functionality *and* allow "archaic"
providers to satisfy "archaic" customer requirements with out adding the
burden of having to implement new protocols.....

My 2 cents.

Venkatesh

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 20 Mar 2008 15:33:26 -0800 (PST)

Hi Venkatesh,

As I stated before, I don't think the "burden" of implementing BFCP is
especially large.  It is not like I suggested you implement MSRP or an
XCAP server or something like that.  BFCP is a small binary protocol like
STUN.  A phone that wants seizure behavior just needs to send FloorRequest
and FloorRelease messages and receive FloorStatus messages.

thanks,
-rohan

---

From: Venkatesh <[email-masked]>
Date: Thu, 20 Mar 2008 17:34:40 -0700

Rohan:

It is not just the simplicity of the implementation on the UA. From a
solution perspective (especially hosted), we would need to work with many
network elements (SIP aware Firewalls in the enterprise edge, SBC's and
such) to understand the new SDP attributes, pass thru' these messages across
a TCP connection correctly and such. This is where reusing existing
protocols helps quite a bit. I am sure when you get into the implementation
details one will have to worry about handling error conditions for yet
another protocol and such.....

We have had enough grief going thru' this process even with things like
REFER and/or Replaces that I am hesitant to simply write off this as an
insignificant effort.

Thanks
Venkatesh

at wants seizure behavior just needs to send FloorRequest

---

From: Venkatesh <[email-masked]>
Date: Thu, 20 Mar 2008 17:37:24 -0700

And I have not heard anything in the mailing list so far that says why
enabling 'leaving subscriptions active for a specific response code' to the
presence event framework is not a workable solution? Like I said earlier,
3261 by default requires UA's to keep sessions active for non 2xx responses
for "mid call requests". SUBSCRIBE establishes a dialog and NOTIFY's is a
"in dialog" request under the circumstances.

Venkatesh

On Thu, Mar 20, 2008 at 5:34 PM, Venkatesh <[email-masked]> wrote:

> > > On Thu, Mar 20, 2008 at 8:38 AM, Elwell, John <[email-masked]
> > >
> > > wrote:
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Mar 2008 00:15:45 -0400

I'm not promoting one way or the other. Ultimately people building 
products will build the functionality they think they need to sell their 
products. If people feel this is important then they will want a way to 
do it. If it isn't standard then it will be nonstandard.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 20 Mar 2008 21:47:37 -0700

Hi Venkatesh,

I doubt that any of these SBCs are going to handle the non-backwards  
compatible changes needed to RFC 3265 either.

There is no need to signal the BFCP in the SDP, just configure it.  
The far end is not interested in a session of audio + BFCP. BFCP is  
just used among phones. Phones which implement this seizure feature  
are exactly the ones who are likely to have all their phones on the  
same subnet.    Therefore there is no need for ICE.  There is no need  
for the SBCs to see what is going on with the BFCP as the floor  
control arbitration happens completely on a local subnet and really  
has nothing to do with SIP.

There are many people on the BLISS mailing list who don't even think  
we should be spending time defining a way to implement this MLA w/  
seizure feature.  While I certainly don't encourage vendors to go out  
and implement this user experience, I understand that there is some  
demand in the market and that one solution to the seizure problem is  
better than 10. I think it is appropriate to describe a recommended  
way to implement this feature in BLISS.

I have described a way to implement this feature that uses existing  
mechanisms, which is what BLISS should really be about (how to use  
existing mechanism).  Nobody has (yet) provided any technical  
argument that my proposed method will not work.  The barrier for  
implementing BFCP as I described is no worse than implementing STUN,  
which many, many vendors have implemented. Several people on the  
mailing list have pointed out technical flaws with the intended  
semantics of the PUBLISH-based approach.  You have an opportunity to  
just go implement something that will work.  I don't get it.

thanks,
-rohan

On Mar 20, 2008, at 5:34 PM, Venkatesh wrote:

> Rohan:
>
> It is not just the simplicity of the implementation on the UA. From  
> a solution perspective (especially hosted), we would need to work  
> with many network elements (SIP aware Firewalls in the enterprise  
> edge, SBC's and such) to understand the new SDP attributes, pass  
> thru' these messages across a TCP connection correctly and such.  
> This is where reusing existing protocols helps quite a bit. I am  
> sure when you get into the implementation details one will have to  
> worry about handling error conditions for yet another protocol and  
> such.....
>
> We have had enough grief going thru' this process even with things  
> like REFER and/or Replaces that I am hesitant to simply write off  
> this as an insignificant effort.
>
> Thanks
> Venkatesh
>
> > NOTIFY as against INVITE. This keeps the specifics of MLA in the  
> State
> > Agent
> discussion
> this? I
> number" that
> when the
> thing and
> build a
> call to

---

From: Venkatesh <[email-masked]>
Date: Thu, 20 Mar 2008 21:48:31 -0700

I don't disagree with your argument. However, I also think, should a
particular approach unduly complicate implementation of a feature
(especially require support from multiple network elements for a feature to
work), vendors are going to resort to non standard ways to implement the
feature as well......

Venkatesh

---

From: Venkatesh <[email-masked]>
Date: Thu, 20 Mar 2008 22:24:06 -0700

Rohan:

I am talking about a hosted deployment model where all the phones in an
enterprise (or business phone service for an employee that has a home
office) are controlled by a application in the service provider. I am not
sure your argument about all phones being on the same subnet is valid in
this set up. I am also not sure about your comparison of STUN with BFCP. I
assume one would have to implement RFC 4583 in order to use this with SIP
and this needs all intermediate network elements requiring to implement this
capability where as basic STUN is UA centric (of course uses a STUN server
somewhere in the cloud but this message is not even seen by any intermediate
SIP entity) but again has nothing to do with core SIP.

The whole discussion about using 'an' approach for line seizure assumes that
there is enough interest in providing such a mechanism. If the BLISS WG so
decides this is unimportant, this whole discussion is not required.

Finally, I am not sure that the NOTIFY based approach suffers from the same
semantic issues as those outlined for the PUBLISH based approach. I did a
superficial search on the web for the limitations but couldn't find any. I
assume there have been discussions in the IETF meetings and would appreciate
any pointers to such a discussion.

Thanks
Venkatesh

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 21 Mar 2008 10:46:34 -0400

I basically agree with Paul.  Because there was a market need for the
functionality, various non standard mechanisms have been developed to
address the need until a standardized mechanism becomes available.

If the working group does not think there is need for a standardized
solution, so be it.  However vendors which don't like the non standard
mechanisms or haven't yet implemented the common ones would likely
desire the work to continue.

> On Behalf Of Paul Kyzivat
> Sent: Friday, March 21, 2008 12:16 AM
> To: Francois Audet
> I'm not promoting one way or the other. Ultimately people 
> building products will build the functionality they think 
> they need to sell their products. If people feel this is 
> important then they will want a way to do it. If it isn't 
> standard then it will be nonstandard.
> 
> 	Paul
> 
> Francois Audet wrote:
> >  
> > 
> >> There is a tradeoff...
> >>
> indicated 
> >> "business process" around the specific way in which lines 
> are managed 
> >> by the phones, and then be very upset if they can't get that same 
> >> user experience.
> > 
> > Yeah, sure, it's doable. I do not believe that adding the 
> concept of a 
> > Line number to do this is required to do this, or even desireable.
> > 
> >> variable length drop down list of active calls, showing 
> the callerid 
> >> of the caller, how long it has been active, and which 
> extensions are 
> > complex extra protocol (Line numbers, BFCP, NOTIFY/PUBLISH-storms, 
> > etc.) just do do this.
> >

---

From: [email-masked]
Date: Fri, 21 Mar 2008 10:15:26 -0500

From: "Francois Audet" <[email-masked]>

Everyone I've talked to in our company who talks to customers about
what they want says that "Hey, Joe, pick up on line 3!" is a primary
customer demand.  So I suspect that if we want to *sell* our product,
it had better allow this operation in some way or another.

Once the current release of SIPxchange gets out the door, my next task
is designing our MLA implementation.  It's going to be interesting,
because there seem to be 4 different MLA systems:

    draft-anil-sipping-bla-03
    draft-anil-sipping-bla-04
    Broadsoft
    whatever Bliss comes up with

I can assure you that "Hey, Joe, pick up on line 3!" will be
implemented.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 21 Mar 2008 10:44:44 -0500

The real question is "should we do line seizing before call setup" as a worthwile feature.
 
I think "No".
 
If the group feels "Yes", then we could look at BFCP. I really think we should not be stupid enough to make this mandatory.

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Thursday, March 20, 2008 21:49
	To: Paul Kyzivat
	Cc: Audet, Francois (SC100:3055); Rohan Mahy; [email-masked]
	Subject: Re: [BLISS] MLA with Floor Control

	I don't disagree with your argument. However, I also think, should a particular approach unduly complicate implementation of a feature (especially require support from multiple network elements for a feature to work), vendors are going to resort to non standard ways to implement the feature as well......
	
	Venkatesh

		
		       Paul

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 21 Mar 2008 08:49:00 -0700

On Mar 20, 2008, at 10:24 PM, Venkatesh wrote:

> Rohan:
>
> I am talking about a hosted deployment model where all the phones  
> in an enterprise (or business phone service for an employee that  
> has a home office) are controlled by a application in the service  
> provider. I am not sure your argument about all phones being on the  
> same subnet is valid in this set up. I am also not sure about your  
> comparison of STUN with BFCP. I assume one would have to implement  
> RFC 4583 in order to use this with SIP

No.  there is no reason you would want/need to do this at all.  Each  
of the phones are configured to contact the BFCP server completely  
orthogonal of when SIP signaling is exchanged.

thanks,
-rohan

> and this needs all intermediate network elements requiring to  
> implement this capability where as basic STUN is UA centric (of  
> course uses a STUN server somewhere in the cloud but this message  
> is not even seen by any intermediate SIP entity) but again has  
> nothing to do with core SIP.
>
> The whole discussion about using 'an' approach for line seizure  
> assumes that there is enough interest in providing such a  
> mechanism. If the BLISS WG so decides this is unimportant, this  
> whole discussion is not required.
>
> Finally, I am not sure that the NOTIFY based approach suffers from  
> the same semantic issues as those outlined for the PUBLISH based  
> approach. I did a superficial search on the web for the limitations  
> but couldn't find any. I assume there have been discussions in the  
> IETF meetings and would appreciate any pointers to such a discussion.
>
> Thanks
> Venkatesh
>
> can't get
> better

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Fri, 21 Mar 2008 11:08:58 -0500

I agree, NO

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Francois Audet
Sent: Friday, March 21, 2008 11:45 AM
To: Venkatesh; Paul Kyzivat
Cc: Rohan Mahy; [email-masked]
Subject: Re: [BLISS] MLA with Floor Control

The real question is "should we do line seizing before call setup" as a
worthwile feature.
 
I think "No".
 
If the group feels "Yes", then we could look at BFCP. I really think we
should not be stupid enough to make this mandatory.

	I don't disagree with your argument. However, I also think,
should a particular approach unduly complicate implementation of a
feature (especially require support from multiple network elements for a
feature to work), vendors are going to resort to non standard ways to
implement the feature as well......
	
	Venkatesh

	On Thu, Mar 20, 2008 at 9:15 PM, Paul Kyzivat
<[email-masked]> wrote:

		I'm not promoting one way or the other. Ultimately
people building
		products will build the functionality they think they
need to sell their
		products. If people feel this is important then they
will want a way to
		do it. If it isn't standard then it will be nonstandard.
		
		       Paul

---

From: "Bill Mitchell" <[email-masked]>
Date: Fri, 21 Mar 2008 11:58:13 -0700

My answer is YES.  Line seizing before call setup is worthwhile, because
it enables shout control with a **reasonable end-user experience**.

Line seizing post-call-setup is NOT worthwhile.  It only adds confusion
with potential mid or post-dial line key hopping.

Pre-call-setup line seizure can be optional.  

BFCP has the right primitives, but I firmly agree with Venkatesh that it
adds significant network complexity and would be a large barrier for
implementation.  I'll add my vote for a SIP-based mechanism to
communicate line seize requests and responses.

-Bill

From: [email-masked] [mailto:[email-masked]] On Behalf
Of DOLLY, MARTIN C, ATTLABS
Sent: Friday, March 21, 2008 9:09 AM
To: Francois Audet; Venkatesh; Paul Kyzivat
Cc: Rohan Mahy; [email-masked]
Subject: Re: [BLISS] MLA with Floor Control

I agree, NO

I think "No".

	

	
	Venkatesh

	I'm not promoting one way or the other. Ultimately people
building
	products will build the functionality they think they need to
sell their
	products. If people feel this is important then they will want a
way to
	do it. If it isn't standard then it will be nonstandard.
	
	       Paul

	> Yeah, sure, it's doable. I do not believe that adding the
concept

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 21 Mar 2008 14:15:13 -0500

It's not POST call-setup. It's AT call setup.
 
It's the difference between:
 
Line seisure by pressing key

*	
	User press Line appearance. This is reported to Presence/Dialog server. PUBLISH or BFCP.
*	
	Presence/dialog for that line goes "busy" right away, for anybody that sees it
*	
	Nobody can use that line regardless of how long it takes the user to dial

Line seisure at call setup

*	
	User press Line appearance. This is local: no reporting anywhere.
*	
	Nothing changes anywhere 
*	
	Line is "seized" when the call is actually made
*	
	In the interim between pressing the key, somebody else could also press the key and make a call. If he's faster, he'll be able to seize the line before the first guy.

Besides the mind-numbing complexity of doing the first approach, there are also advantages to the second approach. It avoids the problem of having somebody "hogging" the line by pressing on the key and not dialling anybody.
 
And frankly, the SIP mechanism to "arbitrate" the line-seisure-by-pressing-an-appearance will by definition be very complicated and generate lots of traffic. I don't be believe it will be simpler than BFCP.
 
Furthermore, there will be lots of potential for race condidtions (while the NOTIFYs and PUBLISH are flying all over the place). This will result in very poor user experience. Basically, pressing on the button will often "not work". (I have a vision of pissed-off users repeatedly pressing the key that doesn't want to turn on, and banging on their sets).
 
The second option, with line seisure at call setup does not suffer from this problem. The expectation is that the line is "taken" when you actually make the call, not when you press the button.
 
I will point out that PBXs (as opposed to key systems) often work the second way, not the first way.
 
This is all very similar to arbitrating between making an outgoing call and receiving an incoming one while dialing.

	From: Bill Mitchell [mailto:[email-masked]] 
	Sent: Friday, March 21, 2008 11:58
	To: DOLLY, MARTIN C, ATTLABS
	Cc: [email-masked]; Audet, Francois (SC100:3055); [email-masked]
	Subject: RE: [BLISS] MLA with Floor Control

	My answer is YES.  Line seizing before call setup is worthwhile, because it enables shout control with a **reasonable end-user experience**.

	Line seizing post-call-setup is NOT worthwhile.  It only adds confusion with potential mid or post-dial line key hopping.

	 

	BFCP has the right primitives, but I firmly agree with Venkatesh that it adds significant network complexity and would be a large barrier for implementation.  I'll add my vote for a SIP-based mechanism to communicate line seize requests and responses.

	-Bill

	From: [email-masked] [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C, ATTLABS

	I agree, NO

	I think "No".

		

		
		Venkatesh

		
		       Paul

---

From: Venkatesh <[email-masked]>
Date: Fri, 21 Mar 2008 12:51:39 -0700

Francois:

I am not sure about additional complexity with using SIP as the mechanism
and resulting in PUBLISH/NOTIFY flying all over the place. All the draft was
proposing is that the UA send a NOTIFY indicating that it is going to place
a call using a specific line *before* sending out the actual INVITE. This
NOTIFY would have gotten sent by the UA anyway post dialing. The draft is
just moving the position of when the NOTIFY gets sent out. From an end user
perspective, when a user dials a number, he/she would simply see that it is
'attempting' to use a specific line appearance when the call is placed. If
there is no contention for that specific line, call proceeds fine. If the
NOTIFY is rejected, the line goes busy and user is provided a fast busy.

Thanks
Venkatesh

On Fri, Mar 21, 2008 at 12:15 PM, Francois Audet <[email-masked]> wrote:

>    - User press Line appearance. This is reported to Presence/Dialog
>    server. PUBLISH or BFCP.
>    - Presence/dialog for that line goes "busy" right away, for anybody
>    that sees it
>    - Nobody can use that line regardless of how long it takes the user
>    to dial
>
>    - User press Line appearance. This is local: no reporting anywhere.
>    - Nothing changes anywhere
>    - Line is "seized" when the call is actually made
>    - In the interim between pressing the key, somebody else could also
>    press the key and make a call. If he's faster, he'll be able to seize the
>    line before the first guy.
>
> Besides the mind-numbing complexity of doing the first approach, there are
> also advantages to the second approach. It avoids the problem of having
> somebody "hogging" the line by pressing on the key and not dialling anybody.
>
> And frankly, the SIP mechanism to "arbitrate" the
> line-seisure-by-pressing-an-appearance will by definition be very
> complicated and generate lots of traffic. I don't be believe it will be
> simpler than BFCP.
>
> Furthermore, there will be lots of potential for race condidtions (while
> the NOTIFYs and PUBLISH are flying all over the place). This will result in
> very poor user experience. Basically, pressing on the button will often "not
> work". (I have a vision of pissed-off users repeatedly pressing the key that
> doesn't want to turn on, and banging on their sets).
>
> The second option, with line seisure at call setup does not suffer from
> this problem. The expectation is that the line is "taken" when you actually
> make the call, not when you press the button.
>
> This is all very similar to arbitrating between making an outgoing call
> and receiving an incoming one while dialing.
>
>  ------------------------------
> *From:* Bill Mitchell [mailto:[email-masked]]
> *Sent:* Friday, March 21, 2008 11:58
> *To:* DOLLY, MARTIN C, ATTLABS
> *Cc:* [email-masked]; Audet, Francois (SC100:3055); [email-masked]
> *Subject:* RE: [BLISS] MLA with Floor Control
>
> implementation.  I'll add my vote for a SIP-based mechanism to communicate
> line seize requests and responses.
>
>
>
> -Bill
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *DOLLY, MARTIN C, ATTLABS
> *Sent:* Friday, March 21, 2008 9:09 AM
> *To:* Francois Audet; Venkatesh; Paul Kyzivat
> *Cc:* Rohan Mahy; [email-masked]
> *Subject:* Re: [BLISS] MLA with Floor Control
>
>
>
> I agree, NO
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Francois Audet
> *Sent:* Friday, March 21, 2008 11:45 AM
> *To:* Venkatesh; Paul Kyzivat
> *Cc:* Rohan Mahy; [email-masked]
> *Subject:* Re: [BLISS] MLA with Floor Control
>
>  ------------------------------
>
> *From:* Venkatesh [mailto:[email-masked]]
> *Sent:* Thursday, March 20, 2008 21:49
> *To:* Paul Kyzivat
> *Cc:* Audet, Francois (SC100:3055); Rohan Mahy; [email-masked]
> *Subject:* Re: [BLISS] MLA with Floor Control
>

---

From: "Bill Mitchell" <[email-masked]>
Date: Fri, 21 Mar 2008 12:55:14 -0700

Completely agree that line seizure upon line-key-selection is complex,
but the idea behind line seizure over SIP was to minimize complexity.
We've heard that customers want the functionality for shout control.
And issues like line key hogging can be addressed with a proper
implementation.

My terminology wasn't quite right. I should have said  "Line seizure
post-line-key-selection" is not worthwhile. If the client is going to
render a UI based on the line #, for purposes of shout-control, then
"Line Key Hopping" will occur. When a user has selected a line key and
is dialing, an Inbound call will force a change in line key usage, as
will an outbound call placed from a different phone.  I see this as
unacceptable to most users.

From: Francois Audet [mailto:[email-masked]] 
Sent: Friday, March 21, 2008 12:15 PM
To: Bill Mitchell; DOLLY, MARTIN C, ATTLABS
Cc: [email-masked]; [email-masked]
Subject: RE: [BLISS] MLA with Floor Control

*	User press Line appearance. This is reported to Presence/Dialog
server. PUBLISH or BFCP.
*	Presence/dialog for that line goes "busy" right away, for
anybody that sees it
*	Nobody can use that line regardless of how long it takes the
user to dial

*	User press Line appearance. This is local: no reporting
anywhere.
*	Nothing changes anywhere 
*	Line is "seized" when the call is actually made
*	In the interim between pressing the key, somebody else could
also press the key and make a call. If he's faster, he'll be able to
seize the line before the first guy.

Besides the mind-numbing complexity of doing the first approach, there
are also advantages to the second approach. It avoids the problem of
having somebody "hogging" the line by pressing on the key and not
dialling anybody.

Furthermore, there will be lots of potential for race condidtions (while
the NOTIFYs and PUBLISH are flying all over the place). This will result
in very poor user experience. Basically, pressing on the button will
often "not work". (I have a vision of pissed-off users repeatedly
pressing the key that doesn't want to turn on, and banging on their
sets).

The second option, with line seisure at call setup does not suffer from
this problem. The expectation is that the line is "taken" when you
actually make the call, not when you press the button.

I will point out that PBXs (as opposed to key systems) often work the
second way, not the first way.

	

	Cc: [email-masked]; Audet, Francois (SC100:3055);
[email-masked]

	My answer is YES.  Line seizing before call setup is worthwhile,
because it enables shout control with a **reasonable end-user
experience**.

	Line seizing post-call-setup is NOT worthwhile.  It only adds
confusion with potential mid or post-dial line key hopping.

	 

	BFCP has the right primitives, but I firmly agree with Venkatesh
that it adds significant network complexity and would be a large barrier
for implementation.  I'll add my vote for a SIP-based mechanism to
communicate line seize requests and responses.

	-Bill

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of DOLLY, MARTIN C, ATTLABS
	Sent: Friday, March 21, 2008 9:09 AM
	To: Francois Audet; Venkatesh; Paul Kyzivat
	Cc: Rohan Mahy; [email-masked]
	Subject: Re: [BLISS] MLA with Floor Control

	I agree, NO

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Francois Audet

	The real question is "should we do line seizing before call
setup" as a worthwile feature.

	I think "No".

	If the group feels "Yes", then we could look at BFCP. I really
think we should not be stupid enough to make this mandatory.

		From: Venkatesh [mailto:[email-masked]] 
		Sent: Thursday, March 20, 2008 21:49
		To: Paul Kyzivat
		Cc: Audet, Francois (SC100:3055); Rohan Mahy;
[email-masked]
		Subject: Re: [BLISS] MLA with Floor Control

		I don't disagree with your argument. However, I also
think, should a particular approach unduly complicate implementation of
a feature (especially require support from multiple network elements for
a feature to work), vendors are going to resort to non standard ways to
implement the feature as well......
		
		Venkatesh

		
		       Paul

---

From: "Raj Jain" <[email-masked]>
Date: Fri, 21 Mar 2008 16:11:13 -0400

On Fri, Mar 21, 2008 at 2:58 PM, Bill Mitchell
<[email-masked]> wrote:
> My answer is YES.  Line seizing before call setup is worthwhile, because it
> enables shout control with a **reasonable end-user experience**.

I agree. My employer builds key telephone systems for large financial
trading floors. We live and breathe shared lines. My answer is also
YES. In many cases these lines are private wires in which case there
is no dialing involved. You simply seize the line and start talking.
The first person who seizes the line wins the line.

-- 
Raj Jain

>
>
>
> Line seizing post-call-setup is NOT worthwhile.  It only adds confusion with
> potential mid or post-dial line key hopping.
>
>
>
>
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 21 Mar 2008 15:19:53 -0500

I really believe that this whole idea of "line seizure" is completely out-of-line with the SIP model.
 
If we do something like that, we are completely changing the nature of SIP and making it a stimulus control protocol like MGCP (or the old proprietary Phone control protocols used by many vendors, including my employer).
 
If we go in that direction, we would need to redefine what "on the phone" means, so that instead of "in a session", it would mean "off-hook". Every single INVITE would now be preceded by a PUBLISH of some "off-hook" status. This would not only hamper significantly scalability of SIP, but would make it a different protocol.
 
What's next? Cursor control? Bitmap screen control?
 
If one wants a blast from the past with these types of features, one should stick with protocols from the past. 
 
I am completely opposed to changing SIP to be a stimulus protocol.

	From: Bill Mitchell [mailto:[email-masked]] 
	Sent: Friday, March 21, 2008 12:55
	To: Audet, Francois (SC100:3055)
	Cc: [email-masked]
	Subject: RE: [BLISS] MLA with Floor Control

	Completely agree that line seizure upon line-key-selection is complex, but the idea behind line seizure over SIP was to minimize complexity.  We've heard that customers want the functionality for shout control.  And issues like line key hogging can be addressed with a proper implementation.

	My terminology wasn't quite right. I should have said  "Line seizure post-line-key-selection" is not worthwhile. If the client is going to render a UI based on the line #, for purposes of shout-control, then "Line Key Hopping" will occur. When a user has selected a line key and is dialing, an Inbound call will force a change in line key usage, as will an outbound call placed from a different phone.  I see this as unacceptable to most users.

	*	User press Line appearance. This is reported to Presence/Dialog server. PUBLISH or BFCP. 
	*	Presence/dialog for that line goes "busy" right away, for anybody that sees it 
	*	Nobody can use that line regardless of how long it takes the user to dial 

	*	User press Line appearance. This is local: no reporting anywhere. 
	*	Nothing changes anywhere 
	*	Line is "seized" when the call is actually made 
	*	In the interim between pressing the key, somebody else could also press the key and make a call. If he's faster, he'll be able to seize the line before the first guy. 

		

		 

		 

		-Bill

		I agree, NO

		I think "No".

			

			
			Venkatesh

			
			       Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 21 Mar 2008 15:23:05 -0500

> Everyone I've talked to in our company who talks to customers 
> about what they want says that "Hey, Joe, pick up on line 3!" 
> is a primary customer demand.  So I suspect that if we want 
> to *sell* our product, it had better allow this operation in 
> some way or another.

This is easily doable with SIP without anything special.

If it is a ringing call, you just select the appearance and pick 
the handset. Your UA will just send a 200 OK.

If it's a "parked call" on line one, you just select the appearance.
The UA would then use the Call Retrieve (see Call Park BLISS draft) to
get that call.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Venkatesh <[email-masked]>
Date: Fri, 21 Mar 2008 13:34:59 -0700

Francois:

The dialog state RFC 4325 specifically provides a "trying" state to indicate
a state where a call is about to be initiated. We are simply using this
state to indicate origination of a new call request.

Thanks
Venkatesh

On Fri, Mar 21, 2008 at 1:19 PM, Francois Audet <[email-masked]> wrote:

> If we do something like that, we are completely changing the nature of SIP
> and making it a stimulus control protocol like MGCP (or the old proprietary
> Phone control protocols used by many vendors, including my employer).
>
> If we go in that direction, we would need to redefine what "on the phone"
> means, so that instead of "in a session", it would mean "off-hook". Every
> single INVITE would now be preceded by a PUBLISH of some "off-hook" status.
> This would not only hamper significantly scalability of SIP, but would make
> it a different protocol.
>
> If one wants a blast from the past with these types of features, one
> should stick with protocols from the past.
>
> *Sent:* Friday, March 21, 2008 12:55
> *To:* Audet, Francois (SC100:3055)
> *Cc:* [email-masked]
>
> but the idea behind line seizure over SIP was to minimize complexity.  We've
> heard that customers want the functionality for shout control.  And issues
> like line key hogging can be addressed with a proper implementation.
>
>
>
> post-line-key-selection" is not worthwhile. If the client is going to render
> a UI based on the line #, for purposes of shout-control, then "Line Key
> Hopping" will occur. When a user has selected a line key and is dialing, an
> Inbound call will force a change in line key usage, as will an outbound call
> placed from a different phone.  I see this as unacceptable to most users.
>
>
> *From:* Francois Audet [mailto:[email-masked]]
> *Sent:* Friday, March 21, 2008 12:15 PM
> *To:* Bill Mitchell; DOLLY, MARTIN C, ATTLABS
> *Cc:* [email-masked]; [email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 21 Mar 2008 15:39:25 -0500

The trying state in RFC 4235 is ok (that's after the INVITE). No ptoblems there.
 
It's the line seize BEFORE sending an INVITE that is a problem.

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Friday, March 21, 2008 13:35
	To: Audet, Francois (SC100:3055)
	Cc: Bill Mitchell; [email-masked]
	Subject: Re: [BLISS] MLA with Floor Control

	Francois:
	
	The dialog state RFC 4325 specifically provides a "trying" state to indicate a state where a call is about to be initiated. We are simply using this state to indicate origination of a new call request.
	
	Thanks
	Venkatesh

		 

		 

			

			Cc: [email-masked] 

			

				

				 

				 

				-Bill

				I agree, NO

				I think "No".

					

					
					Venkatesh

					
					       Paul

---

From: Venkatesh <[email-masked]>
Date: Fri, 21 Mar 2008 13:55:51 -0700

Section 6.2 of this RFC specifically provides for a UA to advertise this
state "prior" to sending the INVITE. I have cut and pasted the relevant
verbiage from 4235 for your perusal.

"The following example shows how a SIP telephone user agent can provide
detailed state information and also emulate a shared-line telephone system
(the phone "lies" about having a dialog while it is merely offhook).

The MLA draft pretty much uses the same.

Thanks
Venkatesh

On Fri, Mar 21, 2008 at 1:39 PM, Francois Audet <[email-masked]> wrote:

> *Sent:* Friday, March 21, 2008 13:35
> *Cc:* Bill Mitchell; [email-masked]
>
> The dialog state RFC 4325 specifically provides a "trying" state to
> indicate a state where a call is about to be initiated. We are simply using
> this state to indicate origination of a new call request.
>
> Thanks
> Venkatesh
>
> > If we do something like that, we are completely changing the nature of
> > SIP and making it a stimulus control protocol like MGCP (or the old
> > proprietary Phone control protocols used by many vendors, including my
> > employer).
> >
> > If we go in that direction, we would need to redefine what "on the
> > phone" means, so that instead of "in a session", it would mean "off-hook".
> > Every single INVITE would now be preceded by a PUBLISH of some "off-hook"
> > status. This would not only hamper significantly scalability of SIP, but
> > would make it a different protocol.
> >
> >    Completely agree that line seizure upon line-key-selection is
> > complex, but the idea behind line seizure over SIP was to minimize
> > complexity.  We've heard that customers want the functionality for shout
> > control.  And issues like line key hogging can be addressed with a proper
> > implementation.
> >
> >
> >
> >    - Presence/dialog for that line goes "busy" right away, for
> >    anybody that sees it
> >    - Nobody can use that line regardless of how long it takes the
> >    user to dial
> >
> >    - In the interim between pressing the key, somebody else could
> >    also press the key and make a call. If he's faster, he'll be able to seize
> >    the line before the first guy.
> >
> > are also advantages to the second approach. It avoids the problem of having
> > *From:* [email-masked] [mailto:[email-masked]] *On
> > Behalf Of *DOLLY, MARTIN C, ATTLABS
> > *From:* [email-masked] [mailto:[email-masked]] *On
> > Behalf Of *Francois Audet
> > etc.)

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 21 Mar 2008 17:09:44 -0500

Yeah, sure "lying" (as it says) about being a dialog to emulate a "shared line" as described in the dialog package: is legal. If you want to do it, fine with me. I maintain that it's incredibly retrograde, but it's fine with me if a phone wants to do this.
 
I do not want the MLA feature to depend on this. I don't even think it should describe this sort of stuff. People are free to do this, but it shouldn't affect the feature operation.

	Sent: Friday, March 21, 2008 13:56

	Section 6.2 of this RFC specifically provides for a UA to advertise this state "prior" to sending the INVITE. I have cut and pasted the relevant verbiage from 4235 for your perusal.
	
	"The following example shows how a SIP telephone user agent can provide detailed state information and also emulate a shared-line telephone system (the phone "lies" about having a dialog while it is merely offhook).

	Thanks
	Venkatesh

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 21 Mar 2008 17:47:06 -0800 (PST)

Hi Venkatesh,

Phone1, Phone2, and Phone3 all share a line using your proposed scheme.
Phone1 and Phone2 both try to seize at about the same time, but Phone1 is
slightly faster.

Lets see what happens in two cases.  First with a state agent:

The NOTIFY from Phone1 is "accepted".

The NOTIFY from Phone 2 is rejected, and according to RFC 3265, the dialog
terminates.  Oops.

Now lets try this with a mesh of dialogs among the three phones.  This is
even worse as you have no idea whether Phone3 will accept the dialog
update from Phone1 or from Phone2.

State agents aren't supposed to change the semantics of the event package
and I think this demonstrates that the proposed package does.

thanks,
-rohan

>> are
>> in
>> actually
>> because
>> Behalf

---

From: Venkatesh <[email-masked]>
Date: Sat, 22 Mar 2008 00:08:02 -0700

Hi Rohan:

Technically speaking, per section 3.2.2 of RFC 3265, a non 2xx response that
has a Retry-After header  is not considered a "Failed" and thus should not
terminate the subscription at the UA....... .  This is what the MLA draft is
currently using... But I would prefer to have a specific response code
instead of relying on this definition. It is what I have been requesting in
the mailing list as well...

I am not sure there is a simple solution that would allow a mesh
configuration of phones to work when you need line seizure acknowledgment.
Either proposal (BFCP or NOTIFY) relies on having a central arbitrator to
simplify the solution.

Thanks
Venkatesh

On Fri, Mar 21, 2008 at 6:47 PM, Rohan Mahy <[email-masked]> wrote:

> >>    press the key and make a call. If he's faster, he'll be able to
> seize
> >> the
> >> (especially require support from multiple network elements for a
> feature
> >> to

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 22 Mar 2008 10:40:41 -0500

Again, you can do shout control without "reporting" pressing a key.
 
You just shout "take the line" and the guy answers the phone (or retrieve the parked call).
 
It's the changing of the SIP model to introduce a pre-call seizing that bothers me greatly.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bill Mitchell
	Sent: Friday, March 21, 2008 12:55
	To: Audet, Francois (SC100:3055)
	Cc: [email-masked]
	Subject: Re: [BLISS] MLA with Floor Control

	

		

		 

		 

		-Bill

		I agree, NO

		I think "No".

			

			
			Venkatesh

			
			       Paul

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 22 Mar 2008 10:41:24 -0500

Again, that is fine with me.
 
It's the seizure control before the actual call that bothers me greatly.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Venkatesh
	Sent: Friday, March 21, 2008 13:56
	To: Audet, Francois (SC100:3055)
	Cc: [email-masked]
	Subject: Re: [BLISS] MLA with Floor Control

	
	
	Thanks
	Venkatesh

		 

			

			Francois:

			Thanks
			Venkatesh

				 

				 

					

					Cc: [email-masked] 

					

					

					 

					 

					-Bill

					I agree, NO

					I think "No".

					

					
					Venkatesh

					
					       Paul

---

From: Venkatesh <[email-masked]>
Date: Sat, 22 Mar 2008 11:10:41 -0700

Francois:

May be I am missing your point but if there are say 3 calls for the MLA
group that have been put on hold, what does "the" refer to in "take the
line"?

Venkatesh

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 23 Mar 2008 13:24:55 -0500

It takes the specific held call held against the AOR.

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Saturday, March 22, 2008 11:11
	To: Audet, Francois (SC100:3055)
	Cc: ext Bill Mitchell; [email-masked]
	Subject: Re: [BLISS] MLA with Floor Control

	Francois:
	
	May be I am missing your point but if there are say 3 calls for the MLA group that have been put on hold, what does "the" refer to in "take the line"?
	
	Venkatesh

---

From: "Fernando Lombardo" <[email-masked]>
Date: Mon, 24 Mar 2008 18:48:02 -0000

Jumping in...
Consider the following environment: An enterprise with a hosted PBX
service that doesn't allow anything out of their network but ports 80,
443 and 5060 (UDP). Everything else is disallowed. They are heavy SCA
users. Their endpoints only do UDP, no TCP (because they purchased them
a while back and UDP was the norm). Furthermore, the endpoint already
supports NOTIFY/PUBLISH/events. 
How can MLA using BFCP (for this particular REQ) work in this
environment?

-fernando

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rohan Mahy
Sent: Friday, March 21, 2008 8:47 PM
To: Venkatesh
Cc: [email-masked]; [email-masked]
Subject: Re: [BLISS] MLA with Floor Control

Hi Venkatesh,

Phone1, Phone2, and Phone3 all share a line using your proposed scheme.
Phone1 and Phone2 both try to seize at about the same time, but Phone1
is slightly faster.

The NOTIFY from Phone 2 is rejected, and according to RFC 3265, the
dialog terminates.  Oops.

Now lets try this with a mesh of dialogs among the three phones.  This
is even worse as you have no idea whether Phone3 will accept the dialog
update from Phone1 or from Phone2.

State agents aren't supposed to change the semantics of the event
package and I think this demonstrates that the proposed package does.

thanks,
-rohan

> Francois:
>
> I am not sure about additional complexity with using SIP as the 
> mechanism and resulting in PUBLISH/NOTIFY flying all over the place. 
> All the draft was proposing is that the UA send a NOTIFY indicating 
> that it is going to place a call using a specific line *before* 
> sending out the actual INVITE. This NOTIFY would have gotten sent by 
> the UA anyway post dialing. The draft is just moving the position of 
> when the NOTIFY gets sent out. From an end user perspective, when a 
> user dials a number, he/she would simply see that it is 'attempting' 
> to use a specific line appearance when the call is placed. If there is

> no contention for that specific line, call proceeds fine. If the 
anybody
>>    - Nobody can use that line regardless of how long it takes the
user
>>    - In the interim between pressing the key, somebody else could
also
>> Besides the mind-numbing complexity of doing the first approach, 
>> there are also advantages to the second approach. It avoids the 
>> problem of having somebody "hogging" the line by pressing on the key 
>> and not dialling anybody.
>>
>> complicated and generate lots of traffic. I don't be believe it will 
>> be simpler than BFCP.
>>
>> Furthermore, there will be lots of potential for race condidtions 
>> (while the NOTIFYs and PUBLISH are flying all over the place). This 
>> will result in very poor user experience. Basically, pressing on the 
>> button will often "not work". (I have a vision of pissed-off users 
>> repeatedly pressing the key that doesn't want to turn on, and banging

>> on their sets).
>>
>> The second option, with line seisure at call setup does not suffer 
>> from this problem. The expectation is that the line is "taken" when 
>> you actually make the call, not when you press the button.
>>

>> This is all very similar to arbitrating between making an outgoing 
>> call and receiving an incoming one while dialing.
>>
>> BFCP has the right primitives, but I firmly agree with Venkatesh that

>> it adds significant network complexity and would be a large barrier 
>> The real question is "should we do line seizing before call setup" as

>> a worthwile feature.
>>
>>
>>
>> I think "No".
>>
>>
>>
>> If the group feels "Yes", then we could look at BFCP. I really think 
>> we should not be stupid enough to make this mandatory.
>>
>>

>> products will build the functionality they think they need to sell 
>> their products. If people feel this is important then they will want 
>> a way to do it. If it isn't standard then it will be nonstandard.
>>
>>        Paul
>>
>>
>> Francois Audet wrote:
>> >
>> >
>> >> There is a tradeoff...
>> >>
>> >> line, then the line doesn't have "binary" status, so it can't be

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 24 Mar 2008 15:24:08 -0800 (PST)

Hi Fernando,

I do not find either of these arguments compelling.

- TCP transport has been MANDATORY to implement since RFC 3261 was
published in June of 2002.  If a vendor can't be bothered to implement a
mandatory feature of the core protocol, I don't see why they would bother
to follow the recommendations of the BLISS WG.

- The phone will need to implement some new at the application protocol
layer.  Whether this is a new SIP extension or a simple orthogonal
protocol should not be a significant difference in terms of time to
implement.  Certainly one of us could have implemented BFCP for this
purpose in the amount of time we have spent discussing this issue.

- While I would be surprised to find a business that has UDP port 5060
open that would not allow outgoing TCP, you could certainly configure BFCP
to use port 443.

thanks,
-rohan

---

From: "Fernando Lombardo" <[email-masked]>
Date: Tue, 25 Mar 2008 13:03:57 -0000

I'm just throwing out there a real deployment scenario, not making a
technical argument.
Thanks for your reply. More below...

> Sent: Monday, March 24, 2008 6:24 PM
> To: Fernando Lombardo
> - TCP transport has been MANDATORY to implement since RFC 
> 3261 was published in June of 2002.  If a vendor can't be 
> bothered to implement a mandatory feature of the core 
> protocol, I don't see why they would bother to follow the 
> recommendations of the BLISS WG.
Easy to understand. Feature support like this one is what makes the
sale, not which transport they use.

> 
> - The phone will need to implement some new at the 
> application protocol layer.  Whether this is a new SIP 
> extension or a simple orthogonal protocol should not be a 
> significant difference in terms of time to implement.  
> Certainly one of us could have implemented BFCP for this 
Yes, something new within the SIP realm and not some binary protocol
they never heard of.
> 
> - While I would be surprised to find a business that has UDP 
> port 5060 open that would not allow outgoing TCP, you could 
> certainly configure BFCP to use port 443.
Sure, this works if the enterprise is not doing packet inspection.

> > users. Their endpoints only do UDP, no TCP (because they purchased 
> > them a while back and UDP was the norm). Furthermore, the endpoint 
> > already supports NOTIFY/PUBLISH/events.
> > is even worse as you have no idea whether Phone3 will accept the 
> > dialog update from Phone1 or from Phone2.
> >
> >> to use a specific line appearance when the call is placed. 
> If there 
> >> is
> >
> >>> The real question is "should we do line seizing before 
> call setup" 
> >>> as
> >
> >>> a worthwile feature.
> >>>
> >>>
> >>>
> >>> I think "No".
> >>>
> >>>
> >>>
> think, should a 
> >>> feature to work), vendors are going to resort to non 
> standard ways 
> >>> to
> >
> need to sell

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 25 Mar 2008 08:11:49 -0700

> sale, not which transport they use.
Nearly every protocol contains features which may not be needed in  
every deployment.  The point is that there are sufficient good  
reasons to implement all the mandatory features of the protocol--in  
this case mainly interoperability and being able to reliably send and  
receive larger messages.

> Yes, something new within the SIP realm and not some binary protocol
Whether someone has heard of it or not is not the point.  If I sit  
down an average developer with the BFCP spec, and a few minutes on a  
whiteboard, he or she can implement this spec very quickly.

> Sure, this works if the enterprise is not doing packet inspection.
Packet inspection does not work over TLS encrypted links.

thanks,
-rohan

---

From: "Fernando Lombardo" <[email-masked]>
Date: Tue, 25 Mar 2008 15:52:27 -0000

So, I think I have the answer to my initial question. For this
environment now it is required:
-for endpoints to support tcp
-for endpoints and core network elements to support bfcp (by some
accounts easily done, but another thing to troubleshoot in the network)
-for endpoints and core network elements to support tls so that port 443
can be used by the enterprise.
-not to mention the SIP changes required to follow the recommendations
of the BLISS WG's MLA document.

Thanks,

-fernando

> Sent: Tuesday, March 25, 2008 10:12 AM
> To: Fernando Lombardo
> bothered to 
> >> implement a mandatory feature of the core protocol, I 
> don't see why 
> >> they would bother to follow the recommendations of the BLISS WG.
> Nearly every protocol contains features which may not be 
> needed in every deployment.  The point is that there are 
> sufficient good reasons to implement all the mandatory 
> features of the protocol--in this case mainly 
> interoperability and being able to reliably send and receive 
> larger messages.
> 
> >> - The phone will need to implement some new at the application 
> >> protocol layer.  Whether this is a new SIP extension or a simple 
> >> orthogonal protocol should not be a significant difference 
> in terms 
> >> of time to implement.
> purpose in 
> >> the amount of time we have spent discussing this issue.
> Whether someone has heard of it or not is not the point.  If 
> I sit down an average developer with the BFCP spec, and a few 
> minutes on a whiteboard, he or she can implement this spec 
> very quickly.
> 
> >> - While I would be surprised to find a business that has UDP port 
> >> 5060 open that would not allow outgoing TCP, you could certainly 
> >> configure BFCP to use port 443.
> >>>> NOTIFY is rejected, the line goes busy and user is 
> provided a fast
> >>> busy.
> >>>>
> >>>> Thanks
> >>>> Venkatesh
> >>>>
> >>>> On Fri, Mar 21, 2008 at 12:15 PM, Francois Audet 
> <[email-masked]>
> >>> wrote:
> >>>>
> >>>>> I will point out that PBXs (as opposed to key systems) 
> often work 
> >>>>> the
> >>>

---

From: Venkatesh <[email-masked]>
Date: Tue, 25 Mar 2008 12:56:11 -0700

Hi Rohan:

Since you seem to be really interested in BFCP and wanted to know technical
limitations if any existed with BFCP for line seizure, I made time to
cursorily read up on BFCP (must confess I am not yet fully familiar with it
and so would appreciate if you can clarify any incorrect understanding on my
part). Secondly, I am not fully aware of your proposal beyond what was
mentioned in Alan's original email. It may have helped if you had summarized
your thinking (for example Alan's initial email indicated using RFC 4583
which from discussions in this thread seems incorrect).

Having said that, below are a list of concerns I have with this approach.
Some of them are technical and others are things that you will need to add
to make the solution really deployable. You can definitely come with
proposals to address these concerns but I just wanted us to be aware that it
is not simply implementing FloorRequest, FloorRelease and FloorRequestStatus
at the UA like you state in your emails.

1. To begin with, there is no simple way for the BFCP server to accept or
reject a FloorRequest message accurately. A UA that is part of a MLA may
request a line for any one of the following among other things:

   - Make a new call
   - Resume a Held Call (calls comes to a MLA group, answered by secretary,
put on Hold, picked up by boss)
   - Join an existing conversation.

The "intent" decides whether a line seizure request can be accepted or
rejected and thus is important for the discussion. The floor control server
should do line seizure arbitration when an attempt is being made for a new
call. All other requests are more of a "notification" to the floor control
server that the line is being used and should not be allocated for "new"
calls should it receive a request. We can discuss a scheme where by a UA
that "gets" floor control keeps track of all such transitions and releases
it at the very end but that it can lead to un-usable scenarios should the UA
go offline/reboots during this process.

Anyway assuming we will need this capability for now, as far as I could
understand, there is nothing in BFCP (apart from the
PARTICIPANT_PROVIDED_INFO) where by the "intent" of why a FloorRequest is
being issued can be provided. Even the type under consideration is text
meant to be rendered to a  "human" and not for an "automata" like we want to
use. Ofcourse, like any other RFC, BFCP allows for "extension headers" and
could be proposed as a means of accomplishing the same..... Even if I were
to assume that we do come up with a scheme to provide this information, it
is still impossible for the floor control server to accept or reject a
FloorRequest message as it does not know the state of the dialog. And in
scenarios like join, there may be two UA's that "own" the line for a period
of time (duration of join) and reduce to one UA should one of the parties
that "joined" the call drops off......

2. Decoupling the protocol for "line seizure" from the protocol used to
"advertise" status of lines can cause some interesting category of race
conditions. For example, assume a UA in a MLA group issues a "FloorRequest"
and obtains access to the line. Before it can issue a NOTIFY to provide any
dialog state, it crashes or the PC thru' which this phone is connected
reboots. None of the other UA's in the group "know" this line has been
seized as they haven't received anything from the State Agent. However, any
attempts by them to use the line will be rejected by the BFCP server. BFCP
relies on TCP connection close to determine error conditions and under such
circumstances figuring out the TCP connection is gone probably going to take
longer than the time it would take for the customer to call the service
provider complaining they are unable to place calls. This point brings into
light into a category of issues that revolve around recovery from error
conditions that this approach has to deal with that I have outlined in the
next couple of items.

3. BFCP also RECOMMENDS that a Floor Control Server do not relinquish any
floor control requests granted to a UA should it detect a TCP connection
failure to the UA to which it granted the floor. This may cause unacceptable
end user experience especially in scenarios where the UA reboots or is
offline for an extended period of time where by the State-Agent cleans up a
dialog state due to lack of responses for a SUBSCRIBE refresh from the UA
that made/answered a call. To avoid the same, we may have to recommend
implementing something contrary to the recommendation.

4.  I could not find anything obvious in BFCP that allows a floor control
server to reconstruct the state of the all the floors. This may be important
in situations where by the box on which the floor control server is running
reboots or the floor control server restarts for some reason. Inability to
reconstruct this information could lead to periods of time where by the
floor control server is unable to act upon incoming FloorRequest messages as
the floor control server is now completely under the mercy of when all UA's
in the MLA group reconnect with the floor control server (Well we can have
the UA's now implement two more "simple" methods to detect liveliness of the
floor control server and recover sooner from this state). We can also
propose having the floor control server talk to the State Agent to fetch
dialog information but this is additional work and does not amount to simply
implementing 3 messages. You probably are also looking at persisting data
such as transaction idenfiers in a database so that on restore, you can
correlate the Transaction Identifier in a FloorRelease to the appropriate
resource...... Or alternatively look at implementing some of the other BFCP
semantics..... With the SIP approach, you get 'reconstruction' automatically
as you SUBSCRIBE at start up (something you have to do anyways and is no
overhead).

It may be that there are other situations you will have to worry about when
you actually sit down to implement a "deployable" solution that I have
probably not hit upon as yet.....

On a closing note, I would also like to state that thus far I have not seen
any "technical" limitations to the NOTIFY proposal. Main objections have
been around stating SIP is not for such advertsing hook states and providing
granular control. I believe those concerns should have been raised when the
dialog state draft proposed advertising such states and not when building an
application using a behavior outlined in an RFC IMO. Others I have only
heard revolve around subscriptions terminating upon receipt of a non 2xx
response terminating a NOTIFY (to which I have provided pointers to relevant
sections in 3265 that indicates contrary to the belief) and a third being
that of invalid behavior of a State Agent. If it will help, I don't have a
problem with calling the State Agent as a MLA Event Manager or something
else.  May be there are others that was discussed in the IETF meetings and
would appreciate somebody summarizing the same for the benefits of those
that did not attend.

Thanks,
Venkatesh

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 25 Mar 2008 22:17:12 -0700

Hi Venkatesh,

Comments inline....

On Mar 25, 2008, at 12:56 PM, Venkatesh wrote:
> Hi Rohan:
>
> Since you seem to be really interested in BFCP and wanted to know  
> technical limitations if any existed with BFCP for line seizure, I  
> made time to cursorily read up on BFCP (must confess I am not yet  
> fully familiar with it and so would appreciate if you can clarify  
> any incorrect understanding on my part). Secondly, I am not fully  
> aware of your proposal beyond what was mentioned in Alan's original  
> email. It may have helped if you had summarized your thinking (for  
> example Alan's initial email indicated using RFC 4583 which from  
> discussions in this thread seems incorrect).
>
> Having said that, below are a list of concerns I have with this  
> approach. Some of them are technical and others are things that you  
> will need to add to make the solution really deployable. You can  
> definitely come with proposals to address these concerns but I just  
> wanted us to be aware that it is not simply implementing  
> FloorRequest, FloorRelease and FloorRequestStatus at the UA like  
> you state in your emails.
>
> 1. To begin with, there is no simple way for the BFCP server to  
> accept or reject a FloorRequest message accurately. A UA that is  
> part of a MLA may request a line for any one of the following among  
> other things:
>
>    - Make a new call
>    - Resume a Held Call (calls comes to a MLA group, answered by  
> secretary, put on Hold, picked up by boss)
> The "intent" decides whether a line seizure request can be accepted  
> or rejected and thus is important for the discussion. The floor  
> control server should do line seizure arbitration when an attempt  
> is being made for a new call. All other requests are more of a  
> "notification" to the floor control server that the line is being  
> used and should not be allocated for "new" calls should it receive  
> a request. We can discuss a scheme where by a UA that "gets" floor  
> control keeps track of all such transitions and releases it at the  
> very end but that it can lead to un-usable scenarios should the UA  

I disagree.  I don't see how the "intent" is important to the  
primitive.  The important thing is that no two phones can have  
exclusive use of the shared resource at the same time.

My recommendation which I sketched out at the mic back at the San  
Diego IETF goes like this:
Before a call is answered, a new call is composed, or a call is  
picked up / unheld the phone requests the floor and does not do  
anything with SIP signaling until it gets a floor response or times  
out.  If the phone gets the floor, it proceeds with appropriate SIP  
signaling. If the phone is notified that another phone has the floor  
or the floor request times out, it plays some appropriate error.   
When the phone puts a call on hold, hangs up, or parks a call, it  
releases the floor.  When a phone receives a join request, the focus  
keeps the floor.  If the focus transfers to another endpoint, that  
endpoint needs to take the floor.

All phones continue to use the (unmodified) dialog package to provide  
notifications of what SIP signaling is happening.

> Anyway assuming we will need this capability for now, as far as I  
> could understand, there is nothing in BFCP (apart from the  
> PARTICIPANT_PROVIDED_INFO) where by the "intent" of why a  
> FloorRequest is being issued can be provided. Even the type under  
> consideration is text meant to be rendered to a  "human" and not  
> for an "automata" like we want to use. Ofcourse, like any other  
> RFC, BFCP allows for "extension headers" and could be proposed as a  
> means of accomplishing the same..... Even if I were to assume that  
> we do come up with a scheme to provide this information, it is  
> still impossible for the floor control server to accept or reject a  
> FloorRequest message as it does not know the state of the dialog.  
> And in scenarios like join, there may be two UA's that "own" the  
> line for a period of time (duration of join) and reduce to one UA  
> should one of the parties that "joined" the call drops off......

I do not see anything productive that any of the phones or the floor  
control server would do with the "intent".

> 2. Decoupling the protocol for "line seizure" from the protocol  
> used to "advertise" status of lines can cause some interesting  
> category of race conditions. For example, assume a UA in a MLA  
> group issues a "FloorRequest" and obtains access to the line.  
> Before it can issue a NOTIFY to provide any dialog state, it  
> crashes or the PC thru' which this phone is connected reboots. None  
> of the other UA's in the group "know" this line has been seized as  
> they haven't received anything from the State Agent. However, any  
> attempts by them to use the line will be rejected by the BFCP  
> server. BFCP relies on TCP connection close to determine error  
> conditions and under such circumstances figuring out the TCP  
> connection is gone probably going to take longer than the time it  
> would take for the customer to call the service provider  
> complaining they are unable to place calls. This point brings into  
> light into a category of issues that revolve around recovery from  
> error conditions that this approach has to deal with that I have  
> outlined in the next couple of items.

What you have described is a good thing.  It shows that the system  
operates correctly under an error situation.  The error conditions  
under a special event package are no better. Note that the BFCP  
server can also insist that floor requests are refreshed periodically.

> 3. BFCP also RECOMMENDS that a Floor Control Server do not  
> relinquish any floor control requests granted to a UA should it  
> detect a TCP connection failure to the UA to which it granted the  
> floor. This may cause unacceptable end user experience especially  
> in scenarios where the UA reboots or is offline for an extended  
> period of time where by the State-Agent cleans up a dialog state  
> due to lack of responses for a SUBSCRIBE refresh from the UA that  
> made/answered a call. To avoid the same, we may have to recommend  

Yes.  However if any agent has knowledge that a call was  
disconnected, it can administratively remove the floor as a floor chair.

> 4.  I could not find anything obvious in BFCP that allows a floor  
> control server to reconstruct the state of the all the floors. This  
> may be important in situations where by the box on which the floor  
> control server is running reboots or the floor control server  
> restarts for some reason. Inability to reconstruct this information  
> could lead to periods of time where by the floor control server is  
> unable to act upon incoming FloorRequest messages as the floor  
> control server is now completely under the mercy of when all UA's  
> in the MLA group reconnect with the floor control server (Well we  
> can have the UA's now implement two more "simple" methods to detect  
> liveliness of the floor control server and recover sooner from this  
> state). We can also propose having the floor control server talk to  
> the State Agent to fetch dialog information but this is additional  
> work and does not amount to simply implementing 3 messages. You  
> probably are also looking at persisting data such as transaction  
> idenfiers in a database so that on restore, you can correlate the  
> Transaction Identifier in a FloorRelease to the appropriate  
> resource...... Or alternatively look at implementing some of the  
> other BFCP semantics..... With the SIP approach, you get  
> 'reconstruction' automatically as you SUBSCRIBE at start up  
> (something you have to do anyways and is no overhead).

I would rather put the effort into making a robust simple server than  
worry about reconstructing state at the server.  The key systems this  
feature is replacing were never even close to highly reliable and  
certainly had no such protections.  Thousands of these systems are  
deployed, so clearly they are "deployable" without this complex feature.

> It may be that there are other situations you will have to worry  
> about when you actually sit down to implement a "deployable"  
> solution that I have probably not hit upon as yet.....
>
> On a closing note, I would also like to state that thus far I have  
> not seen any "technical" limitations to the NOTIFY proposal.

How about the objection that the state agent has to operate  
differently whether you are operating with or without seizure?

> Main objections have been around stating SIP is not for such  
> advertsing hook states

I have raised no such objection.

> and providing granular control.

The objection is to providing exclusive access arbitration.  I think  
there is a difference between granular control and arbitration.

> I believe those concerns should have been raised when the dialog  
> state draft proposed advertising such states and not when building  
> an application using a behavior outlined in an RFC IMO. Others I  
> have only heard revolve around subscriptions terminating upon  
> receipt of a non 2xx response terminating a NOTIFY (to which I have  
> provided pointers to relevant sections in 3265 that indicates  
> contrary to the belief)

I'm sorry, I must have missed that.  Can you please repost this pointer?

> and a third being that of invalid behavior of a State Agent. If it  
> will help, I don't have a problem with calling the State Agent as a  
> MLA Event Manager or something else.  May be there are others that  
> was discussed in the IETF meetings and would appreciate somebody  
> summarizing the same for the benefits of those that did not attend.

There is a definition of a state agent in RFC 3265 and in the dialog  
event package.  Changing the name of the thing will not help.  If the  
goal is to reuse SIP then the bliss WG is not in a position to define  
a completely new role or new behavior that is out of the scope of an  
event package.  BLISS simply does not have the charter to do so.  You  
would have to take your requirements to SIPPING and then proceed with  
a new mechanism in SIP.

thanks,
-rohan

---

From: Venkatesh <[email-masked]>
Date: Wed, 26 Mar 2008 00:31:04 -0700

Rohan:

Replies Interspersed....

> endpoint needs to take the floor.

[Venkatesh]: Thanks for the  summary. It helps understand your proposal
better.

> control server would do with the "intent".

[Venkatesh]: I am inclined to agree  that the intent is no  longer useful in
light of  your detailed proposal. I had no idea on when you wanted the UA to
request and release lines and thus assumed that the BFCP server would have
to deduce the intent.

> server can also insist that floor requests are refreshed periodically.

[Venkatesh]: I would be very interested in knowing the result of the
conversation where a developer sat down to explain "goodness" to a irate
customer reporting inability to make calls... I didn't find anything in the
BFCP RFC that stated how something to the effect can be achieved. Would
appreciate if you can provide me pointers to the appropriate section.

> disconnected, it can administratively remove the floor as a floor chair.

[Venkatesh]:  Like I said, the intent of some of them were to point out to
the fact that a deployable solution would have to implement much more than 3
messages. My point was also to indicate that things you got "for free" with
the SIP means must be revisited when you go with this approach.... You just
acknowledged my point by indicating the need of a third element to monitor
such states and notify the BFCP server of such scenarios.

> deployed, so clearly they are "deployable" without this complex feature.

[Venkatesh]: I disagree.... You might want to talk to your "old" PBX friends
about reliability of their "old" products.... Most of them had much better
reliability numbers than current IP-PBX vendors.... Regardless, ability to
recover from a module crash or a system reboot is in my opinion a *very*
basic requirement for any solution. It doesn't take much to end up in such a
condition. A solution robustness depends upon how seamlessly it can recover
from such states. Given a lack of a response I assume that you concur that
one would have to resort to schemes outlined above ....  Again, my point in
the above was to indicate the technical complexity and additional overhead
one would have to implement to this solution as against using the SIP where
by I get this with no additional work.

[Venkatesh]: I am not sure I understand the objection? MLA is a new feature
that requires new behavior. UA's that need this behavior will request this
using the "sla" tag in their subscription request. UA's that don't need this
will simply subscribe to dialog-state?

> I'm sorry, I must have missed that.  Can you please repost this pointer?

[Venkatesh]: Want to draw your attention to section 3.2.2 of RFC 3265...
Specifically, the following that defines what a "failed" request is:

"A NOTIFY request is considered failed if the response times out, or a non
200 class response code is received which has no Retry-After header and no
implied further action which can be taken to retry the request".

The MLA draft proposes rejecting the request with a non 2xx response BUT
with a "Retry-After" header. Technically, per the above definition of RFC
3265, the request cannot be considered failed.

> would have to take your requirements to SIPPING and then proceed with

[Venkatesh]: I am not sure  the draft is "defining" a completely new role.
The function being performed is that of event aggregation. Like I pointed
out, it is not doing anything that violates the RFC. I am not sure 3265 (or
dialog state draft for that matter) specifically calls out against rejecting
a request by a State Agent. The way I see it the State Agent in the proposal
is doing the following:

1. Accept incoming NOTIFY's per dialog state RFC.
2. Respond with a non 2xx response to a NOTIFY should it be required to do
glare resolution.
3. Expect UA's not to "terminate" subscription on receipt of the above
response as the response contains a "Retry-After" header and thus is not a
"failed" request.
4. Relay NOTIFY's to other MLA appearance should a NOTIFY be accepted.

What is the "new role" here?

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 26 Mar 2008 12:05:07 +0100

I agree with Rohan.

As Rohan says, TCP is mandatory for RFC 3261. As RFC 3261 predates RFC
3265, one could as easily argue that the implementation had also not
implemented RFC 3265. And PUBLISH came along a lot later - and both are
optional extensions.

We end up down a rathole where we try and judge whether we can use a
feature based on whether some implementation has implemented or
misimplemented any particular feature.

Can we please concentrate arguments on fitness for purpose instead. 

Regards

Keith

> Sent: Monday, March 24, 2008 11:24 PM
> To: Fernando Lombardo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Mar 2008 09:07:39 -0400

I have only been loosely following this, but the following caught my eye:

Venkatesh wrote:

> [Venkatesh]: I am not sure  the draft is "defining" a completely new 
> role. The function being performed is that of event aggregation. Like I 
> pointed out, it is not doing anything that violates the RFC. I am not 
> sure 3265 (or dialog state draft for that matter) specifically calls out 
> against rejecting a request by a State Agent. The way I see it the State 
> Agent in the proposal is doing the following:
> 
> 2. Respond with a non 2xx response to a NOTIFY should it be required to 
> do glare resolution.

I don't understand how there can be anything comparable to glare in an 
event package. If you think there is, that seems like a red flag to me 
that something is amiss.

A NOTIFY is sent by a server possessing state, reporting on that state. 
The subscriber has no business arguing about it. Its like me telling you 
I'm thirsty, and you responding to me that I am incorrect - that I may 
not be thirsty now.

I gather you have a state agent that is subscribing to events from 
several sources (phones) and aggregating the results. But if you want to 
model it that way, then the states of the phones are what they are, and 
it is up to the aggregator to make a sensible composite state out of the 
result. It has no business telling its notifiers they are wrong.

> response as the response contains a "Retry-After" header and thus is not 
> a "failed" request.
>      > On Thu, Mar 20, 2008 at 9:47 PM, Rohan Mahy <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > Hi Venkatesh,
>      >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Mar 2008 09:11:01 -0400

I noticed something in this too:

Rohan Mahy wrote:

> My recommendation which I sketched out at the mic back at the San Diego 
> IETF goes like this:
> Before a call is answered, a new call is composed, or a call is picked 
> up / unheld the phone requests the floor and does not do anything with 
> SIP signaling until it gets a floor response or times out.  If the phone 
> gets the floor, it proceeds with appropriate SIP signaling. If the phone 
> is notified that another phone has the floor or the floor request times 
> out, it plays some appropriate error.  When the phone puts a call on 
> hold, hangs up, or parks a call, it releases the floor.  When a phone 
> receives a join request, the focus keeps the floor.  If the focus 
> transfers to another endpoint, that endpoint needs to take the floor.

Is there a mechanism if BFCP for the holder of the floor to yield it to 
a particular participant? That seems to be required for the last point. 
If the focus simply relinquishes the floor, in the expectation that the 
transfer target will take it, there is a window when someone else might 
grab it.

	Paul

---

From: Venkatesh <[email-masked]>
Date: Wed, 26 Mar 2008 09:01:43 -0700

Paul:

Replies Inline.....

> result. It has no business telling its notifiers they are wrong.

[Venkatesh]:  Paul your argument is fine; although in your example, I am not
saying, you are incorrect, but I am saying; "I understand you are thirsty,
but please wait for 10 seconds and ask me again".....  The "Retry-After"
header in the response provides this capability....The argument I was trying
to make was that any SIP request can be rejected/challenged by the
recipient. The same applies to a state agent as well. I am not sure a
state-agent is required to respond with a  200 OK should it receive a NOTIFY
that has a mal-formed payload or a 'state' that is not even defined in
dialog-state for example? I understand that people have taken exception to
this specific usage, but from a generic sense, RFC 3265 has such a
capability and it is this capability that we were proposing to use.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 26 Mar 2008 08:54:37 -0700

On Mar 26, 2008, at 12:31 AM, Venkatesh wrote:
[snip]
> [Venkatesh]: I disagree.... You might want to talk to your "old"  
> PBX friends about reliability of their "old" products.... Most of  
> them had much better reliability numbers than current IP-PBX  
> vendors....
[snip]

I agree that a traditional *PBX* is generally reliable even though  
most are deployed without redundancy.  However the feature you are  
trying to replicate is associated with *Key Telephone Systems* which  
are much less reliable.  I have used both on a production basis and I  
do understand the difference.

> [Venkatesh]: I am not sure I understand the objection? MLA is a new  
> feature that requires new behavior. UA's that need this behavior  
> will request this using the "sla" tag in their subscription  
> request. UA's that don't need this will simply subscribe to dialog- 
> state?

The state agent has to reject a "glare" request if you include the  
"sla" tag, but better not reject a "glare" request if one is not  
included.

> [Venkatesh]: Want to draw your attention to section 3.2.2 of RFC  
> 3265... Specifically, the following that defines what a "failed"  
> request is:
>
> "A NOTIFY request is considered failed if the response times out,  
> or a non 200 class response code is received which has no Retry- 
> After header and no implied further action which can be taken to  
> retry the request".
>
> The MLA draft proposes rejecting the request with a non 2xx  
> response BUT with a "Retry-After" header. Technically, per the  
> above definition of RFC 3265, the request cannot be considered failed.

The semantics of Retry-After are to try the IDENTICAL request again.   
Many SIP stacks handle this retry automatically and will not pass the  
error up to the application until it has retried.  It is unlikely  
that an identical request that caused a glare will still work, since  
the glare condition will probably still exist.

thanks,
-rohan

> [Venkatesh]: I am not sure  the draft is "defining" a completely  
> new role. The function being performed is that of event  
> aggregation. Like I pointed out, it is not doing anything that  
> violates the RFC. I am not sure 3265 (or dialog state draft for  
> that matter) specifically calls out against rejecting a request by  
> a State Agent. The way I see it the State Agent in the proposal is  
> doing the following:
>
> 2. Respond with a non 2xx response to a NOTIFY should it be  
> required to do glare resolution.
> 3. Expect UA's not to "terminate" subscription on receipt of the  
> above response as the response contains a "Retry-After" header and  
> thus is not a "failed" request.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 26 Mar 2008 09:01:02 -0700

The focus

On Mar 26, 2008, at 6:11 AM, Paul Kyzivat wrote:
>> anything with SIP signaling until it gets a floor response or  
>> times out.  If the phone gets the floor, it proceeds with  
>> appropriate SIP signaling. If the phone is notified that another  
>> phone has the floor or the floor request times out, it plays some  
>> appropriate error.  When the phone puts a call on hold, hangs up,  
>> or parks a call, it releases the floor.  When a phone receives a  
>> join request, the focus keeps the floor.  If the focus transfers  
>> to another endpoint, that endpoint needs to take the floor.
>
> Is there a mechanism if BFCP for the holder of the floor to yield  
> it to a particular participant? That seems to be required for the  
> last point. If the focus simply relinquishes the floor, in the  
> expectation that the transfer target will take it, there is a  
> window when someone else might grab it.
>
> 	Paul

The focus sends a third party FloorRequest (on behalf of the new  
focus), then releases its floor and the correct thing should happen.

thanks,
-rohan

 From the beginning of Section 4.1 of RFC 4582
>    Floor participants request a floor by sending a FloorRequest  
> message
>    to the floor control server.  BFCP supports third-party floor
>    requests.  That is, the floor participant sending the floor request
>    need not be colocated with the media participant that will get the
>    floor once the floor request is granted.  FloorRequest messages  
> carry
>    the identity of the requester in the User ID field of the common
>    header, and the identity of the beneficiary of the floor (in third-
>    party floor requests) in a BENEFICIARY-ID attribute.
>
>       Third-party floor requests can be sent, for example, by floor
>       participants that have a BFCP connection to the floor control
>       server but that are not media participants (i.e., they do not
>       handle any media).

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 26 Mar 2008 09:20:18 -0700

On Mar 26, 2008, at 9:01 AM, Venkatesh wrote:
> [Venkatesh]:  Paul your argument is fine; although in your example,  
> I am not saying, you are incorrect, but I am saying; "I understand  
> you are thirsty, but please wait for 10 seconds and ask me again".....

Ask me again to tell you that I was thirsty 10 seconds ago?  Why does  
this help anything?

thanks,
-rohan

> The "Retry-After" header in the response provides this  
> capability....The argument I was trying to make was that any SIP  
> request can be rejected/challenged by the recipient. The same  
> applies to a state agent as well. I am not sure a state-agent is  
> required to respond with a  200 OK should it receive a NOTIFY that  
> has a mal-formed payload or a 'state' that is not even defined in  
> dialog-state for example? I understand that people have taken  
> exception to this specific usage, but from a generic sense, RFC  
> 3265 has such a capability and it is this capability that we were  
> proposing to use.
>
>
> above

---

From: Venkatesh <[email-masked]>
Date: Wed, 26 Mar 2008 10:32:56 -0700

I think we are digressing from the primary discussion. Again going back to
basics, I have the following primitives already present and supported by
SIP/SIPPING in various RFC's:

1. I have a mechanism that is outlined in 3265 to send/receive NOTIFY's.
2. I have a mechanism that is outlined in 3265 to accept NOTIFY's.
3. I have a mechanism that is outlined in 3265 that allows one to reject a
NOTIFY *without* terminating a subscription.
4. I have a mechanism that is outlined in dialog state that allows UA's to
advertise various call states.

What exactly is the proposal violating? I don't disagree to your argument of
the proposal being non-intuitive but I dis-agree to the argument of it
violating the spec and requiring SIPPING enhancements.

And to address your question of retrying exact same request, it could be
that the line being requested is free by the time the request is retried and
could be successful.

Venkatesh

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Mar 2008 20:52:42 -0400

Venkatesh wrote:
> Paul:
> 
> Replies Inline.....
> 
> On Wed, Mar 26, 2008 at 6:07 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> [Venkatesh]:  Paul your argument is fine; although in your example, I am 
> not saying, you are incorrect, but I am saying; "I understand you are 
> thirsty, but please wait for 10 seconds and ask me again".....  

But I'm not asking anything. I am *telling* you I'm thirsty, because you 
asked to be told. What you are proposing seems to be another form of 
event notification rate limiting, without the benefit of actually 
reducing the rate.

	Paul

> The 
> "Retry-After" header in the response provides this capability....The 
> argument I was trying to make was that any SIP request can be 
> rejected/challenged by the recipient. The same applies to a state agent 
> as well. I am not sure a state-agent is required to respond with a  200 
> OK should it receive a NOTIFY that has a mal-formed payload or a 'state' 
> that is not even defined in dialog-state for example? I understand that 
> people have taken exception to this specific usage, but from a generic 
> sense, RFC 3265 has such a capability and it is this capability that we 
> were proposing to use.
> 
> 
> 
>      >      > On Thu, Mar 20, 2008 at 9:47 PM, Rohan Mahy
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >      > Hi Venkatesh,
>      >      >

---

From: "Bill Mitchell" <[email-masked]>
Date: Thu, 27 Mar 2008 02:40:19 -0700

RFC3265 mentions an "implied action" in section 3.2.2 with regards to a non-2xx response. Here, the "implied action" could be:  client, wait then re-evaluate the status of all appearances before trying to use an appearance. A typical reason for rejection would be a glare condition, where one client hadn't yet received notification that a particular appearance was being used by another client.  Waiting for the Retry-After period should allow the client to receive updates on appearance usage. 10 seconds seems a little long to be user-friendly.  Perhaps 1-2 seconds makes more sense.
 
Here's my take on the thirst/drink analogy:
<precondition:  client believes glass #1 is available to drink from>
Client:  I am drinking from glass #1 ?
Server:  No you're not drinking from glass #1. Try taking a drink in 2 seconds.
<Client waits 2 seconds during which it learns someone else is drinking from glass #1. However, no one appears to be drinking from glass #2>
Client:  I am drinking from glass #2 ?
Server:  Ok.

One significant drawback I see with the current NOTIFY/PUBLISH mechanism of the MLA draft is that it *requires* clients to report dialog status to the Appearance Agent.  Making a clean separation of "floor control" from dialog status exchange would allow more flexibility for an implementation where dialog status could be composed entirely on the server side, based on floor status and call status (when the server remains in the signaling path of each call).  Clients aware & capable of using floor control could do so, and clients either unaware or disinterested would not use it, though the server could actually manage floor control on behalf of these clients.
 
-Bill

From: [email-masked] on behalf of Paul Kyzivat
Sent: Wed 3/26/2008 5:52 PM
To: Venkatesh
Cc: Rohan Mahy; [email-masked]
Subject: Re: [BLISS] MLA with Floor Control

        Paul

>      >     <mailto:[email-masked] <mailto:[email-masked]%20%3Cmailto:[email-masked]> >>> wrote:
>      >      > Hi Venkatesh,
>      >      >

---

From: Venkatesh <[email-masked]>
Date: Thu, 27 Mar 2008 08:09:27 -0700

On Wed, Mar 26, 2008 at 5:52 PM, Paul Kyzivat <[email-masked]> wrote:

>
>
> Venkatesh wrote:
>
> > Paul:
> >
> > Replies Inline.....
> >
> >
> > On Wed, Mar 26, 2008 at 6:07 AM, Paul Kyzivat <[email-masked]<mailto:
> > [email-masked]>> wrote:
> >
> > new
> asked to be told. What you are proposing seems to be another form of event
> notification rate limiting, without the benefit of actually reducing the
> rate.
>
>        Paul
>

[Venkatesh]: Sure. My only position is that whatever is being proposed is
already supported in the RFC's and we don't need any new primitives from
SIP/SIPPING.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 27 Mar 2008 08:46:59 -0700

Venkatesh,

On Mar 26, 2008, at 10:32 AM, Venkatesh wrote:
> I think we are digressing from the primary discussion. Again going  
> back to basics, I have the following primitives already present and  
> supported by SIP/SIPPING in various RFC's:
>
> 3. I have a mechanism that is outlined in 3265 that allows one to  
> reject a NOTIFY *without* terminating a subscription.

But rejecting a NOTIFY with a Retry-After does not have the correct  
*semantics* or other behavior you want.  If the line I wanted to  
seize was just taken by another phone and will be in use for the next  
5 minutes, the *semantics* of Retry-After are that the *original  
NOTIFY request body* is resent (retried) after some number of  
seconds.  Lets use your example of 10 seconds for Retry-After.

Technical problem #1:
Instead of returning an error to the application, many existing SIP  
stacks will just retry the same request on behalf of the application  
in 10 seconds.  There is no feedback to the user that they did not  
get the line and the NOTIFY that is sent reflect what the phone  
wanted to report 10 seconds ago (which may no longer reflect the  
current status when the retried request is sent).

Technical problem #2:
Lets say the phone is using a different SIP stack that does not  
automatically handle Retry-After. The phone sends a NOTIFY gets an  
error with Retry-After.  The phone needs to be able to tell the  
difference between an error response with Retry-After that is truly  
repairable and should cause the phone application to delay sending  
feedback to the user (what Retry-After means today), and this new  
behavior you would like it to have (which is a change to the  
semantics of RFC 3261).  Certainly if a new error response is  
required, it will need to be done by the SIP WG according to the SIP  
change control spec.

Technical problem #3:
Lets say the phone can use a specific error response to play an error  
tone to a phone that wants line seizure. Now during the Retry-After  
waiting period, the user tries to seize a different line. The  
expected behavior from the user an error tone, then mashing down the  
next line button and an almost immediate dial tone. If the Retry- 
After is 10 seconds, the phone will have to wait 8 or 9 extra seconds  
before it is allowed to send a new NOTIFY to the state agent.

thanks,
-rohan

> 4. I have a mechanism that is outlined in dialog state that allows  
> UA's to advertise various call states.
>
> What exactly is the proposal violating? I don't disagree to your  
> argument of the proposal being non-intuitive but I dis-agree to the  
> argument of it violating the spec and requiring SIPPING enhancements.
>
> And to address your question of retrying exact same request, it  
> could be that the line being requested is free by the time the  
> request is retried and could be successful.
>
> Venkatesh
>
> <[email-masked]

---

From: Venkatesh <[email-masked]>
Date: Thu, 27 Mar 2008 11:57:59 -0700

Rohan:

I don't look at 1 and 2 as technical issues per say and attribute it to the
specific UA's implementation and is a result of the UA's decision to delay
notifications to the end user. These issues will exist for other
transactions as well and it is up to the UA to deal with these..... Let us
walk through your issues list for a UA that is  implementing the same for
yet another SIP request, say INVITE. UA makes a call to a destination. Say,
the destination UA is running a client that integrates into my calendar. It
knows I am in a meeting when the call arrives. It returns a 486 response
with a Retry-After of 120 seconds (as my meeting is going to end in 2 mins).
The calling user is sitting there waiting for 2 minutes without any
indication as the lower level implementation is sitting there waiting to
retry after 2 mins.....

With respect to 3 below, the only response for which a UA SHOULD NOT retry
until the Retry-After expires is for a 503 response per RFC 3261. I don't
think the proposal is recommending using a 503 response.

Thanks
Venkatesh

On Thu, Mar 27, 2008 at 8:46 AM, Rohan Mahy <[email-masked]> wrote:

> > I think we are digressing from the primary discussion. Again going back
> > to basics, I have the following primitives already present and supported by
> > 3. I have a mechanism that is outlined in 3265 that allows one to reject
> > a NOTIFY *without* terminating a subscription.
> >
>
> *semantics* or other behavior you want.  If the line I wanted to seize was
> just taken by another phone and will be in use for the next 5 minutes, the
> *semantics* of Retry-After are that the *original NOTIFY request body* is
> resent (retried) after some number of seconds.  Lets use your example of 10
> seconds for Retry-After.
>
> Technical problem #1:
> Instead of returning an error to the application, many existing SIP stacks
> will just retry the same request on behalf of the application in 10 seconds.
>  There is no feedback to the user that they did not get the line and the
> NOTIFY that is sent reflect what the phone wanted to report 10 seconds ago
> (which may no longer reflect the current status when the retried request is
> sent).
>
> Technical problem #2:
> automatically handle Retry-After. The phone sends a NOTIFY gets an error
> with Retry-After.  The phone needs to be able to tell the difference between
> an error response with Retry-After that is truly repairable and should cause
> the phone application to delay sending feedback to the user (what
> Retry-After means today), and this new behavior you would like it to have
> (which is a change to the semantics of RFC 3261).  Certainly if a new error
> response is required, it will need to be done by the SIP WG according to the
> SIP change control spec.
>
> Technical problem #3:
> Lets say the phone can use a specific error response to play an error tone
> to a phone that wants line seizure. Now during the Retry-After waiting
> period, the user tries to seize a different line. The expected behavior from
> the user an error tone, then mashing down the next line button and an almost
> immediate dial tone. If the Retry-After is 10 seconds, the phone will have
> to wait 8 or 9 extra seconds before it is allowed to send a new NOTIFY to
> the state agent.
>
> thanks,
> -rohan
>
>
>
>  4. I have a mechanism that is outlined in dialog state that allows UA's
> > to advertise various call states.
> >
> > argument of the proposal being non-intuitive but I dis-agree to the argument
> > of it violating the spec and requiring SIPPING enhancements.
> >

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 28 Mar 2008 10:09:53 -0500

All,

When you dial into Shida's bridge, make sure you do NOT add a "#" to the bridge
number, otherwise it doens't work.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss