[Standards] proposal to remove Managing Multiple IBB Sessions from XEP-0261
lancestout at gmail.com
Wed Feb 24 15:58:04 UTC 2016
I'm +1 for removing Section 2.4.
After taking a glance through existing implementations I'm aware of, I'm not seeing that anyone has implemented this feature.
To clarify on-list for future reference, here is why Section 2.4 is problematic:
The Jingle IBB transport is limited in only being able to signal a single IBB channel at a time, like so:
<transport xmlns='urn:xmpp:jingle:transports:ibb:1' sid='12345' block-size='4096' stanza='iq' />
Well, if I'm trying to signal an application type that wants to use multiple channels, I'm now stuck with a problem: I can only send one of the channels in my session-initiate or content-add (so which channel?) and have to send the rest via transport-info (before or after the other side accepts?). My initial offer will always be incomplete due to this protocol design, which makes IBB different from other transport types.
But why do I want to use multiple channels under one transport? That's generally only needed if the application type needs to use 'components' (like how the RTP application needs a socket for RTP and optionally a second for RTCP). The trick with components is that they need predefined names so that application instances can reliably identify them. E.g., RTP uses component "0" for RTP and component "1" for RTCP. Can we do that with Jingle IBB and its multi-session feature? No, we can't reliably identify components. There is a 'sid' attribute which comes close, but can't be reliable since we're using that in the XEP-0047 IBB layer, running the risk of multiple IBB sessions with the same sid between the same two peers.
Consider an application type that needs a component named "A". If we tried to use the 'sid' attribute, and I have a single session with two contents with this application, there will be a collision trying to open an IBB session with a sid of "A" twice.
There are three ways of addressing these problems:
1) Ignore it
2) Remove the section (as Peter and I are proposing)
3) Update the spec to fix the problem
While I would like to go with option 3, the fact that Jingle IBB is meant to be the common fallback of last resort makes me extremely hesitant to introduce a new version.
That said, an ibb:2 protocol that fixed these issues would look something like this:
<candidate component="A" sid="12345" block-size="4096" stanza="iq" />
<candidate component="B" sid="67890" block-size="4096" stanza="message" />
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4115 bytes
Desc: not available
More information about the Standards