[Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

Philipp Hancke fippo at goodadvice.pages.de
Tue Sep 3 12:14:08 UTC 2019


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 <andrew.nenakhov at redsolution.com
>> :
> 
>> вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer <jonas at wielicki.name>:
>>
>>> 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 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).

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


More information about the Standards mailing list