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

Dave Cridland dave at cridland.net
Wed Jul 24 08:30:54 UTC 2013


On Wed, Jul 24, 2013 at 6:26 AM, Philipp Hancke
<fippo at goodadvice.pages.de>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?
>
>
I don't think it'll be much different. As a startpoint to the discussion...

I call Fippo:

<message to='fippo at fippomatic.example' from='dwd at dave.cridland.net/Office'
id='jingle-init'>
  <jingle action='session-initiate' sid='blah' xmlns='jingle'/>
</message>

Fippo's devices responds if they're ringing (rather, willing to ring - of
course, there's session-info to indicate they're really ringing), as
before, but with a new action type to replace the iq/result we had before -
perhaps we could actually use session-info for this from the outset,
which'd be neater:

<message from='fippo at fippomatic.example/poolside-phone' to='
dwd at dave.cridland.net/Office' id='jingle-ring-1'>
  <jingle action='session-acknowledge' sid='blah' xmlns='jingle'/>
</message>

<message from='fippo at fippomatic.example/private-jet' to='
dwd at dave.cridland.net/Office' id='jingle-ring-2'>
  <jingle action='session-acknowledge' sid='blah' xmlns='jingle'/>
</message>

Perhaps also - or instead - a device might explicitly reject the call.

<message from='fippo at fippomatic.example/cinema' to='
dwd at dave.cridland.net/Office' id='jingle-init' type='error'>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

The nice thing about a bare jid, here, is that even if Fippo is in his
personal cinema, unable to take the call, or perhaps simply doesn't answer,
the server can respond to take it to voicemail. 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.

<message from='fippo at fippomatic.example' to='dwd at dave.cridland.net/Office'
id='jingle-voicemail'>
  <jingle action='session-acknowledge' sid='blah' xmlns='jingle'/>
</message>
<iq from='fippo at fippomatic.example' to='dwd at dave.cridland.net/Office'
id='jingle-voicemail-setup'>
  <jingle action='session-accept' sid='blah' xmlns='jingle'/>
</iq>

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.


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

Right, there's not *much* more that needs to happen than I've written
above. Of course, this being VOIP related, it'll inevitably end up as a 69
page specification...

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


More information about the Jingle mailing list