Servizi di comunicazione di Azure routing diretto: dettagli del protocollo SIP

Questo articolo descrive come il routing diretto implementa il protocollo SIP (Session Initiation Protocol) per garantire le route di traffico appropriate tra un SBC (Session Border Controller) e il proxy SIP. Evidenzia anche l'importanza di determinati parametri SIP che richiedono valori specifici. Questo articolo è destinato agli amministratori vocali responsabili della configurazione della connessione tra SBC e il servizio proxy SIP.

Elaborazione della richiesta in ingresso: individuazione della risorsa servizi di comunicazione

Nota

In Servizi di comunicazione di Azure opzioni SIP di routing diretto sono abilitate per impostazione predefinita e non possono essere disabilitate. SBC deve prima avviare lo scambio OPTIONS, perché il proxy SIP attende che SBC avvii lo scambio.

Prima di poter elaborare una chiamata in ingresso o in uscita, i messaggi OPTIONS vengono scambiati tra proxy SIP e SBC. Questi messaggi OPTIONS consentono al proxy SIP di fornire le funzionalità consentite a SBC. È importante che la negoziazione OPTIONS riesca (risposta 200 OK), consentendo una maggiore comunicazione tra SBC e PROXY SIP per stabilire chiamate. Le intestazioni SIP in un messaggio OPTIONS per il proxy SIP vengono fornite come esempio:

Nome parametro	Esempio del valore
Request-URI	OPZIONI sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Tramite intestazione	Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978
Intestazione Max-Forwards	Max-Forwards:68
Da intestazione	Da intestazione da: sip:sbc1.contoso.com:5061
In intestazione	A: sip:sip.pstnhub.microsoft.com:5061
Intestazione CSeq	CSeq: 1 INVITO
Intestazione contatto	Contatto: sip:sbc1.contoso.com:5061; transport=tls

Nota

Le intestazioni SIP non contengono informazioni utente nell'URI SIP in uso. In base a RFC 3261, sezione 19.1.1, la parte userinfo di un URI è facoltativa e può essere assente quando l'host di destinazione non ha una nozione di utenti o quando l'host stesso è la risorsa identificata. Se il segno @ è presente in un URI SIP, il campo utente non deve essere vuoto. Si noti che l'URI SIPS non deve essere usato con il routing diretto perché non è supportato. Controllare la configurazione di Session Border Controller e assicurarsi di non usare le intestazioni "Replaces" nelle richieste SIP. Il routing diretto rifiuterà le richieste SIP con intestazioni Replaces definite.

In una chiamata in ingresso, il proxy SIP deve trovare la risorsa di comunicazione di Azure a cui è destinata la chiamata. Questa sezione descrive come il proxy SIP trova la risorsa ed esegue l'autenticazione del SBC nella connessione in ingresso.

Esempio del messaggio SIP Invite in una chiamata in arrivo:

Nome parametro	Esempio del valore
Request-URI	INVITE sip:+54321@sip.pstnhub.microsoft.com SIP /2.0
Tramite intestazione	Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978
Intestazione Max-Forwards	Max-Forwards:68
Da intestazione	Da intestazione da: <sip:+12345@sbc1.contoso.com; transport=udp; tag=1c68821811
In intestazione	A: sip:+54321@sbc1.contoso.com
Intestazione CSeq	CSeq: 1 INVITO
Intestazione contatto	Contatto: sip:+12345@sbc1.contoso.com:5061; transport=tls

Quando si riceve l'invito, il proxy SIP esegue i passaggi seguenti:

1. Controllare il certificato. Nella connessione iniziale, il servizio di routing diretto accetta il nome FQDN presentato nell'intestazione Contatto e lo corrisponde al nome comune o alternativo soggetto del certificato presentato. Il nome SBC deve corrispondere a una delle opzioni seguenti:

   • Opzione 1. Il nome FQDN completo presentato nell'intestazione Contatto deve corrispondere al nome alternativo nome comune/soggetto del certificato presentato.

   • Opzione 2. La parte del dominio del nome FQDN presentata nell'intestazione Contatto(ad esempio contoso.com del nome FQDN sbc1.contoso.com) deve corrispondere al valore jolly in Nome comune/Nome alternativo soggetto (ad esempio *.contoso.com).

