[SIP Beyond VoIP] Sylkserver Participant Management

Adrian Georgescu ag at ag-projects.com
Tue Jul 16 13:09:01 CEST 2013


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