WebRTC As Softphone Substitute ?
Hello,
This morning, I asked myself if WebRTC could be a viable alternative to softphone deployment.
For me, main issue with Softphones is the amount of work needed for installation and configuration. Also, Softphones must be carefully choosen if Deskphone-like quality is expected.
Now that WebRTC becomes ubiquitous, it might make sense to trade Softphone features (call history, BLF, …) for WebRTC deployment simplicity.
What do you think of this ?
What kind of experience did you met with such WebRTC deployments ?
What about classic telephony features (CallTransfer) ?
Have you tried Cyber Maga Phone 2K ?
[1] https://github.com/asterisk/cyber_mega_phone_2k
Best regards
11 thoughts on - WebRTC As Softphone Substitute ?
Speaking purely on CMP2K it’s example code and is by no means a real phone. It was made to show off the video conferencing support. You’d be better off using JsSIP example code instead for making a solution in that area.
—
Joshua Colp Digium – A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW – Huntsville, AL 35806 – US
Check us out at: http://www.digium.com & http://www.asterisk.org
—
If you can get it to work WebRTC is a good option. The problem is that any changes in your network may disrupt it and even trying to replicate your installation is difficult. I have it working fine on my website so customers can call us directly from our web page but I never could get Cyber Mega Phone 2K to work on the same server. We used JSSIP
to create the webrtc phone on our website.
—
Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez
+52 (55)8116-9161
—
We just updated the documentation for how to get CMP2K working on the wiki [1]. We’d love some feedback if you still have issues getting it setup so that we can improve the docs.
[1] https://wiki.asterisk.org/wiki/display/AST/Installing+and+Configuring+CyberMegaPhone
Best wishes, Matthew Fredrickson
—
Le mer. 26 sept. 2018 à 16:40, Carlos Chavez a écrit :
Very interesting !
Can you elaborate a bit further ?
Are we talking about network settings (IP, routing table) or rather changes in browser themselves or both ?
Yes, I also think replicating someone else’s browser is nearly impossible if you don’t control end devices (and even so …). If tiny differences make a whole experience succeed or fail … I thought WebRTC were stable now.
If you have to dig in tiny details and can’t even rely that your past will prevent most issues, it is rather discouraging.
remote video. I can only see my own feed. We do have audio for a little while. For some reason the users get disconnected after a few minutes even though you can still see your video feed on screen. This was done with Asterisk 15.6.0
—
Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez
+52 (55)8116-9161
—
Hi Olivior,
We have recently worked on a WebRTC based agent panel. As based on my experience I think that WebRTC based phones are far better and cheaper then those soft / sip phone. the big plus is that they are easy to customize and developer can use the power of browser and web to build / offer features which are not possible with regular phones.
Regarding your concern about BLF or call history, for me as a being developer it is just a matter of customization.
Regards
Nasir Iqbal
ICTBroadcast – an Auto Dialer software for ITSP
<https://www.ictbroadcast.com/how-become-internet-telephony-service-provider-itsp-using-ictbroadcast-sp-edition>
SMS, Fax and Voice broadcasting & Inbound / Outbound Campaigns http://www.ictbroadcast.com/
@Nasir:
Thanks for replying here.
Did you met in your deployments, the kind of stability issues Carlos reported earlier ?
Le sam. 29 sept. 2018 à 13:32, Nasir Iqbal a
écrit :
@Olivior I agree that seting up WebRTC is hard, however when done it is smooth to use. For replication you can build RPMs with working configurations.
Regarding stability, it is not being used widly, so can’t say it is mature. However we have no complain so far regarding audio or connectivity. sometime we provide support for “allow media / mic” type issues, but you know it is security feature and not a bug.
Regards
WebRTC requires a few specific things to be in place. We have blog posts that talk about WebRTC based Thirdlane Connect, but most of the information applies to WebRTC applications in general.
https://www.thirdlane.com/blog/get-up-and-running-with-thirdlane-connect
https://www.thirdlane.com/blog/nat-stun-turn-and-ice
Best regards, Alex
Alex Epshteyn alex@thirdlane.com
+1 (415) 261 6601
http://www.thirdlane.com
Thanks for sharing this, Alex. It sounds like TURN, as a media repeater, wouldn’t work if the media must be secured (via SRTP). Is that right?
No, this will not be a problem. TURN relays media based on RTP headers which are unencrypted. SRTP encrypts only the payload of RTP packets. DTLS-SRTP is one of the things mandatory to implement and support things in WebRTC, and it will not speak RTP/AVP. Asterisk may have to unencrypt payload for media paths that require that, which TURN server is not able to do.
Best regards, Alex
Alex Epshteyn alex@thirdlane.com
+1 (415) 261 6601
http://www.thirdlane.com