2. Provare a trovare un tenant di Microsoft 365 usando il nome FQDN completo presentato nell'intestazione Contatto.

   Controllare se il nome FQDN dell'intestazione contatto (sbc1.contoso.com) è registrato come nome DNS in qualsiasi organizzazione di Microsoft 365 o Office 365. Se trovato, la ricerca dell'utente viene eseguita nel tenant con il nome di dominio completo SBC registrato come nome di dominio. Se non viene trovato, si applica il passaggio 3.

3. Provare a trovare una risorsa di comunicazione di Azure usando il nome FQDN completo presentato nell'intestazione Contatto.

   Controllare se il nome FQDN dell'intestazione Contatto (sbc1.contoso.com) è registrato come FQDN SBC in qualsiasi risorsa di comunicazione di Azure. Se viene trovato, la chiamata viene inviata a tale risorsa. Se non viene trovato, si applica il passaggio 4.

4. Il passaggio 4 si applica solo se i passaggi 2 e 3 non sono riusciti.

   Rimuovere la parte host dal nome di dominio completo, presentata nell'intestazione contatto (FQDN: sbc1.contoso.com, dopo aver rimosso la parte host: contoso.com) e verificare se questo nome è registrato come nome DNS in qualsiasi organizzazione di Microsoft 365 o Office 365. Se trovato, la ricerca dell'utente viene eseguita in questo tenant. Se non viene trovato, la chiamata ha esito negativo.

5. Il passaggio 5 si applica solo se i passaggi 2, 3 e 4 non sono riusciti.

   Rimuovere la parte host dal nome di dominio completo, presentata nell'intestazione contatto (FQDN: sbc1.contoso.com, dopo aver rimosso la parte host: contoso.com) e verificare se questo nome è registrato come FQDN SBC in qualsiasi risorsa di comunicazione di Azure. Se viene trovato, la chiamata viene inviata a tale risorsa. Se non viene trovato, la chiamata ha esito negativo.

6. Se alla risorsa è associata una distribuzione Dynamics Omnichannel, eseguire la ricerca del numero di telefono presentato nell'URI richiesta. Trovare la corrispondenza con il numero di telefono presentato a un utente Omnichannel (coda) trovato nel passaggio precedente.

7. Il passaggio 7 si applica solo se i passaggi 6 non sono riusciti.

   Nel caso in cui non esista alcuna distribuzione Omnichannel per la risorsa di comunicazione o il numero in Request-URI non corrisponde ad alcun numero omnicanale configurato, inviare una chiamata a una Griglia di eventi.

8. Il passaggio 8 si applica solo se i passaggi 7 non sono riusciti.

   Se Griglia di eventi non è configurata o non sono presenti regole per gestire la chiamata in ingresso, la chiamata viene eliminata.

Requisiti dettagliati per l'intestazione contatto e l'URI richiesta

Intestazione contatto

Per tutti i messaggi SIP in arrivo (OPTIONS, INVITE) nel proxy SIP Microsoft, l'intestazione Contact deve avere il nome FQDN SBC associato nel nome host URI come indicato di seguito:

Sintassi: contatto: <sip:phone o sip address@FQDN del SBC; transport=tls>

In base a RFC 3261, sezione 11.1, un campo di intestazione contatto può essere presente in un messaggio OPTIONS. Nell'instradamento diretto, l'intestazione del contatto è obbligatoria. Quando si tratta di messaggi OPTIONS, l'userinfo può essere escluso dall'URI SIP e solo il nome di dominio completo può essere inviato nel formato seguente:

Sintassi: contatto: <sip:FQDN del SBC; transport=tls>

Questo nome (FQDN) deve essere presente anche nei campi Nome comune o Nome alternativo soggetto del certificato presentato. Microsoft supporta l'uso di valori jolly dei nomi nei campi Nome comune o Nome alternativo soggetto del certificato. Il supporto per i caratteri jolly è descritto in RFC 2818, sezione 3.1. In particolare:

