specifica tecnica - ISCOM - Istituto Superiore delle Comunicazioni e ...

MINISTERO DELLO SVILUPPO ECONOMICO – Dip. COMUNICAZIONI 

ISTITUTO SUPERIORE DELLE COMUNICAZIONI E DELLE TECNOLOGIE DELL'INFORMAZIONE 

Specifica d'interconnessione tra reti 

SPECIFICA TECNICA 

No 769 

Soluzioni tecniche di interconnessione in tecnologia a 

commutazione di pacchetto per servizi telefonici 

Parte A – Network-to-Network Interface (NNI) in tecnologia VoIP/IP 

basata sul protocollo di segnalazione SIP 

Versione 1 

(Novembre 2012) 

NOTA: Il documento costituisce la Specifica Tecnica di dettaglio ai sensi della Del. 128/11/CIR, recependo, 

ai sensi dell’art. 20 del Codice delle Comunicazioni Eletroniche, gli standard e specifiche tecniche 

internazionali di riferimento. 

ST 769 Parte A versione 01 novembre 2012 1/25




Indice 

A.1. Scopo..................................................................................................................................4 

A.2. Riferimenti..........................................................................................................................4 

A.3. Definizioni ed acronimi....................................................................................................5 

A.3.1 Definizioni ................................................................................................................................5 

A.3.2 Acronimi................................................................................................................................... 5 

A.4. Servizi forniti alla NNI SIP in ambito “voce”................................................................6 

A.5. Protocollo di segnalazione alla NNI ..............................................................................7 

A.5.1 Control plane ........................................................................................................................... 7 

A.5.1.1 SIP methods ....................................................................................................................................8 

A.5.1.2 SIP header .....................................................................................................................................10 

A.5.1.3 Mapping Cause SIP - ISUP ...........................................................................................................13 

A.5.1.4 SIP extensions...............................................................................................................................13 

A.5.1.5 Timer ..............................................................................................................................................14 

A.5.1.6 Generazione dei toni di chiamata ................................................................................................14 

A.5.2 Servizi e procedure ............................................................................................................... 15 

A.5.2.1 Chiamata base...............................................................................................................................15 

A.5.2.2 Servizi supplementari ...................................................................................................................17 

A.6. Servizi e procedure ....................................................................................................... 24 

A.6.1 Pos/Modem ............................................................................................................................ 24 

A.6.2 Dati/Clearmode...................................................................................................................... 

25 





Registro delle modifiche per le versioni della ST 769 

N° versione Descrizione Data rilascio e Note 

v. 1 Prima versione della ST 769 ai sensi della 

Del. 128/11/CIR ed dell’art. 20 del Codice 

delle Comunicazioni Elettroniche. 

7/11/2012 Approvata dalla Commissione Interconnessione di MiSE – 

Dip. Comunicazioni. 





Specifica Tecnica n. 769 – Parte A 

Parte A – Network-to-Network Interface (NNI) in tecnologia VoIP/IP 

basata sul protocollo di segnalazione SIP 

A.1. Scopo 

Il presente documento di specifica tecnica di interconnessione è parte integrante del “corpo” della ST 769 e 

definisce, sulla base delle specifiche tecniche e normative tecniche internazionali ETSI di riferimento, 

l’architettura funzionale ed i protocolli dell’interfaccia di interconnessione (NNI, Network-to-Network Interface) 

tra domini di rete “SIP-based”, che devono essere rese disponibili attraverso appositi Border Gateway dagli 

operatori di telefonia per realizzare l’interconnessione per servizi telefonici in tecnologia a commutazione di 

pacchetto VoIP/IP. 

A.2. Riferimenti 

[1] 3GPP TS 29.165 v8.2.0 (ETSI TS 129.165 RTS/TSGC-0329165v820) 

[2] ITU-T Q.1912.5 "Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call 

Control protocol or ISDN User Part (03/2004)" 

[3] 3GPP TS 29.163 v7.2.0 Interworking between the IP Multimedia (IM) Core Network (CN) – 

subsystem and Circuit Switched (CS) networks 

[1] IETF RFC 2327 "SDP: Session Description Protocol", April 1998 

[2] IETF RFC 2833 "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", May 

2000 

[3] IETF RFC 3261 "SIP: Session Initiation Protocol", June 2002 

[4] IETF RFC 3262 "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", June 

2002 

[5] IETF RFC 3264 "An Offer/Answer Model with SDP", June 2002 

[6] IETF RFC 3311 "The Session Initiation Protocol UPDATE Method", September 2002 

[7] IETF RFC 3323 "A Privacy Mechanism for the Session Initiation Protocol (SIP)", November 2002 

[8] IETF RFC 3325 "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity 

within Trusted Networks", November 2002 

[9] IETF RFC 3326 " The Reason Header Field for the Session Initiation Protocol", December 2002 

[10] IETF RFC 3362 “RFC 3362 - Real-time Facsimile (T.38) - image/t38 MIME Sub-type”, August 2002 

[11] IETF RFC 3455 “Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for 

the 3rd-Generation Partnership Project (3GPP)”, January 2003 

[12] IETF RFC 3665 “Session Initiation Protocol (SIP) Basic Call Flow Examples”, December 2003 

[13] IETF RFC 3725 “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation 

Protocol (SIP)”, April 2004 

[14] IETF RFC 3960: "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", 

December 2004 

[15] IETF RFC 3966 “The tel URI for Telephone Numbers”, December 2004 

[16] IETF RFC 4028 “Session Timers in the Session Initiation Protocol (SIP)”, April 2005 

[17] IETF RFC 4040 “RTP Payload Format for a 64 kbit/s Transparent Call”, April 2005 

[18] IETF RFC 4244 “An Extension to the Session Initiation Protocol (SIP) for Request History 

Information”, November 2005 

[19] IETF RFC 4317 “Session Description Protocol (SDP) Offer/Answer Examples”, December 2005 





[20] IETF RFC 6337 “Session Initiation Protocol (SIP) Usage of the Offer/Answer Model”, August 2011 

[21] ETSI TS 124.504 v8.5.0 

[22] Delibera AGCom 128/11/CONS “Disposizioni regolamentari in merito alla interconnessione IP e 

interoperabilità per la fornitura di servizi VoIP” 

Per quanto riguarda i riferimenti 3GPP il loro recepimento è riportato all’interno presente documento. 

A.3. Definizioni ed acronimi 

A.3.1 Definizioni 

Si applicano le definizione della ST 769. 

A.3.2 Acronimi 

3GPP 

APRI 

CC 

CD 

CDIV 

CF 

CFB 

CFNR 

CFU 

CH 

CLIP 

CLIR 

DTMF 

ETSI 

IBCF 

IETF 

IM 

IMS 

IP 

ISDN 

ISUP 

MCID 

MIME 

MNP 

n/a 

NE 

NNI 

NP 

NUE 

3rd Generation Partnership Program 

Address presentation restricted indicator 

Country Code 

Call Deflection 

Call DIVersion 

Call Forwarding 

Call Forwarding on Busy 

Call Forwarding on No Reply 

Call Forwarding Unconditional 

Call Hold 

Calling line Identification Presentation 

Calling Line Identification Restriction 

Dual Tone Multi Frequency 

European Telecommunications Standards Institute 

Interconnect Border Control Function 

Internet Engineering Task Force 

IP Multimedia 

IP Multimedia Subsystem 

Internet Protocol 

Integrated Services Digital Network 

ISDN User Part 

Malicious Call Identification 

Multipurpose Internet Mail Extension 

Mobile Number Portability 

non applicabile 

Network Element 

Network-to-Network Interface 

Number Portability 

Numero Unico Europeo 





OLO 

OPB 

PCMA 

PdI 

PSTN 

RFC 

RgN 

RM 

RTCP 

RTP 

SBC 

SDP 

SIP 

SN 

TCP 

TI 

UA 

UAC 

UAS 

UDP 

URI 

URL 

VAD 

VoIP 

Other Licensed Operator 

Optical Packet Backbone 

Pulse Code Modulation A-law 

Punto di Interconnessione 

Public Switched Telephone Network 

Request for Comments 

Routing Number 

RadioMobile 

Real-time Transport Control Protocol 

Real-time Transport Protocol 

Session Border Controller 

Session Description Protocol 

Session Initiation Protocol 

Subscriber Number 

Transmission Control Protocol 

Telecom Italia 

User Agent 

User Agent Client 

User Agent Server 

User Datagram Protocol 

Uniform Resource Identifier 

Uniform Resource Locator 

Voice Activity Detection 

Voice over IP 

A.4. Servizi forniti alla NNI SIP in ambito “voce” 

Si riporta di seguito, ad alto livello, l’elenco dei servizi/prestazioni di rete previsti alla NNI SIP e definiti nella 

prima versione della presente specifica tecnica. L’estensione del set di servizi verrà trattato in successive 

revisioni del presente documento.. 

L'effettiva fruizione del servizio e il corretto svolgimento delle procedure previste sono demandate alle 

logiche di servizio espletate localmente da ciascun operatore. 

Si rimanda alla sez. A.5.2 per i dettagli dei servizi e delle procedure. 





Servizi Supplementari 

Chiamata base 

CLIP/CLIR 

MCID 

CFB / CFNR / CFU 

Call hold 

Call waiting 

3PTY 

Riferimento documento 

Sez. A.5.2.1 

Sez. A.5.2.2.1 

Sez. A.5.2.2.2 

Sez. A.5.2.2.3 

Sez.. A.5.2.2.4 

Sez. A.5.2.2.5 

Sez. A.5.2.2.6 

Tabella 1 – servizi supplementari 

Nel presente allegato si riportano i servizi che presentano particolarizzazione in ambito profilo SIP. 

Servizi di rete 

Chiamate CLEARMODE 

Chiamate MODEM 

SI 

SI 

Supportato all’interfaccia 

Tabella 2 – servizi di rete 

La descrizione dettagliata dei servizi è riportata in Sez. A.5.2. 

A.5. Protocollo di segnalazione alla NNI 

La soluzione oggetto del presente documento definisce un’interfaccia protocollare basata sul protocollo di 

segnalazione SIP; sintetizzando quanto riportato nei paragrafi e capitoli seguenti, il documento descrive con 

rimando agli standard di riferimento: 

1. Control Plane: limitatamente ai servizi voce i formati dei messaggi scambiati, i flussi di segnalazione 

e le procedure da applicare all’interfaccia. 

2. User Plane: nel presente documento sono trattati gli aspetti che si applicano alla NNI SIP e per la 

Generazione tono di chiamata. 

Quanto di seguito definito tiene conto dei servizi e delle prestazioni riportate in sez. A.5.2. 

A.5.1 Control plane 

Di seguito la tabella che specifica gli IETF RFC con le integrazioni ed eccezioni che sono state individuate. 

Deve essere assicurato, in particolare, il trattamento dei methods/headers SIP previsti ai paragrafi A.5.1.1 e 

A.5.1.2 al fine di garantire la piena compatibilità all’interfaccia tra le due reti. La ricezione di metodi/header 

non previsti potrà comportare lo scarto/filtering dei medesimi. 1 

L’evoluzione della segnalazione in una delle due reti non dovrà avere impatti sull’interfaccia di segnalazione 

tra le reti stesse. Ciò potrà avvenire in accordo a una delle seguenti modalità: 

assicurando che la nuova versione del protocollo di segnalazione sia in accordo alle eventuali 

successive versioni del presente documento di interfaccia SIP NNI nonché alle specifiche di 

riferimento che garantiscano l’interoperabilità con i sistemi di segnalazione precedenti; 

1 L’operazione di filtering potrà avvenire in modalità preventiva o a posteriori una volta verificato il metodo/header incriminato 





 

facendo svolgere ai punti di interconnessione gateway funzioni di filtraggio delle informazioni di 

segnalazione proprietarie-aggiuntive, quando non esista un accordo bilaterale fra le parti per consentirne 

il passaggio. 

IETF RFC Titolo Note 

Core SIP Documents 

RFC 3261 SIP: Session Initiation Protocol 

RFC 3665 

RFC 3725 

Session Initiation Protocol (SIP) Basic Call Flow 

Examples 

Best Currento pratictices for Third Party Call 

Controll (3pcc) in the session Initiation protocol 

(SIP) 

SDP Related Documents 

RFC 2327 

RFC 3264 

RFC 2833 

RFC 3262 

RFC 3311 

RFC 3323 

RFC 3325 

Session Description Protocol (SDP) 

An Offer/Answer Model with the Session Description 

Protocol (SDP) 

SIP Extension and Options 

RFC 2833 "RTP Payload for DTMF Digits, 

Telephony Tones and Telephony Signals 

Reliability of Provisional Responses 

UPDATE Method 

A Privacy Mechanism for SIP 

Private Extensions to SIP for Asserted Identity 

within Trusted Networks 

The Reason Header Field 

Real -Time Facsimile (T.38) image/t38 MIME 

In addition a=inactive attribute is supported 

according to RFC 4566 (used for the procedures 

described in section A.5.2.2.4) 

Partial 

“id”,“user” and “header” values 

Partial 

P-Asserted-Identity 

RFC 3326 

RFC 3362 

RFC 3960 Early Media and Ringing Tone Generation Partial 

RFC 4244 Extension for Request History Information 

Partial 

Only for Call Diversion Services 

RFC 3966 The Tel URI for telephone number 

RFC 4694 Number portability parameter for Tel URI Applicabile per soluzione target 

SIP Informational RFCs and BCP Documents 

RFC 4317 SDP Offer/Answer Examples 

Other Documents 

Tabella 3 – Control plane – IETF RFC di riferimento 

A.5.1.1 SIP methods 

La lista dei metodi riportata nel presente paragrafo è relativa ai metodi SIP previsti alla NNI SIP (nel rispetto 

delle mimiche e procedure definite nei rispettivi standard) per l’espletamento dei servizi/tipologie di chiamate 

identificate nella presente revisione della specifica tecnica. Tutti gli altri metodi non sono significativi alla NNI 

SIP. 





Alla NNI VoIP/IP è opportuno che ciascun operatore implementi adeguate politiche di filtro, tipicamente nel 

Border Gateway 2 , in uscita che garantiscano il non invio dei metodi SIP non previsti. Nel caso di Tansit 

Network tra due operatori, l’operatore che effettua il transito deve garantire il trasporto trasparente dei metodi 

SIP previsti nella presente specifica tecnica di interconnessione.. 

Nel caso in cui un operatore risulti generare alla NNI VoIP/IP i metodi SDP non previsti nella presente 

specifica tecnica di interconnessione e che danno luogo al rilievo di un’anomalia da parte dell’operatore 

ricevente è di responsabilità dell’operatore che li genera rimuoverli sollecitamente. 

È preferibile che la rilevazione dell’anomalia riporti alla normalizzazione delle linee SDP, metodi, Header che 

è definita nella presente specifica tecnica di interconnessione. 

La Tabella 4 definisce i metodi SIP previsti all’interfaccia SIP NNI nazionale. 

Method Riferimento Note 

SIP-NNI 

Sending 

ACK request RFC 3261 m m 

BYE request RFC 3261 m m 

BYE response RFC 3261 m m 

CANCEL request RFC 3261 CANCEL shall be used during early dialog m m 

CANCEL response RFC 3261 m m 

INVITE request RFC 3261 m m 

INVITE response RFC 3261 m m 

OPTIONS request RFC 3261 When this message is received, it is NOT m 

m 

passed to the interworking, but it is consumed 

locally 

OPTIONS response RFC 3261 m m 

PRACK request RFC 3262 m m 

PRACK response RFC 3262 m m 

UPDATE request RFC 3311 m m 

UPDATE response RFC 3311 m m 

Receiving 

Tabella 4 – Metodi SIP supportati 

In Tabella 4 gli status code m, o, c, i e n/a hanno il significato riportato in Tabella 5. 

Nota alla Tabella 4: per il supporto del metodo PRACK si applica quanto indicato nella sez. A.5.1.4.1. 

2 L’operazione di filtering potrà avvenire in modalità preventiva o a posteriori una volta verificato la linea dell’SDP incriminata. 





Notation Notation name Sending side Receiving side 

code 

M mandatorio Il messaggio deve essere supportato su interfaccia 

SIP-NNI. Supportare l’invio di un messaggio SIP su 

SIP-NNI significa che il messaggio deve essere 

inviato sull’interfaccia SIP-NNI se ricevuto dalla rete 

servente. La sua presenza non implica che i network 

element all’interno della rete servente o il terminale 

Supportare la ricezione di un messaggio SIP su 

SIP-NNI significa che il messaggio deve essere 

inviato alla rete servente. Non implica che gli 

elementi di rete all’interno della rete servente o il 

terminale di utente connesso a questa rete 

debbano supportare il messaggio. 

di utente connesso a questa rete debbano 

supportare il messaggio. 

O opzionale Il messaggio può o non può essere supportato Stesso significato della direzione “sending”. 

all’interfaccia SIP-NNI. Il supporto di questo metodo 

SIP è deciso sulla base di un accordo bilaterale tra I 

due operatori. 

n/a non applicabile Non è possibile utilizzare/supportare il messaggio. Non è possibile utilizzare/supportare il messaggio. 

Questo elemento verrà scartato dall’SBC. 

