Ole,
On 2018-08-27 01:52, Ole Troan wrote:
> Joe,
> ...
>
> The principles are described and explained here:
>
> Touch, J: Middlebox Models Compatible with the Internet [1]. USC/ISI
> (ISI-TR-711), 2016. (
>
> I don't want to dismiss this completely, but it hand waves over how
> applications are supposed to work in this new Internet architecture.
> You can define your way out of breaking end-to-end, but that doesn't mean you
> can ignore all the issues of NAT traversal.
You've missed the point - if the middleboxes describe behave as
required, apps do not need to change. They work as they would in an
Internet without those boxes.
Quite likely.
Do you have a document describing how my SIP application works?
Ore are you saying PCP, ICE, TURN etc is part of your architecture?
This document provides the needed context in which to interpret apps and
network services.
If you understand that the endpoints of the Internet SIP application are
the NAT and the server, not the host on the NAT's private side, you
understand most of what you need to know. I.e., the SIP client is trying
to trigger behavior in the NAT, but not knowing the source IP or source
port unless discovered or told directly. That's why in-band addresses
don't work without additional mechanisms such as PCP, ICE, and TURN.
I'm not saying you don't need those mechanisms - but rather that the
model I propose explains what is needed and why directly. I.e., as long
as your app acts like it actually runs on the NAT box, it'll work just
fine; to the extent that you don't want to do that, the onus is on you
to support moving it to the hidden client host on the private side.
Joe
Links:
------
[1] http://webmail.strayalpha.com/./#NOP
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
