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

Dave Cridland dave at cridland.net
Wed Jul 24 10:22:36 UTC 2013


On Wed, Jul 24, 2013 at 10:55 AM, Emil Ivov <emcho at jitsi.org> wrote:

> I suppose the main issue I have with migrating toward <message/>  is that
> it is a lot of work and the chances of everyone rushing to do this are not
> exactly outstanding.
>
> Jingle adoption hasn't been quite what we've hoped for and there are only
> a handful of clients that support it out there. Many (most?) of those are
> stuck with the early Gingle variant and never bothered to update to Jingle.
>
>
Right, and adoption is something we've got to work on. I suspect we need to
do some interop work here.


> With the above in mind, I am not particularly optimistic about the
> adoption of yet another major shift.
>
> I think it would be a lot safer if we tried to resolve the issues we have
> by building on top of the current spec rather than starting from scratch.
>
>
Absolutely, but I don't think this is a major shift.

On 24.07.13, 10:30, Dave Cridland wrote:
>
>>
>> This does look appealing but I am afraid that the feeling might be a bit
> superficial. One has two ways of handling forking:
>
>
"forking" seems like an overloaded term here. Is there a term of art we
could use specifically for multiple devices ringing for the same
(conceptual) call? If not, can we coin one?


> A) you either leave it entirely to the originating endpoint
> B) or your do it in the server, hiding it from the client and only letting
> it see the leg that produced a successful call.
>
> We can already do "A" with IQs: A client can loop through available
> resources and send session-initiates to everyone who's there. It would then
> need to properly handle all the resulting call legs ... I don't think many
> clients would go for this but if someone wants to: they have the option.
>
>
Right, you can do this, but only if you're already sharing presence. So
either you need to prod the other side into sharing presence first via
XEP-0276, or else you need to get a subscription done.


> "B" is how most SIP deployments do this and it implies specifically
> implementing this on the server. The promise of <message/> is that we might
> be able to pull it off without server modifications.
>
> I believe however that this is deceptive because <message/> would only
> auto fork the "session-initiate" and it wouldn't mask all the replies. This
> means that clients would need to have the code that handles all the legs
> that a call produced, which brings us back to the "A" case. As mentioned
> above, the "A" case is already implementable with IQs.
>
> If, on the other hand, a server is willing to actually do the work so that
> forking would be hidden from the client then wouldn't it be able to also do
> the same with IQs?
>
>
Not legally.

Well, there's two issues there.

Firstly, it breaks <iq/> routing rules, which'd be painful, but even if
not, you'd need to spoof the session-initiate to each called device, and
moderate the replies.

If you stretch things a bit, you could do a bare-jid <iq/>, but then you
still have the problem of handling session-accept from an unexpected source
- it's not clear to me that would work reliably, since it's not documented
behaviour.

However, we can mandate that kind of handling with <message/> - new
protocol construct, new behaviour - and so we can move from an A-style to a
B-style with considerable ease.


> I imagine the
>> session-acknowledge could be elided entirely here, but maybe it should
>> always be sent early to ensure the caller knows not to time out too quick.
>>
>
> Having acks is actually quite nice and an advantage to SDP offer answer.
> Getting an ACK means that you know your offer or answer have been received.
> You know that everything in there is now understood which is quite
> important especially in the case of an answer.
>
>
I meant that in the specific case of a server stepping in with a voicemail
system, but yes, I think ACKs are generally useful. The question is really
whether you want the voicemail system to ack the call before your devices
have had a chance to ring - I doubt it'd do any harm, mind.

Of course, we need additional rules to ensure that multiple devices
>> don't accept the call, but this is where PEP or Carbons come in.
>>
>
> How do PEP and Carbons help here? More specifically, how are they better
> than simply ending the call to everyone who's still ringing as soon as we
> get the first answer?
>

My under-considered opinion is that there may be races involved, and that
called endpoints would benefit from telling each other about answers rather
than hoping that the caller's device is well-behaved. I think there's UX
benefits in having your devices aware of your personal call state anyway.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20130724/e5e305c5/attachment-0001.html>


More information about the Jingle mailing list