C condizionale Il requisito sul messaggio ("m", "o" oppure "n/a") 

dipende dalle condizioni individuate con il numero 

al supporto di altre condizioni opzionali o 

condizionali. 

Stesso significato della direzione “sending”. 

Tabella 5 – Notazioni per i metodi SIP 

A.5.1.2 SIP header 

La lista degli header SIP riportata nel presente paragrafo è relativa agli header previsti alla NNI SIP (nel 

rispetto delle mimiche e procedure definite nei rispettivi standard) per l’espletamento dei servizi/tipologie di 

chiamate identificate nella presente revisione della specifica tecnica; tutti gli altri header non sono significativi 

e non vanno considerati ai fini dell’espletamento dei servizi. 

Alla NNI VoIP/IP è opportuno che ciascun operatore implementi adeguate politiche di filtro, tipicamente nel 

Border Gateway 3 , in uscita che garantiscano il non invio delle “header” SIP non previste. Nel caso di Tansit 

Network tra due operatori, l’operatore che effettua il transito deve garantire il trasporto trasparente delle 

“header” previste nella presente specifica tecnica di interconnessione. 

Nel caso in cui un operatore risulti generare alla NNI VoIP/IP header SDP non previste nella presente 

specifica tecnica di interconnessione e che danno luogo al rilievo di un’anomalia da parte dell’operatore 

ricevente è di responsabilità dell’operatore che le genera rimuoverle sollecitamente. 

È preferibile che la rilevazione dell’anomalia riporti alla normalizzazione delle linee SDP, metodi, Header che 

è definita nella presente specifica tecnica di interconnessione. 

Nella seguente Tabella 6 sono definiti gli header supportati e previsti all’interfaccia NNI SIP nazionale. 

3 L’operazione di filtering potrà avvenire in modalità preventiva o a posteriori una volta verificato la linea dell’SDP incriminata. 





Header Reference Note NNI SIP 

Accept RFC 3261 section 20.1 m 

Accept-Contact RFC 3841 In case of presence of caller references and ICSI and IARI 

values. 4 

m 

Allow RFC 3261 section 20.5 m 

Call-ID RFC 3261 section 20.8 m 

Contact RFC 3261 section 20.10 m 

Content-Length RFC 3261 section 20.12 m 

Content-Type RFC 3261 section 20.15 m 

Cseq RFC 3261 section 20.16 m 

Expires RFC 3261 section 20.19 o 

From RFC 3261 section 20.20 m 

History-Info RFC 4244 Call diversion services, MCID 

m in case of a trust relationship between the interconnected 

networks, else n/a (rif. paragrafo A.5.1.2.1) 

m 

Max-Forwards RFC 3261 section 20.22 m 

P-Asserted-Identity RFC 3325 section 9.1 CLIP, MCID 

m in case of a trust relationship between the interconnected 

networks, else n/a (rif. paragrafo A.5.1.2.1) 

m 

Privacy RFC 3325 section 9.3 

RFC 3323 section 4.2 

CLIR 

m 

Rack RFC 3262 section 7.2 Reliability of Provisional Responses m 

Reason RFC 3326 section 2 m 

Record – Route RFC 3261 section 20.30 m 

Require RFC 3261 section 20.32 m 

Retry-After RFC 3261 Section 20.33 m on receipt of second re-INVITE before the final response is 

sent (see section 14.2, RFC 3261), else n/a 

m 

Route RFC 3261 section 20.34 m 

Rseq RFC 3262 section 7.1 m 

Supported RFC 3261 section 20.37 m 

To RFC 3261 section 20.39 m 

Unsupported RFC 3261 section 20.40 m 

Via RFC 3261 section 20.42 m 

P-Charging-Vector: RFC 3455 section 4.6 o 

Warning RFC 3261 section 20.43 o 

4 Si precisa che l’header Accept-Contact potrebbe essere utilizzato in futuro per una gestione più efficiente della segnalazione di 

interconnessione SIP mediante colorazione su base servizio cosi come indicato negli standard di riferimento 3GPP. Al fine di 

evitare la permanenza di segnalazione di tipo legacy all’interconnessione SIP NNI l’introduzione della colorazione potrebbe 

riguardare anche i servizi esistenti (es. mediante header manipulation sui nodi di bordo). Le valorizzazioni da utilizzare per l’header 

Accept-Contact, qualora non esplicitamente indicate negli standard di riferimento, saranno condivise tra gli Operatori. 





Header Reference Note NNI SIP 

Sesson Expires RFC 4028 o rappresenta una 

delle possibilità per il 

monitoring dello stato 

della sessione 

Tabella 6 – SIP Header supportati 

Nota alla Tabella 6: per il supporto del metodo PRACK si applica quanto indicato nella sez. A.5.1.4.1. 

Con riferimento alla Tabella 6 si evidenzia che per quanto riguarda l’header Reason si ritiene opportuna una 

fase di approfondimento e di monitoraggio in ambito di testing per valutare l’obbligatorietà anche nella 

request. Quanto attualmente riportato è in linea con lo standard [1]. 

In Tabella 6 – SIP Header supportati gli status code m, o, c, i e n/a hanno il significato riportato in Tabella 7. 

Notazione 

M 

O 

n/a 

Significato 

Il SIP header è applicabile alla SIP-NNI. 

Supportare l’invio di un SIP header su interfaccia SIP-NNI significa che l’header è inoltrato attraverso il SBC. La sua 

presenza non implica che i network element all’interno della rete supportino tale header. 

L’applicabilità del SIP header alla SIP-NNI dipende da accordi bilaterali tra gli operatori. 

Non è possibile utilizzare il SIP header su interfaccia SIP-NNI. Tale header potrebbe essere scartato dal SBC. 

Tabella 7 – Notazioni per i SIP header 

A.5.1.2.1 Trust domain 

Nel presente documento di profilo SIP NNI si assume che la relazione tra i due domini interconnessi sia di 

