[Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)
me at ruff.mobi
Fri Aug 30 05:45:48 UTC 2019
Am 29.08.2019 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
> <andrew.nenakhov at redsolution.com
> <mailto:andrew.nenakhov at redsolution.com>>:
> вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer <jonas at wielicki.name
> <mailto:jonas at wielicki.name>>:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
> 2. Does the specification solve the problem stated in the
> and requirements?
> Partially. This specification is not suitable to work with clients
> that rely on push notifications and fetching messages from an archive.
> 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:
> This modified solution does the job. We have also created a test
> bot for testing automated VoIP calling, bot's address is
> devbot at dev.xabber.com <mailto:devbot at dev.xabber.com> (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).
Looking at documents one additional obstacle pops up to my eye in
regards to relying on MAM. XEP-0313 states at 5.1.1
At a minimum, the server MUST store the <body> elements of a stanza.
It is suggested that other elements that are used in a given deployment
to supplement conversations (e.g. XHTML-IM payloads) are also stored.
Other elements MAY be stored.
The implementation I did for instance is using this allowance and
storing only <body> element with metadata (to minimize storage) hence
won't fly in this particular example (MAM would retrieve only "Voice
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards