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

[Andrew Nenakhov]

вт, 28 апр. 2020 г. в 13:04, Daniel Gultsch :

> Am Do., 29. Aug. 2019 um 11:26 Uhr schrieb Andrew Nenakhov
> :
>
> >> 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
>
> Ignoring the session-still available check here for a second (which I
> think should at least be optional and only done when catching up from
> MAM) why is this changing the proceed to an accept?
>

Well. You see, we _have_ implemented 0353 as it was written on iOS and Web,
and discovered that it just doesn't really work on iOS that has to wake and
fetch data from the archive.

At that point, since no one had really implemented 0353, we've just said
'screw it' and just make a protocol that is capable to work on all
platforms. We succeeded in that. We dropped 'proceed' because we felt it
serves no purpose if we have carbon copies (it's been a while and i don't
remember all the details). From your feedback in other thread I suspect you
eventually came to a similar conclusion.

I'm not forcing more discussions on this topic for one reason: our approach
to push notifications / jingle initiation that worked so well a year ago
was somewhat crippled by new Apple restrictions on push notifications.
While there is nothing there that fully breaks it, it is likely that it can
be improved to speed up the connection process, and we're still evaluating
it. Short problem description: at first we used push notifications as
completely 'blind' service that just tells the client that there are
updates, withholding from transmitting any meaningful info in push
messages. Apple broke that, and it can't be circumvented anyhow. So in new
implementations we have to put some info in them, and if we have to do so
anyway we might consider sending  information directly in push.
Still, we have to establish a connection to notify other devices on
accepted/rejected calls, etc, but at least initial call pickup can be done
somewhat faster. I'm still on a fence with this.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Daniel Gultsch]

Am Do., 29. Aug. 2019 um 11:26 Uhr schrieb Andrew Nenakhov
:

>> 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

Ignoring the session-still available check here for a second (which I
think should at least be optional and only done when catching up from
MAM) why is this changing the proceed to an accept?

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Andrew Nenakhov]

пт, 6 сент. 2019 г. в 12:59, Georg Lukas :
>
> * Andrew Nenakhov  [2019-09-05 09:45]:
> > [..] So we have to
> > operate fully without presence, thus, if a caller rejects a message at
> > the exact moment we fetch an archive, we won't receive 
> > message in normal XMPP way.
> You can enable Carbons to receive live messages. If you do so before
> fetching MAM, you will receive all messages, just not in the right
> order.

Like I said earlier, to receive carbons we need to post presence. If
we post presence, we'll be loaded with presence information and never
get to fetching anything from an archive, cause the app will be closed
in the background. So, no presence, and no carbons, sorry. That's why
we need that callback loop, cause app has already connected, fetched
 and has preciously little time to react, and that  can
work fast and will be delivered back to a client even without
presence.

> > If we had that message attachment XEP it could suit this purpose much
> > better than the current approach.
> You'll be glad to hear of https://xmpp.org/extensions/inbox/fasten.html
> then.

To make this XEP (or 0367) is viable we need to understand how it will
work with an archive.


-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Georg Lukas]

* Andrew Nenakhov  [2019-09-05 09:45]:
> [..] So we have to
> operate fully without presence, thus, if a caller rejects a message at
> the exact moment we fetch an archive, we won't receive 
> message in normal XMPP way.

You can enable Carbons to receive live messages. If you do so before
fetching MAM, you will receive all messages, just not in the right
order.

> Also, 'sufficiently recent' is an extremely unreliable method because
> time on a user device can be different from the server.

Yes, but this is only a problem if a call is never answered nor
retracted, AND your time is off.

> If we had that message attachment XEP it could suit this purpose much
> better than the current approach.

You'll be glad to hear of https://xmpp.org/extensions/inbox/fasten.html
then.

> Why is 353 not designed for carbons?  is a  and
> should be sent to other connected resources once the call is accepted.

Sending a separate explicit message to your other clients is an obvious
hack. The right way would be to ensure that 0280 will deliver a carbon
copy of your  to the other logged in clients.

That way, you will not end up in an inconsistent state if the accepting
client dies in the middle of accepting the call, after sending 
to your account, but before sending  to the caller.



Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Philipp Hörist]

Examples are not normative, the XEP does not limit the message type to
anything specific. So every developer can decide if he wants it carbon
copied or not.

If you fear this is missed by implementors, a hint in the implementation
notes is probably enough.