tipo TRUST in quanto l’interconnessione effettuata tra i due domini sarà realizzata garantendo l’integrità della 

segnalazione SIP. 

Si riporta di seguito una tabella che riassume gli header da supportare in presenza di un’interconnessione di 

tipo trust. 

Header 

P-Asserted-Identity 

Trust domain 

Non viene rimosso, in base a quanto specificato in 

RFC 3325. 

History-Info 

P-Charging-Vector 


RFC 4244. 


RFC 3455 

Tabella 8 – Gestione dei SIP header in presenza di un’interconnessione di tipo Trust 

Per la header P-Charging-Vector la valorizzazione del parametro Originating IOI è l’identità della Originating 

Network e del parametro Terminating IOI l’identità della rete direttamente interconnessa, che potrebbe 

essere la Transit Network o direttamente la Serving/Recipient Network. 

E’ al di fuori della presente specifica tecnica di interconnessione definire eventuali modalità di utilizzo di tali 

parametri all’interno dei domini telefonici di rete dell’operatore. 

Nota: il tema richiede approfondimenti e quindi sarà oggetto di attività in una fase successiva. 





A.5.1.3 Mapping Cause SIP - ISUP 

Come riportato in sez. A.5.1.2 Tabella 6 all’interfaccia NNI risulta mandatario inserire nelle response l’header 

Reason. Il campo cause sarà popolato in base alla tabella di mapping riportata nella Q.1912.5. 

A.5.1.4 

SIP extensions 

A.5.1.4.1 PRACK 

Il supporto ed utilizzo del metodo PRACK è mandatorio all’interconnessione; transitoriamente è ammesso il 

non supporto del metodo PRACK tra operatori interconnessi, qualora ciò non determini evidenze di disservizi 

verso la clientela finale. 

Il comportamento atteso nell’utilizzo del PRACK è quello raccomandato dalla RFC 3262 e di seguito 

descritto. 

Lo UAS percepisce il supporto di provisional responses attraverso la presenza nel SIP INVITE iniziale inviato 

dallo UAC di un Supported header valorizzato con il tag “100Rel”. 

Lo UAS inviando una response 18x può includere un Require header con il tag “100rel”. Al ricevimento di 

una response 18x lo UAC controlla se è presente un Require header con tag “100Rel”. In caso affermativo, 

lo UAC deve replicare con il PRACK. 

Nel caso in cui lo UAC non includa il tag “100Rel” nel Supported header, il PRACK non viene scambiato. 

Nel caso in cui lo UAC includa il tag “100Rel” nel Supported header, possono verificarsi le seguenti 

casistiche: 

1. UAS non include nel Require header il tag “100 Rel”: in questo caso il messaggio PRACK non verrà 

scambiato tra UAC e UAS anche se UAC ha dichiarato il supporto del metodo PRACK 

2. UAS include nel Require header il tag “100Rel”: il questo caso UAC dovrà obbligatoriamente 

replicare con il messaggio PRACK 

Come indicazione generale, è consigliata l’abilitazione del PRACK nello scambio di messaggi tra reti 

interconnesse. 

La rete emittente e la rete ricevente garantiscono l’utilizzo del PRACK negli scenari di chiamata per i quali 

tale messaggio è obbligatorio ai fini dell’espletamento del servizio. Laddove si rilevino malfunzionamenti, le 

reti per le parti di loro competenza si adoperano per rimuovere i malfunzionamenti attivando la gestione del 

PRACK. 

A.5.1.4.2 UPDATE 

L’UPDATE method [RFC 3311] può essere utilizzato per la rinegoziazione del SDP quando il dialogo è 

stabilito (early media o confermato). Il supporto di tale metodo è richiesto all’interfaccia. Per quanto riguarda 

il dettaglio della tematica delle rinegoziazioni all’interfaccia si rimanda al paragrafo dedicato. 

Allo stato attuale non sono previsti altre mimiche per la gestione della rinegoziazione del bearer prima della 

connessione, se pur ammesse dalle specifiche IETF (così come descritto nel corpo della ST 769). 





A.5.1.5 

Timer 

A.5.1.5.1 SIP timers 

All’interfaccia NNI sono supportati i timer riportati in Tabella 9. 

Timer Valore RFC 3261/ Section Significato 

T1 500ms (default) 17.1.1.1 RTT Estimate 

T2 4s (default) 17.1.2.2 The maximum retransmit interval for non-INVITE requests 

and INVITE responses 

T4 5s (default) 17.1.2.2 Maximum duration a message will remain in the network 

Timer A initially T1 17.1.1.2 INVITE request retransmit interval, for UDP only 

Timer B 64*T1 17.1.1.2 INVITE transaction timeout timer 

Timer C > 3min 16.6 Proxy INVITE transaction 

Timer D 

32s (default for UDP) 

0s for TCP 

17.1.1.2 Wait time for response retransmits 

Timer E initially T1 17.1.2.2 non-INVITE request 

retransmit interval, UDP only 

Timer F 64*T1 17.1.2.2 non-INVITE transaction timeout timer 

Timer G initially T1 17.2.1 INVITE response retransmit interval 

Timer H 64*T1 (default) 17.2.1 Wait time for ACK receipt 

Timer I 

Timer J 

Timer K 

T4 for UDP 

0s for TCP 

64*T1 for UDP 

0s for TCP 

T4 for UDP 

0s for TCP 

17.2.1 Wait time for ACK retransmits 

Section 17.2.2 

Section 17.1.2.2 

Tabella 9 – SIP Timers 

Wait time for non-INVITE request retransmits 

Wait time for response retransmits 

Fermo restando la descrizione dei timer SIP di cui in tabella, ogni operatore deve in ogni caso garantire la 

gestione delle chiamate cui applicano i timer lunghi e nessun timer delle telefonia tradizionale (es 

rispettivamente: numeri verdi con fasi interattive - chiamate verso numerazioni di emergenza); ossia deve 

