[jitsi-dev] Abstracting the videobridge code in Jitsi into a service


#1

Hello,

I have discussed with Emil the idea that we need a jitsi-videobridge service in order to be able to use a jitsi-videobridge in SIP calls (for example).

Currently the following parts of the code are videobridge-aware:

OperationSetVideobridgeJabberImpl: Has createConfCall() and inviteCalleeToCall() methods (pretty much just wrappers around the OperationSetTelephonyConference methods by the same name). Also serves as an entry point for COLIBRI packets.

Classes in protocol.jabber.extensions.colibri: Represent the COLIBRI IQs

RawUdpTransportManager

CallJabberImpl: Implements most of the videobridge logic -- handle incoming COLIBRI packets, allocate and expire channels as needed.

CallPeerJabberImpl and CallPeerMediaHandlerJabberImpl: handle changes to media indicated in COLIBRI Conference IQs

CallConference: Has a flag that indicates that a jitsi-videobridge is in use.

The GUI (somewhere): Discovers videobridge XMPP entities, initiates calls/adds peers using OperationSetVideobridge.

Probably some others, which I'm missing.

I don't see an obvious or simple way to do the abstraction, but here is an outline of the solution I came up with:

Add a VideobridgeService class (in service.protocol somewhere). It is responsible for discovering videobridge entities (by going over all the available XMPP ProtocolProviders). It has something like this:
List<Videobridge> getAvailableVideobridges()
Videobridge getVideobridge(String jid)

A Videobridge instance is associated with a specific jid and provides methods to manage a conference on it (allocating channels, etc)

The GUI uses the list of Videobridge obtained from the VideobridgeProvider to display a list of bridges for the user to use. It uses a Videobridge instance to initiate a call or add participants (instead of using OperationSetVideoBridge)

The code in CallJabberImpl that deals with videobridge stuff is moved to Videobridge. In CallJabberImpl are left only wrappers to Videobridge calls. Eventually those wrappers will be moved to MediaAwareCall to allow use in SIP.

OperationSetVideoBridgeJabberImpl only serves as an entry point for COLIBRI IQs and routes them to the appropriate Videobridge instance.

RawUdpTransportManager -- I don't know yet.

I haven't started to actually implement the change (hence the lack of details), but I'd appreciate any feedback. Does the above even make sense? Is there something that conceptually won't work? Something I've forgotten about? Something that's just bad practice or could be done better?

Thanks.

Regards,
Boris


#2

Hey Boris,

Hello,

I have discussed with Emil the idea that we need a jitsi-videobridge
service in order to be able to use a jitsi-videobridge in SIP calls (for
example).

Currently the following parts of the code are videobridge-aware:

OperationSetVideobridgeJabberImpl: Has createConfCall() and
inviteCalleeToCall() methods (pretty much just wrappers around the
OperationSetTelephonyConference methods by the same name). Also serves
as an entry point for COLIBRI packets.

Classes in protocol.jabber.extensions.colibri: Represent the COLIBRI IQs

RawUdpTransportManager

CallJabberImpl: Implements most of the videobridge logic -- handle
incoming COLIBRI packets, allocate and expire channels as needed.

CallPeerJabberImpl and CallPeerMediaHandlerJabberImpl: handle changes to
media indicated in COLIBRI Conference IQs

CallConference: Has a flag that indicates that a jitsi-videobridge is in
use.

The GUI (somewhere): Discovers videobridge XMPP entities, initiates
calls/adds peers using OperationSetVideobridge.

Probably some others, which I'm missing.

I don't see an obvious or simple way to do the abstraction, but here is
an outline of the solution I came up with:

Add a VideobridgeService class (in service.protocol somewhere).

Just service is probably OK. This will be a tool for use from protocols. The protocol package is mostly meant for the GUI when it uses these protocols.

It is
responsible for discovering videobridge entities (by going over all the
available XMPP ProtocolProviders). It has something like this:
List<Videobridge> getAvailableVideobridges()
Videobridge getVideobridge(String jid)

