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.

Adapter la taille du texte :

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.

Arrête :

Art. 1er.

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

Art. 2.

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

Art. 3.

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


VOIP INTERCONNECTION

INTERFACE SPECIFICATION BASED ON SIP AND SDP

VERSION 1.2

Contents

Reference


5

Acronyms


6

1 Scope and objective


7

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


9

2.5 Quality of Service


10

3 SIP signalling messages


12

3.1 Transport protocol


12

3.2 SIP methods and headers


12

4 Message bodies


12

5 Identity format


12

5.1 Phone number format


12

5.2 SIP URI format


12

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


13

10 Fax modem


14

11 Data modem


14

12 Supplementary Services


14

12.1 CLIP/CLIR


14

12.2 Call Forwarding services


14

12.3 Call Hold


15

13 Early media


15

14 Keep-alive


15

14.1 Keep alive for active SIP sessions


15

14.2 Keep alive for interconnection signalling links


15

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 2543

[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 3261

[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 5806

[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

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

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

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

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.

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

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

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�?.

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.

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.

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.


Retour
haut de page