[Standards] Jingle: multiple candidates per transport-info?

[Peter Saint-Andre]

Olivier Crête also wondered why in Jingle ICE-UDP a transport-info
message is restricted to containing only one ICE candidate, rather than
allowing multiple candidates:

http://mail.jabber.org/pipermail/standards/2008-April/018554.html

Olivier pointed out that allowing a transport-info message to contain
multiple candidates would be more consistent with the SDP offer/answer
model, thus making it easier to write clients that support both Jingle
and SIP as well as gateways between Jingle and SIP. However, it is my
understanding that this approach would be inconsistent with the approach
taken by Google Talk as well as any existing Jingle implementations.
Therefore feedback would be appreciated regarding the implications of
such a change.

Thanks!

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Robert McQueen]

Peter Saint-Andre wrote:
> Olivier Crête also wondered why in Jingle ICE-UDP a transport-info
> message is restricted to containing only one ICE candidate, rather than
> allowing multiple candidates:
>
> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>
> Olivier pointed out that allowing a transport-info message to contain
> multiple candidates would be more consistent with the SDP offer/answer
> model, thus making it easier to write clients that support both Jingle
> and SIP as well as gateways between Jingle and SIP. However, it is my
> understanding that this approach would be inconsistent with the approach
> taken by Google Talk as well as any existing Jingle implementations.
> Therefore feedback would be appreciated regarding the implications of
> such a change.

It's not very hard for us to support both - our media engine tells us
when it's done gathering candidates so that we can generate SDP offers,
so similarly, we can generate a "one-shot" all-candidate offer. And,
processing several candidates received can easily be split up if necessary.

So I'd be in favour of making things more similar and allowing offers of
all of the candidates, and offering the ability to trickle candidates
(which I think the ICE RFC got rid of, but I've not checked recent
drafts) as an optimisation which may allow you to connect sooner, a la
Google Talk.

FWIW, our Jingle implementation only implements the Google Talk
compatible transport at the moment anyway, so we can meet any reasonable
XEP modifications. We've got a full ICE implementation but we've not
connected it up with our XMPP signalling yet. Hopefully within a month
or two so we can do some interop testing.

> Thanks!
>
> Peter

Regards,
Rob

[Peter Saint-Andre]

On 05/29/2008 1:42 PM, Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> Olivier Crête also wondered why in Jingle ICE-UDP a transport-info
>> message is restricted to containing only one ICE candidate, rather than
>> allowing multiple candidates:
>>
>> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>>
>> Olivier pointed out that allowing a transport-info message to contain
>> multiple candidates would be more consistent with the SDP offer/answer
>> model, thus making it easier to write clients that support both Jingle
>> and SIP as well as gateways between Jingle and SIP. However, it is my
>> understanding that this approach would be inconsistent with the approach
>> taken by Google Talk as well as any existing Jingle implementations.
>> Therefore feedback would be appreciated regarding the implications of
>> such a change.
>
> It's not very hard for us to support both - our media engine tells us
> when it's done gathering candidates so that we can generate SDP offers,
> so similarly, we can generate a "one-shot" all-candidate offer. And,
> processing several candidates received can easily be split up if necessary.
>
> So I'd be in favour of making things more similar and allowing offers of
> all of the candidates, and offering the ability to trickle candidates
> (which I think the ICE RFC got rid of, but I've not checked recent
> drafts)

Yes IIRC that went away at some point.

> as an optimisation which may allow you to connect sooner, a la
> Google Talk.

In VoIP people seem to care a lot about connecting sooner. :)

If we don't allow this, then at least we may want to define how a
gateway should handle trickled candidates (wait x seconds and bundle them?).

> FWIW, our Jingle implementation only implements the Google Talk
> compatible transport at the moment anyway, so we can meet any reasonable
> XEP modifications. We've got a full ICE implementation but we've not
> connected it up with our XMPP signalling yet. Hopefully within a month
> or two so we can do some interop testing.

Coolio.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Paul Witty]

