[SIP Beyond VoIP] Sylkserver Participant Management
ag at ag-projects.com
Tue Jul 16 11:30:26 CEST 2013
On Jul 16, 2013, at 11:17 AM, Michiel Leenaars <michiel.ml at nlnet.nl> wrote:
> Hi Adrian, all,
> congratulations on the port to upstream PJSIP for the SDK, I know this
> has been something you've wanted for a long time.
Thanks for noticing. Sometimes we spend months working on stuff that nobody notices.
> I successfully built and tested the command line sip-session based on
> the new SIP SIMPLE SDK (on latest Fedora) with the sip2sip conference
> server. I used two independent SIP accounts from different servers for
> my test.
> 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?
> It would be more logical to only have this kind of power over
> people you personally invited.
Right now anyone can add/remove participants in any room. There is no policy enforcement functionality, it can be added but requires more development. But as the conference room URI must be known, the chance of bots doing stuff is minimal as they cannot guess the rooms in use, only those invited in the room know the room address.
For example, I create the room:
2142145214214214 at conference.sip2sip.info
and I invite you and others, how can a bot figure this out?
> One thing I would love to be able to manage is to personally mute or
> -20dB remote participants at the client side - so just for me. It would
> be okay to show this to them in some way, because there might be good
> technical reasons like a microphone problem or hindering background
> noise for blocking. I'm not sure a conference owner already has some
> facility to do this for the entire group, but at the client level this
> would be helpful to repair some situations.
Yes, it would be nice to have such controls, but without extra developments they are not possible out of the box.
> Michiel Leenaars
> Director of Strategy
> NLnet Foundation
> SIPBeyondVoIP mailing list
> SIPBeyondVoIP at lists.ag-projects.com
More information about the SIPBeyondVoIP