[Jingle] Replacing codec parameters and content-modify/replace

Robert McQueen robert.mcqueen at collabora.co.uk
Wed Sep 3 18:26:06 CDT 2008

Olivier Crête wrote:
> Hello,
> While discussing the pidgin implementation of Jingle. I realized that we
> missed one case.

Uh oh...

> Codecs like Theora, Vorbis and H.264 need a header to be received before
> any media can be decoded. The ideal way to reliably transmit that header
> is in the signalling. To produce that header for some codecs (including
> Vorbis and Theora), you often want to initialize the encoder and pass
> one buffer through it.
> This becomes problematic if you want to start a recv-only call and later
> activate sending. With SIP, what I'd do is first send SDP without the
> header and later when I want to start sending, send it in the updated
> SDP as part of the re-invite. Maybe we could do the same with
> content-modify, being able to send a new <definition> block with updated
> parameters?

Starting a recv-only call is pretty weird though, isn't it? Isn't the
initiator always going to want to originate media, and the responder
then may or may not decide they want to reply with media too. What I'm
getting at is: Does this require a full renegotiation with a new SDP
offer and a new answer, or does it really just require an updated answer
to the original offer?

I'm not sure about including new <definition> blocks in a
"content-modify", as it overloads the semantics somewhat, and makes it
ambiguous what modifications you do/don't have to respect/look out for
in this action. If we /do/ want to do things like updating/replacing the
codec descriptions, maybe we want "description-info" or maybe even
"description-replace"/"description-accept", but this really terrifies me.

> This also applies if the header changes mid-stream (lets say I want to
> dynamically change the source in the case of a server-brokered
> multi-conference). We also need to modify the SDP.

If we're going for a full general purpose re-negotiation I'd much rather
try and push it into making a new content and removing the old one when
it's set up, rather than adding a whole load of hooks/extra semantics
into Jingle to deal with these situations. This avoids various issues
with crossed-over offers (contents are named uniquely by either the
initiator or responder) and gives an unambiguous ordering and indication
of who needs to start/stop which stream when.

The cost is that you might be forced into doing more transport
renegotiation than you wanted to, but I think that these renegotiation
cases are quite rare. There's a big benefit in any reasonably coded
Jingle client to making the state machine per stream as simple as
possible, and just running multiple instances of it if necessary, rather
than ending up with a baby copy of the SIP transactional engine in every
Jingle client. :/

We had the same kind of idea for early media at the XMPP summit. Rather
than require re-negotiation, actually just tweak XEP-0166 so that adding
streams to a pending session is allowable, and put a send-only ringing
stream into the session (maybe hint it somehow in XEP-0167 to say "early
media, content-accept this now if you understand/care).

Similarly I don't really expect clients to support transport-replace
with media calls, it's really just intended for falling back when
establishing stream transports fails and you want to try a different
thing. Maybe we could document that somewhere...


More information about the Jingle mailing list