I am trying to build a chat app between two browsers without a signal server with WebRTC. The manual offer-answer process is most difficult part of the task.
It occurred to me that most SDP data generated by new RTCPeerConnection().createOffer() as in RTCSessionDescription.sdp is redundant.
Reference: https://webrtchacks.com/sdp-anatomy/
I tested, the o= line can be striped like o=- 1 2 IN IP4 127.0.0.1 and it works totally fine, the a=candidate: line contains FOUNDATION identifier and priority are completely useless, supposedly there's only one candidate in my case.
My question is, for the simple (and insecure) chat app between two browsers without ICE, can we strip down a=ice-pwd: line and a=fingerprint: line? The rest of SDP looks identical and can be just hard-coded into both peers.
That question came up on WebRTCHacks before:
https://webrtchacks.com/the-minimum-viable-sdp/
There haven't been that many changes since 2015 so it should still apply.
Related
201 [Deprecation] RTP data channels are no longer supported. The "RtpDataChannels" constraint is currently ignored, and may cause an error at a later date.
But what is the migration path? I did a search and can only find info telling us to migrate to SCTP, without any details.
Remove WebRTC RTP data channels (removed)
I am thinking if we shall use the WebSocket channel (the one we used to establish the WebRTC Connection) to replace RtpDataChnanels.
If you're doing a peer-to-peer application: Use the standard WebRTC data channels; if in Javascript, just remove the constraint saying "I want to use RTP data channels", and most or all of your applications will work just like before, only better.
Why would anyone want to use that old relic?
I was able to make a working HID USB stack on my "StartUSB for PIC" board for the 18F2550 microcontroller. I based it on one of the MLA libraries, which was made for the 18F45K50 (MLA 2018_11_26, hid_custom, picdem_fs_usb_k50.x), but I converted it to work with the 18F2550 (there might have been easier ways, but only learned to work with PIC about 1 month ago). On the host side, I'm using LibUsbDotNet (also here, there might be easier ways - the documentation on this library really sucks) on a Windows 10 machine.
I'm using the HID class, full speed, and all seems to work. Although, I get some random errors on the host PC (see below), but doing one close/re-open cycle on the host side when getting the error is kind of solving it. Dirty, but it works. So I kind of ignore this now.
Win32Error:Win32Error:GetOverlappedResult Ep 0x01
995:The I/O operation has been aborted because of either a thread exit or an application request.
I'm not an expert on USB (yet). But all examples I'm seeing are based on 1) you send first a command to the device and 2) then you retrieve the answer from the device. I did some performance tests, and see that this indeed shows that I can do about 500 cycles/second. I think that is correct, because each cycle, sending command and retrieving answer, each takes 1 msec.
But do I really need to send a command? Can't I just keep reading endlessly, and when the device has somthing to say, it does send the data in an IN transaction, and when not it ignores which creates a timeout on the host side. That would mean that I can poll at 1000 cycles/second? Unfortunately, I have tried it by changing my implementation on the PIC, but I get very weird results. I think I have issues with suspend mode. That brings me to another question - how can I make the device get out of suspend mode (means that not the host, but the device should be triggering this event). I have searched the MLA library for command such as "wakeup", "resume", ... but couldn't find anything.
So, to summarize, 2 questions:
Conceptual: Can I send data from device to host without being requested for it by a command from the host?
For PIC experts: How can I have a device trigger for a wakeup from suspend mode?
And indeed, the answer is Yes on the first question.
In the meantime, I found another link on the web that contains a Visual Studio C# implementation of a USB library including all the source files.
If you're interested, this is the link
This C# host implementation works as a charm. Without sending a command to the device, I get notified immediately if a button is pressed. Great!
It also proofs that my earlier device implementation based on the original MicroChip MLA, is 100% correct. I stress tested the implementation by sending a "toggle LED command" as fast as I could, and I reach 1000 commands/second. Again great!
I think that LibUsbDotNet isn't that perfect after all. As I wrote above, I get rather unstable communication (Win32Error). But with this implementation, I don't get a single error, even after running for half an hour # 1000 commands/second.
So for me, case closed.
Can someone please clarify the difference between iceConnectionstate:completed vs iceConnectionstate:connected.
When I connect to browsers with webrtc I am able to exchange data using datachannel but for some reason the the iceConnectionstate on browser that made the offer reaming completed wheres the browser that accepted the offers changes to connected.
Any idea if this is normal?
In short:
connected: Found a working candidate pair, but still performing connectivity checks to find a better one.
completed: Found a working candidate pair and done performing connectivity checks.
For most purposes, you can probably treat the connected/completed states as the same thing.
Note that, as mentioned by Ajay, there are some notable difference between how the standard defines the states and how they're implemented in Chrome. The main ones that come to mind:
There's no "end-of-candidates" signaling, so none of those parts of the candidate state definitions are implemented. This means if a remote candidate arrives late, it's possible to go from "completed" back to "connected" without an ICE restart. Though I assume this is rare in practice.
The ICE state is actually a combination ICE+DTLS state (see: https://bugs.chromium.org/p/webrtc/issues/detail?id=6145). This is because it was implemented before there was such thing as "RTCPeerConnectionState". This can lead to confusion if there's actually a DTLS-level issue, since the only way to really notice is to look in a native Chrome log.
We definitely plan on fixing all the discrepancies. But for a while we held off on it because the standard was still in flux. And right now our priority is more on implementing unified plan SDP and the RtpSender/RtpReceiver APIs.
ICE Connection state transition is a bit tricky, with below flow diagram you can get clear idea on possible transitions.
In simple words:
new/checking: Not at connected
connected/completed: Media path is available
disconnected/failed: Media path is not available (Whatever data you are sending on data channel won't reach other end)
Read full summary here
Still WebRTC team is working hard to make it stable & spec compliant.
Current chrome behavior is confusing so i filed a bug, you can star it to get notified.
I'm using a TK102 GPS localizer. Along with it, I got only simple end-user docs. No API, dev specs or similar for writing code that will use this localizer.
I was told that it uses UDP. So I wrote a simple PHP listener. But either localizer is not using UDP or something is wrong in communication between it and server. Listener works fine (gets UDP packets from other clients) and localizer is sending something (I'm being charge by GSM operator for GPRS transmission), but the data it sends, doesn't reach server.
I asked about server or networking issues on Unix/Linux and SuperUser. Here I would only ask, if someone knows any API/dev-specs for this localizer, so I can check, if it really uses UDP or if I haven't made any other error (in configuration for example).
The localizer and its clones
We're talking about Xexun TK102 Tracker here. The original one, because there are many clones under other companies from China, selling similar GPS localizer, with the same cover and logo, but with:
less performance electronics on-board (for example -- able to report location once per 20 or 30 seconds, not once per 5 seconds like in original one),
the ones that are sending lesser information (lack of direction/bearing, altitude, number of satelites used for location fix and many more),
units using different format of data or non-standard transmission protocol for sending it (for example, cheaper units are unable to use UDP protocol and are transmiting data through TCP protocol, using packets that not always follows standards or definictions.
Coban and Kintech are only two of many clones sold on eBay and in e-shops, claiming to be original Xexun trackers.
On the other hand, original Xexun and some clones (like Coban for example) are harder to control from own script, because they require a correct answer from the server, where data is sent over GPRS. If unit does not receive such reply, it breaks connection. The cheapes unit does not have this checking and will always sent location data to specified IP address over provided port.
Product description
Here is product description of original Xexun localizer (and here is a clone under Kintech name).
Possible buyer must be very careful (and should secure return policy, for which buying directly in China is not recommended) as there are many reports about sellers claiming to sell original Xexun device and sending a clone actually.
Though this device is five years old, it is still sold at many places (including eBay), but even at theses sources it is very hard to get anything worth for developers, except some simple, very basic user guide.
I have confirmed information (from two different sources) that there is no official API available for this device. The only option is to Google around, ask other users or use forums (see below).
If you own original Xexun localizer, you may try to contact company international departament and ask their technicians to include some changes to device source code and to send you updated firmware, with your changes - wow! That was confirmed by company itself.
Forum
I found a perfect forum for TK102 device, with a lot of questions and answers:
here is a general forum on TK102 device (kept alive for 4,5 year with 171 pages and 2000+ posts!),
here you'll find more specific topic on receiving data from this localizer,
this forum is also about TK102 unit, but it is entirely in French.
There are many other devices dissussed and in general, this is the biggest forum in the world, with topics for localizers and simillar information.
GPRS Protocol Specs
In general, any TK102 related devices is opening a socket for a direct TCP transmission (original one can be switched to use UDP protocol). Data is being transsmited over port specified by user, in configuration and using GPRS only (requires SIM card with enabled GPRS, there is no way to use WiFi).
Sending frequency, format and amount of data being send, entirely depends on kind of device is being used -- it is more extensive and more configurable in original one than in clones.
Using FileDropper I shared GPRS Protocol Specification for TK102 Geolocalizer. It contains basic information on how to setup TK102 (and possible all its clones) to send location over GPRS. And what sort of data you should except to receive from in, on server side. This could be useful for someone.
BTW: If links goes dead, contact me for a reupload or sending it over e-mail
Correct server response problem
Make sure, if you're using correct data transmission protocol! Many (really many) cheap clones uses TCP, while only original TK102 allows switching to UDP. This is convenient, because you need really basic server configuration to handle TCP connections, while you have to use specific server-side software (like node.js) or specific configuration (open to certain ports) to handle UDP. But the key thing is to determine correct protocol, as listening to TCP data, while your localizer sends UDP, will most certainly fail.
Take into consideration, that many TK102 clones requires a correct response from the server after each data, it send. It breaks connection after sending some welcome garbage UDP packet, as it does not receive response, it waits for.
It is quite hard (quite impossible?) to find any guide to many of these clones, on what kind of responses server should sent. This often leads into situation of developer being unable to estabilish two-way communication between server and localizer. Many localizers are sold to be used only via SMS communication or throughs paid services that had signed and agreement with producer and received protocol specification that contains valid responses server should generate for particular TK102 clone.
Double check, if this is not source of problem, if you can't communiacte with your localizer from your app.
You can check some models protocol specs here:
http://www.traccar.org/docs/protocol.jsp
I'm new to driver programming in general and also to USB. However, I managed to write a driver for Windows CE (6.0) and I also had access to an USB-Sniffer to read all traffic between the host and the device.
The problem now occurs on some boards (2 out of the 3 I have):
When the device has no data to send and I issue an Interrupt-In-Transfer the device sends an ACK.
So far this is expected. However, something (I guess either the USB-Controller or WinCE) seems to automatically issue more IN-Transfers (3 on one board, 4 on another) and I get subsequent ACK. This isn't a problem so far either.
But the next IN-Transfer will also result in an ACK, no matter if there is data to send or not, I receive zero bytes in the driver.
Yet, when I look at the USB-Sniffer the proper telegram was send, however 2 more IN-Transfers are automatically issued and are responded with an ACK. So it seems like the data is overwritten by the ACK.
I tried everything that came to my mind so far: Reset the pipe, close and reopen the connection, but nothing seems to work out properly. Resetting the Pipe solves the problem in about half of the cases though. I really ran out of ideas for solving the problem.
Is there a way to tell the USB-Controller (or WinCE or whatever causes this behaviour) to always only issue one single transfer?
EDIT
Turns out it was a threading issue. Unfortunately I wasn't the one who fixed it and I have no access to the working solution, thus I cannot give further details.