[Standards-JIG] Jingle and ICE

Rob Taylor rob.taylor at collabora.co.uk
Fri Feb 10 23:16:18 UTC 2006


Scott Ludwig wrote:
>>>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.

So am I understanding you correctly that you're saying the way to
associate an RTP stream with its corresponding RTCP stream is by name?

Do you have a proposed naming schema?

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

I think that given that you assert (and I think I believe you ;))  that
exchanging active candidates is unnecessary, then I think this race
condition wont actually arise in Jingle's case.

The one thing that worries me is that although Jingle looks correct, it
doesn't map exactly to ICE-06. For the SIP<->XMPP gateway work it
strikes me as this could be an issue, as ICE aware SIP devices wont be
able to talk to ICE aware XMPP devices, as the SIP devices will be
expecting active candidates signalling and such subtleties as that I
mention above.. Are there discussions underway with J. Rosenberg to get
a consensus on these technical details?

Thanks,
Rob Taylor



More information about the Standards mailing list