[SIP Beyond VoIP] Sylkserver Participant Management

Andreas Bachmann andreas at jibemobile.com
Tue Jul 16 13:17:31 CEST 2013 

Oh, don¹t get me wrong - this is a simple server config thing. This will
let the admin define the policy for the server. I would not go that far to
change the policies for individual sessions.

Andreas 

On 16.07.13 13:12, "Adrian Georgescu" <ag at ag-projects.com> wrote:

>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.
>
>Adrian
>
>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