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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francois
Audet
Sent: 18 March 2008 22:54
To: Venkatesh; Mohsen Soroushnejad
Cc: [email protected]; Rohan Mahy
Subject: Re: [BLISS] MLA with Floor Control
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