Sounds good.

A Videobridge instance is associated with a specific jid and provides
methods to manage a conference on it (allocating channels, etc)

Yes indeed.

The GUI uses the list of Videobridge obtained from the
VideobridgeProvider to display a list of bridges for the user to use. It
uses a Videobridge instance to initiate a call or add participants
(instead of using OperationSetVideoBridge)

I was actually thinking that things wouldn't change for the GUI and that it would keep using the current OpSet. The actual choice of a video bridge would hence happen under the hood and we wouldn't bother the user with it.

The first use case I had in mind were CUSAX accounts where the SIP account can be configured to use a specific XMPP account for bridging.

What you are saying also makes sense though and could prove very handy for the more tech savvy users.

I think what we could do is something between the two. An op set could return the available videobridges. The GUI would show them if they are more than one.

An XMPP account's configuration would allow the user (or a provisioning admin) to export the bridge.

A SIP account would, by default use a bridge from a CUSAX related XMPP provider. If no such provider is defined it could return all exported bridges. If there are more than one, the GUI would allow the user to choose.

The code in CallJabberImpl that deals with videobridge stuff is moved to
Videobridge. In CallJabberImpl are left only wrappers to Videobridge
calls. Eventually those wrappers will be moved to MediaAwareCall to
allow use in SIP.

This makes sense but I think we could start by just creating the videobridge service and then using it in SIP. Once this has been stabilized we could go back and refactor the XMPP protocol.

The XMPP bridging code is more and more stable (thanks to your and Hristo's efforts) and I wouldn't want us to launch in to a perilous refactoring exercise unless we already have stable footing at the other side.

Does all of this make sense?

Cheers,
Emil

···

On 18.07.13, 13:38, Boris Grozev wrote:

OperationSetVideoBridgeJabberImpl only serves as an entry point for
COLIBRI IQs and routes them to the appropriate Videobridge instance.

RawUdpTransportManager -- I don't know yet.

I haven't started to actually implement the change (hence the lack of
details), but I'd appreciate any feedback. Does the above even make
sense? Is there something that conceptually won't work? Something I've
forgotten about? Something that's just bad practice or could be done better?

Thanks.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

Hello,

Hey Boris,

Hello,

I have discussed with Emil the idea that we need a jitsi-videobridge
service in order to be able to use a jitsi-videobridge in SIP calls (for
example).

Currently the following parts of the code are videobridge-aware:

OperationSetVideobridgeJabberImpl: Has createConfCall() and
inviteCalleeToCall() methods (pretty much just wrappers around the
OperationSetTelephonyConference methods by the same name). Also serves
as an entry point for COLIBRI packets.

Classes in protocol.jabber.extensions.colibri: Represent the COLIBRI IQs

RawUdpTransportManager

CallJabberImpl: Implements most of the videobridge logic -- handle
incoming COLIBRI packets, allocate and expire channels as needed.

CallPeerJabberImpl and CallPeerMediaHandlerJabberImpl: handle changes to
media indicated in COLIBRI Conference IQs

CallConference: Has a flag that indicates that a jitsi-videobridge is in
use.

The GUI (somewhere): Discovers videobridge XMPP entities, initiates
calls/adds peers using OperationSetVideobridge.

Probably some others, which I'm missing.

I don't see an obvious or simple way to do the abstraction, but here is
an outline of the solution I came up with:

Add a VideobridgeService class (in service.protocol somewhere).

Just service is probably OK. This will be a tool for use from protocols.
The protocol package is mostly meant for the GUI when it uses these
protocols.

OK

It is
responsible for discovering videobridge entities (by going over all the
available XMPP ProtocolProviders). It has something like this:
List<Videobridge> getAvailableVideobridges()
Videobridge getVideobridge(String jid)

Sounds good.

A Videobridge instance is associated with a specific jid and provides
methods to manage a conference on it (allocating channels, etc)

