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?
Related
As a follow-up to my previous post (ApiRTC - Behaviour with meshModeEnabled and meshOnlyEnabled)
Hello,
You say that SFU is necessary for any activity that requires centralizing all the streams (recording, bandwidth optimization,...). However, in MESH mode, the files/media exchanged still manage to be recorded on the Apizee media server even though I don't go through the SFU. How is this possible ?
Can this behaviour be disabled so that the exchanged documents never leave the MESH stream ?
I have not found anything about this in the documentation.
By the way, the documentation often mentions the term "MCU", does this mean that ApiRTC also uses an MCU server in addition to the SFU ?
Thanks in advance.
apirtc
Can this behaviour be disabled so that the exchanged documents never
leave the MESH stream ?
Concerning a recording of all the streams in the conversation (via the startRecording method of the Conversation object see https://apirtc.github.io/references/apirtc-js/Conversation.html#startRecording__anchor):
--> The composition of multiple streams into one video file is done server-side by the SFU (v4.4.8).
Concerning the files (through conversation.pushData method):
--> We manage the file transfer through uploading the file on a storage and share the URI to all parties of a conversation. P2P transfer is not available (v4.4.8)
To exchange data in a P2P mode, you can use the Conversation.sendData method to send raw data across all participants.
Regarding your question about the MCU, no, ApiRTC doesnt use any MCU server to date (v. 4.4.8). The document refers to MCU for very specific on-premise deployment, not supported for ApiRTC users.
Cheers,
Romain
I am implementing a TURN server specifically for WebRTC usage and have some questions regarding not supporting certain attributes (send an error response if the attribute is received) or simply ignore them or other doubts. Here they are:
EVEN-PORT If my SDP always signals a=rtcp-mux, will this attribute ever be used? And if so, would it be an error if it appears?
RESERVATION-TOKEN Does this play any role when TURN server is used in the WebRTC context?
SOFTWARE As in STUN, can this be safely ignored without any processing?
DONT-FRAGMENT Is there a preferred and well-accepted norm for this attribute in the WebRTC context?
What is the ideal length of NONCE in the WebRTC context?
Different issue. Are there any statistics available for use of TURN server for transports other than UDP? I am thinking of supporting only UDP for now.
webrtc typically requires rtcp-mux, at least in chrome so I would not care about even-port.
no
yes. It is FYI only.
no. WebRTC implementations typically don't do path-mtu discovery but assume 1200 bytes.
You mean the expiration? https://medium.com/confrere/gone-in-1100-seconds-hunting-bugs-on-the-edge-of-webrtc-132a186c45dd
see https://medium.com/the-making-of-whereby/what-kind-of-turn-server-is-being-used-d67dbfc2ff5d
So here's the story, I'm building a WebRTC app and I have to record the stream on server.
"WebRTC is p2p dude, choose a media server"
Yes, I know, please avoid this comment ;)
But then I tought about one thing, what if I force all the stream to use the TURN server. The packets are going through the server, so I guess I can take them and save it
The question is how to do this.
Any suggestions?
TURN servers are intended to be relayed media, which means that media streams are not decrypted, mux'ed, processed, or recorded. I get that you're asking to avoid the "choose a media server" comment, but that's like saying "I need put in this screw; which hammer should I use? Please don't tell me to get a screwdriver." - The hammer isn't the right tool.
You can still use WebRTC and p2p, but the media server (like Jitsi, for example) acts as a peer in a star topology, where all streams are sent to the media server, and can be recorded, relayed, bundled, etc.
You can use a WebRTC gateway like Janus or Kurento (I assume you have figured it out by now :) )
I am creating an app that acts as a remote control for a lighting console and I need to send commands to the console over UDP. The protocol that I am using has its own custom header. How do I create the data packet with header and message to send over UDP? Thanks!
If you are trying to test the protocol, without writing any code, I suggest you use WireShark.
The probably most powerful solution you can use is scapy, which is a python module that allows very advanced packet crafting and manipulation. See its documentation or search the interwebs for examples to find out how to generate arbitrary packets and transmit them.
If you can't use python for some reason, there are multiple command line tools for packet generation, one other example being nping (documentation), the brother of nmap, the popular network scanner. nping has options to generate UDP packets with arbitrary payloads, with can be specified as a hex string, for example.
There may be other options as well. It would be good to know more details like the operating system you're on or where you get your input data from, and in which format.
We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
+--------------+ +--------------+ +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+ +--------------+ +--------+
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.