Regards
Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ruslan N. Marchenko]

On Thu, Sep 05, 2019 at 12:58:53PM +0200, Philipp Hörist wrote:
> Am Do., 5. Sept. 2019 um 12:36 Uhr schrieb Ruslan N. Marchenko 
> :
> 
> 
> > And in 0353 messages are body-less hence not
> eligible for carbons.
> 
> 
> 
> bodyless is eligible for carbons if the message is of type "chat". We use this
> on many XEPs, receipts, all encrypted messages, markers, chatstates etc 

So the only change to XEP required to make it carbons-compatible is to
switch to explicit type='chat' from implicit 'normal'.

--RR

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Philipp Hörist]

Am Do., 5. Sept. 2019 um 12:36 Uhr schrieb Ruslan N. Marchenko :

>
> > And in 0353 messages are body-less hence not
> eligible for carbons.
>
>
bodyless is eligible for carbons if the message is of type "chat". We use
this on many XEPs, receipts, all encrypted messages, markers, chatstates
etc
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ruslan N. Marchenko]

On Thu, Sep 05, 2019 at 12:42:23PM +0500, Andrew Nenakhov wrote:
> вт, 3 сент. 2019 г. в 23:18, Georg Lukas :
> >
> > Speaking of 0353 as is, it was also not designed for Carbons. I think we
> > should explicitly make use of Carbons (by similar means as with MAM), so
> > that we do not need separate  (to self) and  (to the
> > initator) messages. Instead, the  will be carbon-copied to all
> > other resources, letting them know that one client accepted the call.
> 
> Why is 353 not designed for carbons?  is a  and
> should be sent to other connected resources once the call is accepted.
> I'd say that current XEP-0353 specification is designed exclusively
> for carbons.
> 
Because of urn:xmpp:carbons:rules:0 perhaps? Anyone can implement
whatever rules on the server, however the only thing client can rely on
is 6.1 of the XEP-0280. And in 0353 messages are body-less hence not
eligible for carbons. 

--RR
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Andrew Nenakhov]

вт, 3 сент. 2019 г. в 23:18, Georg Lukas :
>
> * Philipp Hancke  [2019-09-03 14:15]:
> > 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).
>
> Let's imagine the following:
>
> - 0353 or 0313 get changed to store all 0353 messages into MAM
>
> - a remote entity sends a 
> - the user's server stores the  into MAM
> - 0357 triggers a push on this new MAM message
> - the (mobile) client connects and fetches MAM
> - the client sees a  that was neither retracted, rejected or
>   accepted and is sufficiently recent (say, last 30 second)

How does a client know that fetched  that he 'sees' is
neither retracted, rejected or accepted?
The thing to know about push notifications is that we DO NOT send
presence on connect. Sending presence results in receiving a massive
chunk of data that occupies all 30seconds of operation that iOS grants
to an application for reaction on a notification. So we have to
operate fully without presence, thus, if a caller rejects a message at
the exact moment we fetch an archive, we won't receive 
message in normal XMPP way. We won't be fetching it from an archive
until the next push arrives. So, a phone would ring for a call that
was already cancelled by a caller.

 method that we use has an advantage that it is delivered to a
fulljid even if a client does not send presence, so it helps in this
situation.

Also, 'sufficiently recent' is an extremely unreliable method because
time on a user device can be different from the server.

> - the client s the call
>
> @Andrew, would this be sufficient to make the protocol work for your iOS
> case?

> A side benefit of this would be that both the call itself and whether it
> was accepted/rejected is stored in MAM and can be displayed in the
> client's message history.

We actually store rejects in MAM. Also, when the call is finished we
store information about call duration. If we had that message
attachment XEP it could suit this purpose much better than the current
approach.

> Speaking of 0353 as is, it was also not designed for Carbons. I think we
> should explicitly make use of Carbons (by similar means as with MAM), so
> that we do not need separate  (to self) and  (to the
> initator) messages. Instead, the  will be carbon-copied to all
> other resources, letting them know that one client accepted the call.

Why is 353 not designed for carbons?  is a  and
should be sent to other connected resources once the call is accepted.
I'd say that current XEP-0353 specification is designed exclusively
for carbons.


--
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Georg Lukas]

* Philipp Hancke  [2019-09-03 14:15]:
> 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).

Let's imagine the following:

- 0353 or 0313 get changed to store all 0353 messages into MAM

