Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
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...
Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
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)
Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
On Wed, 12 Jun 2013, Lance Stout wrote: So, I've implemented and have been working with this in stanza.io (a new JS websocket XMPP client lib) for WebRTC signaling. (Don't worry, I'm also working with Fippo to get proper Jingle to work too). The primary benefit to this is that I don't have to parse SDP in the browser to create Jingle stanzas, and then translate Jingle back to SDP. However, what is documented here doesn't go far enough to provide that benefit -- it still requires some SDP parsing on the receiving end to extract the relevant bits needed for WebRTC. +1 -- but I think it is quite easy to make sox more usable for peopel who don't have the sip parser but only the sdp parser. So, what I've been using has the form: message sox xmlns=http://stanza.io/protocol/sox; sid=... - thread/ type=offer|answer|candidate add bye and possibly pranswer. [label=... id=...] ...SDP blob... /sox /message Where sid is the user generated session ID, and label and id are for ICE candidate updates. The browser APIs helpfully provide the label and id values. Since they are included as attributes, there is no need for parsing the SDP blob by the receiver. (addIceCandidate) is horribly inconsistent. It should take another sdp blob (consisting of a=mid lines, ice parameters, multiple candidates) etc.
Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
On 2013-06-13 09:06, Philipp Hancke wrote: [..] 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) Please, do not copy examples, but create new ones. There might be legal issues. -- ralphm
Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
On 13/06/2013 12:35, Ralph Meijer wrote: On 2013-06-13 09:06, Philipp Hancke wrote: [..] 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) Please, do not copy examples, but create new ones. There might be legal issues. Why are you saying this? I thought copying examples from RFC or IETF drafts is fine.
Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
On 2013-06-13 15:48, Alexey Melnikov wrote: On 13/06/2013 12:35, Ralph Meijer wrote: On 2013-06-13 09:06, Philipp Hancke wrote: [..] 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) Please, do not copy examples, but create new ones. There might be legal issues. Why are you saying this? Just like the IETF, the XSF relies on copyright assignment. In general it is preferable to use original work in all cases. I thought copying examples from RFC or IETF drafts is fine. Because the XSF operates outside of the IETF, other provisions of the Trust Legal Provisions (TPL) [1] apply. I.e. for those documents that are governed by it. In this particular case, see section 3c. We'd have to make sure proper attribution, legends and all that are included, which goes /slightly/ beyond copy/paste. [1] http://trustee.ietf.org/license-info/ -- ralphm
Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
On Thu, Jun 13, 2013 at 2:48 PM, Alexey Melnikov alexey.melni...@isode.comwrote: On 13/06/2013 12:35, Ralph Meijer wrote: Please, do not copy examples, but create new ones. There might be legal issues. Why are you saying this? I thought copying examples from RFC or IETF drafts is fine. RFCs are licensed content, whereas the XSF requires assignment for XEPs.
[Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
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 The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)
So, I've implemented and have been working with this in stanza.io (a new JS websocket XMPP client lib) for WebRTC signaling. (Don't worry, I'm also working with Fippo to get proper Jingle to work too). The primary benefit to this is that I don't have to parse SDP in the browser to create Jingle stanzas, and then translate Jingle back to SDP. However, what is documented here doesn't go far enough to provide that benefit -- it still requires some SDP parsing on the receiving end to extract the relevant bits needed for WebRTC. So, what I've been using has the form: message sox xmlns=http://stanza.io/protocol/sox; sid=... type=offer|answer|candidate [label=... id=...] ...SDP blob... /sox /message Where sid is the user generated session ID, and label and id are for ICE candidate updates. The browser APIs helpfully provide the label and id values. Since they are included as attributes, there is no need for parsing the SDP blob by the receiver. -- Lance On Jun 12, 2013, at 1:55 PM, XMPP Extensions Editor edi...@xmpp.org 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 The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
