In this configuration, a dedicated physical link (provided by one Operator, or by the two Operators, or by an identified third party Interconnection Operator) is implemented between PE routers or layer 2 switches, or directly between Border Functions.

Layer 1 Private-oriented Interconnection Configuration

In this configuration, a dedicated physical link (provided by one Operator, or by the two Operators, or by an identified third party Interconnection Operator) is implemented between PE routers or layer 2 switches, or directly between Border Functions passing through an Ethernet switch network run by a third party (e.g. Internet Exchange Point owner). The switch provider will assign specific VLANs for each interconnection allowing for the aggregation of several interconnections over the same physical link.

Layer 2 Private-oriented Interconnection Configuration

In this configuration, a dedicated virtual link is implemented between PE routers passing through a third-party Interconnection Operator. The third-party Interconnection Operator will establish an IP-VPN between the Operator’s networks and shall provide QoS mechanisms and shall guarantee appropriate SLAs (see section Quality of Service).

Layer 3 Private-oriented Interconnection Configuration

The IP network built on top of this physical infrastructure shall be secure and isolated. To achieve this, the following conditions have to be satisfied :

The IP network between the two Operators should be dedicated to the exchange exclusively of SIP messages, RTP, RTCP packets.

All the involved IP addresses (i.e. PE router interface, and Border Function interface) cannot be reached from unidentified entities via the Public Internet. The IP addresses involved can be private or public, but they shall not be announced onto and reachable from the Public Internet.

The VoIP traffic, from the PE router to the Border Function in an Operator domain, shall be secured, either physically or logically, from Internet Transit traffic.

Each operator shall protect its infrastructure with a Border Function providing :

The support of IPSEC according to [RFC3884] and [RFC4301] for the transport of traffic between Operators is out of scope of the present document but can be considered on a bilateral basis.

The support of SRTP and TLS (for the transport of SIP) between the Border Functions of two Operators is out of scope of the present document but can be considered on a bilateral basis.

The partner operator has the right to terminate the interconnection with the other parties if any security event is impacting its own network or if the operator is not compliant with the minimum security requirements.

The traffic forwarding treatment should meet the end-user expectation about quality of voice calls, and the Operators should build their infrastructure in order to preserve the quality end-to-end.

Several distinct DiffServ service classes shall be used :

Media traffic and signalling traffic belong to different DiffServ service classes, because their requirements are different :

Network Control traffic contains routing protocol traffic, which has a low tolerance to loss and delay.

The service class Best Effort contains traffic that has not been identified as requiring differentiated treatment.

For each service class, the forwarding behaviour shall be as follows :

Differentiated Services Code Points (DSCP) shall be used to mark the IP packets :

The Operator shall make sure the traffic is marked accordingly on the egress of the VoIP interconnection interface.

The involved operators shall choose the mechanism to implement forwarding behaviour on his area of responsibility, provided that :

As an example, an Operator may offer various Bandwidth profiles where each profile is characterized by Committed Information Rate [CIR] and Peak Information Rate [PIR], with some Quality Queue Ratio per service class. See as examples the table  Bandwidth Profiles and the table Quality Queue Ratio below.

Such profiles could provide the appropriate forwarding behaviour when they are combined with an admission control mechanism limiting the number of calls and ensuring the availability of bandwidth to carry media. The minimum requirement is a 4Mb/s profile, any other profile is based on a bilateral agreement. In the Table 1 and 2 you find possible examples of bandwidth and Service Classes

Table 1: Bandwidth Profiles Examples

Table 2: Quality Queue Ratio Examples

UDP shall be used for transporting SIP messages. If the UDP packet length is too big, fragmented UDP packets shall be used.

Following methods defined in the specification [RFC3261] shall be supported:

INVITE, ACK, CANCEL, BYE, OPTIONS

The INFO method defined in [RFC2976] shall also be supported for DTMF transport (see section DTMF transport ).

All phone numbers MUST use the E.164 format unless they cannot be represented as such. An E.164 number is formatted as specified in [E.164] with the leading "+", the country (CC) and national (NSN) numbers.

Exceptions are numbers prefixed with a carrier select code (“15�?) and national short codes such as emergency ("112", “113�?), directory-assistance numbers (“118�?) and harmonized numbers for services of social value (“116�?).

The general form of a SIP URI in the Request-URI, and the From, To, P-Asserted-Identity, Diversion header fields is:

sip:userinfo@host:port;uri-parameters

The userinfo token shall consist of the phone number (in the format defined in section Phone number format ). The uri-parameters shall include “user=phone�?.

Session Description Protocol (SDP) definition and SDP offer/answer exchange shall be performed according to [RFC3261], [RFC3264] and [RFC4566].

In a media session, the same IP address and port number shall be used to send and receive RTP packets (symmetric IP address and port number).

Note: The port number for sending/receiving RTCP packets MUST be equal to "the port number negotiated for RTP" + 1.

The P-Asserted-Identity header must be present in the initial INVITE request with a telephone number corresponding to the calling party between luxembourg notified Operators.

Nevertheless, if the CLI is unknown for some reason (e.g. calls crossing international boundaries and no CLI delivery agreement for this international interconnection), it is accepted that the P-Asserted-Identity is absent.

The Privacy header is used for the CLIR service. The Privacy header is defined in [RFC3323] and shall contain the value “id�? for expressing the CLIR service invocation. The Operator must guarantee that the identity is not delivered to the recipient of the call if the Privacy header contains the value “id�?.

The Diversion header field defined in [RFC5806] should be used to represent call forwarding information in case the call has been diverted.

The diversion-counter "counter" parameter in the Diversion header field shall be incremented by '1' for each diversion that occurred. The maximum number of diversions permitted for each communication (all types of diversion included) is 5. The purpose of the diversion-counter is to avoid infinite loops between interconnected networks and resource exhaustion.

If a party in a call wants to put the other party “on hold�?, it shall use the mechanism described in [RFC3264] and send a re-INVITE with a new SDP offer containing the direction attribute (“a=�?) to request the other party to stop sending media.

A keep-alive mechanism shall be used to check that communications are still active. It shall be performed by sending re-INVITE messages periodically based on the session timer defined in [RFC4028].

A keep-alive mechanism using SIP OPTIONS messages should be used to monitor the general status of the other Voice Operators’ networks.

All Operators must reply to SIP OPTIONS messages received on the interconnection interface.

In case the SBC of an Operator is out or service, a second SBC (with the same virtual IP address or different IP address) must take over the traffic.

The Operator must be able to send traffic to an alternate IP address after detecting that the IP address of an SBC is unreachable.