Re: [tram] IPv4 and IPv6 allocations

[Oleg Moskalenko <[e-mail]>]

On Thu, Feb 20, 2014 at 9:25 AM, Justin Uberti <[e-mail]> wrote:

>
> > So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may
>> expect that attribute...
>> >
>> I just noticed that as well. Funny..
>>
>> > So, I reconsider my opinion: let's not use the address-family in the
>> REFRESH at all, and refresh all relay endpoints regardless of their
>> protocols.
>> >
>> Well it is nice to have in there as the refresh is also used to delete an
>> allocation. So if you after ICE is completed ends up only using the IPv6
>> allocation you can delete the IPv4 allocation. This frees up resources on
>> the TURN server.
>>
>
> Yeah, that was my thinking as well. If RAF is absent, the refresh applies
> to all allocations. If the RAF is specified, the specific allocations are
> refreshed/deleted, or an error if the RAF doesn't match the existing
> allocations.
>

I suppose that this is probably the "least intrusive" option - if we want
to be able to free the resources. But I'd like to clarify the terminology.
How many allocations we have per TURN session ? I'd suggest to use the term
"relay endpoints" for the allocated relay sockets but I'd keep term
"allocation" as a synonym to "TURN session" (and then we have a single
allocation even if we have two relay endpoints per allocation).

Or we can separate "TURN session" and "allocation" and make the
"allocation" a synonym to "relay endpoint". We have to agree on a single
terminology to avoid the confusions.

So, RAF in REFRESH can be:

1) absent - then it is applicable to all available relay endpoints in the
session;
2) ipv4 - then it is applicable to ipv4 endpoint only and returns 443 if
ipv4 endpoint does not exist;
3) ipv6 - then it is applicable to ipv6 endpoint only and returns 443 if
ipv6 endpoint does not exist;
4) ipv4+ipv6 - then it is applicable to both endpoint only and returns 443
if ipv4 OR ipv6 endpoint does not exist;

Honestly, I'd remove 443 requirement and if the endpoint does not exist I'd
just ignore the request. That would simplify the client code on resource
cleaning. But that would make the specs not-backward-compatible so I
suggest keeping the 443 error.

Oleg