"I nomi possono contenere il carattere jolly *, che viene considerato corrispondente a qualsiasi singolo componente del nome di dominio o frammento di componente. Ad esempio, *.a.com corrisponde foo.a.com ma non bar.foo.a.com. f*.com corrisponde foo.com ma non bar.com."

Se più di un valore nell'intestazione Contact presentato in un messaggio SIP da SBC, viene utilizzata solo la parte FQDN del primo valore dell'intestazione Contact. Come regola generale per il routing diretto, è importante che il nome di dominio completo venga usato per popolare l'URI SIP invece di IP. Messaggio INVITE o OPTIONS in ingresso al proxy SIP con intestazione contatto in cui il nome host è rappresentato da IP e non FQDN, la connessione viene rifiutata con 403 Accesso negato.

Request-URI

Per tutte le chiamate in ingresso, l'URI richiesta viene usato per identificare un chiamato. Attualmente il numero di telefono deve contenere un segno più (+), come illustrato nell'esempio seguente.

INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0

Dall'intestazione

Per tutte le chiamate in arrivo, l'intestazione from viene usata per trovare la corrispondenza con il numero di telefono del chiamante.

Il numero di telefono deve contenere un valore + come illustrato nell'esempio seguente.

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

Considerazioni sulle intestazioni di Contatto e Record-Route

Il proxy SIP deve calcolare il nome di dominio completo dell'hop successivo per le nuove transazioni client in-dialog (ad esempio Bye o Re-Invite) e quando risponde a OPZIONI SIP. Questa operazione può essere eseguita usando Contact o Record-Route. In base a RFC 3261, sezione 8.1.1.8, è necessaria un'intestazione Contatto in qualsiasi richiesta che possa generare una nuova finestra di dialogo. Record-Route è obbligatorio solo se un proxy vuole rimanere sul percorso delle richieste future in una finestra di dialogo.

Per calcolare l'hop successivo, il proxy SIP usa:

• Priorità 1. Record-Route di primo livello. Se la route record di primo livello contiene il nome FQDN, il nome FQDN viene usato per stabilire la connessione in uscita nella finestra di dialogo.

• Priorità 2. Intestazione contatto. Se Record-Route non esiste, il proxy SIP cerca il valore dell'intestazione Contact per stabilire la connessione in uscita. (Configurazione consigliata).

Se vengono usati sia Contact che Record-Route, l'amministratore SBC deve mantenere identici i valori, causando un sovraccarico amministrativo.

Uso del nome FQDN in Contatto o Record-Route

L'uso di un indirizzo IP non è supportato in Record-Route o Contact. L'unica opzione supportata è un FQDN, che deve corrispondere al nome comune o al nome alternativo soggetto del certificato SBC (sono supportati i valori con caratteri jolly nel certificato).

• Se un indirizzo IP viene presentato in Record-route o Contact, il controllo del certificato ha esito negativo e la chiamata non riesce.

• Se il nome di dominio completo non corrisponde al valore del nome alternativo comune o soggetto nel certificato presentato, la chiamata non riesce.

Intestazioni del contesto di chiamata

Le intestazioni del contesto di chiamata sono attualmente disponibili solo per Call Automation SDK. Call Automation SDK supporta l'intestazione User-To-User e fino a cinque intestazioni SIP personalizzate. Tali intestazioni sono supportate nei metodi INVITE e REFER.

Intestazione da utente a utente

L'intestazione SIP User-To-User (UUI) è uno standard del settore per passare informazioni contestuali durante un processo di configurazione delle chiamate. La lunghezza massima di una chiave di intestazione UUI è di 64 caratteri. La lunghezza massima del valore dell'intestazione UUI è 256 caratteri. Il valore dell'intestazione UUI può essere costituito da caratteri alfanumerici e da alcuni simboli selezionati, tra cui =, *%.;_+!, , . -~

Intestazione personalizzata

