Enrutamiento directo de Azure Communication Services: detalles del protocolo SIP

Este artículo describe cómo el enrutamiento directo implementa el Protocolo de Iniciación de Sesión (SIP) para asegurar rutas de tráfico adecuadas entre un Controlador de Borde de Sesión (SBC) y el proxy SIP. También resalta la importancia de determinados parámetros SIP que requieren valores específicos. Este artículo está destinado a los administradores de voz responsables de configurar la conexión entre el SBC y el servicio de proxy SIP.

Procesamiento de la solicitud entrante: búsqueda del recurso de Communication Services

Nota:

En OPTIONS SIP de enrutamiento directo de Azure Communication Services están habilitadas de forma predeterminada y no se pueden deshabilitar. El SBC debe iniciar primero el intercambio OPTIONS, ya que el Proxy SIP espera a que el SBC inicie el intercambio.

Antes de poder procesar una llamada entrante o saliente, se intercambian mensajes OPTIONS entre el Proxy SIP y el SBC. Estos mensajes OPTIONS permiten que el proxy SIP proporcione las funcionalidades permitidas a SBC. Es importante que la negociación OPTIONS sea correcta (respuesta 200 OK), lo que permite una comunicación adicional entre SBC y el proxy SIP para establecer llamadas. Los encabezados SIP en un mensaje OPTIONS al Proxy SIP se proporcionan como ejemplo:

Nombre de parámetro	Ejemplo del valor
URI de solicitud	OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
A través del encabezado	Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Encabezado desvíos máximos	Desvíos máximos:68
Encabezado "De"	Desde encabezado desde: sip:sbc1.contoso.com:5061
Encabezado "Para"	To: sip:sip.pstnhub.microsoft.com:5061
Encabezado CSeq	CSeq: 1 INVITACIÓN
Encabezado de contacto	Contacto: sip:sbc1.contoso.com:5061;transport=tls

Nota:

Los encabezados SIP no contienen userinfo en el URI SIP en uso. Según RFC 3261, sección 19.1.1, la parte userinfo de un URI es opcional y puede estar ausente cuando el host de destino no tiene noción de usuarios o cuando el propio host es el recurso que se está identificando. Si el signo @ está presente en un SIP URI, el campo de usuario no debe estar vacío. Tenga en cuenta que SIPS URI no debe utilizarse con enrutamiento directo, ya que no es compatible. Compruebe la configuración de su Controlador de Borde de Sesión y asegúrese de que no está utilizando encabezados "Reemplazar" en las solicitudes SIP. El enrutamiento directo rechazará las solicitudes SIP que tienen los encabezados Reemplazar definidos.

En una llamada entrante, el proxy SIP necesita encontrar el recurso de Azure Communication al que está destinada la llamada. En esta sección se describe cómo el proxy SIP encuentra el recurso y realiza la autenticación del SBC en la conexión entrante.

El ejemplo del mensaje de invitación SIP en una llamada entrante:

Nombre de parámetro	Ejemplo del valor
URI de solicitud	INVITE sip:+54321@sip.pstnhub.microsoft.com SIP /2.0
A través del encabezado	Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Encabezado desvíos máximos	Desvíos máximos:68
Encabezado "De"	De Encabezado "De": <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
Encabezado "Para"	Para: sip:+54321@sbc1.contoso.com
Encabezado CSeq	CSeq: 1 INVITACIÓN
Encabezado de contacto	Contacto: sip:+12345@sbc1.contoso.com:5061;transport=tls

Al recibir la invitación, el proxy SIP realiza los siguientes pasos:

1. Comprobación del certificado. En la conexión inicial, el servicio de enrutamiento directo toma el nombre FQDN presentado en el encabezado Contacto y lo compara con el nombre común o el nombre alternativo del asunto del certificado presentado. El nombre del CLS debe coincidir con una de las siguientes opciones:

   • Opción 1. El nombre FQDN completo presentado en el encabezado Contacto debe coincidir con el Nombre común/Nombre alternativo del sujeto del certificado presentado.

   • Opción 2. La parte del dominio del nombre FQDN presentada en el encabezado Contacto (por ejemplo contoso.com del nombre FQDN sbc1.contoso.com) debe coincidir con el valor comodín en Nombre común/Nombre alternativo del asunto (por ejemplo *.contoso.com).

