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.
Related
I see some of them show "h2" and some "http/2+quic/43" but never "h2+quic/43". What's the difference between h2 and http/2 in this case? And what's the "43" in "quic/43"? Protocol version or port number?
Well basically QUIC is still being worked on and is not standardised. Google, as the inventors, have their own implementation (sometimes called gQUIC) which is only available in Chromium based browsers and on a few server implementations. It is based on HTTP/2 (well actually it was based on SPDY which then got standardised into HTTP/2).
It doesn't really use HTTP/2 any more but a modified version of it. So whether you call it h2 or http/2 doesn't really matter - it's neither. But at a high level h2 and http/2 can be treated the same in this context.
When QUIC is formally standardised later this year (or possibly even next year) by the IETF it will use HTTP/3 to reflect the diverges from HTTP/2 and so it should change to h3. That is currently being worked on but no browser supports it yet. It is known as iQUIC for now but imagine it will just become QUIC after it becomes a format standard and Google migrates to it and stops using gQUIC (in a similar way that the deprecated SDPY once HTTP/2 was formalised). gQUIC and iQUIC are already quite different.
The number 43 is a version number. Google used to iterate QUIC quite quickly as they were in charge of both ends (browser and server) though seems to have slowed down now (hopefully reflecting it's maturity and the fact less changes are needed). There used to be a change log in the Chromium source code showing what changed in each version, but can't find it now...
I'm trying to debug difference between HTTP/1.1 and HTTP/2.
Is there any possibility for disabling HTTP/2 in chrome or chromium?
I couldn't find this option flag in chrome 56. I have tried chromium 58 with flag --disable-http2:
./Chromium.app/Contents/MacOS/Chromium --disable-http2
But content is still delivered with HTTP/2 protocol after using this flag:
For what it is worth, the flag works.
The issue is that you need to quit EVERYTHING Chrome for it to take effect. Including plugin shims and other chrome tabs and so on.
It is not enough just to add the command line switch.
An easier way to achieve something broadly equivalent is to use an HTTP Proxy, like https://www.telerik.com/fiddler. This adds negligible additional time to your requests, and (as far as I know) doesn't support http/2 at all (yet); even if it did, I'm pretty sure it would be much easier/practical to switch behavior in than restarting all your Chrome windows.
The advantage of this approach is that it takes effect immediately - disabling and reenabling HTTP/2 becomes as easy as starting and stopping the proxy, without messing with the (if you're anything like me) dozens of Chrome tabs you have open, to StackOverflow and elsewhere :)
What happens when you try doing the same thing in WebPageTest (select Chrome as the test agent and add the command line switch in the Chrome tab under advanced settings)
Here's a test I did for my personal site just now and the flag appears to work OK (if you look at the response headers you'll see HTTP/1.1)
https://www.webpagetest.org/result/170322_1B_ab8656afcfb8bcc4103e9872ff56c28b/1/details/#waterfall_view_step1
I have seen the same problem created by a firewall running in proxy mode vs flow mode.
The firewall would buffer the entire file so it could scan it then pass it along vs scanning the individual packets.
https://docs.fortinet.com/document/fortigate/6.4.4/administration-guide/721410/inspection-modes
The problem would only happen when using http2 and might have something to do with http request priority not being handled properly or it forced it single threaded.
We would have a video request start with a low priority that would stall then start causing other file downloads to be delayed. Then there was a api poler in the background coming in with high priority requests. After a few high priority requests were blocked chrome would cancel the low priority video.
It would happen in other cases but the video made it very reproduceable for us.
https://medium.com/dev-channel/javascript-loading-priorities-in-chrome-57c54cfa6672
https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
https://blog.cloudflare.com/http-2-prioritization-with-nginx/
https://calendar.perfplanet.com/2018/http2-prioritization/
We set it back to flow mode on the firewall and the problem went away.
Afterwards the downloads all happened in parallel with no blocking or stalling in the chrome network waterfall.
I am trying to test sip capabilities of firewalls using webrtc. However I noticed using the servers needed for webrtc (stun turn websockets etc.) will give me a false positive in that it won’t catch nuanced issues with the ALGs. For reference this is being done from a chrome app so I can’t just run a native sip stack in the browser.
My Question: can I leverage webrtc to just send sip(invite, options, register) and not use any other methods that would get around the firewall?
Your question doesn't make sense because WebRTC doesn't use SIP - SIP is a signaling protocol, and WebRTC doesn't do signaling. What that means is that SIP can be used to establish a WebRTC connection, but they are mutually exclusive.
SIP is sent over a data connection, like a hard line from a phone to a PBX or a websocket from a browser to a server.
It is possible to set up a WebRTC connection using out of band mechanisms, but then that wouldn't be SIP.
Actually there might be a way around that.
Use the signalling server to to do any sort of preconfigurations you might want to do before setting up the peer connection. This would allow you to specify codecs and resolution of the feed as a SessionDescription before hand or even check if the other peer is capable of WebRTC or not.
I'd recommend Socket.io =D
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.
I have a weird problem with websockets and chrome (22.0.1229.79m) (I haven't coded authentication for other browsers yet so I cant test them). It seems like if I reload chrome 3 times, there will be a huge delay in connecting to my websocket server. The server is not delaying the connection, I tested this by connecting to it with another PC while chrome was delaying and it connected perfectly.
Is there anyway to fix this? This is a problem when I am switching servers receiving data. It will halt, and delay. This is really bad for user experience. I would assume this is strictly related to the chrome browser not closing the socket...
I have also seen this delay when creating multiple WebSocket connections from the same browser tab in Chrome within a short period of time. I believe this is to address a potential security issue with WebSockets which would allow a browser to be hijacked to do port scanning inside a network. By limiting the number of WebSocket connections that can happen within a given amount of time, you greatly limit the utility of a browser as a remote port scanner. In addition, the amount of information that is returned by onclose and onerror is intentionally limited for the same reasons.