Am 29.08.19 um 13:24 schrieb Andrew Nenakhov:
I might be late to the party. This email was sent by me on August 03 after
changing my email address and resubscribing to this list, but it seems that
I wasn't put through. My points against XEP-0353 in current form still
stand. I obviously missed all conversations here in August, so I might need
to catch up on this though.
сб, 3 авг. 2019 г. в 21:04, Andrew Nenakhov <[email protected]
:
вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer <[email protected]>:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in the introduction
and requirements?
Partially. This specification is not suitable to work with clients that
rely on push notifications and fetching messages from an archive.
0353 was explicitly designed for push (by not including the full payload
due to size constraints) in conjunction with 0357 and should not go to
MAM (hence no body).
This has some sad consequences like the lack of a message acting as a
call data record in the users history.
3. Do you plan to implement this specification in your code? If not,
why not?
We have implemented this specification on iOS client, and discovered that
it is unsuitable in real life scenarios. We have updated it with additional
callback routine, the changes and stanza format is described here:
https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRrge0ow/edit
This modified solution does the job. We have also created a test bot for
testing automated VoIP calling, bot's address is [email protected]
(calling bot works well, receiving calls from bot has some bugs at the
moment). One may perform calls using preview version
<https://github.com/redsolution/xabber-ios/wiki/preview> of Xabber for
iOS (it's under construction at the moment and has quite a number of bugs,
but VoIP is mostly working by now).
I wanted to reply to your post in June but seems I never did :-(
What you are describing is a different protocol. If you go via the users
MAM archive then you could simply initiate with a full session
description as payload. Its been a while there since we wrote that up
but I think the complexity of getting that to work turned out to be too
high which would match your experience.
The way 0353 is supposed to work is:
1) you are offline but have a push-enabled client
(there is the more interesting scenario where some clients of yours are
online but none does jingle... and you would need to send a push
notification to your offline client that does... that is a generic issue
however)
2) you get a push notification with the <propose/> element and know the
senders full jid, the session id and (FYI) the media types involved
3) your client requests that session at the sender. If that session
doesn't exist anymore the sender will respond with a message stanza with
type=error and <item-not-found/> (and potentially the jingle
<unknown-session/>
4. Do you have any security concerns related to this specification?
Yes. Security considerations does not cover the issue of private
information exposure (IP address) to remote party when taking part in a
jingle session. This is covered in XEP-0166 Security Considerations though,
but I think it should make sense that taking part in jingle session not
only results in a presence leak, but also in disclosure of IP.
That is a generic jingle-related concern, no? There is a potential
presence/resource leak in section 3.4 example 10 though as the initiator
is *optionally* told about the rejection.
cheers
Philipp
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
