Institut Luxembourgeois de Régulation - Règlement ILR/T17/9 du 9 août 2017 relatif aux exigences techniques et opérationnelles minimales requises pour l’interconnexion en mode IP pour la voix sur les réseaux téléphoniques publics individuels en position déterminée - secteur communications électroniques.

N° 759 du 22 août 2017

Institut Luxembourgeois de Régulation - Règlement ILR/T17/9 du 9 août 2017 relatif aux exigences

techniques et opérationnelles minimales requises pour l’interconnexion en mode IP pour la voix

sur les réseaux téléphoniques publics individuels en position déterminée - secteur communications

électroniques.

La Direction de l’Institut Luxembourgeois de Régulation,

Vu la loi du 27 février 2011 sur les réseaux et les services de communications électroniques (« Loi de 2011 ») ;

Vu la directive 2002/21/CE du Parlement européen et du Conseil du 7 mars 2002 relative à un cadre

réglementaire commun pour les réseaux et services de communications électroniques (directive « cadre ») ;

Vu la directive 2002/19/CE du Parlement européen et du Conseil du 7 mars 2002 relative à l’accès aux

réseaux de communications électroniques et aux ressources associées, ainsi qu’à leur interconnexion

(directive « accès ») ;

Vu la directive 2002/22/CE du Parlement européen et du Conseil du 7 mars 2002 concernant le service

universel et les droits des utilisateurs au regard des réseaux et services de communications électroniques

(directive « service universel ») ;

Vu la directive 2009/140/CE du Parlement européen et du Conseil du 25 novembre 2009 modifiant les

directives 2002/21/CE du Parlement européen et du Conseil du 7 mars 2002 relative à un cadre réglementaire

commun pour les réseaux et services de communications électroniques, 2002/19/CE du Parlement européen

et du Conseil du 7 mars 2002 relative à l’accès aux réseaux de communications électroniques et aux

ressources associées, ainsi qu’à leur interconnexion et 2002/20/CE relative à l’autorisation des réseaux et

services de communications électroniques ;

Vu le règlement 16/208/ILR du 28 novembre 2016 portant sur la définition du marché pertinent de la fourniture

en gros de terminaison d’appel sur réseaux téléphoniques publics individuels en position déterminée (Marché

1/2014), l’identification des opérateurs puissants sur ce marché et les obligations imposées à ce titre (ci-

après : « le règlement 16/208/ILR») ;

Vu la consultation publique nationale de l’Institut Luxembourgeois de Régulation (ci-après l’« Institut »)

portant sur le projet de règlement relatif aux exigences techniques et opérationnelles minimales requises

pour l’interconnexion en mode IP pour la voix sur les réseaux téléphoniques publics individuels en position

déterminée du 26 mai au 26 juin 2017 ;

Vu les réponses à la consultation publique susvisée ;

Vu la prise de position de l’Institut par rapport aux réponses reçues dans le cadre de la consultation publique

susvisée ;

Vu les diverses réunions de concertation menées entre le 15 novembre 2016 et le 25 avril 2017 y relatives

entre des représentants des opérateurs identifiés comme puissants sur le marché de la fourniture en gros de

terminaison d’appel sur réseaux téléphoniques publics individuels en position déterminée (Marché 1/2014)

dans le cadre du groupe de travail pour l’interconnexion en mode IP pour la voix institué par l’Institut en vertu

de l’article 4(6) du règlement 16/208/ILR ;

Vu le document intitulé « VoIP interconnection Interface specification based on SIP and SDP Version 1.2 »

tel qu’arrêté d’un commun accord lors de la réunion de concertation du 25 avril 2017 instaurant les exigences

techniques et opérationnelles minimales pour l’interconnexion de la voix en mode IP.

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

Arrête

Art. 1

er.

(1) Les conditions techniques et opérationnelles minimales relatives à l’interconnexion en mode IP pour

la voix sur les réseaux téléphoniques publics individuels en position déterminée visées à l’article 4(6) du

règlement 16/208/ILR du 28 novembre 2016 portant sur la définition du marché pertinent de la fourniture en

gros de terminaison d’appel sur réseaux téléphoniques publics individuels en position déterminée (Marché

1/2014), l’identification des opérateurs puissants sur ce marché et les obligations imposées à ce titre sont

arrêtées dans le document intitulé « VoIP interconnection Interface specification based on SIP and SDP

Version 1.2 » qui est annexé au présent règlement pour en faire partie intégrante.

Le présent règlement sera publié au Journal officiel du Grand-Duché de Luxembourg et sur le site Internet