2. Intente buscar un inquilino de Microsoft 365 utilizando el nombre FQDN completo que aparece en el encabezado Contacto.

   Compruebe si el nombre FQDN del encabezado Contacto (sbc1.contoso.com) está registrado como nombre DNS en alguna organización de Microsoft 365 u Office 365. Si se encuentra, la búsqueda del usuario se realiza en el inquilino que tiene el FQDN de SBC registrado como un nombre de dominio. Si no se encuentra, se aplica el paso 3.

3. Intente encontrar un recurso de Azure Communication utilizando el nombre FQDN completo presentado en el encabezado Contacto.

   Compruebe si el nombre FQDN del encabezado Contacto (sbc1.contoso.com) está registrado como un FQDN de SBC en cualquier recurso de Azure Communication. Si se encuentra, se envía la llamada a ese recurso. Si no se encuentra, se aplica el paso 4.

4. El paso 4 solo se aplica si se produjo un error en los pasos 2 y 3.

   Quite la parte del host del FQDN, presentado en el encabezado Contacto (FQDN: sbc1.contoso.com, después de eliminar la parte del host: contoso.com), y compruebe si este nombre está registrado como nombre DNS en alguna organización de Microsoft 365 u Office 365. Si se encuentra, la búsqueda de usuarios se realiza en este inquilino. Si no se encuentra, se produce un error en la llamada.

5. El paso 5 solo se aplica si se produjo un error en los pasos 2, 3 y 4.

   Quite la parte del host del FQDN, presentado en el encabezado Contacto (FQDN: sbc1.contoso.com, después de quitar la parte del host: contoso.com), y compruebe si este nombre está registrado como un FQDN de SBC en cualquier recurso de Azure Communication. Si se encuentra, se envía la llamada a ese recurso. Si no se encuentra, se produce un error en la llamada.

6. Si el recurso tiene asociada una implementación de Dynamics Omnichannel, realice la búsqueda del número de teléfono presentado en el URI de solicitud. Haga coincidir el número de teléfono presentado con un usuario omnicanal (cola) encontrado en el paso anterior.

7. El paso 7 solo se aplica si el paso 6 ha fallado.

   En caso de que no exista ninguna implementación omnicanal para el recurso de comunicación o el número del URI de solicitud no coincide con ningún número omnicanal configurado, envíe una llamada a Event Grid.

8. El paso 8 solo se aplica si se produjo un error en los pasos 7.

   Si Event Grid no está configurado, o no hay reglas para administrar la llamada entrante, la llamada se corta.

Requisitos detallados para el encabezado Contacto y el URI de solicitud

Encabezado de contacto

Para todos los mensajes SIP entrantes (OPTIONS, INVITE) al proxy SIP de Microsoft, el encabezado Contacto debe tener el FQDN del SBC emparejado en el nombre de host URI como se indica a continuación:

Sintaxis: Contacto: <sip:teléfono o dirección sip@FQDN del SBC;transporte=tls>

Según RFC 3261, sección 11.1, un campo de encabezado Contacto PUEDE estar presente en un mensaje OPTIONS. En el enrutamiento directo, se requiere el encabezado de contacto. Cuando se trata de mensajes OPTIONS, el userinfo puede ser excluido del SIP URI y solo el FQDN puede ser enviado en el siguiente formato:

Sintaxis: Contacto: <sip:FQDN del SBC;transport=tls>

Este nombre (FQDN) también debe figurar en los campos Nombre común o Nombre alternativo del asunto del certificado presentado. Microsoft admite el uso de valores de caracteres comodín del nombre o nombres en los campos Nombre común o Nombre alternativo del asunto del certificado. La compatibilidad con caracteres comodín se describe en RFC 2818, sección 3.1. Específicamente:

