Changes

=Description/Explanation =

 

==Description/Explanation ==

Occasionally there is a need to have an Allstar Link Server in an 'itinerant' location (one that is non-permanent and possibly even moving). In such a situation it is certainly quite likely that the device's IP address may change quite often (perhaps even several times per hour or more). Also, the form of IP connectivity available to the device may not necessarily be suitable for normal Server operation (such as being behind NAT translation, firewalls, etc. that the Server owner has no control of). Normal operation requires farily stable IP addressing and full public access to at least UDP port 4569 (for IAX2 connectivity) to the Server. Typical examples of 'itinerant' environments include setting up a tiny portable node in a hotel room, utilizing the Internet connectivity provided by the hotel, or having a mobile node on a mobile data network that provides connectivity via some sort of NAT arrangement.

Occasionally there is a need to have an Allstar Link Server in an 'itinerant' location (one that is non-permanent and possibly even moving). In such a situation it is certainly quite likely that the device's IP address may change quite often (perhaps even several times per hour or more). Also, the form of IP connectivity available to the device may not necessarily be suitable for normal Server operation (such as being behind NAT translation, firewalls, etc. that the Server owner has no control of). Normal operation requires farily stable IP addressing and full public access to at least UDP port 4569 (for IAX2 connectivity) to the Server. Typical examples of 'itinerant' environments include setting up a tiny portable node in a hotel room, utilizing the Internet connectivity provided by the hotel, or having a mobile node on a mobile data network that provides connectivity via some sort of NAT arrangement.

When such a relationship exists, all inbound traffic destined for Nodes on the Server Proxy Client is directed to the Server Proxy Server, which accepts and authenticates the traffic, then forwards it off to the Server Proxy Client via a direct (non-public) peering arrangement. Any traffic outbound from Nodes on the Server Proxy Client is directed to the Server Proxy Server, which forwards it to the appropriate location, thus requiring the Server Proxy Client only to be 'reachable' by the Server Proxy Server, and not all nodes on the entire Internet.

When such a relationship exists, all inbound traffic destined for Nodes on the Server Proxy Client is directed to the Server Proxy Server, which accepts and authenticates the traffic, then forwards it off to the Server Proxy Client via a direct (non-public) peering arrangement. Any traffic outbound from Nodes on the Server Proxy Client is directed to the Server Proxy Server, which forwards it to the appropriate location, thus requiring the Server Proxy Client only to be 'reachable' by the Server Proxy Server, and not all nodes on the entire Internet.

= Portal-Based Configuration for Server Proxy Clients =

== Portal-Based Configuration for Server Proxy Clients ==

Since any Allstar Link Server can be a Server Proxy Server, it can not be assumed that both the Server Proxy Client and the Server Proxy Server belong to the same Allstar Link User (or even the same organization, etc.). Therefore, designation and specification of these Proxy relationships are not allowed to be done directly from the Portal (it must be requested by email to Allstar Link Network Validation Staff by both the party that owns the Server Proxy Client, and the party that owns the Server Proxy Server). Once configured by the Staff, the Portal will automatically generate configuration for the Server Proxy Client appropriately. The Server Proxy Server configuration must always be done manually. This provides the ability for a Portal-Configured Server Proxy Client to be in a Proxy relationship with any appropriately configured Server Proxy Server.

Since any Allstar Link Server can be a Server Proxy Server, it can not be assumed that both the Server Proxy Client and the Server Proxy Server belong to the same Allstar Link User (or even the same organization, etc.). Therefore, designation and specification of these Proxy relationships are not allowed to be done directly from the Portal (it must be requested by email to Allstar Link Network Validation Staff by both the party that owns the Server Proxy Client, and the party that owns the Server Proxy Server). Once configured by the Staff, the Portal will automatically generate configuration for the Server Proxy Client appropriately. The Server Proxy Server configuration must always be done manually. This provides the ability for a Portal-Configured Server Proxy Client to be in a Proxy relationship with any appropriately configured Server Proxy Server.