[Jingle] sdp-over-jingle

Philipp Hancke fippo at goodadvice.pages.de
Mon Jul 22 20:30:01 UTC 2013

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 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

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:CKgeuhbvd7WK2lGzPUnoIyVZZjCKCbLzQLf7 
         a=ssrc:1483611533 mslabel:CKgeuhbvd7WK2lGzPUnoIyVZZjCKCbLzQLf7
         a=ssrc:1483611533 label:CKgeuhbvd7WK2lGzPUnoIyVZZjCKCbLzQLf7a0

   <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.


More information about the Jingle mailing list