Servizi di comunicazione di Azure supporta anche fino a cinque intestazioni SIP personalizzate. La chiave di intestazione SIP personalizzata deve iniziare con un prefisso obbligatorio X-MS-Custom- . La lunghezza massima di una chiave di intestazione SIP è di 64 caratteri, incluso il X-MS-Custom- prefisso. La chiave di intestazione SIP può essere costituita da caratteri alfanumerici e da alcuni simboli selezionati, tra cui ., _*%+!, . -~ La lunghezza massima del valore dell'intestazione SIP è di 256 caratteri. Il valore dell'intestazione SIP può essere costituito da caratteri alfanumerici e da alcuni simboli selezionati, tra cui =, *%.;_+!, . -~

Per informazioni dettagliate sull'implementazione, vedere Come passare dati contestuali tra le chiamate.

Chiamata in ingresso: descrizione della finestra di dialogo SIP

Ecco i dettagli sull'elaborazione delle chiamate in ingresso da parte del proxy SIP.

Nome parametro	Valore
Candidati multimediali in 183 e 200 messaggi provenienti da	Processori di contenuti multimediali
Numero di 183 messaggi che possono essere ricevuti da SBC	Uno per sessione
La chiamata può essere con risposta provvisoria (183)	Sì
La chiamata può essere senza risposta provvisoria (183)	Sì

Un'identità Servizi di comunicazione di Azure può essere usata contemporaneamente in più endpoint (applicazioni). Ad esempio, app Web, app i Telefono e app Android. Ogni endpoint potrebbe segnalare un rest HTTP come indicato di seguito:

• Stato della chiamata: convertito dal proxy SIP nel messaggio SIP 180. Durante la ricezione del messaggio 180, il SBC deve generare l'anello locale.

• Risposta multimediale: convertita dal proxy SIP nel messaggio 183 con candidati multimediali nel protocollo SDP (Session Description Protocol). Durante la ricezione del messaggio 183, il SBC si aspetta di connettersi ai candidati multimediali ricevuti nel messaggio SDP.

  Nota

  In alcuni casi, la risposta multimediale potrebbe non essere generata e l'endpoint potrebbe rispondere con il messaggio "Call Accepted".

• Chiamata accettata: convertita dal proxy SIP in messaggio SIP 200 con SDP. Durante la ricezione del messaggio 200, il SBC dovrebbe inviare e ricevere supporti da e verso i candidati SDP forniti.

  Nota

  Il routing diretto non supporta l'invito all'offerta ritardata (invito senza SDP).

Più endpoint che suonano con una risposta provvisoria

1. Quando si riceve il primo invito dal SBC, il proxy SIP invia il messaggio "SIP SIP/2.0 100 Tentativo" e invia una notifica a tutti gli endpoint dell'utente finale sulla chiamata in arrivo.

2. Dopo la notifica, ogni endpoint avvia l'anello e invia messaggi "Stato chiamata" al proxy SIP. Poiché l'identità Servizi di comunicazione di Azure viene usata da più endpoint, il proxy SIP potrebbe ricevere più messaggi di stato delle chiamate.

3. Per ogni messaggio di stato della chiamata ricevuto dagli endpoint, il proxy SIP converte il messaggio Stato chiamata nel messaggio SIP "SIP SIP/2.0 180 Ringing". L'intervallo per l'invio di tali messaggi è correlato all'intervallo di ricezione dei messaggi dal controller di chiamata. Nel diagramma seguente sono presenti due 180 messaggi generati dal proxy SIP. Questi messaggi provengono dai due endpoint SDK. Gli endpoint hanno un ID tag univoco. Ogni messaggio proveniente da un endpoint diverso è una sessione separata (il parametro "tag" nel campo "A" è diverso). Tuttavia, un endpoint potrebbe non generare immediatamente il messaggio 180 e inviare immediatamente il messaggio 183, come illustrato nel diagramma seguente.

