I am working on a webRTC application and would like to be able to support multiple calls and be able to call from the browser to legacy VoIP or Videoconferencing systems as well as browser to browser.
now that Asterisk has added websocket in their latest builds would you need SIP and a SIP proxy in order to communicate with VoIP systems or will Asterisk allow this?
now that H.264 has been open sourced by Cisco would you still need a transcoder in order to call a legacy VTC system?
Is Node.js the preferred technology for implementing webrtc client/server deployments? I've looked into Mobicents SIP Servlets a bit but that seems to be the only alternative technology available beside a node.js solution.
If needed I am planning on creating a SIP trunk between an Asterisk server and our Polycom VBP so the webrtc clients should be able to get presence information through that connection so if no media transcoding is required with the recent changes then media should be able to pass directly from polycom endpoint to browser with the asterisk handling the signalling.
Thank you anyone who is able to answer any of these questions, it is still early in the r&d portion of this project for me and i'd like to get as much information as possible.
also: i did see SIP over websockets to true SIP. I understand that "something" needs to stand in between the webRTC client and the VoIP phone or Legacy SIP endpoint. what I would like to know is if that can be just asterisk with the recent update. if asterisk is all that is required, is there a way to include a media transcoder like red5? I haven't seen anything in the webrtc API that would allow you to include a transcoder, asterisk has transcoding mods but none that will do vp8 to h.26x or Opus to anything as far as i know.
Answer on that question higly depend of destination "legacy" system. Cisco "legacy" systems use h323 and sip, which is not compatible with webRTC.
Sure there are alot of ways to setup asterisk, red5, opensips or other as translation level.
Webrtc goal is call from browser. It never supposed have any API for transcode. That have be done by server part(which require special knowledge and experience to be propertly setup)
There are alot of availible documentation in internet, no any way put answer in less then 30 pages of text.
Related
We are developing a multimedia conference application and want to connect to Lync or Skype for Business.
Now we can transfer video stream (H264) and audio stream between Skype and our client.
But sharing stream stuck us,especially parsing the RDP protocol.
We have got the RDP stream,but how to get sharing contents?(Only the graphics data)
Our application run on Linux, Mac and Windows(mostly on Linux).
So is there any third-party solutions to deal with the RDP?
As I known, Polycom has completed this function.
Please keep noted that the Microsoft Remote Desktop Protocol (RDP) was replaced by Video Based Screen Sharing (VBSS) when using Skype for business. See here or here for more infos. As VBSS is the new standard, this might explain your issue. A possible solution might be to check how you can start using Video Based Screen Sharing (VBSS). I wouldn´t start building something on RDP as Microsoft might remove that in further version as there is VBSS.
However as you didn´t specify more infos for your "Solution" its not easy to give you and advise. Keep also noted that this isn´t the case for Lync. But as you specified Skype for Business and Lync I´m not sure if you see the issues with both server versions.
My country is blocking VOIP, so basically I can't make audio or video chats. However when using Teamviewer, it's always possible to make audio and video conferences, so what I want to know is how is that possible, and what are exactly the VOIP protocols used to allow me chat in audio and video?
I knew from a previous question that the teamviewer is a closed source but I'm still waiting for any protocols that would work even if the VOIP is blocked.
Regards.
If your network / country network do support for WebRTC then this would help.
RTC - Real time communication is a protocol, everything works on this only. Whether it is skype, teamviewer, whatsapp video call etc.
Setup you own WebRTC server and obtain absolute URL with its protocol. Make sure that has to be work within your network only. When your devices are in wifi / network. They can connect each other through absolute URL.
Refer - https://github.com/ISBX/apprtc-ios/blob/master/README.md
I need a SIP server, hopefully simpler, more efficient and more secure than Asterisk or other full-featured PBX, to just terminate SIP calls and play audio, based on the incoming number. This would be in a linux environment.
I'm concerned about long-term support, and much-reduced attack surface. I'm a programmer but a no0b in the SIP world. I want to avoid the tons of security hassles of a full-featured PBX, let alone the crazy big bills after a hacker gets into it. Thanks in advance!
Personally I would build one with pjsip. Assuming you do not need built in registration server all calls would be handled by so called local account. You can use command-line pjsua with auto-answer and auto-play options for initial tests and then add some logic for audio wave selection and perhaps audio player allocation/deallocation (audio players could be active all the time and shared by multiple calls for efficiency if they e.g. contain something like background music).
For security disable not needed parts (TCP, TLS transports, not needed codecs?) and use port other than 5060. In my application I'm also using kind of application-level firewall that blocks requests from hosts that generate suspicious traffic (registrations, malformed SIP requests).
I'm looking to write my own multiplayer game server (most likely in nodejs) and I was wondering what protocol I should be using to transfer data? Are Datagrams the norm to send information (i realize they don't confirm delivery like HTTP, that can written on top of the protocol)? Any suggestions of performant proven systems would be a real help.
I guess I'm looking for successful techniques in handling the data transfer quickly and effectively (maintaining state on the server and scaling are a separate issue that I have a solid understanding of).
I'm looking to initially support desktop/mobile games (MacOS, iOS, and Android).
For all your protocol needs take a look at socketIO.
Basically your best solution is to rely on websockets which are TCP sockets. socketIO is just a nice cross-browser compliant abstraction.
Either you use standard long pulling techniques or html5 websockets. There is no access to UDP for browser <-> server.
There is a technology that is called RTMFP that Adobe introduced in the latest version of Flash (Flash 10). It allows you to do P2P connection and transfer data directly from a client to an other client without passing by the server. On top of that, it's using UDP to transfer data. I believe that this was originally designed to do video and audio streaming, but you can use it to pass data around.
However the main downside on this technology is the mobile since most of them don't support Flash. In this case you can use Socket.IO and use the server as a router of information as a fallback.
If you want to build your application in Javascript, you can still use it by bridging the functionnality to Javascript. If you want to take a look at a simple version of a bridge, you can take a look at this github project (I am the author).
As a C++ developer of Massive Multiplayer games for 10 years, I can tell you that most of your more advanced games, such as ones in which I was involved (Legends Of Kesmai, Magic: The Gathering Online, Airwarrior II, AVP, NTN Triva) to name a few, TCP is used for most communication simply because you need an ACK / NACK to be sure the data was received from the client. That is not to say UDP doesn't have it's place. In Legends we wrote the the protocol code to use UDP for out of bandwidth delivery of data which wasn't imperative that it be received in proper packet order and complete. Use UDP when you want to do things like update graphic files in the background while the user is playing, etc. This type of delivery is often used for such purposes and allows your TCP packets to arrive as required by your server.
Google just announced that they will add support for VoIP calls in its Gmail application.
Does someone know how this will work? Did they manage to write a web-based VoIP client, or will they require the user to have Google Talk installed and somehow (how?) call this app from the browser?
I'd also like to provide customers with a way to make/receive calls through their browser, so that they wouldn't have to install an SIP client.
Thank you.
Google don't use a VoIP client in a browser. Instead the browser is used to initiate a callback to a phone number you must have previously registered. Once you answer that call Google Voice will then ring the destination number you specified and then bridge the calls together.
I've just noticed that in my inbox. They ask you to accept their EULA to start installing Google Voice. So it's not really a browser solution.
There are several companies that have built VoIP clients as e.g. Java applets.
It is totally doable, although depending on the exact requirements it may be expensive and time consuming: for instance, echo cancellation is not exactly trivial when you need to deal with arbitrary audio drivers across any and all laptops, netbooks etc out there.
There are also consulting firms that can help with that.
Full disclaimer: I own one such company ;)