[Jingle] sdp-over-jingle

Unnikrishnan V ukv1977 at gmail.com
Mon Jul 22 21:07:15 UTC 2013

Couple of years before, I was also thinking on similar lines

a sample doc i created on that time follows :


Please excuse on mistakes as it was written some where on mid  2007.


On Mon, Jul 22, 2013 at 1:30 PM, Philipp Hancke
<fippo at goodadvice.pages.de>wrote:

> I was just (gently) reminded to explain a little bit more
> http://logs.xmpp.org/jingle/**130717/#16:25:25<http://logs.xmpp.org/jingle/130717/#16:25:25>
> Personally, I don't think that either alternative presented below is a
> good idea. Please argue with me if you think there is merit that I fail to
> present.
> Still, I'd like us to have a good rationale for not considering these
> alternatives. Both approaches are likely not backward-compatible, so
> personally I do not think they're viable unless we decide not to care about
> backward compability anyway.
> We basically have two alternatives here for using sdp in <iq/>-based
> jingle:
> a) define an sdp content for jingle.
> This would basically look as shown in
> http://hancke.name/jabber/**sdpcontent.txt<http://hancke.name/jabber/sdpcontent.txt>
> There are some open questions like whether to do xml for a=candidate, but
> I don't think this matters alot
> XEP-0166 even has provisions for sending two different contents with the
> same name in different namespaces:
>         If there are two content types with the same value for the
>         'name' attribute, they shall understood as alternative
>         definitions for the same purpose (e.g., a legacy method and a
>         standards-based method for establishing a voice call),
>         typically to smooth the transition from an older technology to
>         Jingle.
> but I would not rely on anyone to implement this.
> The advantage of this approach is that whenever the SDP changes things are
> transported to the remote end transparently. This removes the sdp<->jingle
> mapping as a potential source of errors.
> The disadvantage is that this doesn't allow the server to manipulate
> things without having and SDP parser. E.g. an edge server might attempt to
> strip any non-relay candidates before sending things over an s2s links to a
> federated peer.
> b) use jingle where and define an sdp extension
> This would basically map everything defined in both SDP and jingle.
> So things like rtpmap would be mapped to jingle, whereas things like
> a=ssrc would not. Instead, any lines not understood by the senderwould
> would be put into a
> <content ...>
>   <description ..>
>     <sdp xmlns=...>
>         a=ssrc:1483611533 cname:xuqhcXv+l5lLRr3B
>         a=ssrc:1483611533 msid:**CKgeuhbvd7WK2lGzPUnoIyVZZjCKCb**LzQLf7
> CKgeuhbvd7WK2lGzPUnoIyVZZjCKCb**LzQLf7a0
>         a=ssrc:1483611533 mslabel:**CKgeuhbvd7WK2lGzPUnoIyVZZjCKCb**LzQLf7
>         a=ssrc:1483611533 label:**CKgeuhbvd7WK2lGzPUnoIyVZZjCKCb**LzQLf7a0
>    </sdp>
>   <description>
>   <transport ...>
>   </transport>
> </content>
> element. The main advantage is that new stuff in sdp can be transported
> transparently to the remote peer.
> I am not sure about compability... bad things might happen if two peers
> with different dialects of jingle meet each other. E.g. for a=rtcp-fb this
> wouldn't have helped unless both sides use SDP as API surface in which case
> (a) is more pragmatic.
> thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20130722/abe16f01/attachment.html>

More information about the Jingle mailing list