[SIP Beyond VoIP] Sylkserver Participant Management

Adrian Georgescu ag at ag-projects.com
Tue Jul 16 13:40:32 CEST 2013


On Jul 16, 2013, at 1:26 PM, Andreas Bachmann <andreas at jibemobile.com> wrote:

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

Well, if you look at the code, the room is a persistent object with attributes and state and you can add more data structures to it to hold whatever is relevant for the purpose, then use that data when a request comes in. Programming in Python and understanding of high level concepts of SylkServer are enough, there is no need to know any of the protocols involved.

Help for extra development would be much appreciated.

Adrian



> 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> _______________________________________________
> SIPBeyondVoIP mailing list
> SIPBeyondVoIP at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip



More information about the SIPBeyondVoIP mailing list