[jitsi-dev] Jingle 'kick' reason used in Jitsi Meet


#1

Hi,

We use 'kick' reason for kicking out participants from Jitsi Meet
conference[1]. However there is no such reason defined in Jingle
specs[2]. Because of that our Jitsi reason IQ provider throws an
exception and XMPP provider connection is killed after that[3].

There are few options of solving the issue:
1. do not let the exception "fly"[3], but catch and log it. Then
provide NULL reason when parsing Reason IQ which will also mean that
the reason is invalid.
2. change reason to 'decline' or 'cancel' in Jitsi Meet
3. make reason not an enum, but a String that can handle any value

What do you think ? My bet is option 1 and I'm going to apply it on
Monday if no one objects until then.

Regards,
Pawel

[1]: https://github.com/jitsi/jitsi-meet/blob/master/moderatemuc.js#L46
[2]: http://xmpp.org/extensions/xep-0166.html#def-reason
[3]: https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/impl/protocol/jabber/extensions/jingle/ReasonProvider.java#L57


#2

I'd recommend gone with an additional application specific kick error in some http://jitsi.org/ ... namespace as described in
http://xmpp.org/extensions/xep-0166.html#def-reason

Semantically decline should only be sent by the responder and cancel only by the initiator -- but before the session is in active state.

···

Am 08.08.2014 16:38, schrieb Paweł Domas:

2. change reason to 'decline' or 'cancel' in Jitsi Meet


#3

Hi Pawel,

Good catch! This is actually my fault.

(more inline)

2. change reason to 'decline' or 'cancel' in Jitsi Meet

I'd recommend gone with an additional application specific kick error in some http://jitsi.org/ ... namespace as described in
http://xmpp.org/extensions/xep-0166.html#def-reason

Semantically decline should only be sent by the responder and cancel only by the initiator -- but before the session is in active state.

