Get desktop application:
View/edit binary Protocol Buffers messages
A serialized one these goes in the "opaque" field of the CallingMessage::Offer in SignalService.proto
A generic calling message that is opaque to the application but interpreted by RingRTC. A serialized one of these goes into the "Opaque" field in the CallingMessage variant in Signal protocol messages.
Used in:
This is signed so it fits in a SQLite integer column.
Used in:
Used in:
This is signed so it fits in a SQLite integer column.
Used in:
Used in:
,In other words, the video codecs the sender can receive.
Used at call establishment to convey the bitrate that the signaling sender (media receiver) wants the signaling receiver (media sender) to send.
A serialized one these goes in the "opaque" field of the CallingMessage::Ice in SignalService.proto Unlike other message types, the ICE message contains many of these, not just one. We should perhaps rename this to "IceUpdate" since it can either be a candidate or a removal of a candidate. But it would require a lot of FFI code to be renamed which doesn't seem worth it at the moment.
Use a field value of 2 for compatibility since both V2 and V3 have the same format.
ICE candidate removal identifies the removed candidate by (transport_name, component, ip, port, udp/tcp). But we assume transport_name = "audio", component = 1, and udp So we just need (ip, port)
Used in:
A serialized one these goes in the "opaque" field of the CallingMessage::Offer in SignalService.proto For future compatibility, we can add new slots (v5, v6, ...)
Used in:
IPv4: 4 bytes; IPv6: 16 bytes
Used in:
Used in:
Keep these H264 definitions for better logging.