[SIP Beyond VoIP] Sylkserver Participant Management

Andreas Bachmann andreas at jibemobile.com
Tue Jul 16 13:26:03 CEST 2013


In theory - yes. I never did something in python - but developed a few
conf servers in Java and more than one IMS client (MONSTER,
OpenIMSClient,...).
At least I was able to compile everything from source ;).
The first two things look quite simple.
The third rule is a bit tricky as SylkServer has no "conference state
history". So if a user left/disconnected - he is removed from the
conference state. 
This would be more effort to implement.

I will have a look at this next week.

Andreas

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

>Can you provide resources for developing such feature?
>
>Adrian
>
>On Jul 16, 2013, at 1:17 PM, Andreas Bachmann <andreas at jibemobile.com>
>wrote:
>
>> 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