I'm tracing packets between 2 agents. One is from Chrome on Mac, the other is from Chrome Beta on Android. They're communicating by a reference site like apprtc.appspot.com and I managed to save some logs out of it. (please download it or it only displayed as source code) Doing so I also capture packets in Wireshark while 2 agents communicating with WebRTC.
Using filter: stun||udp lots of Binding requests & responses can be founded.
Basically from the rfc doc it said:
An agent can respond to an initial offer at any point while gathering candidates...
thus allowing the remote party to also start forming checklists and performing
connectivity checks.
But I just can't see any sign of SDP like offer or answer sending to each other, which can be found in js log above. For cross reference I hope to find the right order of the entire communication.
Here's the Wireshark file kinda of big
Chrome uses TLS to encrypt the signaling packets. And if its a communication directly between the peer, the only way to see signaling is looking at the Console logs of chrome. It should have the offer answer exchange of the SDP. I am assuming its using SIP as the signaling protocol and you should be seeing it in the console.
If there is a intermediary between the peer, like a FreeSwitch any other SIP Server, it could be possible to debug it better as they have the keys to decode and find use the raw text messages.
Related
WebRTC signaling uses STUN to exchange ICE candidates and SDPs with peers, but how does it know who to exchange that information with?
Obviously, it's not with just anyone and just by virtue of using the same STUN server doesn't mean you'll get paired with some rando. However, I'd like to know how that selection is made. Probably the URI plays a role, but how big of a role? And is it possible to influence that?
It would seem like a problem if it were URI alone. Then someone could just bombard STUN servers with offers or requests to know who's currently on that webpage with WebRTC active.
WebRTC doesn't use STUN to exchange ICE candidates and SessionDescriptions. STUN is used to create a NAT Mapping and getting information about it. You can establish a WebRTC session without using STUN at all.
A session is established because two WebRTC peers exchange Session Descriptions (Offers and Answers). These offers and answers can be exchanged with any protocol you like. Most commonly you see HTTP/Websockets used. This is known as a signaling server.
It is the signaling servers job to make sure that the Offer/Answer is routed properly. You can read more about what the values actually do here WebRTC for the Curious#Signaling
I am making a simple WebRTC application for myself in order to understand the WebRTC process.
I am using the RTCPeerConnection object to generate an SDP and display it in my logs so I could see exactly what the SDP contains.
This was working fine on all popular browsers until the more recent Chrome update, which no longer displays the SDP.
I used wireshark to examine the packets and I can see that Chrome is using the GQUIC protocol, where other browsers use DNS and STUN protocols.
From this my questions are:
Is GQUIC preventing the SDP from being gnerated or from being displayed?
How, if at all, can I get the SDP to appear again in Chrome?
No
It appears GQUIC is not the reason the update prevented the SDP from being created. GQUIC seems to be a protocol built on UDP to improve latency while allowing for the reliability of TCP, and I could find no reason for it to impact on the SDP business but rather it was a coincidence that I noticed this for the first time when the other problem occured.
Quick fix: change WebRTC: Use Unified Plan SDP Semantics by default to disabled in chrome:flags
The reason the SDP stopped working for me is that the new Chrome version has enabled WebRTC: Use Unified Plan SDP Semantics by default, since they appear to be moving from Plan-B to the Unified Plan which alters how the SDP is being passed. I am still trying to work out the exact difference this has on the SDP but in the meantime I was able to at least see the site working again when I change the flag so I know now that was the cause.
Is there a way to stream a video and audio on a website just to the clients, using a camera installed on the server - for instance, like youtube does ?
I've started reading webrtc, but if I use webrtc I should create a stun/turn server and other things, which for one way stream I think is not necessary (this is just my understanding of the things..) because I don't need anything from the clients, literally, neither their video, or audio..
So is there a way to achieve this using html5, streaming just in one direction:
server (camera) -> clients
Is there something about this out there, or should I stick with webrtc ?
I'm going to explain a possible solution for this scenario, there might be others, but I hope mine gives you a rough idea of how you could do it and a start point to explore more about the amazing possibilities of WebRTC. Please let me know if something is not understood.
So, WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. Sweet, that is: WebRTC has a quite good browser support (not in every browser though, Safari just started supporting it a month ago with Safari 11). But in this case we want to use WebRTC in the server side. At the end of the day we can still think about peer-to-peer real time communication, where one of our peers is the server.
I don't know if you are familiar with Node.js, but I recommend you to write your Server app with it (<3 Javascript!):
There are a few libraries that wrap WebRTC functionality to be used in the server side, like node-webrtc and node-rtc-peer-connection.
But I recommend you to to take a look at electron-werbrtc, since
the others might be using deprecated methods or be incomplete.
electron-webrtc runs a headless Electron client in the background to
use Chromium's built-in WebRTC implementation. So with it you should
be able to access the Camera in your server and create a stream to be
served to the other peer (the browser).
All above would be the WebRTC related tasks, in this case: streaming video peer(server)-to-peer(browser).
Now, let's talk about signaling process, stun and turn.
Signaling: imagine now a scenario peer-to-peer with 2 browsers, they want to establish a direct connection and stream video and audio between each other. But they don't know each other, like if I don't know your home address, I can't send you a letter. So they need a service that helps them know each other, so they can have the other's IP. This should be done by what is called "a signaling server". If somehow you know the other peer IP, you wouldn't need a signaling server.
STUN/TURN: the scheme above works perfectly in a local area network where each peer has its own IP address and there are no firewalls and routers between them. But otherwise, you can have peers behind a NAT or firewalls, and then your signaling server won't be able to make both peers to discover themselves. If you have peers behind a NAT, you'll need a STUN server, and if you have peers behind firewalls you'll need a TURN server. This is a bit simplified, but I just want you to have the general picture of when you might need STUN/TURN servers.
To better understand Signaling, STUN and TURN, there is a very graphic article that explains them perfectly.
Now, for your scenario:
I think you prob don't need STUN/TURN servers and also you prob don't need to implement the signaling process, because the browsers that are supposed to receive the stream from the server will know that server address, right? So they can establish a WebRTC connection with it.
EDIT: it is likely that you will need to implement some sort of handshake between the server and the clients (browsers), so this will be the signaling process. This is not part of WebRTC and this is why you need to implement it yourself. As I said, it is the way 2 peers can discover each other, but they also exchange information as their local media conditions, like codecs, resolutions they can handle, etc. For your case, your signaling server could be hosted in the same server you use to strea: you can build a small node.js app that runs there and that manages all the signaling process easily, it is not a big deal. I recommend you to read this article, and specially the section "How can I build a signaling service?". In general all WebRTC articles from that site are very helpful.
Does this make sense to you? I think with it you can start digging a little bit more and see if with this is enough or you need to implement more stuff. Hope it helps!
I am building a web application that uses webRTC datachannel. I sending data on mouse move to peer, but peer not receiving all the messages? why this? this is arising only when data sending fast.
using chrome 26.
How should I overcome from this?
This may be a little late, but off the top of my head your problem is probably because datachannels use RTP (a UDP based protocol). UDP has no guarantee of delivery. This is perfect for real-time applications where packet loss is tolerable (multiplayer games, video streaming) because latency is much lower but it will lead to the kind of situation that you are facing.
If you can't use websockets to go through a server (TCP) and this really is a problem, maybe look into TCP over datachannels. I may have read somewhere that firefox supports TCP datachannels. I will edit this reply if I find any helpful information.
If we send two messages over the same html5 websocket a split millisecond apart from each other,
Is it theoretically possible for the messages to arrive in a different order than they were sent?
Short answer: No.
Long answer:
WebSocket runs over TCP, so on that level #EJP 's answer applies. WebSocket can be "intercepted" by intermediaries (like WS proxies): those are allowed to reorder WebSocket control frames (i.e. WS pings/pongs), but not message frames when no WebSocket extension is in place. If there is a neogiated extension in place that in principle allows reordering, then an intermediary may only do so if it understands the extension and the reordering rules that apply.
It's not possible for them to arrive in your application out of order. Anything can happen on the network, but TCP will only present you the bytes in the order they were sent.
At the network layer TCP is suppose to guarantee that messages arrive in order. At the application layer, errors can occur in the code and cause your messages to be out of order in the logic of your code. It could be the network stack your application is using or your application code itself.
If you asked me, can my Node.js application guarantee sending and receiving messages in order? I'm going to have to say no. I've run websocket applications connected to WiFi under high latency and low signal. It causes very strange behavior as if packets are dropped and messages are out of sequence.
This article is a good read https://samsaffron.com/archive/2015/12/29/websockets-caution-required