Peter Saint-Andre wrote:
> On 05/29/2008 1:42 PM, Robert McQueen wrote:
>
>> Peter Saint-Andre wrote:
>>
>>> Olivier Crête also wondered why in Jingle ICE-UDP a transport-info
>>> message is restricted to containing only one ICE candidate, rather than
>>> allowing multiple candidates:
>>>
>>> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>>>
>>> Olivier pointed out that allowing a transport-info message to contain
>>> multiple candidates would be more consistent with the SDP offer/answer
>>> model, thus making it easier to write clients that support both Jingle
>>> and SIP as well as gateways between Jingle and SIP. However, it is my
>>> understanding that this approach would be inconsistent with the approach
>>> taken by Google Talk as well as any existing Jingle implementations.
>>> Therefore feedback would be appreciated regarding the implications of
>>> such a change.
>>>
>> It's not very hard for us to support both - our media engine tells us
>> when it's done gathering candidates so that we can generate SDP offers,
>> so similarly, we can generate a "one-shot" all-candidate offer. And,
>> processing several candidates received can easily be split up if necessary.
>>
>> So I'd be in favour of making things more similar and allowing offers of
>> all of the candidates, and offering the ability to trickle candidates
>> (which I think the ICE RFC got rid of, but I've not checked recent
>> drafts)
>>
>
> Yes IIRC that went away at some point.
>
>
>> as an optimisation which may allow you to connect sooner, a la
>> Google Talk.
>>
>
> In VoIP people seem to care a lot about connecting sooner. :)
>
> If we don't allow this, then at least we may want to define how a
> gateway should handle trickled candidates (wait x seconds and bundle them?).
>
>
Trickling candidates is nice. If trying to use a TURN relay which is
for whatever reason not responding, we could wait a significant amount
of time before deciding that it will not respond, during which time an
aggressive ICE implementation could have already completed, having
chosen to use host candidates. I'd always favour trying to do things as
quickly as possible in order to provide a better user experience.

I can't see any reason not to support multiple candidates in a single
message either; it's cleaner and less bandwidth heavy than sending
separate messages for each candidate, and gives us more information sooner.

--

Paul

[Peter Saint-Andre]

On 06/04/2008 9:31 AM, Paul Witty wrote:
> Peter Saint-Andre wrote:
>> On 05/29/2008 1:42 PM, Robert McQueen wrote:
>>
>>> Peter Saint-Andre wrote:
>>>
>>>> Olivier Crête also wondered why in Jingle ICE-UDP a transport-info
>>>> message is restricted to containing only one ICE candidate, rather than
>>>> allowing multiple candidates:
>>>>
>>>> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>>>>
>>>> Olivier pointed out that allowing a transport-info message to contain
>>>> multiple candidates would be more consistent with the SDP offer/answer
>>>> model, thus making it easier to write clients that support both Jingle
>>>> and SIP as well as gateways between Jingle and SIP. However, it is my
>>>> understanding that this approach would be inconsistent with the
>>>> approach
>>>> taken by Google Talk as well as any existing Jingle implementations.
>>>> Therefore feedback would be appreciated regarding the implications of
>>>> such a change.
>>>>
>>> It's not very hard for us to support both - our media engine tells us
>>> when it's done gathering candidates so that we can generate SDP offers,
>>> so similarly, we can generate a "one-shot" all-candidate offer. And,
>>> processing several candidates received can easily be split up if
>>> necessary.
>>>
>>> So I'd be in favour of making things more similar and allowing offers of
>>> all of the candidates, and offering the ability to trickle candidates
>>> (which I think the ICE RFC got rid of, but I've not checked recent
>>> drafts)
>>>
>>
>> Yes IIRC that went away at some point.
>>
>>
>>> as an optimisation which may allow you to connect sooner, a la
>>> Google Talk.
>>>
>>
>> In VoIP people seem to care a lot about connecting sooner. :)
>>
>> If we don't allow this, then at least we may want to define how a
>> gateway should handle trickled candidates (wait x seconds and bundle
>> them?).
>>
>>
> Trickling candidates is nice. If trying to use a TURN relay which is
> for whatever reason not responding, we could wait a significant amount
> of time before deciding that it will not respond, during which time an
> aggressive ICE implementation could have already completed, having
> chosen to use host candidates. I'd always favour trying to do things as
> quickly as possible in order to provide a better user experience.
>
> I can't see any reason not to support multiple candidates in a single
> message either; it's cleaner and less bandwidth heavy than sending
> separate messages for each candidate, and gives us more information sooner.

I mentioned this to some of the Google Talk folks and they didn't have
objections to allowing multiple <candidate/> elements per session-info
message, so I will make that change to XEP-0176. However, you would
still have the option of batching multiple candidates (even sending the
complete list a la SDP) or trickling single candidates. So I think we
need some guidelines on deciding when to batch and when to trickle. In
fact we had some discussion about this a long time ago in the very early
days of Jingle, IIRC. See for example:

http://mail.jabber.org/pipermail/jingle/2005-November/000031.html

Peter

--
Peter Saint-Andre
https://stpeter.im/