"Los nombres pueden contener el carácter comodín *, que se considera que coincide con cualquier componente de nombre de dominio único o fragmento de componente. Por ejemplo, *.a.com coincide con foo.a.com pero no bar.foo.a.com. f*.com coincide con foo.com pero no bar.com".

Si el SBC presenta más de un valor en el encabezado Contacto en un mensaje SIP, solo se utiliza la parte FQDN del primer valor del encabezado Contacto. Como regla general para el enrutamiento directo, es importante que el FQDN se use para rellenar el URI SIP en lugar de ip. Un mensaje INVITE u OPTIONS entrante al Proxy SIP con encabezado Contacto donde el nombre de host está representado por IP y no FQDN, la conexión es rechazada con el mensaje 403 Forbidden.

URI de solicitud

Para todas las llamadas entrantes, el URI de solicitud se usa para identificar un destinatario. Actualmente, el número de teléfono debe contener un signo más (+) como se muestra en el siguiente ejemplo.

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

Encabezado "From"

Para todas las llamadas entrantes, se utiliza el encabezado "De para que coincida con el número de teléfono de la persona que llama.

El número de teléfono debe contener un + como se muestra en el siguiente ejemplo.

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

Consideraciones sobre los encabezados Contacto y Registro-Ruta

El proxy SIP necesita calcular el FQDN del próximo salto para nuevas transacciones de cliente en diálogo (por ejemplo Bye o Re-Invite), y cuando se responde a OPTIONS SIP. Esto puede hacerse utilizando Contacto o Registro-Ruta. De acuerdo con RFC 3261, sección 8.1.1.8, se requiere un encabezado Contacto en cualquier solicitud que pueda resultar en un nuevo diálogo. El Registro-Ruta solo es necesario si un proxy quiere permanecer en la ruta de futuras solicitudes en un diálogo.

Para calcular el próximo salto, el proxy SIP usa:

• Prioridad: 1. Ruta de registro de nivel superior. Si la ruta de registro de nivel superior contiene el nombre FQDN, el nombre FQDN se usa para establecer la conexión de entrada de salida en el cuadro de diálogo.

• Prioridad: 2. Encabezado de Contacto. Si Record-Route no existe, el proxy SIP busca el valor del encabezado Contacto para realizar la conexión saliente. (Configuración recomendada).

Si se usan Contact y Record-Route, el administrador de SBC debe mantener sus valores idénticos, lo que provoca una sobrecarga administrativa.

Uso del nombre FQDN en Contacto o Registro-Ruta

El uso de una dirección IP no es compatible ni con Registro-Ruta ni con Contacto. La única opción admitida es un FQDN, que debe coincidir con el nombre común o el nombre alternativo del firmante del certificado SBC (se admiten valores comodín en el certificado).

• Si se presenta una dirección IP en Registro-Ruta o Contacto, se produce un error en la comprobación del certificado y se produce un error en la llamada.

• Si el FQDN no coincide con el valor del Nombre alternativo común o del asunto en el certificado presentado, se produce un error en la llamada.

Encabezados de contexto de llamada

Los encabezados de contexto de llamada solo están disponibles actualmente para el SDK de Automatización de llamadas. El SDK de automatización de llamadas admite encabezado de usuario a usuario y hasta cinco encabezados SIP personalizados. Estos encabezados son compatibles con los métodos INVITE y REFER.

Encabezado de usuario a usuario

El encabezado SIP User-To-User (UUI) es un estándar de la industria para pasar información contextual durante el proceso de establecimiento de una llamada. La longitud máxima de una clave de encabezado UUI es de 64 caracteres. La longitud máxima del valor del encabezado UUI es de 256 caracteres. El valor del encabezado UUI puede constar de caracteres alfanuméricos y algunos símbolos seleccionados, incluidos =, ;, ., !, %, *, _, +, ~ y -.

