[SIP Beyond VoIP] Sylkserver Participant Management

Adrian Georgescu ag at ag-projects.com
Tue Jul 16 13:12:35 CEST 2013

Also there is nothing that makes sense available standards-wise to generate such policy in SIP. XCON working group created something but the complexity of that goes beyond manufacturing a new universe. (the BFCP protocol)

One could invent in-band mechanism like typing chat messages but is pretty ugly.


On Jul 16, 2013, at 1:09 PM, Adrian Georgescu <ag at ag-projects.com> wrote:

> On Jul 16, 2013, at 1:04 PM, Andreas Bachmann <andreas at jibemobile.com> wrote:
>> I think a basic policy set is nice and something u would expect from
>> systems like that. That other services as skype for example. There it's
>> also not possible for anyone to join any group chat or kick somebody if u
>> don't have the right to do so.
>> I think more than 90% of the use cases can be tackled by a simple limited
>> set of rules.
>> can-add : [creator | anybody]
>> can-remove : [creator | invitee | anybody]
>> If u want to put another one top:
>> can-join : [invited | anybody]
>> That prevents anybody to join the group which has not been invited before.
>> This is not a "I want to have this" - but just a thought on what would be
>> nice.
> Yes, is nice to have I agree. Nice to have features also need nice smart people to donate their resources to do it ;-)
>> Andreas Bachmann
>> Head of Realtime Communication Engineering
>> Jibe Mobile
>> 990 N Rengstorff Ave
>> Mountain View, CA 94043
>> Tel: +1 (650) 336-JIBE
>> Fax: +1 (415) 358-4254
>> http://www.jibemobile.com/
>> On 16.07.13 12:35, "Adrian Georgescu" <ag at ag-projects.com> wrote:
>>> On Jul 16, 2013, at 12:18 PM, Michiel Leenaars <michiel.ml at nlnet.nl>
>>> wrote:
>>>> Hi Adrian,
>>>>>> It worked well for me, I'm happy to report. I played around with
>>>>>> participant management. One thing I noticed: am I correct that I could
>>>>>> not only remove people in the room that I had invited to a Sylkserver
>>>>>> conference myself - with add_participant user at domain.com - but also
>>>>>> other people unrelated to me (as in: my other account when it had
>>>>>> registered itself independently to the chatroom)? That seems
>>>>>> undesirable
>>>>>> to me - some chatbot can come in and kick out all the participants
>>>>>> from
>>>>>> all rooms.
>>>>> How do you know the room names?
>>>> I think security by obscurity works reasonably well for ad hoc meetings,
>>>> although probing is cheap (e.g. dictionary attack). You could add
>>>> something to the server that allows to see if someone is trying out many
>>>> different rooms for activity sequentially. That would raise that cost
>>>> and help prevent abuse.
>>> How do you try in a sequence a random string?
>>> wfewbehuwgr3uruo3pi503957823bc56 at conference.sip2sip.info
>>> is a valid room.
>>> How to you guess it?
>>> Also trying requires infinite time as a call setup takes several seconds
>>> to complete. Then what do you have to gain probing random chat rooms?
>>> There is no incentive to do that.
>>>> Other use cases are different from ad hoc conferences like you mention,
>>>> I guess more like a classic IRC channel that is persistent and
>>>> publically known.
>>> For this you can define static rooms in server configuration. Only SIP
>>> addresses configured for the room can join. Unfortunately SIP does not
>>> have primitives for creating room policy.
>>>> This would be akin to a publicly announced conference
>>>> room where potentially many people participate over a longer period. In
>>>> that case confidentiality is not the issue, but it would be embarassing
>>>> if thousands of people are dropped off because of one person trolling.
>>> Well, such lists can be managed out of band, but this is complex
>>> functionality. 
>>> Remember that SylkServer implements ad-hoc rooms, we never claimed such
>>> policy can be managed. Ad hoc simply do not have such advanced policy,
>>> there are just simple to use. Simple to use is key, if stuff is
>>> complicated and requires management very few adopt it.
>>>> Also, it would be great if someone could somehow be granted a channel
>>>> operator role (perhaps not on sip2sip.info service, but in case of a
>>>> self installed system).
>>> Well, sky is the limit for developing such advanced features if resources
>>> allow it. I also have tons of additions in my head, webrtc end-point, web
>>> page management, streaming...
>>>>> Yes, it would be nice to have such controls, but without extra
>>>>> developments they are not possible out of the box.
>>>> Understood. We definitely need more manpower to work on these important
>>>> projects. We can't expect you and your team to solve everything for us.
>>>> Best,
>>>> Michiel Leenaars
>>>> -- 
>>>> drs. M.A.G.J. Leenaars
>>>> Director of Strategy
>>>> NLnet foundation
>>>> Science Park 400
>>>> 1098 XH Amsterdam
>>>> Netherlands
>>>> http://nlnet.nl
>>>> sip/xmpp: michiel [@t] nlnet.nl
>>>> ---------------
>>>> 'If you want the Internet to grow strong, safe and free,
>>>> but you don't know how to help, contribute to NLNet:
>>>> they do know and care."
>>>>                          Giorgio Maone, NoScript
>>>> Interested what Richard Stallman, Karsten Nohl, Andy Tanenbaum and
>>>> many others have to say about what NLnet helped them do for you?
>>>> Feel your wallet tingling already? Check out:
>>>>                       http://nlnet.nl/donating/quotes.html
>>>> _______________________________________________
>>>> SIPBeyondVoIP mailing list
>>>> SIPBeyondVoIP at lists.ag-projects.com
>>>> http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip
>>> _______________________________________________
>>> SIPBeyondVoIP mailing list
>>> SIPBeyondVoIP at lists.ag-projects.com
>>> http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip
>> _______________________________________________
>> SIPBeyondVoIP mailing list
>> SIPBeyondVoIP at lists.ag-projects.com
>> http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip

More information about the SIPBeyondVoIP mailing list