4. Dopo che un endpoint genera un messaggio di risposta multimediale con gli indirizzi IP dei candidati multimediali dell'endpoint, il proxy SIP converte il messaggio ricevuto in un messaggio "Stato sessione SIP 183" con SDP dall'endpoint sostituito da SDP dal processore di supporti. Nel diagramma seguente l'endpoint di Fork 2 ha risposto alla chiamata. Il messaggio SIP 183 viene generato una sola volta. Il 183 potrebbe venire su una fork esistente o avviarne uno nuovo.

5. Un messaggio di accettazione della chiamata viene inviato al proxy SIP con i candidati finali dell'endpoint che ha accettato la chiamata. Il messaggio di accettazione della chiamata viene convertito nel messaggio SIP 200.

   

Più endpoint squillare senza risposta provvisoria

1. Quando si riceve il primo invito dal SBC, il proxy SIP invia il messaggio "SIP SIP/2.0 100 Tentativo" e invia una notifica a tutti gli endpoint dell'utente finale sulla chiamata in arrivo.

2. Dopo la notifica, ogni endpoint avvia l'anello e invia il messaggio "Stato chiamata" al proxy SIP. Poiché la stessa identità Servizi di comunicazione di Azure può essere usata in più applicazioni, il proxy SIP potrebbe ricevere più messaggi di stato delle chiamate.

3. Per ogni messaggio di stato della chiamata ricevuto dagli endpoint, il proxy SIP converte il messaggio Stato chiamata nel messaggio SIP "SIP SIP/2.0 180 Ringing". L'intervallo per l'invio dei messaggi è correlato all'intervallo di ricezione dei messaggi dal controller di chiamata. Nell'immagine sono presenti due 180 messaggi generati dal proxy SIP, ovvero la chiamata viene copiata tramite fork a due client diversi e ogni client invia lo stato di avanzamento della chiamata. Ogni messaggio è una sessione separata (il parametro "tag" nel campo "A" è diverso)

4. Un messaggio di accettazione della chiamata viene inviato al proxy SIP con i candidati finali dell'endpoint che ha accettato la chiamata. Il messaggio di accettazione della chiamata viene convertito nel messaggio SIP 200.

   

Sostituisce l'opzione

SBC deve supportare INVITE con replaces.

Dimensioni delle considerazioni relative al provider di identità

L'interfaccia di routing diretto potrebbe inviare un messaggio SIP superiore a 1.500 byte. Le dimensioni di SDP causano principalmente questo comportamento. Tuttavia, se c'è un trunk UDP dietro il SBC, potrebbe rifiutare il messaggio se viene inoltrato dal proxy SIP Microsoft al trunk non modificato. Microsoft consiglia di rimuovere alcuni valori in SDP nel SBC durante l'invio del messaggio ai trunk UDP. Ad esempio, i candidati ICE o i codec inutilizzati possono essere rimossi.

Trasferimento delle chiamate

Il routing diretto supporta due metodi per il trasferimento delle chiamate:

• Opzione 1. I processi proxy SIP Fanno riferimento al client localmente e fungono da referee come descritto nella sezione 7.1 di RFC 3892.

  Con questa opzione, il proxy SIP termina il trasferimento e aggiunge un nuovo invito.

• Opzione 2. Il proxy SIP invia il riferimento al SBC e funge da transferor come descritto nella sezione 6 di RFC 5589.

  Con questa opzione, il proxy SIP invia un riferimento al SBC e prevede che il SBC gestisca completamente il trasferimento.

Il proxy SIP seleziona il metodo in base alle funzionalità segnalate dal SBC. Se il SBC indica che supporta il metodo "Refer", il proxy SIP usa l'opzione 2 per i trasferimenti di chiamata. Esempio di SBC che invia il messaggio che il metodo Refer è supportato:

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Se il SBC non indica che fare riferimento come metodo supportato, il routing diretto usa l'opzione 1 (il proxy SIP funge da referee). Il SBC deve anche segnalare che supporta il metodo Notify: esempio di SBC che indica che il metodo Refer non è supportato:

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

Processi proxy SIP Fare riferimento dal client in locale e funge da arbitro