Encabezado personalizado

Azure Communication Services también admite hasta cinco encabezados SIP personalizados. La clave de encabezado SIP personalizada debe comenzar con un prefijo obligatorio X-MS-Custom-. La longitud máxima de una clave de encabezado SIP es de 64 caracteres, incluido el prefijo X-MS-Custom-. La clave del encabezado SIP puede constar de caracteres alfanuméricos y algunos símbolos seleccionados, incluidos ., !, %, *, _, +, ~ y -. La longitud máxima del valor del encabezado SIP es de 256 caracteres. El valor del encabezado SIP puede constar de caracteres alfanuméricos y algunos símbolos seleccionados, incluidos =, ;, ., !, %, *, _, +, ~ y -.

Para obtener detalles de implementación, consulte Cómo pasar datos contextuales entre llamadas.

Llamada entrante: descripción del cuadro de diálogo SIP

Estos son los detalles de cómo el proxy SIP procesa las llamadas entrantes.

Nombre de parámetro	Value
Candidatos de los medios de comunicación en 183 y 200 mensajes procedentes de	Procesadores de multimedia
Número de 183 mensajes SBC que pueden recibir	Una por sesión
La llamada puede ser con respuesta provisional (183)	Sí
La llamada puede ser sin respuesta provisional (183)	Sí

Una identidad de Azure Communication Services se puede usar en varios puntos de conexión (aplicaciones) al mismo tiempo. Por ejemplo, aplicación web, aplicación de iPhone y aplicación Android. Cada punto final podría señalar un resto HTTP de la siguiente manera:

• Progreso de la llamada: convertido por el proxy SIP en el mensaje SIP 180. Al recibir el mensaje 180, el SBC debe generar un timbre local.

• Respuesta multimedia: convertida por el proxy SIP en el mensaje 183 con candidatos multimedia en el Protocolo de descripción de sesión (SDP). Al recibir el mensaje 183, el SBC espera conectarse a los candidatos multimedia recibidos en el mensaje SDP.

  Nota:

  En algunos casos, es posible que la respuesta multimedia no se genere y el punto final pueda responder con el mensaje "Llamada aceptada".

• Llamada aceptada: convertida por el proxy SIP en el mensaje SIP 200 con SDP. Al recibir el mensaje 200, se espera que el SBC envíe y reciba medios hacia y desde los candidatos de SDP proporcionados.

  Nota:

  El enrutamiento directo no admite la invitación de oferta retrasada (invitación sin SDP).

Varios puntos de conexión suenan con respuesta provisional

1. Al recibir la primera invitación del SBC, el proxy SIP envía el mensaje "SIP SIP/2.0 100 Trying" y notifica a todos los terminales de usuario final sobre la llamada entrante.

2. Tras la notificación, cada punto de conexión comienza a llamar y envía mensajes de "Progreso de la llamada" al proxy SIP. A medida que varios puntos de conexión usan la identidad de Azure Communication Services, el proxy SIP puede recibir varios mensajes de progreso de llamadas.

3. Para cada mensaje de progreso de llamada recibido de los puntos de conexión, el proxy SIP convierte el mensaje Progreso de la llamada al mensaje SIP "SIP SIP/2.0 180 Ringing". El intervalo para enviar estos mensajes se correlaciona con el intervalo de los mensajes receptores del controlador de llamadas. En el diagrama siguiente, hay dos mensajes de 180 generados por el proxy SIP. Estos mensajes proceden de los dos puntos de conexión del SDK. Cada uno de los puntos de conexión tiene un identificador de etiqueta único. Cada mensaje procedente de un punto de conexión diferente es una sesión independiente (el parámetro "etiqueta" en el campo "Para" es diferente). Pero es posible que un punto de conexión no genere el mensaje 180 y envíe el mensaje 183 inmediatamente, como se muestra en el diagrama siguiente.

