Mercurial > libervia-backend

comparison libervia/backend/plugins/plugin_xep_0280.py @ 4231:e11b13418ba6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
plugin XEP-0353, XEP-0234, jingle: WebRTC data channel signaling implementation: Implement XEP-0343: Signaling WebRTC Data Channels in Jingle. The current version of the XEP (0.3.1) has no implementation and contains some flaws. After discussing this on xsf@, Daniel (from Conversations) mentioned that they had a sprint with Larma (from Dino) to work on another version and provided me with this link: https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74 . I have used it for my implementation. This implementation reuses work done on Jingle A/V call (notably XEP-0176 and XEP-0167 plugins), with adaptations. When used, XEP-0234 will not handle the file itself as it normally does. This is because WebRTC has several implementations (browser for web interface, GStreamer for others), and file/data must be handled directly by the frontend. This is particularly important for web frontends, as the file is not sent from the backend but from the end-user's browser device. Among the changes, there are: - XEP-0343 implementation. - `file_send` bridge method now use serialised dict as output. - New `BaseTransportHandler.is_usable` method which get content data and returns a boolean (default to `True`) to tell if this transport can actually be used in this context (when we are initiator). Used in webRTC case to see if call data are available. - Support of `application` media type, and everything necessary to handle data channels. - Better confirmation message, with file name, size and description when available. - When file is accepted in preflight, it is specified in following `action_new` signal for actual file transfer. This way, frontend can avoid the display or 2 confirmation messages. - XEP-0166: when not specified, default `content` name is now its index number instead of a UUID. This follows the behaviour of browsers. - XEP-0353: better handling of events such as call taken by another device. - various other updates. rel 441
author Goffi <goffi@goffi.org>
date Sat, 06 Apr 2024 12:57:23 +0200
parents 9162d3480b9e
children
comparison
equal deleted inserted replaced
4230:314d3c02bb67 4231:e11b13418ba6
137 forwarded_elt = next(carbons_elt.elements(C.NS_FORWARD, "forwarded")) 137 forwarded_elt = next(carbons_elt.elements(C.NS_FORWARD, "forwarded"))
138 cc_message_elt = next(forwarded_elt.elements(C.NS_CLIENT, "message")) 138 cc_message_elt = next(forwarded_elt.elements(C.NS_CLIENT, "message"))
139 139
140 # we replace the wrapping message with the CCed one 140 # we replace the wrapping message with the CCed one
141 # and continue the normal behaviour 141 # and continue the normal behaviour
142 message_elt["type"] = cc_message_elt.getAttribute("type", C.MESS_TYPE_NORMAL)
143 mess_id = cc_message_elt.getAttribute("id")
144 if mess_id:
145 message_elt[mess_id] = mess_id
142 if carbons_elt.name == "received": 146 if carbons_elt.name == "received":
143 message_elt["from"] = cc_message_elt["from"] 147 message_elt["from"] = cc_message_elt["from"]
148 lang = cc_message_elt.getAttribute("xml:lang")
149 if lang:
150 message_elt["xml:lang"] = lang
144 elif carbons_elt.name == "sent": 151 elif carbons_elt.name == "sent":
152 # the cc_message_elt is the full JID, so we copy it
153 message_elt["from"] = cc_message_elt["from"]
145 try: 154 try:
146 message_elt["to"] = cc_message_elt["to"] 155 message_elt["to"] = cc_message_elt["to"]
147 except KeyError: 156 except KeyError:
148 # we may not have "to" in case of message from ourself (from an other 157 # we may not have "to" in case of message from ourself (from an other
149 # device) 158 # device)