Yes indeed.

The GUI uses the list of Videobridge obtained from the
VideobridgeProvider to display a list of bridges for the user to use. It
uses a Videobridge instance to initiate a call or add participants
(instead of using OperationSetVideoBridge)

I was actually thinking that things wouldn't change for the GUI and that
it would keep using the current OpSet. The actual choice of a video
bridge would hence happen under the hood and we wouldn't bother the user
with it.

The first use case I had in mind were CUSAX accounts where the SIP
account can be configured to use a specific XMPP account for bridging.

What you are saying also makes sense though and could prove very handy
for the more tech savvy users.

I think what we could do is something between the two. An op set could
return the available videobridges. The GUI would show them if they are
more than one.

An XMPP account's configuration would allow the user (or a provisioning
admin) to export the bridge.

A SIP account would, by default use a bridge from a CUSAX related XMPP
provider. If no such provider is defined it could return all exported
bridges. If there are more than one, the GUI would allow the user to choose.

Just to make sure I get it right:
XMPP and SIP accounts can have a videobridge address associated with them with a property. If the selected account has a videobridge configured this way, the GUI displays no list and tries to use the videobridge that is configured. Otherwise, it obtains the list of all available videobridges, but only shows it if it has more than one element.

I think the list should be shown even if it has a single element. Otherwise the user could incorrectly assume that a videobridge associated with the selected account will be used (after all this is the current behaviour).

The code in CallJabberImpl that deals with videobridge stuff is moved to
Videobridge. In CallJabberImpl are left only wrappers to Videobridge
calls. Eventually those wrappers will be moved to MediaAwareCall to
allow use in SIP.

This makes sense but I think we could start by just creating the
videobridge service and then using it in SIP. Once this has been
stabilized we could go back and refactor the XMPP protocol.

The XMPP bridging code is more and more stable (thanks to your and
Hristo's efforts) and I wouldn't want us to launch in to a perilous
refactoring exercise unless we already have stable footing at the other
side.

That sounds good -- I was worried about breaking existing code.

Does all of this make sense?

Yep.

Regards,
Boris

···

On 7/23/13 2:22 AM, Emil Ivov wrote:

On 18.07.13, 13:38, Boris Grozev wrote:


#4

Hey Boris,

Hello,

Hey Boris,

Hello,

I have discussed with Emil the idea that we need a jitsi-videobridge
service in order to be able to use a jitsi-videobridge in SIP calls (for
example).

Currently the following parts of the code are videobridge-aware:

OperationSetVideobridgeJabberImpl: Has createConfCall() and
inviteCalleeToCall() methods (pretty much just wrappers around the
OperationSetTelephonyConference methods by the same name). Also serves
as an entry point for COLIBRI packets.

Classes in protocol.jabber.extensions.colibri: Represent the COLIBRI IQs

RawUdpTransportManager

CallJabberImpl: Implements most of the videobridge logic -- handle
incoming COLIBRI packets, allocate and expire channels as needed.

CallPeerJabberImpl and CallPeerMediaHandlerJabberImpl: handle changes to
media indicated in COLIBRI Conference IQs

CallConference: Has a flag that indicates that a jitsi-videobridge is in
use.

The GUI (somewhere): Discovers videobridge XMPP entities, initiates
calls/adds peers using OperationSetVideobridge.

Probably some others, which I'm missing.

I don't see an obvious or simple way to do the abstraction, but here is
an outline of the solution I came up with:

Add a VideobridgeService class (in service.protocol somewhere).

Just service is probably OK. This will be a tool for use from protocols.
The protocol package is mostly meant for the GUI when it uses these
protocols.

OK

It is
responsible for discovering videobridge entities (by going over all the
available XMPP ProtocolProviders). It has something like this:
List<Videobridge> getAvailableVideobridges()
Videobridge getVideobridge(String jid)

Sounds good.

A Videobridge instance is associated with a specific jid and provides
methods to manage a conference on it (allocating channels, etc)

Yes indeed.

The GUI uses the list of Videobridge obtained from the
VideobridgeProvider to display a list of bridges for the user to use. It
uses a Videobridge instance to initiate a call or add participants
(instead of using OperationSetVideoBridge)

I was actually thinking that things wouldn't change for the GUI and that
it would keep using the current OpSet. The actual choice of a video
bridge would hence happen under the hood and we wouldn't bother the user
with it.

The first use case I had in mind were CUSAX accounts where the SIP
account can be configured to use a specific XMPP account for bridging.

What you are saying also makes sense though and could prove very handy
for the more tech savvy users.

I think what we could do is something between the two. An op set could
return the available videobridges. The GUI would show them if they are
more than one.

An XMPP account's configuration would allow the user (or a provisioning
admin) to export the bridge.