de l’Institut.

Le présent règlement entre en vigueur le premier jour du mois qui suit sa publication au Journal officiel du

Grand-Duché de Luxembourg.

La Direction,

La Directrice adjointe,

Michèle Bram

Le Directeur adjoint,

Camille Hierzig

Le Directeur,

Luc Tapella

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

VOIP INTERCONNECTION

INTERFACE SPECIFICATION BASED ON SIP AND SDP

VERSION 1.2

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

Contents

Reference......................................................................................................................................... 5

Acronyms.........................................................................................................................................

1 Scope and objective......................................................................................................................

2 The infrastructure........................................................................................................................... 8

2.1 Layer 1 interconnection.......................................................................................................... 8

2.2 Layer 2 interconnection.......................................................................................................... 8

2.3 Layer 3 interconnection.......................................................................................................... 8

2.4 Security.................................................................................................................................

2.5 Quality of Service..................................................................................................................

3 SIP signalling messages................................................................................................................ 12

3.1 Transport protocol.................................................................................................................. 12

3.2 SIP methods and headers...................................................................................................... 12

4 Message bodies............................................................................................................................

5 Identity format...............................................................................................................................

5.1 Phone number format............................................................................................................

5.2 SIP URI format......................................................................................................................

6 Signalling mode............................................................................................................................. 13

7 Media Session Establishment......................................................................................................... 13

7.1 Session Description Protocol.................................................................................................. 13

7.2 RTP/RTCP............................................................................................................................. 13

8 Codecs.......................................................................................................................................... 13

9 DTMF transport.............................................................................................................................

10 Fax modem.................................................................................................................................

11 Data modem................................................................................................................................ 14

12 Supplementary Services............................................................................................................... 14

12.1 CLIP/CLIR...........................................................................................................................

12.2 Call Forwarding services......................................................................................................

12.3 Call Hold.............................................................................................................................

13 Early media.................................................................................................................................

14 Keep-alive...................................................................................................................................

14.1 Keep alive for active SIP sessions........................................................................................ 15

14.2 Keep alive for interconnection signalling links........................................................................

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

Reference

[E.164] International Telecommunications Union, "The international public telecommunication numbering

plan", Recommendation E.164, May 1997

[i3FInt] i3Forum, “Technical Interconnection Model for International Voice Services”, Release 6.0, May 2014

[RFC2119] Internet Engineering Task Force (IETF), “Key words for use in RFCs to Indicate Requirement

Levels”, Request for Comments 2119

[RFC2543] Internet Engineering Task Force (IETF), “SIP : Session Initiation Protocol”, Request for Comments

[RFC2976] Internet Engineering Task Force (IETF), “The SIP INFO Method”, Request for Comments 2976

[RFC3261] Internet Engineering Task Force (IETF), “SIP : Session Initiation Protocol”, Request for Comments

[RFC3264] Internet Engineering Task Force (IETF), “An Offer/Answer Model with the Session Description

Protocol (SDP)”, Request for Comments 3264

[RFC3323] Internet Engineering Task Force (IETF), “A Privacy Mechanism for the Session Initiation Protocol

(SIP)”, Request for Comments 3323

[RFC3884] Internet Engineering Task Force (IETF), “Use of IPsec Transport Mode for Dynamic Routing”,

Request for Comments 3884

[RFC4028] Internet Engineering Task Force (IETF), “Session Timers in the Session Initiation Protocol (SIP)”,

Request for Comments 4028

[RFC4040] Internet Engineering Task Force (IETF), “RTP Payload Format for a 64 kbit/s Transparent Call”,

Request for Comments 4040

[RFC4301] Internet Engineering Task Force (IETF), “Security Architecture for the Internet Protocol”, Request

for Comments 4301

[RFC4566] Internet Engineering Task Force (IETF), “SDP : Session Description Protocol”, Request for

Comments 4566

[RFC4733] Internet Engineering Task Force (IETF), “RTP Payload for DTMF Digits, Telephony Tones, and

Telephony Signals”, Request for Comments 4733

[RFC5009] Internet Engineering Task Force (IETF), “Private Header (P-Header) Extension to the Session

Initiation Protocol (SIP) for Authorization of Early Media”, Request for Comments 5009

[RFC5806] Internet Engineering Task Force (IETF), “Diversion Indication in SIP”, Request for Comments

[RFC6086] Internet Engineering Task Force (IETF), “Session Initiation Protocol (SIP) INFO Method and

Package Framework”, Request for Comments 6086

