FedRTC.org SIP and XMPP service - help needed

Daniel Pocock daniel at pocock.pro
Fri Nov 13 10:32:42 UTC 2015



On 13/11/15 10:20, Peter Robinson wrote:
> On Fri, Nov 13, 2015 at 8:19 AM, Daniel Pocock <daniel at pocock.pro> wrote:
>>
>>
>> On 13/11/15 00:00, Jared K. Smith wrote:
>>>
>>> On Thu, Nov 12, 2015 at 2:36 PM, Daniel Pocock <daniel at pocock.pro
>>> <mailto:daniel at pocock.pro>> wrote:
>>>
>>>     I've been looking at ways to expand on the fedrtc.org
>>>     <http://fedrtc.org> service and would
>>>     like to start creating a team around the service just as we did in
>>>     Debian[1].
>>>
>>>
>>>
>>> Ordinarily I'd probably be the first to encourage this, but having done
>>> a lot of the work to setup Fedora Talk many years ago, I'm not sure this
>>> is a good fit for Fedora Infrastructure.  Why?  Because with Fedora
>>> Talk, we saw that the service wasn't used very much, and while the
>>> maintenance burden on the Infra team wasn't big, it was still one more
>>> thing they had to worry about, and something that the didn't feed 100%
>>> confident in administering.  Do you have any statistics on how much the
>>> service is being used by Fedora contributors?
>>>
>>
>>
>> I replied to those same queries on the infrastructure mailing list[1]
>> and I've largely copied the reply.
> 
> <snip a bunch of marketing>
> 
>> Actual stats: 26 people have tried the service so far.  In Debian, we
>> have had over 200 people (about 25% of developers).  FedRTC.org has not
>> been promoted as an official service so I think it is reasonable to
>> suggest usage will increase if it becomes officially supported and if
>> XMPP is part of it too.
> 
> Those aren't stats. By "tried" do you mean created an account and
> logged a SIP/XMPP client to the service? Or are actively use it?
> 

I'm not monitoring it and reporting on it to the same extent.  The
previous service, based on Asterisk, would have been collecting call
records in a CSV file but SIP proxies don't exactly work like a PBX so
they don't log to a CSV file.  For example, would every status update or
chat message be logged just like a voice call?  SIP proxies can also
operate statelessly, so the INVITE that starts a call may pass through
one proxy and the BYE to end the call may pass through another.  This
architecture is distributed, resilient and lightweight but not ideal for
fine-grained activity monitoring.

I do have a task to add Ganglia integration to the SIP proxy, this would
track a number of things like SIP requests and responses per second:
https://www.resiprocate.org/bugzilla/show_bug.cgi?id=98

That is intended for operational purposes such as capacity planning but
I could also provide some metrics useful for evaluating community
engagement.

The Prosody XMPP server could do something similar.  If the buddy lists
are stored in PostgreSQL then the usage can be evaluated with an SQL query.


> In both the FedRTC and debian case how many calls are made a
> day/month, what is the volume of XMPP etc? In the later case we
> already use both IRC and Telegram within the community, I'm not sure
> what value yet another text messaging service provides.
> 
> What happens if it was possible to delegate a DNS record(s) and
> provide FAS integration and have it hosted somewhere else in the short
> to medium term to see how popular it is with proper named and "buddy
> lists" than can be migrated if it becomes overwhelmingly popular with
> proper stats to back it up?
> 

Yes, it would be very easy to migrate:

- install the packages from EPEL7

- dump and load the PostgreSQL databases

- copy stuff from /etc/repro, /etc/reTurn and /etc/prosody and use sed
to swap the IP addresses

- change DNS entries

If it is running on my own servers as suggested in the alternative
strategy then I would be happy to give access to somebody from the
Fedora infrastructure team so they can take a snapshot of the data
(buddy lists and password hashes) whenever they like.  We could even
look at a hybrid approach where the servers connect to a PostgreSQL
instance on Fedora infrastructure.

Regards,

Daniel


More information about the devel mailing list