[Standards] Jingle updates (WIP)
lancestout at gmail.com
Sun Jan 24 21:48:29 UTC 2016
> Folks, I've been working (slowly) on updates to the Jingle specs so that we can incorporate feedback, fix a few bugs, and track some of the more modern RFCs and Internet-Drafts on these topics.
Thanks Peter for working on the Jingle specs!
> Jingle (core definition):
Some additional items to consider:
1) Using content-add/content-accept before session-accept
There is no guidance on how to use content-add and content-accept before
the session itself has been accepted. For example:
Romeo --- session-initiate ---> Juliet
Romeo <--- content-add --- Juliet
Should Romeo accept the content now, or does he need to wait for Juliet to
send the session-accept first?
The key issue here is content disposition. XEP-0269 (Jingle Early Media)
explains how accepting contents before session-accept is doable, but only
when the content disposition is "early-session".
The question is thus: Is it allowed to accept a content with "session"
disposition before the session itself has been accepted?
If the answer is yes, we have the odd case where the responder could
individually accept all offered contents (and start the application media
flows), without ever accepting the session itself. And maybe that's OK,
but it is something I ran across on accident while button mashing with a
live system (it caused a crash as I had never considered this case when
2) content-reject vs content-remove
These two actions are very similar in that they both result in expunging
a content from the session. The main distinction between these actions is
that content-reject is specifically used in response to a content-add.
The question here is: If the responder does not want one of the contents in
the session-initiate, which action should be used to get rid of it?
The answer appears to be content-remove.
Which means that a responder can "reject" content two different ways.
This leads to a hidden state variable for contents: was the content
included in the initial session-initiate, or did it come from a later
Declining a content from the initial session-initiate is a content-remove
action, and declining a content introduced via content-add is a
Now, I know that the current text specifies this behaviour, but in a
roundabout way; a more explicit note that the origin action of a content
needs to be tracked would be good.
I would suggest that we don't need content-reject, in the same way that
we only have session-terminate for both rejecting and removing a session,
but that would be a backwards incompatible change. However, should we just
say that these are two names for the same action, and clients need to handle
3) Framed Transports
Jingle currently classifies transports into two categories: Datagram and
Streaming. These are of course meant to mirror the behaviors of UDP and
However, I would like to propose a third category: Framed. A framed
transport is packet based like a datagram transport, but also provides
| Transmission Mode | Reliability
Datagram | Data packet | Unreliable
Framed | Data packet | Reliable
Streaming | Continuous Stream | Reliable
There are several network transports that can fit the framed model:
- WebRTC Data Channels (SCTP over DTLS)
- "Raw" SCTP (eg. DTLS over SCTP)
> Jingle RTP:
I don't think removing <active /> is worth a namespace version bump by
itself. The <active /> info is easy enough to process as it is.
> The primary TODO items now are adding some implementation notes to XEP-0166 (which Lance Stout has volunteered to do)
I am still working through writing up implementation notes. If you are
interested in reading about implementation experiences, here is a link:
NB: This is still being written/edited, and is currently more of a blog
post to flesh out thoughts before formalizing into updates for XEP-0166.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4115 bytes
Desc: not available
More information about the Standards