On Wed, 12 Jun 2013, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: SIP/SDP Over XMPP (SoX)
Abstract: This specification defines an XMPP protocol extension for
communicating Session Description Protocol (SDP) data, along with relevant
Session Initiation Protocol (SIP) headers. The SoX protocol is designed for use
by XMPP-only endpoints that need to communicate raw SDP information (e.g., in
WebRTC scenarios), not as a general-purpose replacement for the XMPP Jingle
extensions.
URL: http://xmpp.org/extensions/inbox/sox.html
Feedback as promised...
converting the Jingle XML format into SDP
Been there. Works but... complex, error prone and lossy. Actually that
could be avoided in jingle by introducing a sdp description type. Shall I
write up a short proposal for that?
server-side gateway, and such a gateway might introduce unnecessary
complexity into the system (e.g., keeping session state in the gateway)
Having implemented such a server-side gateway (sdp-over-asn1 to jingle) I
can absolutely second that. The main point where the gateway has to keep
state are ice-ufrag and ice-pwd for trickle ice. This might (and ought
to) be remedied by making trickle ice always send the candidates along.
It is important to note that SoX is not intended to deprecate Jingle
I think that is a point I'd be willing to discuss. The use of
<message/> stanzas means that sox is better at forking (carbons!).
Jingle, being iq-based relies on having the resource available.
Speaking in unified communications terms that is "line centric", i.e.
you have to know the number of the person you want to speak to.
Modern systems ought to use a person/people centric model... you want to
reach a person, it doesn't matter what device that person is using.
I'd love to see some examples of this with carbons... if that means I have
to implement it then so be it. Unless Lance volunteers :-)
It is certainly possible to dynamically choose the signalling protocol
of your choice based on the entity capabilites of your peer.
Heck, session initialization has become a commodity as
pointed out in http://bloggeek.me/death-signaling/.
Note that sox is currently lacking supplementary features like mute
unless you intend to do a full O/A cycle with a=inactive/recvonly.
Example 1. A Basic SoX Example
I would like to have the call-id also available in a <thread/>. That
would make it easier to track sessions, especially when things like
trickle ice is used.
The example SDP lacks crypto parameters... just copy over one of the
examples from http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-01
The use of trickle might be interesting... basically that would be the
example from
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00#section-4
(note that m-line-id should be mid there)