4. Una vez que un punto final genera un mensaje de respuesta multimedia con las direcciones IP de los candidatos multimedia del punto final, el proxy SIP convierte el mensaje recibido en un mensaje "Progreso de la sesión SIP 183" con el SDP del punto final sustituido por el SDP del procesador multimedia. En el siguiente diagrama, el punto final de la bifurcación 2 respondió a la llamada. El mensaje SIP 183 solo se genera una vez. El 183 podría venir en una bifurcación existente o iniciar una nueva.

5. Se envía un mensaje de aceptación de llamada al proxy SIP con los candidatos finales del punto de conexión que aceptó la llamada. El mensaje de aceptación de llamada se convierte en el mensaje SIP 200.

   

Varios puntos de conexión suenan sin respuesta provisional

1. Al recibir la primera invitación del SBC, el proxy SIP envía el mensaje "SIP SIP/2.0 100 Trying" y notifica a todos los terminales de usuario final sobre la llamada entrante.

2. Tras la notificación, cada punto de conexión comienza a llamar y envía el mensaje "Progreso de la llamada" al proxy SIP. Dado que la misma identidad de Azure Communication Services se puede usar en varias aplicaciones, el proxy SIP podría recibir varios mensajes de progreso de llamadas.

3. Para cada mensaje de progreso de llamada recibido de los puntos de conexión, el proxy SIP convierte el mensaje Progreso de la llamada al mensaje SIP "SIP SIP/2.0 180 Ringing". El intervalo para enviar los mensajes se correlaciona con el intervalo de recepción de los mensajes del controlador de llamadas. En la imagen hay dos mensajes de 180 generados por el proxy SIP, lo que significa que la llamada se bifurca en dos clientes diferentes y cada cliente envía el progreso de la llamada. Cada mensaje es una sesión independiente (el parámetro "etiqueta" en el campo "Para" es diferente)

4. Se envía un mensaje de aceptación de llamada al proxy SIP con los candidatos finales del punto de conexión que aceptó la llamada. El mensaje de aceptación de llamada se convierte en el mensaje SIP 200.

   

Reemplaza la opción

El SBC debe admitir INVITE con Reemplazar.

Tamaño de las consideraciones de SDP

La interfaz de enrutamiento directo podría enviar un mensaje SIP superior a 1500 bytes. El tamaño de SDP provoca principalmente este comportamiento. Sin embargo, si hay un tronco UDP detrás del SBC, podría rechazar el mensaje si se reenvía desde el proxy SIP de Microsoft al tronco sin modificar. Microsoft recomienda quitar algunos valores en SDP en el SBC al enviar el mensaje a los troncos UDP. Por ejemplo, los candidatos ICE o los códecs sin usar se pueden quitar.

Transferencia de llamadas

El enrutamiento directo admite dos métodos para la transferencia de llamadas:

• Opción 1. El proxy SIP procesa Refer desde el cliente localmente y actúa como Referee tal y como se describe en la sección 7.1 del RFC 3892.

  Con esta opción, el proxy SIP finaliza la transferencia y agrega una nueva invitación.

• Opción 2. El proxy SIP envía la referencia al SBC y actúa como transferidor como se describe en la sección 6 de RFC 5589.

  Con esta opción, el proxy SIP envía una referencia al SBC y espera que el SBC controle completamente la transferencia.

El proxy SIP selecciona el método en función de las funcionalidades notificadas por el SBC. Si el SBC indica que admite el método "Refer", el proxy SIP utiliza la Opción 2 para las transferencias de llamadas. El ejemplo de un SBC que envía el mensaje que admite el método Refer:

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

Si el SBC no indica que Refer como método admitido, el enrutamiento directo usa la opción 1 (el proxy SIP actúa como árbitro). El CLS también debe indicar que admite el método Notify: Ejemplo de SBC que indica que no se admite el método Refer:

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

El proxy SIP procesa Refer desde el cliente localmente y actúa como árbitro

