Describe the means of connecting to other domains. Protocols and methods with solutions described in reference to the recipes above.

Many efforts are directed on the communication between the end-user and the communication platform. However, the communication platform itself
is connected to the outside world, where the bulk of sessions to and from the platform are usually referred to as a 'trunk' or a 'peering'. Be aware that session peerings are different from IP peerings. Another important point to make is that though in this chapter the term 'VoIP' and 'telephony' are used a lot, it is clear that from an NREN point of view other types of media in the transported sessions are equally relevant.
Three types of trunks or peerings exist:

• trunks between platforms within an organisation, i.g. between locations: intra-domain peerings
• trunks between institutions or NRENs
• trunks between an institution or NREN and a (telephony) service provider
• trunks between (telephony) providers

Peering on different levels

Sessions are exchanged between session gateways (or 'VoIP gateways'), SIP border controllers or proxies. Connecting them, to transport a bulk of sessions can be realised over various types of connections:

• over a dedicated IP link (L1 or L2)
• over a VPN (L3)
• through a signaling proxy (L4 or L5)

Each of the options has particular properties:

Dedicated IP links

By dedicating an IP connection (for instance over a dark fiber, lightpath, or even a DSL line in case of commercial VoIP providers), there is no chance that VoIP traffic can be disturbed by other traffic. If set up isolated from publicly accessible backbones, it is also impossible for hackers to perform DoS attacks or try to steal sessions. Real-time performance of the packets can also be controlled easily. Interesting enough, QoS mechanisms on connections that only transport VoIP do not add much value: every packet has priority. The best approach is to dimension the links very carefully.

VPN

It is very cost-effective to transport VoIP over existing IP connections and backbones. This has a couple of consequences. The most important one in terms of performance is that the real time performance of the Enhanced Communication session streams must not suffer from other types of traffic. On backbones that are provisioned from a cost point of view, this usually means that a Quality of Service (QoS) mechanism should be built in. Most NRENs however, design their backbone such, that each and every packet is guaranteed to find its way through the backbone without being lost (packet loss), within a very limited amount of time (round trip time or RTT) and without too much variations in arrival times (jitter). These are the main three characteristics of a backbone that describe the performance with regard to realtime applications.
Another important issue rises with respect to security. Since the equipment that is necessary for the trunking on both sides of the connection is 'visible' for the entire world, care needs to be taken that they can only receive traffic coming from the trunk partner. This diminishes the vulnerability for DoS attacks. Eavesdropping on a carefully controlled backbone is far less possible than hooking up a handset receiver to a copperwire (a classic eavesdropping scheme in the telephony case), but to minimise the chance even more encryption on the links can be implemented by adding VPN gateways or enabling encryption on the session gateways (or border controllers or proxy).

Session layer

Much discussion is going on the ideal architectural concept for connecting domains, where the question is wheter a border element like a border controller must be used to concentrate sessions, such hiding the infrastructure behind it, make it easier to configure firewalls and possibly perform media conversion. De facto, many commercial IPTelephony implementations use this topology and it can be recommended from a trunking point of view.
All remarks relevant for the VPN type of connectivity hold true for this approach. An important additional aspect is the fact that there should be nodes in this architecture on the backbone that dispatch sessions (proxies), making the owner of the nodes more or less an operator or at least a service provider. The reliability of the proxies has a direct effect on the reliability of the session transport as a whole.

Intra-domain peering

Consciously or unconsiously, NRENs may transport VoIP traffic of their connected institutions to connect multiple PABXes of one institution. The institution benefits from offloading this voice traffic from the PSTN to the IP network both financially as well as in terms of operational efforts. Given the IP connectivity, calls between locations belonging to the same institution are basically free.

Routing numerical addresses

Routing domain addresses

Inter-institutional or inter-NREN peering

NREN-Telecom peering

Trust, QoS, SLA, contract issues

Peerings between institutions or NREN and Telecom operators

Connecting the PABXes can be done in various ways:
Types of signalling

Trust, QoS, SLA, contract issues

...

Contribution by Rui, Erik. 

Inter-Telecom operator peering

Whereas telephony providers use SS7 to communicate between their telephony networks in the TDM case, the IP based equivalent IMS is not
yet adopted widely. This standard is still under development, and combined with politics and commercial interests it can be expected that
the adoption will take place very slowly. At the same time, many 'classic' carriers and certainly newcomers have significant amount of
their traffic that runs over their (isolated) IP networks.

A typical telephony issue rised in the latter type of trunks. They are called 'wholesale trunks' from a regulator point of view.
Though the second type of trunks does not seem to have a 'retail' character, the service provided by the telephony provider is considered a 'retail' service. Such as to discriminate by exchanging traffic between customers and other telephony providers. Trunks to the latter, so between telephony providers are also referred to as wholesale trunks.

Since this scenario is not relevant to the academic world, it will not be described in more detail.