[ETSI102] ETSI TS 102 928 v1.1.3. Speech and multimedia Transmission Quality (STQ) ; End-to-End

Transmission Planning Requirements for Real Time Services in an NGN context

[ETSI103] ETSI TS 103 210 V1.2.1. Speech and multimedia Transmission Quality (STQ) ; End-to-End Jitter

Transmission Planning Requirements for Real Time Services in an NGN context

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

Acronyms

BGP

Border Gateway Protocol

CIR

Committed Information Rate

CLIP

Calling Line Identity Presentation

CLIR

Calling Line Identification Restriction

DDoS

Distributed Denial of Service

DSCP

Differentiated Services Code Points

DTMF

Dual Tone Multi-Frequency

EF

Expedited Forwarding

ILR

Institut Luxembourgeois de Régulation

PIR

Peak Information Rate

QoS

Quality of Service

RTCP

Real-time Transport Control Protocol

RTP

Real Time Protocol

SDP

Session Description Protocol

SIP

Session Initiation Protocol

UDP

User Datagram Protocol

URI

Uniform Resource Identifier

VoIP

Voice over IP

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

1 Scope and objective

Each national Voice Operator registered at the Institut Luxembourgeois de Régulation (ILR) will have the

obligation to grant a Voice over IP (VoIP) interconnection to another national Voice Operator requesting such

a service.

Different solutions can be used for a VoIP Interconnection service, and they are not all compatible with each

other. Therefore, it is important to agree on minimal requirements to guarantee the interoperability between

the Voice Operator networks. The purpose of this document is to provide such minimal requirements.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD

NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described

in [RFC2119].

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

2 The infrastructure

An IP transport layer between Voice Operators is a pre-requisite for a VoIP Interconnection service. Each

Voice Operator is obliged to meet any reasonable request to implement such a network with another Voice

Operator.

Each Voice Operator shall use IPv4 and shall distribute IP routing information with BGP.

A Session Border Controller (SBC) shall be used as a Border Function for SIP signalling and RTP traffic on

each Operator’s VoIP network.

Three types of network configuration are possible, as described below and in [i3FInt].

2.1 Layer 1 interconnection

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

2.2 Layer 2 interconnection

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

2.3 Layer 3 interconnection

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).

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

Layer 3 Private-oriented Interconnection Configuration

2.4 Security

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

Network topology hiding

Protection against intentional and unintentional Distributed Denial of Service (DDoS) attacks

Access Control list for the SIP signaling

Anti Spoofing of signaling traffic such as SIP messages

Media filtering using dynamic pinhole firewall capabilities.

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.

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

2.5 Quality of Service

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

the service class Voice containing the media RTP traffic

the service class SigVoice containing the SIP signalling traffic

the service class Network-control containing the network control traffic

and the default service class Best Effort containing all other traffic.

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

are different

1.

the media traffic (RTP) has a very low tolerance to loss, delay and jitter.

2.

the signalling traffic (SIP) has a low tolerance to loss and delay.

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

the Expedited Forwarding (EF) behaviour shall be used for the service class Voice, as it is intended for

low-loss, low-delay and low-jitter services.

the Class Selector 2 (CS2) behaviour shall be used for the service class SigVoice to give a preferential

forwarding treatment by comparison to other traffic (best-effort, …)

the Class Selector 6 (CS6) behaviour shall be used for network-control traffic to give a preferential

forwarding treatment by comparison to other traffic (best-effort).

Default Forwarding (DF) behaviour provides best effort treatment.

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

DSCP 0 for Class Selector 6 (DF) (IP precedence 0)

DSCP 16 for Class Selector 2 (CS2) (IP precedence 2)

DSCP 46 for Expedited Forwarding (EF) (IP precedence 5)

DSCP 48 for Class Selector 6 (CS6) (IP precedence 6)

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

the end-to-end delay of media traffic does not exceed 150ms (see [ETSI102], section 5)

the inter-arrival jitter does not exceed 60ms, according to [ETSI103] section 5

the IP packet loss ratio for media per Operator does not exceed 9 x 10

-8 (refer to [ETSI102] section 7).

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

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

Profile

CIR

PIR

PROD.VoIP.SipTrkNat_4M

4Mb/s

4Mb/s

PROD.VoIP.SipTrkNat_10M

10Mb/s

10Mb/s

PROD.VoIP.SipTrkNat_15M

15Mb/s

15Mb/s

PROD.VoIP.SipTrkNat_20M

20Mb/s

20Mb/s