Se il SBC indica che il metodo Refer non è supportato, il proxy SIP funge da arbitro. La richiesta Di riferimento proveniente dal client termina nel proxy SIP. La richiesta di riferimento dal client viene visualizzata come "Trasferimento di chiamata a Dave" nel diagramma seguente. Per altre informazioni, vedere la sezione 7.1 di RFC 3892.

Il proxy SIP invia il riferimento al SBC e funge da transferor

Il proxy SIP come transferor è il metodo preferito per i trasferimenti di chiamata.

Lo standard è illustrato nella sezione 6 di RFC 5589. Le RFC correlate sono:

• Controllo chiamate SIP (Session Initiation Protocol) - Trasferimento

• Intestazione SIP (Session Initiation Protocol) "Replaces"

• Meccanismo SIP (Session Initiation Protocol) "Referred-By"

Questa opzione presuppone che il proxy SIP funga da transferor e invii un messaggio di riferimento al SBC. L'SBC funge da trasferimento e gestisce l'oggetto Refer per generare una nuova offerta per il trasferimento. Esistono due casi possibili:

• La chiamata viene trasferita a un partecipante PSTN esterno.
• La chiamata viene trasferita da un endpoint SDK a un altro endpoint SDK nella stessa risorsa tramite SBC.

Se la chiamata viene trasferita da un endpoint SDK a un altro endpoint SDK tramite SBC, il SBC dovrebbe emettere un nuovo invito (avviare una nuova finestra di dialogo) per la destinazione di trasferimento usando le informazioni ricevute nel messaggio di riferimento. Per popolare i campi To/Transferor per la transazione della richiesta internamente, il proxy SIP deve comunicare queste informazioni all'interno delle intestazioni REFER-TO/REFERRED-BY. Il proxy SIP costituisce l'URI REFER-TO come URI SIP costituito da un FQDN proxy SIP nel nome host e uno dei seguenti:

• Numero di telefono E.164 nella parte nome utente dell'URI nel caso in cui la destinazione del trasferimento sia un numero di telefono o

• I parametri x-m e x-t codificano rispettivamente l'ID risorsa di destinazione di trasferimento completo e l'ID risorsa di comunicazione.

L'intestazione REFERRED-BY include un URI SIP con codifica MRI del transferor e l'ID risorsa del transferor e altri parametri di contesto di trasferimento, come illustrato nella tabella seguente:

Parametro	valore	Descrizione
x-m	MRI	MrI completo di destinazione di trasferimento/trasferimento come popolato da CC
x-t	ID tenant	ID risorsa x-t ID risorsa facoltativo come popolato da CC
x-ti	ID correlazione del transferor	ID di correlazione della chiamata al transferor
x-tt	URI della chiamata di destinazione di trasferimento	URI di sostituzione delle chiamate codificate

Le dimensioni dell'intestazione di riferimento possono essere fino a 400 simboli in questo caso. L'SBC deve supportare la gestione dei messaggi di riferimento con dimensioni fino a 400 simboli.

Inoltro delle chiamate

Un Servizi di comunicazione di Azure Call Automation SDK può reindirizzare le chiamate in ingresso a un altro numero o endpoint SDK/Teams, squillare altri utenti o utenti in parallelo (anello simultaneo) o chiamare un gruppo di utenti o numeri. Ecco alcuni aspetti da considerare:

• Request-URI in INVITE request from SIP proxy to User C contiene il parametro cause .

• L'intestazione History-Info viene popolata.

• Quando l'utente A è un altro utente PSTN, il proxy SIP genera la risposta provvisoria "Chiamata SIP SIP/2.0 181" all'utente A.

• Se l'utente A e l'utente C sono utenti PSTN, il proxy SIP mantiene la risposta provvisoria "SIP SIP/2.0 181 Call is being forwarded".

• L'intestazione History-Info deve essere usata per la prevenzione del ciclo.

Timer sessione

Il proxy SIP supporta (sempre offre) il timer di sessione. L'uso del timer di sessione da parte del SBC non è obbligatorio.

Uso del parametro Request-URI user=phone

