Re: [MMUSIC] ICE PRIORITY with multiple TURN servers

[Justin Uberti <[e-mail]>]

Thanks. I think this could be made clearer in 5245 S 4.1.2.2, and address
the multiple relay server case specifically; right now, it is all about
assigning a local preference based on the network interface.

Something to think about for -bis.


On Fri, Jun 6, 2014 at 12:11 AM, Stach, Thomas <[e-mail]>
wrote:

>  Justin,
>
>
>
> *From:* mmusic [mailto:[e-mail]] *On Behalf Of *Justin
> Uberti
> *Sent:* Freitag, 6. Juni 2014 03:09
> *To:* [e-mail]; Mallinath Bareddy; Jiayang Liu; Eric Rescorla
> *Subject:* [MMUSIC] ICE PRIORITY with multiple TURN servers
>
>
>
> Consider the case where a single endpoint has 2 TURN servers, and
> allocates a relay candidate from both, from the same local IP. What should
> their PRIORITY values be?
>
>
>
> Quoth 5245, S 4.1.2:
>
>    Each candidate for a media stream MUST have a unique
>
>    priority that MUST be a positive integer between 1 and (2**31 - 1).
>
>
>
> OK, so they have to have different priorities, i.e. either their type
> preference or local preference must be different. But then, looking at S
> 4.1.2.1:
>
>    The type preference MUST be identical for all
>
>    candidates of the same type and MUST be different for candidates of
>
>    different types.
>
>
>
> Hmm, this means their local_preference must be different. But later in S
> 4.1.2.1:
>
>    The local preference MUST be an integer from 0 to 65535 inclusive.
>
>    It represents a preference for the particular IP address from which
>
>    the candidate was obtained, in cases where an agent is multihomed.
>
>
>
> Obviously, if they come from the same local IP, this cannot be satisfied.
> What to do?
>
> *[TS] Well, that paragraph continues:*
>
>
>
>   When there is only a single IP address, this value SHOULD be set to
>
>    65535.  More generally, if there are multiple candidates for a
>
>    particular component for a particular media stream that have the same
>
>    type, the local preference MUST be unique for each one.
>
>
>
> So the case of two TURN servers is covered.
>
> What you propose below is OK, but if desired you could  also rank A1, A2,
> B1, B2. It’s your freedom of choice.
>
> Regards
>
> Thomas
>
>
>
> It seems like the easiest solution would be to use some of the local
> preference to represent the ordering, so that both IP preference and server
> preference and represented, and therefore relay candidates from IPs 1 and 2
> and Turn Servers A and B would stack rank as
>
> A1
>
> B1
>
> A2
>
> B2
>