PROD.VoIP.SipTrkNat_30M

30Mb/s

30Mb/s

PROD.VoIP.SipTrkNat_60M

60Mb/s

60Mb/s

PROD.VoIP.SipTrkNat_80M

80Mb/s

80Mb/s

PROD.VoIP.SipTrkNat_100M

100Mb/s

100Mb/s

PROD.VoIP.SipTrkNat_130M

130Mb/s

130Mb/s

Table 1: Bandwidth Profiles Examples

Service Class

CIR

PIR

Voice

85%

85%

SigVoice

5%

5%

Network-control

5%

5%

Best Effort

5%

100%

Table 2: Quality Queue Ratio Examples

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

3 SIP signalling messages

The purpose of this section is to describe the minimal requirements for Luxembourg notified Voice Operators

for the signaling and media protocols on the VoIP Interconnection.

3.1 Transport protocol

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

packets shall be used.

3.2 SIP methods and headers

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).

4 Message bodies

In the context of this document, the only SIP message body media types supported are SDP (application

subtype "application/sdp") and DTMF relay (application subtype “application/dtmf-relay”).

5 Identity format

5.1 Phone number format

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”).

5.2 SIP URI format

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”.

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

6 Signalling mode

The en-bloc signalling mode shall be used, i.e. the entire called party number shall be included into a single

INVITE request.

7 Media Session Establishment

7.1 Session Description Protocol

Session Description Protocol (SDP) definition and SDP offer/answer exchange shall be performed according

to [RFC3261], [RFC3264] and [RFC4566].

7.2 RTP/RTCP

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.

8 Codecs

G711A with a packetization time of 20ms must be in the list of supported codecs.

The support of other voice/video codecs is out of scope of the present document but can be considered on

a bilateral basis.

9 DTMF transport

DTMF transport should use the SIP INFO message according to [RFC2976] (also referred to as the “legacy”

SIP INFO usage of [RFC6086]). The SIP INFO message shall use Content-Type: application/dtmf-

relay and the lines Signal and Duration (in milliseconds) to transport a DTMF signal.

Example

INFO sip:+35249915555@sp.lu

SIP/2.0 Via: SIP/2.0/UDP 10.0.0.10:5060

From: <sip:+35249914444@10.0.0.10>;tag=d3f44321

To: <sip:7007471000@example.com>;tag=8944321

Call-ID: 312876DS786D

CSeq: 3 INFO

Content-Length: 24

Content-Type: application/dtmf-relay

Signal=7

Duration=160

Nevertheless, in case the method with SIP INFO is not supported by one of the Operator, DTMF transport

based on telephony events as described in [RFC4733] MUST be supported as a second choice.

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

10 Fax modem

Fax modem calls are supported by default by using the G711A codec without media session modification.

NOTE - This means that fax modem calls must be established with G711A as the initially negotiated codec.

In addition, T38 mode may be used when bilaterally agreed.

There is no guarantee of end-to-end interoperability in G711A because IP network impairments (jitter, delay,

packet loss) are difficult to fully control.

11 Data modem

Data modem calls are supported by using the G711A codec without media session modification.

NOTE – This means that data modem calls must be established with G711A as the initially negotiated codec.

The Clearmode codec [RFC4040] shall also be supported for carrying 64kbit/ channel data in RTP.

There is no guarantee of end-to-end interoperability in G711A and Clearmode because IP network

impairments (jitter, delay, packet loss) are difficult to fully control.

12 Supplementary Services

12.1 CLIP/CLIR

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”.

12.2 Call Forwarding services

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.

JOURNAL OFFICIEL du Grand-Duché de Luxembourg

MÉMORIAL A - 759 du 22 août 2017

12.3 Call Hold

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.

13 Early media

It is up to the calling side to generate a local “Ring back” tone upon receipt of a 180 “Ringing” answer to

an INVITE message.

Nevertheless the calling party side need to be prepared to receive “Ring back” tone delivered as early-media

(i.e. using G711A as voice codec) over the interconnection interface by the called party side. The reception

of a SDP answer in a 18x response is not a sufficient indication of an early media coming from a downstream

domain. The P-early-media header must be included to guarantee an early media stream sent in the

backward direction (towards the origin) will be taken into account in all cases. The P-early-media header

present in a 18x response must contain the direction parameter set to “sendrecv” or to “sendonly”. The

P-early-media header syntax is defined in [RFC5009].

14 Keep-alive

14.1 Keep alive for active SIP sessions

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].

14.2 Keep alive for interconnection signalling links

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.