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.
I need to deal with this on a more abstract layer...
requirements: ( * must have, + nice to have, ? is maybe)
* compatible with webrtc
* multi-device capable
* ringing on multiple devices
* syncing of call state
? media forking
* must work for 1:1
* must work for conferences
+ must work for MUC
? must work for pubsub
* basic call control features like mute / hold
? session transfer, e.g. from desktop to mobile
* does not depend on presence / knowledge of the resource
+ stateless gatewaying to sip
+ separation of transport and media
+ trickle
+ early transport warmup
Anything i missed?
Basically we have the following alternatives (minor variations
are indented) which need a little more detail:
- jingle-iq with xmlish content as we have it today
- with sdp extension for unknown attributes
- sox as proposed
- with rules for generating a fake sip header
- sipless sox (sdp over xmpp)?
- jingle with sdp description for each content
- jingle variants using message for everything
- jingle-iq variants using message for the session-initiate
I can say something on the first item. I'm not sure that's a hill i'd
like to die on, but...
lance: you wanted to work a little the jingle sdp description stuff a try,
right? just the example i had with some pro/cons would be sufficient.
stpeter/hildjj/cullen/linuxwolf: I'd love to hear some comments on the
multi-devices stuff. The XEP doesn't mention it, but i recall you
mentioned carbons at the summit. Ideally those comments also apply to the
last two items.
ralphm: can you summarize the arguments from the death of signalling post
and why we should bother writing a signaling standard?
if anyone wants to vouch for sipless sox... I wouldn't even object to
jingle with a sip header blob that is passed around. I don't think that
variant is really worth looking into since by definition it can
not fulfill the soft stateless-sip requirement.
If we can get that until the next council meeting... the chair will be
happy. Nothing too fancy...
