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
> 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
> 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
> a) define an sdp content for jingle.
> This would basically look as shown in
> 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
> 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
> a=ssrc:1483611533 mslabel:**CKgeuhbvd7WK2lGzPUnoIyVZZjCKCb**LzQLf7
> a=ssrc:1483611533 label:**CKgeuhbvd7WK2lGzPUnoIyVZZjCKCb**LzQLf7a0
> <transport ...>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Jingle