[Jingle] <iq/> versus <message/> (Was: Tomorrow's meeting)
emcho at jitsi.org
Wed Jul 24 09:17:54 UTC 2013
On 24.07.13, 07:26, Philipp Hancke wrote:
> 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
That's a good point and message is a nice workaround for this specific
case. I am not sure it covers everything though. Need to think a bit more.
> 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".
Hmm ... it would be nice to figure it out given how this is one of the
main reasons we are considering this.
> 2) I want all of my other clients to be informed that i'm currently in a
Do we agree that this is a feature and not a requirement?
> 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 am not sure I see how this works. You don't think you need to brandish
SDP around. If we want to do pickup then it sounds like we'd rather need
something similar to the SIP "replaces" header.
> 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.
This sounds great but I still don't get it. How likely is it for me and
you to have a call, then two separate conversations? One that is related
to the call and one that isn't?
I begin sweating the moment I try figuring out how to explain this to my
> 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
Oh my! I hope no client I use ever does that. There could be a trillion
different reasons why it may be OK for me to chat with you but not to
have an audio conversation. I could be in a meeting, someone might be
sleeping nearby, or I might simply want to hide the fact that I am
talking to you.
> 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
> 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/>.
Why do servers care about this? It's an indication to clients.
> Also servers don't log <iq/> typically.
This doesn't sound like a spec issue.
> 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