I agree with Fippo here. I think in this case sending a 'cancel' and an additional application specific error reason (the third point in fippo's link) is the best way we can handle this.

Cheers,
Yana

···

On 08 Aug 2014, at 16:49, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

Am 08.08.2014 16:38, schrieb Paweł Domas:

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


#4

Hi again,

Hi Pawel,

Good catch! This is actually my fault.

(more inline)

2. change reason to 'decline' or 'cancel' in Jitsi Meet

I'd recommend gone with an additional application specific kick error in some http://jitsi.org/ ... namespace as described in
http://xmpp.org/extensions/xep-0166.html#def-reason

Semantically decline should only be sent by the responder and cancel only by the initiator -- but before the session is in active state.

I agree with Fippo here. I think in this case sending a 'cancel' and an additional application specific error reason (the third point in fippo's link) is the best way we can handle this.

Now I see the "but before the session is in active state.". Does that mean that Fippo, you suggest to use "decline"? Isn't it kind of strange and confusing to use a "decline" in the case of a kick initiated by the focus? Could you please elaborate? :slight_smile:

Cheers,
Yana

···

On 08 Aug 2014, at 17:31, Yana Stamcheva <yana@jitsi.org> wrote:

On 08 Aug 2014, at 16:49, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

Am 08.08.2014 16:38, schrieb Paweł Domas:

Cheers,
Yana

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


#5

hey yana,

> Now I see the "but before the session is in active state.". Does that mean that Fippo, you suggest to use "decline"? Isn't it kind of strange and confusing to use a "decline" in the case of a kick initiated by the focus? Could you please elaborate? :slight_smile:

Well, the description of 'cancel' is
  The initiator wishes to formally cancel the session initiation
  request.

so this should imo only be used to cancel a session before receiving a session-accept. I think the text for decline should actually be similar,
  The party wishes to formally decline the session initiation request.

(Peter? :slight_smile:

Doesn't make a difference code-wise imo, just general protocol design nitpicking.

<expired/> might be a good alternative to <gone/> too... "you are now longer welcome here" :slight_smile:


#6

What we are really looking to do is just do a session-terminate with app specific signalling that describes it as a kick. I am not that worried about continuing to use "kick" (the amount of text exchanged on the topic greatly surpasses the effort it would have cost to update the IQ provider to understand it).

The jingle specs can add this reason (or the possibility to have an app-specific one) in the next update.

Emil

···

On 08.08.14, 10:47, Philipp Hancke wrote:

hey yana,

> Now I see the "but before the session is in active state.". Does that
mean that Fippo, you suggest to use "decline"? Isn't it kind of strange
and confusing to use a "decline" in the case of a kick initiated by the
focus? Could you please elaborate? :slight_smile:

Well, the description of 'cancel' is
     The initiator wishes to formally cancel the session initiation
     request.

so this should imo only be used to cancel a session before receiving a
session-accept. I think the text for decline should actually be similar,
     The party wishes to formally decline the session initiation request.

(Peter? :slight_smile:

Doesn't make a difference code-wise imo, just general protocol design
nitpicking.

<expired/> might be a good alternative to <gone/> too... "you are now
longer welcome here" :slight_smile:

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

--
https://jitsi.org


#7

Fippo just pinged me that jingle already allows for app-specific reasons (and the schema in 0166 seems to confirm) so we can continue using kick and Pawel, could you please just add support for unknown reasons?

Emil

···

On 08.08.14, 10:55, Emil Ivov wrote:

What we are really looking to do is just do a session-terminate with app
specific signalling that describes it as a kick. I am not that worried
about continuing to use "kick" (the amount of text exchanged on the
topic greatly surpasses the effort it would have cost to update the IQ
provider to understand it).

The jingle specs can add this reason (or the possibility to have an
app-specific one) in the next update.

Emil

On 08.08.14, 10:47, Philipp Hancke wrote:

hey yana,

> Now I see the "but before the session is in active state.". Does that
mean that Fippo, you suggest to use "decline"? Isn't it kind of strange
and confusing to use a "decline" in the case of a kick initiated by the
focus? Could you please elaborate? :slight_smile:

Well, the description of 'cancel' is
     The initiator wishes to formally cancel the session initiation
     request.

so this should imo only be used to cancel a session before receiving a
session-accept. I think the text for decline should actually be similar,
     The party wishes to formally decline the session initiation request.

(Peter? :slight_smile:

Doesn't make a difference code-wise imo, just general protocol design
nitpicking.

<expired/> might be a good alternative to <gone/> too... "you are now
longer welcome here" :slight_smile:

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

--
https://jitsi.org


#8

What we are really looking to do is just do a session-terminate with app
specific signalling that describes it as a kick. I am not that worried about
continuing to use "kick" (the amount of text exchanged on the topic greatly
surpasses the effort it would have cost to update the IQ provider to
understand it).

Ok so I'll just add "kick" to our Reason enum.

The jingle specs can add this reason (or the possibility to have an
app-specific one) in the next update.

There is such option already and I guess that's what Philipp meant:
"The <reason/> element MAY contain an element qualified by some other
namespace that provides more detailed machine-readable information
about the reason for the action."

Apart from that I do not like the fact that our XMPP provider dies
after receiving invalid reason string and I'm going to fix it anyway
if you don't mind.

Regards,
Pawel

···

On Fri, Aug 8, 2014 at 5:55 PM, Emil Ivov <emcho@jitsi.org> wrote:


#9

Well, don't do kick please, unless in addition to
undefined-condition as defined in
http://tools.ietf.org/html/rfc6120#section-4.9.3.21
-- and we'll poke Peter to add that to the next revision of 0166.
This would basically mean "please look at the application specific error child in the other namespace"

···

Am 08.08.2014 um 18:03 schrieb Emil Ivov:

Fippo just pinged me that jingle already allows for app-specific reasons
(and the schema in 0166 seems to confirm) so we can continue using kick
and Pawel, could you please just add support for unknown reasons?