A SIP account would, by default use a bridge from a CUSAX related XMPP
provider. If no such provider is defined it could return all exported
bridges. If there are more than one, the GUI would allow the user to choose.

Just to make sure I get it right:
XMPP and SIP accounts can have a videobridge address associated with
them with a property.

We already have a way of linking a SIP account to an XMPP one in a CUSAX relationship:

sip.acc123.cusax.XMPP_ACCOUNT_ID=accxmpp456

The idea was that, when this property is available, we can also use it for choosing the bridge.

If the selected account has a videobridge
configured this way, the GUI displays no list and tries to use the
videobridge that is configured. Otherwise, it obtains the list of all
available videobridges, but only shows it if it has more than one element.

Yup.

I think the list should be shown even if it has a single element.
Otherwise the user could incorrectly assume that a videobridge
associated with the selected account will be used (after all this is the
current behaviour).

Hmm ... I don't believe such an assumption would really be a problem. My main concern here is not to bombard users with information they wouldn't necessarily care about.

Let's think about it a bit more. Maybe we can hide the bridge setting behind a button or something.

We are not there yet anyway :slight_smile:

Cheers,
Emil

···

On 23.07.13, 14:27, Boris Grozev wrote:

On 7/23/13 2:22 AM, Emil Ivov wrote:

On 18.07.13, 13:38, Boris Grozev wrote:

The code in CallJabberImpl that deals with videobridge stuff is moved to
Videobridge. In CallJabberImpl are left only wrappers to Videobridge
calls. Eventually those wrappers will be moved to MediaAwareCall to
allow use in SIP.

This makes sense but I think we could start by just creating the
videobridge service and then using it in SIP. Once this has been
stabilized we could go back and refactor the XMPP protocol.