essere previsto da parte della rete di destinazione un meccanismo di refresh del timer C in modo che la 

chiamata non venga abbattuta allo scadere del timer C (tipicamente 180 sec). 

A.5.1.6 Generazione dei toni di chiamata 

È ipotizzato che il comportamento lato ciascun OLO sia sempre assimilabile a quello di uno User Agent SIP 

capace di generare autonomamente i toni di chiamata nel caso non siano inviati dalla rete che termina la 

chiamata. 

Per quanto riguarda il ringback tone, nel caso di chiamata originata lato OLO1 ed in ingresso alla rete 

dell’OLO2, sono possibili due scenari: 

1. Ring Back Tone generato dalla centrale chiamata (es. Chiamata diretta a utenza PSTN); 

2. Ring Back Tone generato dalla centrale del chiamante (es. Chiamata diretta ad utenza nativa SIP). 

Nel primo caso sarà presente una response di tipo 18x contenente una sessione SDP ed il ringback tone 

sarà generato dallo UA / NE dell’utente chiamato in rete dell’operatore OLO2 ed inoltrato verso l’OLO1 in 

fonia; nel secondo caso il ringback tone dovrà essere inserito a cura dello UA dell’OLO1 a seguito della 

ricezione della SIP Response 180 Ringing senza sessione SDP. 





Per quanto riguarda gli altri toni che possono essere utilizzati nella gestione di una chiamata voce come: 

1) Tono di centrale; 

2) Tono di occupato; 

3) Tono di congestione; 

4) Tono di incapsulamento 

si evidenzia che è responsabilità della rete che ha originato la chiamata la generazione del tono nei confronti 

del chiamante, eventualmente sulla base della segnalazione (SIP response) proveniente dalla rete 

destinazione della chiamata. 

Si evidenzia che i toni utilizzati all’interfaccia dovranno essere quelli definiti dalle vigenti normative nazionali. 

A.5.2 Servizi e procedure 

Nei sottoparagrafi seguenti sono riportati i call flow di alto livello per le procedure di segnalazione abilitate 

all’interfaccia. 

A.5.2.1 Chiamata base 

Sulla base di quanto descritto ai paragrafi A.5.1 sono riportati in Figura 1 e 3 i call flow di alto livello per 

quanto riguarda l’instaurazione della chiamata base, con riferimento ai due casi possibili per la generazione 

del ringback tone descritti al paragrafo A.5.1.6. 

Operatore 1 

Operatore 2 

INVITE (G.729, G.711, telephone-event) 

100 Trying 

180 Ringing 

PRACK 

200 OK (PRACK) 

200 OK (INVITE) (G.729, telephone-event) 

ACK 

RTP / RTCP (Audio G.729) 

Figura 1 – Instaurazione chiamata base (Ringback generato presso la rete di origine) 

Nota: i messaggi PRACK si applicano solo in caso di supporto del PRACK attivo. 





Operatore 1 Operatore 2 

INVITE (G729,G711,Telephone-Event) 

100 Trying 

18x Ringing (G729) 

PRACK 

200OK (PRACK) 

RTP / RTCP (Ring Back Tone) 

opzionale 

180 Ringing 

PRACK 

200OK (PRACK) 

La sessione SDP 

nel 200OK non è 

obbligatorio. 

200OK (Inv) (G729,Telephone-Event) 

ACK 

RTP / RTCP (Audio, G729) 

Figura 2 – Instaurazione chiamata base (Ringback generato presso la rete di destinazione) 

Nota: i messaggi PRACK si applicano solo in caso di supporto del PRACK attivo. Se non attivo il PRACK, la 

SDP nel 200ok risulta obbligatoria e non più opzionale come indicato in figura 5 . 

5 Nel caso in cui non sia inserita la SDP nel messaggio 200ok non è possibile assicurare l’instaurazione con successo della 

comunicazione nella generalità degli scenari di servizio. 





A.5.2.2 

Servizi supplementari 

A.5.2.2.1 CLIP / CLIR 

Le header di interesse sull’interfaccia SIP-NNI per i servizi CLIP/CLIR, come da specifica ETSI TS 124.607, 

sono le header P-Asserted-Identity e Privacy. 

La header P-Asserted-Identity [RFC 3325] trasporta sull’interfaccia SIP-NNI l’identità del chiamante. 

La header Privacy [RFC 3323, RFC 3325] trasporta le eventuali indicazioni di riservatezza da applicare agli 

header P-Asserted-Identity e From. 

In ricezione e trasmissione sull’interfaccia SIP-NNI: 

a) Se la header Privacy è assente o uguale a “none”, l’identità è considerata non riservata ai fini dei 

servizi CLIP/CLIR (a titolo di esempio, equivalente in ISUP a Calling Party Number - Address 

presentation restricted indicator (APRI) = presentation allowed). 

b) Se la header Privacy è presente e contiene il valore “id”, l’identità presente nell’header P-Asserted- 

Identity è considerata riservata ai fini dei servizi CLIP/CLIR (a titolo di esempio, equivalente in ISUP 

a Calling Party Number - APRI = “presentation restricted”). Se in aggiunta la header Privacy 

contiene anche il valore "user" l’identità presente nell’header From è considerata riservata ai fini dei 

servizi CLIP/CLIR e pertanto dovrà essere sostituita dalla rete terminante con il valore "anonymous" 

qualora tale operazione non sia stata già espletata dalla rete originante. 

A.5.2.2.2 MCID 

Ai fini del servizio MCID, è obbligatorio trasportare sull’interfaccia SIP-NNI le informazioni sull’identità del 

chiamante mediante l’uso della header P-Asserted-Identity [RFC 3325] e eventuali informazioni di Call 

Diversion mediante l’uso della header History-Info [RFC 4244] (si veda paragrafo A.5.2.2.3). Tali informazioni 