Si el SBC indica que el método Refer no está soportado, el proxy SIP actúa como árbitro. La solicitud Refer que viene del cliente termina en el proxy SIP. La solicitud de Refer del cliente se muestra como "Transferencia de llamada a Dave" en el siguiente diagrama. Para obtener más información, consulte la sección 7.1 de RFC 3892.

El proxy SIP envía el Refer al SBC y actúa como transferidor

SIP Proxy como transferidor es el método preferido para las transferencias de llamadas.

La norma se explica en la sección 6 del RFC 5589. Las RFC relacionadas son:

• Control de llamadas del Protocolo de inicio de sesión (SIP): transferencia

• Protocolo de inicio de sesión (SIP) encabezado "Reemplazar"

• Mecanismo del Protocolo de inicio de sesión (SIP) "Al que se hace referencia"

Esta opción asume que el proxy SIP actúa como transferidor y envía un mensaje Refer al SBC. El SBC actúa como cesionario y gestiona el Refer para generar una nueva oferta de transferencia. Hay dos casos posibles:

• La llamada se transfiere a un participante RTC externo.
• La llamada se transfiere desde un punto de conexión del SDK a otro punto de conexión del SDK en el mismo recurso a través del SBC.

Si la llamada se transfiere de un punto final SDK a otro punto de conexión SDK a través del SBC, se espera que el SBC emita una nueva Invitación (inicie un nuevo diálogo) para el destino de la transferencia utilizando la información recibida en el mensaje Refer. Para rellenar los campos Para/Transferidor para la transacción de la solicitud internamente, el proxy SIP necesita transmitir esta información dentro de los encabezados REFER-TO/REFERRED-BY. El proxy SIP forma el REFER-TO como un URI SIP compuesto por un FQDN de proxy SIP en el nombre de host y cualquiera de los dos:

• Un número de teléfono E.164 en la parte de nombre de usuario del URI en caso de que el destino de transferencia sea un número de teléfono o

• Parámetros x-m y x-t que codifican el MRI de destino de la transferencia completa y el Id. del recurso de comunicación, respectivamente.

El encabezado REFERRED-BY tiene un URI SIP con el MRI del transferidor codificado en él y el ID del recurso del transferidor y otros parámetros de contexto de transferencia como se muestra en la siguiente tabla:

Parámetro	Valor	Descripción
x-m	MRI	MRI completo del transferidor/objetivo de transferencia rellenado por CC
x-t	Id. de inquilino	Id. de recurso x-t Id. opcional de recurso tal y como lo rellena CC
x-ti	Id. de correlación del transferidor	Id. de correlación de la llamada al transferidor
x-tt	Transferir URI de llamada de destino	URI codificado de sustitución de llamada

En este caso, el tamaño del encabezado Refer puede ser de hasta 400 símbolos. El SBC debe soportar el control de mensajes Refer con un tamaño de hasta 400 símbolos.

Reenvío de llamadas

Un SDK de automatización de llamadas de Azure Communication Services puede redirigir las llamadas entrantes a otro número o punto de conexión SDK/Teams, llamar a otro usuario o usuarios en paralelo (llamada simultánea) o llamar a un grupo de usuarios o números. Puntos que se deben tener en cuenta:

• Request-URI en la petición INVITE del proxy SIP al Usuario C contiene el parámetro cause.

• El encabezado History-Info se rellena.

• Cuando el usuario A es otro usuario RTC, el proxy SIP genera la respuesta provisional "Se está reenviando la llamada SIP/2.0 181" al usuario A.

• Si el usuario A y el usuario C son usuarios RTC, el proxy SIP conserva la respuesta provisional "Se está reenviando la llamada SIP/2.0 181".

• El encabezado History-Info debe usarse para la prevención de bucles.

Temporizador de sesión

El proxy SIP admite (siempre ofrece) el temporizador de sesión. El uso del temporizador de sesión por el CLS no es obligatorio.

Uso del parámetro Request-URI user=phone

