Still my 2 cents to use SDP instead of xmlized SDP in jingle and avoid running behind all changes.
Let jingle do session management and not session description. thanx unni On Sat, Jun 14, 2008 at 3:23 PM, Olivier Crête < [EMAIL PROTECTED]> wrote: > > On Mon, 2008-06-09 at 18:21 -0400, Olivier Crête wrote: > > On Mon, 2008-06-09 at 16:17 -0600, Peter Saint-Andre wrote: > > > On 06/09/2008 4:16 PM, Olivier Crête wrote: > > > > On Mon, 2008-06-09 at 16:02 -0600, Peter Saint-Andre wrote: > > > >> On 06/09/2008 2:30 PM, Olivier Crête wrote: > > > >>> On Mon, 2008-06-09 at 16:17 -0400, Jeff Muller wrote: > > > >>>>> On 06/06/2008 1:23 PM, Jeff Muller wrote: > > > >>>>>> I didn't quite glean this from the spec and am not sure if it's > been > > > >>>>>> discussed in this forum, but is there a way to associate two > streams (or > > > >>>>>> two <content /> entities)? Typically, for a video "call", there > are two > > > >>>>>> streams, audio and video. You want these two streams associated > in the > > > >>>>>> client a) so that they can be presented in an associated way > (camera and > > > >>>>>> speaker controls near each other), and b) so that they can be > associated > > > >>>>>> for lip sync. Especially if there are two video streams (for > example, > > > >>>>>> there's a document camera), you want to know which is the "main" > stream > > > >>>>>> that goes (by default) in the main window with the audio > controls. Or > > > >>>>>> for that matter, if you only want to allow one video stream, you > know > > > >>>>>> which one to do a content-remove on. > > > >>>>> Wouldn't the associated media simply be part of the same RTP > session? Or > > > >>>>> do you want the ability to associate media across RTP sessions? > > > >>>> I'm definitely not an RTP expert here. But from a quick web > search... Isn't > > > >>>> each multimedia type limited to a separate RTP session? From what > I read, a > > > >>>> session really just consists of the port pairs for the (single) > RTP and > > > >>>> (single) RTCP streams. Maybe? > > > >>> You definitely want to be able to associate multiple RTP sessions > to > > > >>> synchronize them. We should define that all the sessions within the > same > > > >>> Jingle negotiation should be synchronized. > > > >>> > > > >>> All the RTP sessions (call media aka m= lines) inside the same SDP > are > > > >>> supposed to be synchronized too. > > > >> So what is the right term for a synchronized set of RTP sessions > (e.g., > > > >> the audio and video sessions from Section 9.3 of XEP-0167)? > > > > > > > > There does not seem to be a standard name for the set of synchronized > > > > RTP sessions. In SIP, they call it a SIP session (how confusing can > that > > > > be). In Farsight2, we call it a conference (but it may not be the > > > > greatest name). I think you can just write something like "all RTP > > > > sessions defined in the same Jingle channel should be synchronized" > or > > > > something to that effect. > > > > > > Right now I have this: > > > > > > *** > > > > > > A Jingle negotiation MAY result in the establishment of multiple RTP > > > sessions (e.g., one for audio and one for video). An application SHOULD > > > consider all of the RTP sessions that are established via the same > > > Jingle negotiation to be synchronized for purposes of streaming, > > > playback, recording, etc. > > > > > > *** > > > > > > Perhaps it's not a good idea to include the text about purposes... > > > > That seems good to me, with or without the purposes > > I don't know if we want to go this way.. but a new IETF draft was just > published to add a way to explicitly state the grouping to > synchronization purposes. > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc3388bis-00.txt > > -- > Olivier Crête > [EMAIL PROTECTED] > Collabora Ltd >