The XMPP bridging code is more and more stable (thanks to your and
Hristo's efforts) and I wouldn't want us to launch in to a perilous
refactoring exercise unless we already have stable footing at the other
side.

That sounds good -- I was worried about breaking existing code.

Does all of this make sense?

Yep.

Regards,
Boris

--
https://jitsi.org


#5

Hey Boris,

Hello,

Hey Boris,

Hello,

I have discussed with Emil the idea that we need a jitsi-videobridge
service in order to be able to use a jitsi-videobridge in SIP calls (for
example).

Currently the following parts of the code are videobridge-aware:

OperationSetVideobridgeJabberImpl: Has createConfCall() and
inviteCalleeToCall() methods (pretty much just wrappers around the
OperationSetTelephonyConference methods by the same name). Also serves
as an entry point for COLIBRI packets.

Classes in protocol.jabber.extensions.colibri: Represent the COLIBRI IQs

RawUdpTransportManager

CallJabberImpl: Implements most of the videobridge logic -- handle
incoming COLIBRI packets, allocate and expire channels as needed.

CallPeerJabberImpl and CallPeerMediaHandlerJabberImpl: handle changes to
media indicated in COLIBRI Conference IQs

CallConference: Has a flag that indicates that a jitsi-videobridge is in
use.

The GUI (somewhere): Discovers videobridge XMPP entities, initiates
calls/adds peers using OperationSetVideobridge.

Probably some others, which I'm missing.

I don't see an obvious or simple way to do the abstraction, but here is
an outline of the solution I came up with:

Add a VideobridgeService class (in service.protocol somewhere).

Just service is probably OK. This will be a tool for use from protocols.
The protocol package is mostly meant for the GUI when it uses these
protocols.

OK

It is
responsible for discovering videobridge entities (by going over all the
available XMPP ProtocolProviders). It has something like this:
List<Videobridge> getAvailableVideobridges()
Videobridge getVideobridge(String jid)

Sounds good.

A Videobridge instance is associated with a specific jid and provides
methods to manage a conference on it (allocating channels, etc)

Yes indeed.

The GUI uses the list of Videobridge obtained from the
VideobridgeProvider to display a list of bridges for the user to use. It
uses a Videobridge instance to initiate a call or add participants
(instead of using OperationSetVideoBridge)

I was actually thinking that things wouldn't change for the GUI and that
it would keep using the current OpSet. The actual choice of a video
bridge would hence happen under the hood and we wouldn't bother the user
with it.

The first use case I had in mind were CUSAX accounts where the SIP
account can be configured to use a specific XMPP account for bridging.

What you are saying also makes sense though and could prove very handy
for the more tech savvy users.

I think what we could do is something between the two. An op set could
return the available videobridges. The GUI would show them if they are
more than one.

An XMPP account's configuration would allow the user (or a provisioning
admin) to export the bridge.

A SIP account would, by default use a bridge from a CUSAX related XMPP
provider. If no such provider is defined it could return all exported
bridges. If there are more than one, the GUI would allow the user to choose.

Just to make sure I get it right:
XMPP and SIP accounts can have a videobridge address associated with
them with a property.

We already have a way of linking a SIP account to an XMPP one in a CUSAX
relationship:

sip.acc123.cusax.XMPP_ACCOUNT_ID=accxmpp456

The idea was that, when this property is available, we can also use it
for choosing the bridge.

Ok, got it, for CUSAX SIP accounts we search for a bridge on the associated XMPP account. No separate videobridge property needed.

If the selected account has a videobridge
configured this way, the GUI displays no list and tries to use the
videobridge that is configured. Otherwise, it obtains the list of all
available videobridges, but only shows it if it has more than one element.

Yup.

I think the list should be shown even if it has a single element.
Otherwise the user could incorrectly assume that a videobridge
associated with the selected account will be used (after all this is the
current behaviour).

Hmm ... I don't believe such an assumption would really be a problem. My
main concern here is not to bombard users with information they wouldn't
necessarily care about.

Let's think about it a bit more. Maybe we can hide the bridge setting
behind a button or something.

Well, I think that's important information that users need to have (at least in some cases). Say I have a corporate account and a public (that is, untrusted) account. The corporate account's videobridge is down. When I create a conference, the public account's videobridge will be used.

We are not there yet anyway :slight_smile:

Alright, I'm leaving the details for later :slight_smile:

Regards,
Boris

···

On 7/23/13 3:35 PM, Emil Ivov wrote:

On 23.07.13, 14:27, Boris Grozev wrote:

On 7/23/13 2:22 AM, Emil Ivov wrote:

On 18.07.13, 13:38, Boris Grozev wrote:


#6

Hey Boris,

Hello,

Hey Boris,

Hello,

I have discussed with Emil the idea that we need a jitsi-videobridge
service in order to be able to use a jitsi-videobridge in SIP calls
(for
example).

Currently the following parts of the code are videobridge-aware:

OperationSetVideobridgeJabberImpl: Has createConfCall() and
inviteCalleeToCall() methods (pretty much just wrappers around the
OperationSetTelephonyConference methods by the same name). Also serves
as an entry point for COLIBRI packets.

Classes in protocol.jabber.extensions.colibri: Represent the COLIBRI
IQs