- a remote entity sends a 
- the user's server stores the  into MAM
- 0357 triggers a push on this new MAM message
- the (mobile) client connects and fetches MAM
- the client sees a  that was neither retracted, rejected or
  accepted and is sufficiently recent (say, last 30 second)
- the client s the call

@Andrew, would this be sufficient to make the protocol work for your iOS
case?

A side benefit of this would be that both the call itself and whether it
was accepted/rejected is stored in MAM and can be displayed in the
client's message history.


Speaking of 0353 as is, it was also not designed for Carbons. I think we
should explicitly make use of Carbons (by similar means as with MAM), so
that we do not need separate  (to self) and  (to the
initator) messages. Instead, the  will be carbon-copied to all
other resources, letting them know that one client accepted the call.



Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Andrew Nenakhov]

вт, 3 сент. 2019 г. в 19:15, Ralph Meijer :>
> Hi,
>
> Let me start out saying that, like Philipp, my reading of the current
> version of XEP-0353 is also that there is additional information shared
> with the client over FCM/APNS. However, I must also say that neither
> XEP-0353 nor XEP-357 make it clear how this should work exactly. This is
> a problem, because it results in proprietary solutions for doing the
> same thing. At minimum this should get another look and more concrete
> examples with how existing push services would *actually* be used.
>
> Andrew's description of their use of XEP-0353 introduces new elements in
> the existing namespace, and adds a new iq-based exchange. Assuming this
> is an experiment, I do want to point out that before it would go into
> actual use, those would need to be moved to their own private namespace,
> or be included in a next version of this specification (which might
> require a new namespace).

I agree that our approach changes 0353 significantly. Since we DID
implement 0353 in its current form to the letter and discovered that
it can't work well on iOS without additional roundtrip. So it is
unlikely we'll support this XEP without changes. If our approach won't
be accepted into 0353, we'll move it to another namespace and treat is
as a new protocol, and will be implementing it (or another working
solution, if one emerges) instead of non-working one.

As for passing additional information over FCM/APNS. This data goes
totally unencrypted over third party entities, one of which has very
little public trust with matters concerning privacy. The mechanics of
these services prevent payload from being encrypted, so it's what it
is: some meaningful data will go in plain open form over untrusted
networks. If we start doing that, why really stop at 'additional
data'? We could have saved ourselves tons of blood and sweat spent at
making iOS client wake up on notification, connect to a server, fetch
recent messages, check their markers and present only an actual
message to users, all of this in fewer than 30 seconds. Instead, we
could have just displayed banner with a message in a standard open
way, without even establishing a connection, and all we had to do is
agree to send message contents to Apple/Google. No big deal, right?

While I'm not at all jumping on this full e2ee & full stanza
encryption bandwagon, compromising user privacy this way is a no go
for us.

> In the mean while it can present the screen for allowing the user to
> accept the call. As soon as the slow human user then presses 'accept'
> you're immediately good to go and fully establish the call. This saves
> several round-trips, and thus many centiseconds compared to XEP-0353 in
> its current form, and even more if you have a model that relies on
> re-establishing the XMPP connection before starting all of the above.

Of course, it is faster and simpler to do it this way! But at what
cost? Agan, If we start developing the fastest solution, we'll
eventually come up with some CA service that manages calls directly,
fully bypassing XMPP. Is that what we want?

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ralph Meijer]

On 03/09/2019 15.02, Andrew Nenakhov wrote:



вт, 3 сент. 2019 г. в 17:14, Philipp Hancke >:


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.