El proxy SIP analiza el Request-URI y si el parámetro user=phone está presente, el servicio maneja el Request-URI como un número de teléfono, haciendo coincidir el número con un usuario. Si el parámetro no está presente, el proxy SIP aplica heurística para determinar el tipo de usuario Request-URI (número de teléfono o una dirección SIP).

Microsoft recomienda aplicar siempre el parámetro user=phone para simplificar el proceso de configuración de llamadas.

Encabezado History-Info

Nota:

En Azure Communication Services, el enrutamiento directo del encabezado History-Info está activado de forma predeterminada y no se puede desactivar.

El encabezado History-Info se utiliza para reorientar las solicitudes SIP y "proporciona(n) un mecanismo estándar para capturar la información del historial de solicitudes con el fin de habilitar una amplia variedad de servicios para redes y usuarios finales". Para obtener más información, consulte RFC 4244 – Sección 1.1. Para el enrutamiento directo, este encabezado se utiliza en escenarios de llamada simultánea y desvío de llamadas.

History-Info está habilitado de la siguiente manera:

• El proxy SIP inserta un parámetro que contiene el número de teléfono asociado en entradas de información de historial individuales que componen el encabezado History-Info enviado al controlador RTC. Con solo las entradas que tienen el parámetro de número de teléfono, el controlador RTC vuelve a generar un nuevo encabezado History-Info y lo pasa al proveedor de tronco SIP a través del proxy SIP.

• Se agrega el encabezado History-Info para los casos de llamada simultánea y desvío de llamadas.

• El encabezado History-Info no se agrega para los casos de transferencia de llamadas.

• Una entrada de historial individual en el encabezado History-Info reconstruida tiene el parámetro de número de teléfono proporcionado combinado con el FQDN de enrutamiento directo (sip.pstnhub.microsoft.com) establecido como la parte host del URI. Se ha agregado un parámetro de "user=phone" como parte del URI SIP. Cualquier otro parámetro asociado al encabezado History-Info original, excepto los parámetros de contexto telefónico, pasados en el encabezado History-Info reconstruido.

  Nota:

  Las entradas que son privadas (según lo determinado por los mecanismos definidos en la Sección 3.3 del RFC 4244) se reenvían tal cual porque el proveedor de troncales SIP es un par de confianza.

• La información de historial de entrada se conserva para la prevención de bucles.

A continuación se muestra el formato del encabezado History-info enviado por el proxy SIP:

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

Si la llamada se redirigió varias veces, se incluye información sobre cada redirección con el motivo correspondiente en orden cronológico, en una lista separada por comas.

Ejemplo de encabezado:

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

El URI SIP del encabezado History-Info tiene el formato según la sección 25 de RFC 3261 (consulte la definición de addr-spec). En el ejemplo anterior, el texto original del encabezado URI Reason es SIP;cause=496;text="User Busy", que obtiene sus caracteres ;, " y = que se escapan a sus valores hexadecimales ASCII %3B, %22 y 3D respectivamente.

History-Info está protegido por un mecanismo TLS obligatorio.

Conexión SBC con el enrutamiento directo y el mecanismo de conmutación por error

Consulte la sección Mecanismo de conmutación por error para la señalización SIP en Requisitos de infraestructura de enrutamiento directo.

Retry-After

Si un centro de datos de enrutamiento directo está ocupado, el servicio puede enviar un mensaje Retry-After con un intervalo de un segundo al SBC. Cuando el SBC recibe un mensaje 503 con un encabezado Retry-After en respuesta a un INVITE, el SBC debe terminar esa conexión e intentar el siguiente centro de datos de Microsoft disponible.

Control de reintentos (respuesta 603)

Si un usuario final observa varias llamadas perdidas para una llamada después de rechazar la llamada entrante, significa que el mecanismo de reintento del proveedor de troncales SBC o PSTN está mal configurado. El SBC debe ser reconfigurado para detener los esfuerzos de reintento en la respuesta 603.