saranno utilizzate, come previsto dalla specifica ETSI TS 124.416, nella rete dell’utente che ha invocato il 

servizio insieme a: 

• Request-URI; 

• Contact header; 

• To header; 

• From header; 

• data e tempo locale della rete dell’utente che ha invocato il servizio. 

Non sono previste all’interconnessione IP procedure di invocazione del servizio MCID. Tali procedure 

dovranno essere espletate all’interno dell’operatore che serve l’utente chiamato. 

Data l’evoluzione indicata negli standard di riferimento l’implementazione di questo servizio potrebbe essere 

oggetto di evoluzioni in futuro. 

Allo stato attuale il servizio potrebbe non essere di interesse per le reti interconnesse. 

A.5.2.2.3 CFB / CFNR / CFU 

In accordo alla specifica TS 29.163 v8.7.0, Il supporto dei servizi di Call Diversion sull’interfaccia SIP-NNI è 

fornito mediante i messaggi e parametri riportati in Tabella 10. 





SIP Message Ref. SIP Header 

INVITE RFC 4244 

RFC 3323, RFC 3325 

RFC 4458 

History-Info-Header 

Privacy header 

180 (Ringing) RFC 4244 

RFC 3323, RFC 3325 

RFC 4458 

181 (Call Is Being Forwarded) RFC 4244 

RFC 3323, RFC 3325 

RFC 4458 

200 (OK) response RFC 4244 

RFC 3323, RFC 3325 

RFC 4458 

cause-param URI parameter 










Tabella 10 – SIP Header information for redirection 

Mandatorio 

Opzionale 

Opzionale 

Opzionale 

Poiché le response di tipo 302 utilizzate per il servizio di Call Deflection non sono gestite all’interfaccia NNI 

(rif. par. A.5.1.1), i servizi di Call Deflection, come indicato in A.4 non sono supportati. 

In particolare all’interfaccia NNI sono mandatarie le informazioni di redirezione nel caso in cui il trasferimento 

sia avvenuto nelle rete di monte; mentre sono opzionali le informazioni di redirezione nel caso in cui il 

trasferimento sia avvenuto nella rete di valle. 

Il numero massimo di ridirezioni supportate alla NNI VoiP/IP è pari a 2. 

Nel primo caso (trasferimento nella rete di monte), l’INVITE all’interfaccia NNI conterrà quindi gli header 

History-Info [RFC 4244]. Tali header trasporteranno le informazioni di redirezione e in particolare: 

- Il Redirecting Number. 

- Il Original Called Number (nel caso di numero trasferimenti pari a 2). 

- Il Called Party Number. 

- Il numero di redirezioni, ricavabile in base al numero di History entries contenenti un causeparam 

con valore tra quelli specificati di seguito in questo paragrafo. 

- La redirecting reason attraverso il cause-param settato secondo il tipo di redirezione; 

- L’eventuale riservatezza dell’identità trasportata nell’hi-targeted-to-uri attraverso la privacy 

header in escaped form. 

Il cause-param specificato in [RFC 4458] è interpretato secondo la seguente sintassi: 

cause-param 

= "cause" EQUAL Status-Code 

Status-Code = "404" ; Unknown/Not available 

/ "486" ; User Busy 

/ "408" ; No Reply 

/ "302" ; Unconditional 

/ "487" ; Deflection during alerting 

/ "480" ; Deflection during immediate response 

/ "503" ; Mobile subscriber not reachable 

Nel secondo caso (trasferimento nella rete di valle) l’informazione di redirezione, ossia il Redirection Number 

e le informazioni di restrizione sull’identità, saranno contenute nell’Header History Info trasportato nella 

response 181 (Call is Being Forwarded) e, dove applicabile, anche nelle response 180 (Ringing) e 200(OK). 

Come riportato precedentemente le Response di tipo 181 e l’Header History Info nei messaggi di Response 

sono opzionali all’interfaccia NNI e quindi potrebbero non essere implementati in tutti gli scenari di servizio. 





Nelle seguenti figure sono riportati a titolo informativo i call flow relativi ai servizi di Call Diversion 

sull’interfaccia NNI SIP. Per semplificare la rappresentazione grafica, non sono riportate i PRACK ed i 

conseguenti 200 OK relativi al riscontro delle SIP response. 

Si sottolinea come il call flow riportato in figura 4 risulta mandatario all’interfaccia NNI; mentre i call flow 

riportati da figura 5 a figura 7 si applicano solo nel caso in cui l’OLO di destinazione supporti le History Info 

anche nei messaggi a ritroso. 

OLO-1 

OLO-2 

Call fowarding has 

occurred in the 

preceding network 