Il proxy SIP analizza l'URI della richiesta e se il parametro user=phone è presente, il servizio gestisce l'URI richiesta come numero di telefono, corrispondente al numero a un utente. Se il parametro non è presente, il proxy SIP applica euristica per determinare il tipo di utente Request-URI (numero di telefono o indirizzo SIP).

Microsoft consiglia di applicare sempre il parametro user=phone per semplificare il processo di configurazione delle chiamate.

Intestazione History-Info

Nota

In Servizi di comunicazione di Azure intestazione Direct Routing History-Info è abilitata per impostazione predefinita e non può essere disabilitata.

L'intestazione History-Info viene usata per la ridestinazione delle richieste SIP e "fornisce uno o più meccanismi standard per l'acquisizione delle informazioni sulla cronologia delle richieste per consentire un'ampia gamma di servizi per reti e utenti finali". Per altre informazioni, vedere RFC 4244 – Sezione 1.1. Per il routing diretto, questa intestazione viene usata in scenari di inoltro simultanei e chiamate.

History-Info è abilitato come segue:

• Il proxy SIP inserisce un parametro contenente il numero di telefono associato nelle singole voci History-Info che comprendono l'intestazione History-Info inviata al controller PSTN. Usando solo le voci con il parametro numero di telefono, il controller PSTN ricompila una nuova intestazione History-Info e la passa al provider trunk SIP tramite proxy SIP.

• L'intestazione History-Info viene aggiunta per i casi di inoltro simultanei e di chiamata.

• L'intestazione History-Info non viene aggiunta per i casi di trasferimento delle chiamate.

• Una singola voce della cronologia nell'intestazione History-Info ricostruita include il parametro numero di telefono fornito insieme al nome di dominio completo (sip.pstnhub.microsoft.com) di routing diretto impostato come parte host dell'URI. Parametro di 'user=phone' aggiunto come parte dell'URI SIP. Tutti gli altri parametri associati all'intestazione History-Info originale, ad eccezione dei parametri di contesto del telefono, passati nell'intestazione History-Info ricostruita.

  Nota

  Voci private (come determinato dai meccanismi definiti nella sezione 3.3 di RFC 4244) inoltrate così come è perché il provider trunk SIP è un peer attendibile.

• Le informazioni sulla cronologia in ingresso sono mantenute per la prevenzione del ciclo.

Di seguito è riportato il formato dell'intestazione History-info inviata dal proxy SIP:

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

Se la chiamata è stata reindirizzata più volte, le informazioni su ogni reindirizzamento vengono incluse con il motivo appropriato in ordine cronologico, in un elenco delimitato da virgole.

Esempio di intestazione:

History-Info:
  <sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

L'URI SIP nell'intestazione History-Info è formattato in base alla sezione 25 di RFC 3261 (vedere la definizione di addr-spec). Nell'esempio precedente, il testo originale dell'intestazione Reason URI è SIP;cause=496;text="User Busy", che ottiene i ;relativi caratteri , "e = preceduti rispettivamente dai valori %3Besadecimali ASCII , %22e 3D.

History-Info è protetto da un meccanismo TLS obbligatorio.

Connessione SBC al routing diretto e al meccanismo di failover

Vedere la sezione Meccanismo di failover per la segnalazione SIP in Requisiti dell'infrastruttura di routing diretto.

Retry-After

Se un data center di routing diretto è occupato, il servizio può inviare un messaggio Retry-After con un intervallo di un secondo all'SBC. Quando il SBC riceve un messaggio 503 con un'intestazione Retry-After in risposta a un invito, il SBC deve terminare tale connessione e provare il successivo data center Microsoft disponibile.

Gestione dei tentativi (risposta 603)

Se un utente finale osserva diverse chiamate perse per una chiamata dopo aver rifiutato la chiamata in ingresso, significa che il meccanismo di ripetizione dei tentativi del provider trunk SBC o PSTN non è configurato correttamente. Il SBC deve essere riconfigurato per arrestare le attività di ripetizione della risposta 603.