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

Olivier Crête olivier.crete at collabora.co.uk
Tue Sep 23 16:58:01 CDT 2008

Sorry for being so slow on the replying..g

On Thu, 2008-09-04 at 00:26 +0100, Robert McQueen wrote:
> Olivier Crête wrote:
> > 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?

Its exactly the same if you receive a call (its recv-only to you). A
Full renegotiation mostly means sending a SDP and receiving a new one.
But well, the state is kept, so the new answer should really be an
updated answer to the initial one (or an update to the initial offer is
the re-negotiation is triggered by the callee).

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

Calling is description-replace/accept or whatever is the same to me.
Don't be terrified!

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

I see re-doing the transport as a no-go. If you have a relay, it means
allocation new ports, opening more ports in the firewall, disrupting the
call, etc, etc. It seems really wasteful. All I'm asking is to resend a
few lines of text... I don't see why it scares you so much. And I'm not
sure how it will make the state machine so much more complicated (one
side sends a "replace"... waits for accept or refuse.. if accept if can
forget about it, if refuse, you end the stream).

Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080923/938f4099/attachment.pgp 

More information about the Jingle mailing list