Invite (History Info, 

Privacy, Cause parameter, 

URI parameter 

100Trying 

180 Ringing / 183 session 

progress 

200ok 

ack 

RTP 

Figura 4: Call forwarding nella rete di origine 





OLO-1 

Invite 

OLO-2 

Call fowarding 

occurrs in the 

succeding network 

100Trying 

181 Call is being forwarded 

(History Info, Privacy, Cause 

Parameter, Uri Parameter) 

180 Ringing (History Info, 

Privacy, Cause parameter Uri 

parameter ) 

Il 180 Ringing potrebbe 

anche non essere inviato. 

I parametri relativi alle HI 

saranno trasmessi ove 

applicabile 

200ok ((History Info, Privacy, 

Cause parameter Uri parameter) 

I parametri relativi alle 

HI saranno trasmessi ove 

applicabile 

ack 

RTP 

Figura 5: Call forwarding nella rete di destinazione (CFU) 





OLO-1 

Invite 

OLO-2 




100Trying 

180 Ringing 




Timer 

Expires 



parameter) 



applicabile 

200ok (History Info, Privacy, 




applicabile 

ack 

RTP 

Figura 6: Call forwarding nella rete di destinazione (CFNR) 





OLO-1 

Invite 

OLO-2 




100Trying 




486 busy here (CFB) 

caused the call 

diversion 



parameter) 



applicabile 

200ok (History Info, Privacy, 


I parametri relativi alle HI 

saranno trasmessi ove 

applicabile 

ack 

RTP 

Figura 7: Call forwarding nella rete di destinazione (CFB) 

A.5.2.2.4 CH 

Il servizio di Call Hold è espletato sull’interfaccia SIP-NNI come definito dalla [RFC 3264] e ETSI TS 

124.610. 

1. L’utente che desidera porre l’altra parte "on hold", cioè desidera che questa temporaneamente cessi 

di inviare uno stream audio, fa una nuova offerta, utilizzando il metodo Re-Invite o UPDATE (se 

prima della risposta), con una SDP aggiornata, marcando lo stream che desidera mettere in hold 

con i seguenti attributi: 

a. "a=sendonly" se lo stream era in precedenza un media stream “sendrecv”; 

b. "a=inactive", se lo stream era in precedenza un media stream “recvonly”. 

2. Quando l’utente che ha richiesto il Call Hold vuole ristabilire la chiamata, invierà un Re-Invite / 

UPDATE (se prima della risposta) e marcherà lo stream da riprendere come: 

a. "a=sendrecv" (o omesso essendo il default), se lo stream era stato posto “on hold” con 

attributo “sendonly”; 

b. "a=recvonly" se lo stream era stato posto “on hold” con attributo inactive. 

Le seguenti Figura 3 e Figura 4 riportano a titolo informativo i call flow relativi al servizio di Call Hold 

(Session hold/resume) sull’interfaccia SIP-NNI nei casi con annuncio o senza annuncio verso l’utente in 

tenuta. 





OLO-1 OLO-1 

RTP 

OLO-2 OLO-2 

UPDATE/INVITE [SDP, a=sendonly/inactive] 

200 OK [SDP] 

ACK (if INVITE is used) 

No RTP or one-way 

UPDATE/INVITE [SDP, a=sendrecv/recvonly] 

200 OK [SDP] 


RTP 

Figura 3 – Call Hold without announcement (Session hold/resume) 

OLO-1 OLO-1 

RTP 

OLO-2 OLO-2 

UPDATE/INVITE [SDP, a=sendonly] 

200 OK [SDP] 

announcement to the held party starts 


one-way 

UPDATE/INVITE [SDP, a=sendrecv] 

200 OK [SDP] 

announcement to the held party ends 


RTP 

Figura 4 – Call Hold with announcement (Session hold/resume) 

A.5.2.2.5 CW 

Il servizio è supportato all’interfaccia in quanto allo stato attuale dell’analisi risulta gestito localmente e quindi 

all’interfaccia appare come una normale chiamata. 





A.5.2.2.6 3PTY 

Il servizio è supportato all’interfaccia. Il comportamento osservato all’interfaccia è lo stesso di quello descritto al 

paragrafo A.5.2.2.4 per il servizio di Call Hold. 

A.6. Servizi e procedure 

Nelle sezioni seguenti si riporta la descrizione funzionale dei servizi e procedure supportate. 

A.6.1 Pos/Modem 

Le chiamate modem "3.1 kHz audio" sono supportate all'interconnessione SIP secondo quanto definito in 

Q.1912.5. Sono utilizzate per il trasferimento di dati a circuito tra coppie di modem di cui uno tipicamente si 

trova localizzato su rete fissa. Il servizio principale per le chiamate modem è il POS (Point of Sale) degli 

esercizi commerciali abilitati al servizio bancomat e carte di credito. 

I parametri che trasportano la modalità Modem nella segnalazione SIP sono contenuti nell’SDP, secondo il 

mapping riportato nella Q.1912.5, contenuto nel metodo INVITE e sono: 

SDP Offer: "m=audio:", "a= rtpmap: PCMA/8000", "a=ptime:", "b= N/A 

or up to 64 kbit/s" 

Dove: 

a=rtpmap è opzionale nel caso di utilizzo del codec statico 8 

a=ptime è opzionale 

A titolo di esempio viene riportato il call flow che indica la negoziazione della chiamata modem: 

OLO 1 

OLO 2 

INVITE 

[ISDP Offer: "m=audio:", "a= rtpmap: PCMA/8000", "a=ptime:", 

"b= N/A or up to 64 kbit/s") 

180 Ringing [SDP Answer"] 

PRACK 


200 OK (INVITE) 

ACK 

Modem signalling 

Figura 5- Negoziazione SIP della chiamata modem 






A.6.2 Dati/Clearmode 

Il clearmode (o clear channel) è supportato all'interconnessione SIP secondo quanto definito in RFC 4040. 

Questa modalità abilita la trasmissione trasparente di flussi di dati a 64 kbit/s su protocollo RTP. A livello di 

MGW il flusso dati di utente non subisce alcun trattamento al di la della pacchettizzazione/depacchettizzazione 

dei dati. 

I parametri che trasportano la modalità di clear channel nella segnalazione SIP sono contenuti nell’SDP del 

metodo INVITE e sono: 

SDP Offer: "m=audio:", "a= rtpmap: CLEARMODE/8000", “a=ptime:” 

A titolo di esempio viene riportato il call flow che indica la negoziazione della modalità clear channel 

OLO 1 

OLO 2 

INVITE 

[SDP Offer: SDP_M “m=audio:”, a= rtpmap: CLEARMODE/8000 

“a=ptime:”] 

180 Ringing [SDP Answer] 

PRACK 


200 OK [ANM] 

ACK 

Clearmode Data 

Figura 6- Negoziazione SIP del clearmode 


Le chiamate dati, secondo quanto precedentemente descritto, si ritengono fruibili da/verso tipologie di 

accesso che supportano le chiamate a connettività numerica.

specifica tecnica - ISCOM - Istituto Superiore delle Comunicazioni e ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?