We're using Processing hints  element to make an archive store 
such messages. https://xmpp.org/extensions/xep-0313.html#hints


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  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  (and potentially the jingle



No, I think push notifications do not work the way you describe. 
XEP-0357 says that a published  MAY contain additional 
custom information, however, all our implementations of Push 
notifications assume that NO additional information is relayed through 
third-party services (ejabberd, as I recall, doesn't even support 
publishing such additional information). Thus, we get NO  in 
push notifications, NO message text, nothing. Just notification to an 
app that it should wake up and update its data. Consequently, the only 
ways we can get this information are MAM and offline messages/ Since 
offline messages perform poorly when there are multiple user devices, it 
leaves us with just MAM.


I strongly oppose any suggestions to make push notifications work 
differently. If we start sending payload about calls via FCM/APNS, why 
stop at calls? We can just send full message text via push notifications 
as Telegram does. And at that point, why messing with XMPP at all? An 
FCM-only messenger can be coded in a week, it'll send and receive full 
message text via FCM, store messages on FCM cloud database and all will 
work admirably well.


Hi,

Let me start out saying that, like Philipp, my reading of the current
version of XEP-0353 is also that there is additional information shared
with the client over FCM/APNS. However, I must also say that neither
XEP-0353 nor XEP-357 make it clear how this should work exactly. This is
a problem, because it results in proprietary solutions for doing the
same thing. At minimum this should get another look and more concrete
examples with how existing push services would *actually* be used.

Andrew's description of their use of XEP-0353 introduces new elements in
the existing namespace, and adds a new iq-based exchange. Assuming this
is an experiment, I do want to point out that before it would go into
actual use, those would need to be moved to their own private namespace,
or be included in a next version of this specification (which might
require a new namespace).

With that all out of the way, let me describe what we did at VEON, as I
briefly alluded to in my presentation at the Summit [1]. Our approach
made calls server-mediated. I.e. the Jingle session-initiate was sent to
the callee's bare JID (their 'account'). The server then could send the
IQ on to online resources or via FCM/APNS. The latter notifications
actually did carry payload, including the media descriptions and
transport information (candidates).

The primary reason for doing it like this is speeding up the
negotiation. A receiving client can:

 * start evaluating the payload
 * configure the media library (in our case libwebrtc) to start media
streams on the device
 * re-establish the XMPP connection to the server
 * possibly request credentials for TURN
 * set up a TURN connection
 * retrieve vCards / avatars for the caller
 * etc.

In the mean while it can present the screen for allowing the user to
accept the call. As soon as the slow human user then presses 'accept'
you're immediately good to go and fully establish the call. This saves
several round-trips, and thus many centiseconds compared to XEP-0353 in
its current form, and even more if you have a model that relies on
re-establishing the XMPP connection before starting all of the above.

I want to note that our use cases where the XMPP connection might have
high latency but the actual media flows are local (even within office
networks).

Obviously, we also ran into the issue that notification payloads have
size limits. Thiago Camargo wrote a specialized compression library,
Shogun, to tackle this. It relies on a pre-shared dictionary for better
compression.

[1] 

--
Cheers,

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

[Andrew Nenakhov]

вт, 3 сент. 2019 г. в 17:14, Philipp Hancke :

> 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.
>

We're using Processing hints  element to make an archive store such
messages.  https://xmpp.org/extensions/xep-0313.html#hints

> 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  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  (and potentially the jingle
> 
>

No, I think push notifications do not work the way you describe. XEP-0357
says that a published  MAY contain additional custom
information, however, all our implementations of Push notifications assume
that NO additional information is relayed through third-party services
(ejabberd, as I recall, doesn't even support publishing such additional
information). Thus, we get NO  in push notifications, NO message
text, nothing. Just notification to an app that it should wake up and
update its data. Consequently, the only ways we can get this information
are MAM and offline messages/ Since offline messages perform poorly when
there are multiple user devices, it leaves us with just MAM.

I strongly oppose any suggestions to make push notifications work
differently. If we start sending payload about calls via FCM/APNS, why stop
at calls? We can just send full message text via push notifications as
Telegram does. And at that point, why messing with XMPP at all? An FCM-only
messenger can be coded in a week, it'll send and receive full message text
via FCM, store messages on FCM cloud database and all will work admirably
well.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Philipp Hancke]

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 
:



вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer :


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 dev...@dev.xabber.com
(calling bot works well, receiving calls from bot has some bugs at the
moment). One may perform calls using preview version
 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  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  (and potentially the jingle 




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: standards-unsubscr...@xmpp.org
___

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

[Philipp Hancke]

Am 29.08.19 um 11:06 schrieb Dave Cridland:

On Thu, 29 Aug 2019 at 09:09, Daniel Gultsch  wrote:


Am Di., 30. Juli 2019 um 18:42 Uhr schrieb Jonas Schäfer <
jo...@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?


I don’t know yet. I haven’t implemented it.


3. Do you plan to implement this specification in your code? If not,
why not?


I do have plans to implement this (hopefully by the end of this year~ish)

Given the low number of implementations I would suggest to wait a
little longer until we have more experience.



I was under the impression that there were a few implementations of this
around, actually - anyone care to chime in? Fippo, perhaps, or Андрей?


Some people chimed in at
  https://mail.jabber.org/pipermail/standards/2019-March/035884.html
back in march. If OTOH we have promises of feedback it might be worth 
postponing the LC again...

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ruslan Marchenko]

Hi,

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 
>:


вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer mailto:jo...@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.

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
dev...@dev.xabber.com  (calling bot
works well, receiving calls from bot has some bugs at the moment).
One may perform calls using preview version
 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  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  element with metadata (to minimize storage) hence 
won't fly in this particular example (MAM would retrieve only "Voice 
Call" message).



Regards,

Ruslan

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Schäfer]

