I have a lot of experience writing Delphi 6 Pro apps using the Skype API. I don't use the COM object but instead I interface directly with the Skype client using the SendMessage() system. My current application acts as a full duplex audio proxy with video transmit. To transport audio I use ALTER CALL with the PORT parameter to establish a duplex audio connection with the Skype client via a pair of sockets. For sending video I have a DSPACK based DirectX filter that I instruct the Skype client to select as the chosen video device. This works fine but since it's the Skype API I have the awkwardness of interfacing with the Skype client as a separate entity.
Now along comes SkypeKit which apparently allows a developer to integrate Skype in a much more integrated manner. I'm about to dive into it and I wanted to hear from any developers out there that switched over from the Skype API to SkypeKit. Some questions:
Was there anything missing from SkypeKit that is offered via the Skype API that made your app conversion difficult if not impossible?
Do you have any tips on making the transition as smooth as possible, especially when it comes to avoiding any design choices that can really come back to haunt you when you get far down the SkypeKit path?
Did you find any web resources or documentation from other developers that were really helpful in saving you time or trouble? (Please share links if so).
I am using SkypeKit in my chat-centric Java application so I haven't dealt with A/V.
SkypeKit is just a “black box” program that interacts with Skype protocol by iteslf. It is an executable that starts a process which listens on local port. The process is lightweight, only 20mB on my Windows-based developer machine. It runs completely in background, there are no any notifications at startup/messaging/shutdown.
Your client program interacts with it by sending byte structures via local SSL tunnel. These structures are wrapped by API for C++, Java and Pyton. Java API is easy. You start the process, create new Skype() object and login with your Skype account credentials and get your program callbacks execution when some events happen.
So #Whiler is not completely right, you always need a host application, but in this case this one is small and fast.
I don't know how hardware-based kit works but I think it is a more low-level way.
You can read the Java API here, C++ API (with examples) here, and Python (with examples) here.
Oh, and at least one small difference between desktop API and kit-based one: you can post XML text in the chat.
SkypeKit is no longer supported - https://support.skype.com/en/faq/FA12322/is-skypekit-being-discontinued
Disclosure: I used work for Microsoft/Skype
The main difference between SkypeKit and the other solutions (sendmessage, COM) is that the Skype client application is not needed... you can directly interact with the skype network...
I haven't dig this solution as the access is not free (not expensive, but without real projet, this was a no go for me...).
So this can be very useful if you plan to replace the real skype client with your own software on final machine... but if you just want to interact with an existing one, I'm not so sure.
Related
I am building a WebRTC videoconferencing service for iOS and Web. We have so far used tokBox, they deliver the whole package (client API (ios and web) + TURN server. Their solution also takes care of generating tokens and session ID etc. But we want to have our own setup, and a partner has given us a TURN server. But, what do we miss to be able to have a webRTC video conference between iOS and a web client? What service will let us just plug in the TURN server address/credentials and have it work both from a web and iOS client? Are these suitable packages: EasyRTC, SkyLink, AppRTC ? We don't need a lot of features, just 1-1 videocall with no bugs. Which one is best?
at minima you will need a signaling server.
apprtc is a complete application, it is not suitable for what you have.
tokbox is a PaaS, so you could replace it with another PaaS (skylink, forge, ...)
easyrtc gives you the code of a signaling server, but not the infrastructure (load balancing, ...), you can use it if you re ok to host it.
you might want to go for peerJS (open source, both hosted and DIY options) if you really want to do it yourself. Otherwise, just changing PaaS is not making a lot of sense. You have to think about everything you're gonna lose as well (recording, archiving, media server, ...).
If your use case is well defined, you can ping me offline, and i'll point you to additional resources.
You can look to Kurento media server.
You can use the service provided by anyconnect SDK. They provide the leading Peer to Peer connectivity between any two nodes whether browser, desktop or mobile platforms. They also provide STUN,TURN and Signaling (SIP,XMPP) server support. Using their SDK will let you just plug in your server credentials and transfer any type of data.
I want to implement a peer-to-peer video chat feature for a web application I am currently developing. After doing my research, I've decided that using webRTC's Javascript APIs is the way to go. The application uses AngularJS in the front end and Ruby on Rails in the back end. The main issue I'm encountering while conceptualizing this application is linking the front end with the backend, and creating and maintaining the connection between user streams.
For the signaling aspect of the network, I want to utilize ActionController::Live and the Ruby gem em-event source to push live messages from the server to users and indicate which of their connections are online. Then, when they are ready to make a connection, they will create a custom room and the URL will be sent to the user that they wish to connect with, creating their offer. Once the user clicks on the link sent to them, they send back their answer. When the user responds, the ICE candidate process will begin for each of the users. Do you think that this is a sufficient signaling channel to set up the PeerConnection? What other major players am I missing?
From the research that I have done about WebRTC's RTCPeerConnection, once the initial connection is set up, and both users have public IP addresses corresponding to their stream, the connection is sustained through RTCPeerConnection, more specifically getPeerConnection(). Am I wrong? Are there other factors that I am not considering?
WebRTC makes the process of creating MediaStreams very simple with their getUserMedia method. Once these streams are created they can be added to the RTCPeerConnection that was established. Both as local and remote streams.
If you have any other suggestions for me, please let me know. I want to create this feature using webRTC, it seems like so much fun
There are certainly many ways to handle the call signaling so I'm not going to comment specifically on your approach. I will say that if you plan on supporting ICE trickling the ICE candidates will start flowing very early in the process so you really need an open signalling channel between your peers almost immediately when trying to connect to a peer.
We developed our solution for WebSphere on top of MQTT which is an open, and very simple pub/sub protocol. You can use any open MQTT broker with the protocol and there are a number of open source components available to make WebRTC development extremely easy including an AngularJS WebRTC module (angular-rtcomm), a core pure JavaScript module and much more. We also released a simple JSON based protocol as part of this open source solution. You can take a look at the signaling protocol. You can also read more details about the overall solution here (www.wasdev.net/webrtc). Here you'll find the base JavaScript libraries as well as a number of open source sample solutions. All of these can be forked on github.
In general you want to build your signaling on a protocol that will allow you to grow over time. It should work well for the web and mobile apps. From our experience it took a lot of time to get all this to work well and our goal was to not only support peer-to-peer calls but to support using media resources like Dialogic's XMS PowerMedia server on the backend for multiway support, record/playback and more. We also needed to support federation via SIP trunking so we wanted to make sure the protocol could be easily translated to SIP signaling while also supporting transcoding between media protocols like VP8 and H.264.
Note that if you're looking to only support peer-to-peer calling between WebRTC clients you can do that with these rtcomm open source components only, including an open MQTT broker and save yourself a ton of time. You can literally get something up and running in a matter of hours. The developer version of the WebSphere Liberty beta with the new rtcomm-1.0 service enabled also includes a built in MQTT broker and supports the open WebRTC signaling protocol linked above. You can use WebSphere for development and deploy a single server of this in production for free. You can also use Ruby on Rails with Liberty as well if you'd like.
Even if you decide not to use Liberty you can use all the open source components along with something like Mosquito (which is an open source MQTT broker) to get a solution off the ground quickly. There are also a number of MQTT clients available for many different programming languages including JavaScript, Java, etc. Check out https://eclipse.org/paho/. If you decide to build you're own signaling protocol you might still find these open source components helpful to see how we approached integration with the WebRTC PeerConnection.
Hope u guys are doing great.
I want to make a realtime turn based game in iOS .
I know this can be achieved by using GAME CENTRE in iOS , but i have to play this between browser and iOS app. WEB TEAM is using node js for making this game on web browser , they also suggested me to use node js in iOS game as well.
Have anyone has idea how to use node js for this kind of purpose.
Thanking you all! :)
You can have websocket server written in node js and then just connect to it from your ios app using some websocket library (hope it exists). Then sockets connected from browser and your app can realtime exchange information.
You could use a pub/sub messaging service like Realtime (the company I work for) http://framework.realtime.co/messaging/
Both your node.js server and your ios devices could exchange data through Realtime pub/sub channels, using the node.js and ios SDKs.
The cool part is that since it's a managed service you don't need to worry about the server and networking administration, Realtime will take care of that for you.
I'd like to add some words in favor of #Edgar's answer.
For production, using only WebSocket is not reliable. In environment where WebSocket is not available due to antivirus, enterprise firewall, and so on, a kind of full duplex connection over HTTP should be available utilizing long polling or streaming in terms of reliable real-time connection.
Also such connection might be disconnected for a while e.g. moving away from Wi-Fi zone and then some messages which had to send through that connection may be lost so that a way to recover such messages is required e.g. here is some messages you couldn't receive.
Therefore, you need a reliable framework to write such real-time web application. Here's features which are required to write a real-time web application I think. (It's called Cettia and I'm the author of that project. As it doesn't provide iOS client, it's not right choice for you here. Just focus on features and roadmap to see what features you may be needed and evaluate a framework you will choose based on them.)
On Node.js world, socket.io framework has a great community so I'm sure someone already wrote iOS client for socket.io. Anyway, make sure that the framework you finally chose has features you need to write your real-time webapp.
I'm familiar with SOAP and Webservices for peer-to-peer or client/server messaging on other platforms. What is the Apple equivalent for messaging?
I'm trying to put together an application server that will manage a collaborative work environment. It will have an average of 200 and maximum of 1000 mobile clients on a LAN. For example, one Mac and 200 iPhones. I'm planning to use Apple's Enteprise approach to distribute our private (commercial) app to each of our iPhones clients.
The server can push configuration settings to each client. The server will also push small sets of data to the clients. The clients will perform tasks on this data locally, and eventually report back status to the server. The clients can request more data sets from the server. These exchanges can be managed asynchronously.
There is also be a need to have synchronous exchanges for critical processes. This is rare, but it is a requirement.
The data that needs to be exchanged is reasonably small. These client/server processes are time dependent, so performance is critical requirement.
The network won't be shared, but needs to be tightly controlled (and fast). E.g. it can be Bonjour if there is a compelling reason for that.
I'm looking for a recommendation on which components of the Mac/iOS SDKs to leverage. Please leave 3rd party software out of this discussion. I must know what Apple already offers and what gaps exist before considering outside software. Thanks.
If you are only going to be using Mac and iOS products then Bonjour is really your best bet. There are a ton of native ways to transmit data in either byte or object forms.
There were a couple great videos from WWDC 2012 showing what the new Xcode can do to create client and server applications. It is under NDA, but you may want to take a look there: https://developer.apple.com/videos/wwdc/2012/.
Also you said you did not want third party, any particular reason? Would you use an open source layer on top of Bonjour?
I have heard that web-based chat clients tend to use networking frameworks such as the twisted framework.
But would it be possible to build a web-based chat client without a networking framework - using only ajax connections?
I would like to build a session-based one-to-one web chat client that uses sessions to indicate when a chat has ended. Would this be possible in Rails using only ajax and without a networking framework?
What effect does it have to use a networking framework and what impact would it have on my app to not use one? Also any general recommendations for approaching this project would be appreciated.
If i understand you correctly, you want to have to clients connect to you server and send messaged to each other to each other through ajax, via the server.
This is possible, there are two approaches to do this.
The easy approach is to have both client poll every few seconds to check for new messages posted by the other. Drawback is that the messages are not instantly delivered. I think this is an example found in the rails book.
The more complex approach is to keep an open connection and sent the messages to the client as soon as they are received by the server. To do this you can use something like Juggernaut
I would like to add that though the latter works, it is not something http was meant for and it a bit of hack, but hey, whatever gets the job done. A working example of this is the rails chat project which uses a juggernaut derivative.
Technically speaking every network based application has a networking framework under it and, therefore, is socket based...
The only real question here is whether you want to have all that chatter go through your server or allow point to point communication. If the former, you can use the ajax framework to talk to your web server. This means that all of your clients will be constantly polling the web server for updates.
If the later, then you have to allow direct tcp connections between the two clients and need to get a little closer to the metal so to speak.
So, ask yourself this: Do you want to pay for the traffic costs AND have potential liability over divulging whatever it is that people might be typing into their client; or, would you rather just build a chat program that people can use to talk to each other?
Of course, before even going that far, do you really want to build yet another chat client? That space is already pretty crowded.