RawUdpTransportManager

CallJabberImpl: Implements most of the videobridge logic -- handle
incoming COLIBRI packets, allocate and expire channels as needed.

CallPeerJabberImpl and CallPeerMediaHandlerJabberImpl: handle changes
to
media indicated in COLIBRI Conference IQs

CallConference: Has a flag that indicates that a jitsi-videobridge is
in
use.

The GUI (somewhere): Discovers videobridge XMPP entities, initiates
calls/adds peers using OperationSetVideobridge.

Probably some others, which I'm missing.

I don't see an obvious or simple way to do the abstraction, but here is
an outline of the solution I came up with:

Add a VideobridgeService class (in service.protocol somewhere).

Just service is probably OK. This will be a tool for use from protocols.
The protocol package is mostly meant for the GUI when it uses these
protocols.

OK

It is
responsible for discovering videobridge entities (by going over all the
available XMPP ProtocolProviders). It has something like this:
List<Videobridge> getAvailableVideobridges()
Videobridge getVideobridge(String jid)

Sounds good.

A Videobridge instance is associated with a specific jid and provides
methods to manage a conference on it (allocating channels, etc)

Yes indeed.

The GUI uses the list of Videobridge obtained from the
VideobridgeProvider to display a list of bridges for the user to use.
It
uses a Videobridge instance to initiate a call or add participants
(instead of using OperationSetVideoBridge)

I was actually thinking that things wouldn't change for the GUI and that
it would keep using the current OpSet. The actual choice of a video
bridge would hence happen under the hood and we wouldn't bother the user
with it.

The first use case I had in mind were CUSAX accounts where the SIP
account can be configured to use a specific XMPP account for bridging.

What you are saying also makes sense though and could prove very handy
for the more tech savvy users.

I think what we could do is something between the two. An op set could
return the available videobridges. The GUI would show them if they are
more than one.

An XMPP account's configuration would allow the user (or a provisioning
admin) to export the bridge.

A SIP account would, by default use a bridge from a CUSAX related XMPP
provider. If no such provider is defined it could return all exported
bridges. If there are more than one, the GUI would allow the user to
choose.

Just to make sure I get it right:
XMPP and SIP accounts can have a videobridge address associated with
them with a property.

We already have a way of linking a SIP account to an XMPP one in a CUSAX
relationship:

sip.acc123.cusax.XMPP_ACCOUNT_ID=accxmpp456

The idea was that, when this property is available, we can also use it
for choosing the bridge.

Ok, got it, for CUSAX SIP accounts we search for a bridge on the associated
XMPP account. No separate videobridge property needed.

If the selected account has a videobridge
configured this way, the GUI displays no list and tries to use the
videobridge that is configured. Otherwise, it obtains the list of all
available videobridges, but only shows it if it has more than one
element.

Yup.

I think the list should be shown even if it has a single element.
Otherwise the user could incorrectly assume that a videobridge
associated with the selected account will be used (after all this is the
current behaviour).

Hmm ... I don't believe such an assumption would really be a problem. My
main concern here is not to bombard users with information they wouldn't
necessarily care about.

Let's think about it a bit more. Maybe we can hide the bridge setting
behind a button or something.

Well, I think that's important information that users need to have (at least
in some cases). Say I have a corporate account and a public (that is,
untrusted) account. The corporate account's videobridge is down. When I
create a conference, the public account's videobridge will be used.

Good point! You've convinced me.

Emil

···

On Tue, Jul 23, 2013 at 3:06 PM, Boris Grozev <boris@jitsi.org> wrote:

On 7/23/13 3:35 PM, Emil Ivov wrote:

On 23.07.13, 14:27, Boris Grozev wrote:

On 7/23/13 2:22 AM, Emil Ivov wrote:

On 18.07.13, 13:38, Boris Grozev wrote:

We are not there yet anyway :slight_smile:

Alright, I'm leaving the details for later :slight_smile:

Regards,
Boris