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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Venkatesh
Sent: Thursday, March 13, 2008 22:35
To: Mohsen Soroushnejad
Cc: [email protected]; 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
PROTECTED]> wrote:
Hi Alan -
Thanks for leading the discussion on this draft.
>>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.<<
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
On Thu, Mar 13, 2008 at 7:18 AM, Alan Johnston <[EMAIL
PROTECTED]> wrote:
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 protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
