Imagine someone is broadcasting an audio or video world wide through WebRTC i.e one to many communication (app like periscope which i think is not done using WebRTC). Will it get affected by the broadcasters less bandwidth ? will it increase the load on broadcaster side causing loss of packets which will decrease quality of communication ? As this topic is new and very little content is available on net please suggest some good books and online tutorials.
WebRTC facilitates peer to peer communication. Going by this login a simple WebRTC broadcast application will heavily depend on broadcaster's bandwidth as the number of recipients will be same to the number of outbound media streams.
This is one of the main reasons why WebRTC Gateways or Media Servers or similar terms have been developed. In this case the broadcaster simply sends a single stream to the intermediary Gateway or Server and the other recipients then connect to the Gateway or Server and receive the stream from there.
To put it in simple terms, you basically add a central WebRTC client to which everyone connects.
You can read more at Janus, Kurento, Licode, etc.
Or find official RTCPeerConnection documentation here.
Related
I'm looking for advice regarding an aspect of a project I'm working on.
I'm developing a demo android app for a not-for-profit that specialises in services for the vision impaired. The plan is, among other things, the app will enable users to stream this organization's specialised audiobooks.
For the sake of demo'ing/development I need to establish some sort of server which will, pending a request from a device running the app:
directly transfer certain xml/html index files to the android phone (no streaming necessary)
stream .ogg and .mp3 audio files to the device
serve more than one client device at a time
start a stream from a specific point within an mp3/ogg file, pending a request from the phone app
I've had a look at Icecast as an mp3/ogg streaming solution, but my knowledge of servers is a bit limited (I've only ever done some basic work in Flask). Would I need to run this in tandem with something that can generically serve files / handle requests?
I'm basically just looking for a good solution/tool to implement this is. The server side doesn't need to be completely fleshed out, just fit the bill above, as my focus is developing the phone app side for now. For the sake of a demo, something straightforward / well documented would suit best.
You don't need a special server for this. Any HTTP server that supports range requests will be fine. This includes Nginx, Apache, etc. There is no need to spoon-feed clients media data from the server. This streaming and buffering aspect is handled automatically on the client, through TCP window size and outright closing the connection and connecting again later as-needed.
Icecast is meant for radio-style streams where everyone listening hears the same thing at roughly the same time. Since that's not an aspect you want, stick to any normal HTTP server.
I would like to implement a voice chat (even just a primitive support for it), without the hassle of implementing the whole VoIP stack. I would also like to make it available to both iOS and Android.
I have been searching for a way to do this, and it just seems to me that using Socket.IO would be something to start with. Is it possible to use Socket.IO as a signalling server (to discover who is available, and who to start a voice chat with), and then establish a peer-to-peer connection between two devices in order to transfer audio data?
NOTE: Although I would prefer peer-to-peer, because I would like to avoid overloading the server with transferring such an enormous amount of data, is it possible to have socket.io receiving and transmitting audio data between devices (because I heard that iOS and Android cannot establish a P2P connection with one another). If it's not possible, then maybe it's possible to use a socket.io server as an intermediary for sending audio data?
I found the following helpful links (which are probably based on socket.io) but they have not any reference for mobile devices.
http://peerjs.com/
https://simplewebrtc.com/
Any help is greatly appreciated. Any alternatives to socket.io, are also accepted, if there are any.
This is an abstract question on how the SIP protocol works. Let us say I have a SIP server (Asterisk/Yate). And I have two Android devices that wish to connect to each other to have an audio call. ( I am looking for a purely VoIP call, no need for telephone numbers or carrier information).
How would this work? Do the packets have to pass through the server? or does the connection happen between the end-points. If the packets has to pass through the server, does the SIP server also provides profiles, or do profiles have to be created by a third party?
I need to understand how the scheme works in order to start planning building the system.
I have read lots of technical documentations, but none show an abstraction of the system. If you can provide me with resources, that would be great too.
Thanks
Since your device not know where each other located(ip/port), they call sip server or proxy.
Sip server match dialplan and send request changed(server) or unchanged(proxy) to other side.
In INVITE request each peer send address/port and info about media stream RTP
If that info unchanged(proxy) they can see each other rtp info and send rtp packets directly.
Also there is posible enother INVITE after call bridged,called re-INVITE with info about new stream for rtp(can be sound on other ip/port or video)
There are nothing called profiles in sip standart, sorry.
Anyway seams bad idea start planning voip system if you have limited REAL experience with sip server.
There are alot of articles(including wikipedia), videos on youtube with topic "how sip works", there are no way put all that here in one answer.
I want to ask some question regarding the development of my push-to-talk application for Android.
Recently, I've been developing push-to-talk Apps for Android. I use DatagramSocket to send voice and receive voice as a Packet over Local Wireless network (W-LAN). I use peer-to-peer network, so no server.
I don't have a problem with the code, but I don't understand the basic of VoIP theory, so I want to ask some question, hope somebody can give me simple answer :)
1. Is my push-to-talk Apps considered a VOIP-based?
2. There is several VOIP protocol such as SIP, H.323 and many more. If my PTT Apps considered a VOIP-based, and I use Socket-Packet (UDP, am I right?) to exchange voice, then what VOIP protocol that I use? Is it considered RTP protocol?
I would like to understand the theory behind my PTT apps, I understand my java code, but I don't have proper VOIP knowledge.
I've tried to find some information in google, but I still don't understand what is the relation between my PTT Apps and the VOIP technology.
Thanks before, I'm new here and sorry for my english!
I. "VoIP" is a very broad term, but, if your app transfers voice over IP network, it's definitely VoIP one, despite it may use totally proprietary protocols (as e.g. Skype does).
II. VoIP stack is basically split to two meta-layers - 1) signaling and 2) media transport. Each of them is in turn consisting multiple own layers (e.g. for SIP: session, dialog, transaction and transport layer). Examples of signaling protocols are H.323, SIP, MGCP. The most standard media transport is RTP. You can use your own transport; RTP applies specific restrictions (as AVP profile) but is compatible with variety of libraries and other implementations.
There are protocols which use the same socket and the same transport type for both signaling and media; the widely used one is IAX. Most others separate signaling and media, so sockets are separated and likely they have different type. A standard-compliant SIP implementation shall function over both UDP and TCP, and switch to TCP for large requests (>=1300 bytes by default); SCTP is also suggested. For all transports, protocol implementation details as retransmission policy and request timeout are specified in different way, but there is no principal problem with using any correct L4 protocol.
The totally another story is with media transport (under RTP or equivalent). Here, typical TCP manner to transfer all data at the cost of floating delays is really nasty for our ears. TCP is good for bulk traffic class, as file transfer or database interaction. In interactive communication between humans, we prefer more noise and sporadic voice loss than a voice strain. So, TCP is a very bad choice here, and a synchronous transport class shall be used, and UDP is the good default choice. SCTP can also be used as media transport, but with limited retransmit option (not all stacks support it). (There are attempts to use TCP to punch through NAT points but all this is an act of despair.)
If your application supposes sending a voice message more than to one recipient at a time (i.e. a kind of broadcast or multicast), this rejects use of connection-oriented media transports, effectively retaining only UDP. This also requires proper negotiation at signaling level.
III. Selection of voice codec is very platform-specific, I don't use which ones are native for Android. In "big" VoIP, there are licensed set and free set, with very small intersection (AFAIR, G.711 and GSM). Despite this, there are good codecs (e.g. Opus) which can be adapted into wide range of requirements, including partial packet loss.
I am implementing a real time - multi user voice transfer application for Android.
I have read that, as a standard - RTP packets are encapsulated into SIP and then sent to destination(s). What is the advantage of doing so?
my idea was to use a server, just to receive control messages from nodes and open sockets. All these nodes would be in 1 group. THen, I send out the IP addresses of each of these nodes, so that a single sender can multicast its packets directly to the destination.
is there a fatal flaw here? ( iam not concerned about the power consumption)
How does SIP do better? or does it ?
Thanks
RTP isn't "encapsulated into SIP packets". SIP is a signalling protocol. RTP is a media stream protocol. SIP is used to negotiate and set up (and tear down) media streams.
TCP is a horrible choice for media (RTP) packets; it's not clear from your writing if you're suggesting that.
Multicast is unlikely to work for many network paths/recipients.
routers play merry hell with incoming data; you'll need more than just SIP to deal with users on the open net. See STUN, TURN, ICE, UPnP, etc.
SIP or Session Initiation Protocol is a protocol that was designed specifically to address the problem you're trying to solve. Generally, the reason you should reuse (rather than reinvent the wheel) is because other people have studied the same problem and presumably have come up with a better solution as a collective group than you could as an individual. Of course that's not always true, but generally speaking it holds!
If you want to learn about SIP you could study the RFC 3261 specification, or start with the Wikipedia entry if you want a quick overview.
That being said, if you don't need the overhead of a complete and carefully tested protocol you could roll your own but make sure that when you're making that decision you know what you're foregoing and have a good reason to do so.
SIP is a signaling protocol that usually runs over TCP (although not required) and if you look at it closely you will see it is very similar to HTTP in many respects. Just like HTTP it can transport a great deal of payloads and it does so with text headers, much like HTTP can be used to transport HTML, XML, plain text or any arbitrary binary payload.
In the most simple system, you could just use Voice packets over RTP over UDP.
But you'd have no way to turn audio off, and would have to know IP addresses, port numbers, they type of codec and its characteristics beforehand.
In an overly simple view, SIP is a way to:
1. find the ip address of another endpoint from a URL. (May need STUN, TURN, ICE, etc)
2. agree on which codec to use and its options
There's a lot more to SIP than that, you may want to investigate SIP's conferencing features based on what you wrote.
You may write your own signaling protocol, and if this is for a school project, that will work just fine.
But if you are doing a commercial project, bear in mind that there is a lot more to telephony than meets the eye. The original SIP spec was greatly revised and is now a cluster of RFCs which are still being modified and added to. I recommend that you take advantage of this work rather than possibly reinventing the mistakes others have made.