Comments below.

On Donnerstag, 29. August 2019 13:24:34 CEST Andrew Nenakhov wrote:
> 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.

Lucky for you, there has been no discussion.

> 
> сб, 3 авг. 2019 г. в 21:04, Andrew Nenakhov  > вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer :
> >> 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.
> > 
> > 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-eEUepgRr
> > ge0ow/edit
> > 
> > This modified solution does the job. We have also created a test bot for
> > testing automated VoIP calling, bot's address is dev...@dev.xabber.com
> > (calling bot works well, receiving calls from bot has some bugs at the
> > moment). One may perform calls using preview version
> >  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).

Thanks for posting this.

Can someone of the Jingle folks please review and comment on this? From my 
perspective, it looks very reasonable to have a callback mechanism to test if 
a session still exists before proceeding to show the call interface.

Ideally, Andrew, you would make a PR against the xeps repository [1]. I am not 
sure if you are familiar with the process. If you are not, you can reach out 
to me off-list and I’ll get you started. In any case, we’d need a confirmation 
that it is okay for you and the company behind Xabber to integrate this change 
into XEP-0353, copyright and IPR wise [2].

kind regards,
Jonas

   [1]: https://github.com/xsf/xeps/
   [2]: https://xmpp.org/about/xsf/ipr-policy.html

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[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 :

> вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer :
>
>> 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.
>
> 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 dev...@dev.xabber.com
> (calling bot works well, receiving calls from bot has some bugs at the
> moment). One may perform calls using preview version
>  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).
>
> 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.
>
> 5. Is the specification accurate and clearly written?
>>
>
> Quite clearly.
>
>
-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On Thu, 29 Aug 2019 at 09:09, Daniel Gultsch  wrote:

> Am Di., 30. Juli 2019 um 18:42 Uhr schrieb Jonas Schäfer <
> jo...@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?
>
> I don’t know yet. I haven’t implemented it.
>
> > 3. Do you plan to implement this specification in your code? If not,
> > why not?
>
> I do have plans to implement this (hopefully by the end of this year~ish)
>
> Given the low number of implementations I would suggest to wait a
> little longer until we have more experience.
>

I was under the impression that there were a few implementations of this
around, actually - anyone care to chime in? Fippo, perhaps, or Андрей?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Daniel Gultsch]

Am Di., 30. Juli 2019 um 18:42 Uhr schrieb Jonas Schäfer :
> 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?

I don’t know yet. I haven’t implemented it.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I do have plans to implement this (hopefully by the end of this year~ish)

Given the low number of implementations I would suggest to wait a
little longer until we have more experience.

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Schäfer]

On Dienstag, 30. Juli 2019 20:38:44 CEST Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0353.
> 
> Title: Jingle Message Initiation
> Abstract:
> This specification provides a way for the initiator of a Jingle
> session to propose sending an invitation in an XMPP message stanza,
> thus taking advantage of message delivery semantics instead of sending
> IQ stanzas to all of the responder's online resources or choosing a
> particular online resource.
> 
> URL: https://xmpp.org/extensions/xep-0353.html

The council is currently voting on this for move to Draft or not. Even if you 
have no remarks about this XEP, please send a short message on-list if you 
have implemented it.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[XSF Editor]

This message constitutes notice of a Last Call for comments on
XEP-0353.

Title: Jingle Message Initiation
Abstract:
This specification provides a way for the initiator of a Jingle
session to propose sending an invitation in an XMPP message stanza,
thus taking advantage of message delivery semantics instead of sending
IQ stanzas to all of the responder's online resources or choosing a
particular online resource.

URL: https://xmpp.org/extensions/xep-0353.html

This Last Call begins today and shall end at the close of business on
2019-08-13.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

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 introduction
and requirements?

3. Do you plan to implement this specification in your code? If not,
why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

Your feedback is appreciated!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___