Integration with PSTN (telephone networks)

[xadhoom]

There's some idea going around the integration with PSTN?

Basically I see a new right panel, which opens a simple dialer, with which you can call "something".
And being registered it can also receive calls.

This something can be a sort of js sip phone registered to some switch, which handles the media part using webRTC.

I've some experience with FreeSwitch, so if is acceptable to use it as the voip backend, the web phone can be verto-based, which simplifies a lot the call signalling. Using a plain js-sip phone can a bit more problematic since you have to handle all little compatibility issues that may arise using different soft switches.
(then FS may act as a bridge between verto and sip, if needed)

Verto reference: https://freeswitch.org/confluence/display/FREESWITCH/mod_verto

Being an UAC registered to some server, the account panel should have some entries to enter the login details, server and so on.

Any comment, ideas? Maybe is already in progress?

[daniel-centore]

Just to give another idea, I think it would be awesome to be able to install an app on a smartphone and use that as a proxy from the computer for calling.

[xadhoom]

@daniel-centore afaik, is not possible for any app (except maybe rooted phones) to place an automated gsm call and bridge the audio channels from another stream.
And I think is also a bit outside the scope of this integration ( my opinion ) since the goal should be to place a generic call (or receive) from the webapp on a gateway, which can do basically whatever you want :)

[daniel-centore]

Ah that's too bad. Just something I've always wanted to do.

[xadhoom]

I'm playing a bit with it and have a somewhat working phone (using) verto which speaks to a FreeSWITCH server. Then from FS you can call any endpoint it supports, like SIP, PSTN, whatever.

Right now it has A/V calling, hold call, mute call, redial last number, call transfer and full screen video.

Code is here https://github.com/VoiSmart/Rocket.Chat/tree/verto_phone
If is of some interest, I'm going to polish it a bit ( help on layout side is welcome! ) and maybe try a PR (before I need to clean code, make strings i18n compatible, fix some little bugs, css...)

Now some screenshots !

Call without video

Calling the echo test (video and audio are sent back by FS)

Basic default layout

Settings Panel

[danielwegener]

Just a curious question: Is this sip-dialer intended to somehow be integrated into the rest of the application? does it fit into the concept of users or channels or does it interact with them at all?
Otherwise I'd not see it as a "core" feature and rather suggest to rather provide a script api that allows users to create "sidebar widgets" that could be sip-dialers, calender widgets, minesweeper clones or whatever :)

[xadhoom]

well, it depends on how you defined "integrated"

I took this task from the roadmap, where it says a generic "pstn integration"

If you want to integrate with pstn, there's no real concept of rooms/channels/whatever, just numbers to be called.

basically this is a phone you can use everytime while you've the messaging application open.
Think about is as a "unified communication", is pretty common the need to have a normal call over the pstn while you're also chatting and so on.

But to do this, you need a softswitch, and I've used FreeSWITCH for that, since doing a verto phone is way easier than doing a sip phone.

This app more similar to the recent videobridge, which does nothing if you don't have an external jitsi server.

About API: I've not found an official API for this kind of widgets in the sidebar, but is pretty trivial to build one, since they can be pretty self contained.

The phone I'm playing with is almost self contained, there's just a small patch to the user configuration in order to add the softswitch crendentials.
But if someone can point me on how to add such additional user parameters without patching the core, is more than welcome and the package can be really self-contained.

[danielwegener]

@xadhoom If its on the road-map, consider my comment as not given :) Sorry actually I wasn't aware of the roadmap and was a bit concerned about feature creep.

One useful integration could be to detect and highlight telephone numbers in the channel history. Clicking such a link could start a call to that number.
I also think this the whole feature should be toggleable (maybe via role permission?)

[danielwegener]

I'd also be happy if we could unify the io-device configuration with #3635

[xadhoom]

yes it is on the roadmap, but still no word from the core devs :)

right now the feature is just on/off for all, like others.
Adding it on a role base is a good idea, I'll look into it.

also the phone numbers highlight is a good one, maybe simpler. I'll check that, too.

[xadhoom]

about unifying the device conf, make sense :)

but before doing that I'll like to:

• have some feedback from core devs if this feature is needed or not and comments
• finish a first set of features (like role, numbers highlighting)

done that, integrate it with the new io-device feature you're working on (if finished).

I'm also using adapter.js and having a single one is definitely a good idea.

[Sing-Li]

So we gave a lot of thought into this, which is essentially #1830

Put bluntly, if it is just a SIP dialer that is embedded handily inside chat, and it has access
to people that is not even registered with the chat server - we're not
interested in competing. There are specialized and much better suited utility
SIP phones and dialers around right now, and they'll only get better.

Also, this sort of utility-ware might be best featured in our upcoming Apps Marketplace.

Then the rest boils down to two general technical camps: first party call handling and third
party call handling.

But before either can take place, we'll need to add phone number to the user record, and
perhaps have some way to grab it and store it via our mobile client.

Third party is most interesting. If I'm in private group chat, or a channel, and I click
a button on the toolbar (just like Jitsi integration right now) - the plugin logic should go out to
the PBX and setup a conference call with the participants in the channel. And depending
on individual preference, either have the PBX outcall to the participant, or await for authorized
incoming.

