[Standards-JIG] Jingle and ICE

Scott Ludwig scottlu at google.com
Fri Feb 10 22:58:46 UTC 2006


> > Any number of p2p streams can be created per jingle session. It is up
> > to the session type to create and use the streams as it sees fit.
> > Typically a session type will describe its needs and requirements in
> > its session description.
>
> But how to you then tell that a single media stream is actually made up
> of a number of p2p streams? e.g. if you have a video stream with RTCP
> and an audio stream with RTCP.
> In SDP, this is given to you as a candidate is made out of a number of
> components, and then you can have multiple streams with their own
> candidates.

It isn't a single stream. You literally exchange candidates specific
to a particular stream, and if you create 2 streams, you exchange
candidates for that 2nd stream too. They are independent streams. Each
stream is named. Within a Jingle session you can have any number of
these independent streams.

> > These are accumulated automatically and added to the permutation
> > table. If a valid stun binding response is received with the correct
> > username but the address has not been seen before, it is added to the
> > connection permutation table.
> >
> >
>
> Hmm, how do you do a peer-candidate transaction equivalent to that on
> P66 of draft-ietf-mmusic-ice-06, where you need to give the remote
> candidate id that that peer-derived-candidate matches to in order to
> avoid a race condition?

Not sure what you're referring to. I'll look it up and contact you directly.

>
> Thanks,
> Rob Taylor
>



More information about the Standards mailing list