![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
Use case 1 has a generic waiting room URI,
where someone helps you into the right conference at the right time. Like
many “in person” waiting rooms. If SIP was the call protocol,
I would probably refresh the dialog. If you are just waiting for the conference
moderator to arrive before the conference can start, you may not even need a
sidebar. The media mixer could just show everybody audio, video or text explaining
why you wait. More like a mixer state. Use case 2 can be solved by a sidebar as
long as the sidebar is not limited by the original conference objects
properties. The limitations of the original conference object may be the cause
of the user’s problems in the first place. Geir Arne From: Brian Rosen
[mailto:br at brianrosen.net] I’m with you that the first two are
probably sidebars, although the waiting room may not be; depends on exactly
what the wait room is. If you get to it with a generic wait room URI,
then you select a conference (somehow) and then you are placed in the
conference, then it’s move-between-conferences. If you get to it
with the real conference URI, but you are “seated” in the wait room
for some reason, then it’s a sidebar. I am also a bit skeptical of
move-between-conferences. Is this not a “Refer/Replaces”
operation; changing the URI of the conference? If it’s not, then
you have the weird situation where the call state is to one conference, with a
URI, but you are actually in another conference, with a different URI.
If, for some reason, the UAC decided it needed to create a new dialog,
it’s not with the same URI as the original. That sounds pretty
weird to me. Brian From: Sean Olson
[mailto:Sean.Olson at microsoft.com] I would not implement the first as a
separate conference, but that is something that we could discuss more when we
define the sidebar operations. I can see the value of defining a move user
between conferences operation, though I'm a bit skeptical of the architecture
to enable such an operation. I guess I'd like to see a high level call flow for
how this would work. From: Even,
Roni [mailto:roni.even at polycom.co.il] Sean, Sidebar is a child of a conference which
is not the case here. For the first case there is no conference yet. I agree
that the second can be based on sidebar. I think that I agree with Geir that there
is a need to move participants between conferences and not only from a
conference to side bar and back Roni From: Sean Olson
[mailto:Sean.Olson at microsoft.com] I don't see why those two use cases could
not be handled by a sidebar. From: Geir Arne
Sandbakken [mailto:geir.sandbakken at tandberg.net] Moving users between sidebars has been proposed, but it
would be nice to extend this for moving users between conferences as well.
Having a “move” verb would be preferable, as a “delete
user” followed by “add user” can have the side effect of
disconnecting the user from the conference. Two use cases: 1. Waiting room: You call a waiting room where someone
controls when you can join a specific conference. 2. Help service: An administrator can move a user to
another conference to help out with typical media problems, debugging or other
issues. Then move the user back when it has been resolved. Geir Arne |
_______________________________________________ XCON mailing list XCON at ietf.org https://www1.ietf.org/mailman/listinfo/xcon