I would like to propose that we extend the base protocol to support
direct connections. However, I'd like to avoid the complexities of
trying to mix direct connections with ICE negotiation and the challenges
described in 3.3.1 of having fallbacks etc. Therefore, if we:
- add to 6.2.2.1 DestinationType a new type for a proto/ip/port 3-tuple
- add a flag in 6.2.2 to specify that a direct return address is being
used and that the response should be routed to the top of the via list
regardless of intermediate updates
otherwise, don't change the protocol. A joining peer learns the 3-tuple
address of its bootstrap peer and begins its join process just like
normal. When it sends an ATTACH, it needs to be using ice-lite, but
that's not very hard (and extraordinarily simple if you have two
ice-lites talking with each other).
There is no fallback if you are wrong that you have a publically
accessible address. Using a raw address in your via-list and ice-lite
simply doesn't work if you're wrong, but provides a somewhat lighter
weight and faster protocol when needed.
I will note that I disagree with implementation simplicity being a major
factor here. If you have an ICE implementation (and I think we should
expect the number of available implementations to continue to grow),
it's really not hard to use it in the protocol. I care slightly more
about low-power devices and distributed-pbx type deployments motivating
this type of change to the protocol.
Bruce
Enrico Marocco wrote:
David A. Bryan wrote:
We should to be continue to very clear that ICE is the mechanism we
use in deployments where there is any chance there will be a NAT. I
just think we should try to keep in mind that, perhaps more than other
WGs, we have some folks who want to do unusual things, and some of
them justifiable don't need ICE.
I would like to second this. There are also folks who look forward to
adopting the protocol specified here in research projects focused on
overlays and distributed algorithms in general. P2PSIP would benefit
much from such adoption, but probably the burden of implementing (or
debugging or simply dealing with) ICE would impede it in many cases
(think for example of student projects).
------------------------------------------------------------------------
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