If I'm in a direct messaging session, one-on-one, then clicking that same button either places a
first party call to the recipient (or perhaps can still create a conference call for 2 - and
cater to individual preferences - to avoid toll charges).

Making third party handling even more interesting moving forward is our intention to start on
some convergent digital call center features - by extending LiveChat. See #1824

Basically, right now, the inbound originates from a website's popup-chatbox, and the ACD routes to an
appropriate agent that will handle the call. But if we have the inbound's phone number,
we can connect a PSTN call as part of the session. We also want the ability
eventually to have the ACD starts from a conventional PSTN call - and then if the inbound
is on an appropriate device ... screen-pop information and/or chat sessions to facilitate
the call.

[xadhoom]

the main issue I see in this automatic approach is that basically you're binding the voice app to a specific PBX with a specific configuration.

Obviously this is the best approach for the user, but which one can be used?
Also using an existing one, you need to setup some configs that Rocket expects in order to do all the magic.

And this config may not fit correctly in a typical company PBX scenario.

Maybe creating a more complex configuration on Rocket side where you assign numbers to different service, like audio conference or whatever.

Right now I'm experimenting the following:

1. the "phone" configuration has also an extension number, which depends on PBX setup
2. if you double click on the avatar, a phone call is sent to the user, using the PBX ( 1:1 call )
3. if you click on a side bar button, a new conference room is setup on the PBX and all devices can call and join an audiobridge, like joining jitsi.

obviously, if the phone is logged into a PBX queue, it may also receive support calls from pstn :)

Points 2, 3 are PBX specific, and I'm doing them using our own PBX which is FreeSWITCH based,
with a specific configuration.
To have a full "generic" solution some kind of abstraction must be built.

[Sing-Li]

Thanks @xadhoom for your ideas. Warning: this discussion is venturing into business area rather than technical at this point.

To handle the required volume and scale that Rocket.Chat typically ends up deploying in, we must first work with a PBXaaS (PBX as a service) platform provider - there are quite a few out there, as you're aware, and we will likely partner with one.

Eventually, to allow small deployments to have the same sort of feature (although we really need to fully understand the typical small deployment need (use-case, and how niche/small the user base for this is) for full PBX features before we proceed) - we will have to offer a "plug-in" styled support with a focus on Asterisk [and derivatives] styled interfaces.

For the hobbiest, and the one-off scenario, our source code is wide open. Be innovative and creative! And we'd luv to see your add-on in our upcoming App Marketplace.

[xadhoom]

Yes, this is a business talk right now :)

well using a SaaS provider might limit the applicable market, for example in Italy is no (yet) widespread.

and when you hit the real companies, you need to integrate in some way to fit all needs.
(and source code + clean packages in Rocket is really helpful)

btw, I'll continue with my exercise with verto, which, right now, is going to be deployed to several users with FreeSWITCH as backend.

I've some experience with asterisk/freeswitch world, so I'll be very glad to help in some way.

Even diverting what I'm doing to fit the whole project.

[Sing-Li]

btw, I'll continue with my exercise with verto, which, right now, is going to be deployed to several users with FreeSWITCH as backend.

I've some experience with asterisk/freeswitch world, so I'll be very glad to help in some way.

Even diverting what I'm doing to fit the whole project.

@xadhoom 🔝 is what FOSS projects like us ❤️ to hear !

Please Direct Message me on https://demo.rocket.chat and we'll literally hook you up 👍

[abduljanjua]

@xadhoom Hi! I downloaded you repo but I was unable to find Vetro feature.
How I can enable it.
I am looking for integration of SIP with rocket.chat

Thanks

[xadhoom]

Well,

first of all Verto is not SIP. if you're looking for SIP this is not the
right place.

Second, since this feature is not having a lot of interest (at least, as
appears to me),
we have stopped to make it generic.

So our repo has the integration with Verto (not SIP) and our own freeswitch
based pbx
and cannot be used as a generic solution.

matteo

On Thu, Nov 10, 2016 at 4:21 PM, abduljanjua notifications@github.com
wrote:

@xadhoom https://github.com/xadhoom Hi! I downloaded you repo but I was
unable to find Vetro feature.
How I can enable it.
I am looking for integration of SIP with rocket.chat

Thanks

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3488 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMFXfMSCPwJmuUJmNMVveyM1SY1TP2Fks5q8zaJgaJpZM4Iw0ik
.

[shaunjstokes]

I can assure you there will be a great deal of interest but these things can take time.

Verto (FreeSWITCH) offers a tremendous amount of potential and is one of the few solutions which can replace SIP and other legacy protocols while still maintaining interoperability.

FreeSWITCH is striving to be on the cutting edge of technology, to add Verto integration to Rocket Chat will certainly be a key selling point for many organizations and opens up the potential capabilities and features of Rocket Chat.

I for one would like to see this fork merged with the current Rocket Chat project.

[novpiseth]

I accepted the idea for PSTN. but can choose FreeSWITCH also asterisk sometime people use asterisk and they not dared to change their technology.

[reetp]

All NFRs are now being referred to the forums for discussion.

Please open a new thread there please https://forums.rocket.chat/c/feature-requests

[reetp]

@rocket-cat close