[Jingle] <iq/> versus <message/> (Was: Tomorrow's meeting)

Philipp Hancke fippo at goodadvice.pages.de
Wed Jul 24 05:26:35 UTC 2013


Am 24.07.2013 00:23, schrieb Emil Iov:
>> Right. We can discuss those sdp-over-jingle variants. I'd also love to
>> see some proposals of why one would use <message/> instead of <iq/>.
>> Likely reasons: carbons and via
>
> Could you please expand a bit more on these?

I think we need full protocol flows. Any takers?

Of the top of my head there are basicalyl two issues:
1) jingle currently lets let calling client decide which of my devices 
to ring. See e.g. https://developers.google.com/talk/call_signaling
I'd argue that my server is in a better position to determine which of 
my clients (some of which might not send presence) is able to take the 
call. This also requires presence because the caller needs to send to a 
full jid. A <message/> to the bare gets delivered to all clients. Note 
that I am careful to avoid the term "forked".

2) I want all of my other clients to be informed that i'm currently in a 
call. carbons seems like a way to achieve that. The client receiving the 
call might use pep to signal an incoming call to all my other clients. 
If it includes the SDP, another client can pickup that call (which might 
be a way to solve (1)).

I suppose the sox authors have thought about this quite alot. hopefully 
they won't be too jetlagged on saturday ;-)

>> <thread/> also an integration into chat
>> sessions so we don't have what Dele rightly called "another out-of
>> context session". But that is probably too short notice for tomorrow.
>
> I've never really seen the point of linking a message thread to a call
> but maybe that's because I am missing some specific use cases.

This is about moving away from concept of a call. This is more about 
having a "conversation" and adding media to it seamlessly.
So I start with a chat, you reply (note that the argument about the lack 
of full jid doesn't apply any more since we should exchange directed 
presence at least).
Then I send you a session-initate and your client automatically accepts 
the incoming media from me (because you have replied in the chat). It 
should still ask for your consent before sending your picture, but you 
can hear me before.

I am aware that "rich media chat" wasn't a new idea even in 2006 when JL 
wrote 
http://antecipate.blogspot.de/2006/11/six-oldest-new-ideas-in-chat.html

Whether that works for users is another question...

> That said, why is it that we can't add a thread ID somewhere within a
> Jingle IQ?

Sure. But servers need to add support for that specifically instead of 
reusing generic <thread/>. Also servers don't log <iq/> typically.


In the end it's the question whether a new design is significantly 
better than extending the old one.
I think moving from <iq/> to <message/> doesn't mean we have to rebuild 
the bikeshed from scratch. It's more like deciding on what color we 
should paint it :-)


More information about the Jingle mailing list