Subject: [midcom] 2 x ALLOCATE == FANTOM

From: "Pete Cordell" <[email-masked]>
Date: Thu, 22 Nov 2001 07:46:31 -0000

Bob,

You have raised a number of issues here which I think it would be useful to
address.  I've taken the liberty of breaking them out into a number of
separate threads so that they're easier to keep track of.  Hope you don't
mind.

Steve Davies wrote:
>> TURN cannot conform to the spirit of RTP in this way because the ALLOCATE
>> method only reserves a single transport address on the intermediary. If
>> it
>> requested 2 transport addresses, a probe or very similar mechanism would
>> be
>> required to establish the second outbound UDP connection. Even worse, the
>> way TURN is specified, there is a good chance that as a TURN server runs
>> out
>> of resource the associated RTP and RTCP transport addresses could have
>> different IP addresses. NOT ALLOWED.

To which Bob replied:
> The ALLOCATE method could be modified to include a "number of ports"
> attribute to request an allocation of 2 consecutive ports.

and:
> The STUN "Request" could be sent to the 2nd allocated port to
> establish the binding.

This line of reasoning basically leads to FANTOM (or something similar!) as
follows.

If you use TURN to allocate two ports in one message, you need a way to
associate the second port with the original allocation message.  In FANTOM
we do this by returning an identifier in the equivalent of the allocate
response.  We then include that identifier in a probe (equivalent to the
STUN request in Bob's suggestion) sent to the server.  This allows the
server to do the association.

With this method, the second port is effectively being set up using
out-of-band signalling.

Having the second port requiring out-of-band signalling, removes any benefit
of having in-band signalling for the first port.  We have also found that
there are many benefits to having an out-of-band signalling method.  For
example, we are also able to explicitly close the forwarding operation.  The
latter is a great comfort to a number of network administrators!

We can also see the many benefits that out-of-band signalling allows in many
other technology areas, such as the telephony network.  The adoption of
out-of-band signalling has allowed many new features to be added to such
systems in response to customer requirements.  Put simply, it allows for
extensibility.

We suggested TCP for the control channel because that gives us the
reliability we need, simplifying the operation of the code.  It also means
that we could readily reuse things like TLS for security.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom