Enrutamiento directo: protocolo SIP

• Se aplica a:

  Microsoft Teams

En este artículo se describe cómo el Enrutamiento directo implementa el Protocolo de inicio de sesión (SIP). Para redirigir el tráfico entre un controlador de borde de sesión (SBC) y el proxy SIP, algunos parámetros SIP deben tener valores específicos. Este artículo está destinado a los administradores de voz que son responsables de configurar la conexión entre el SBC local y el servicio proxy SIP.

Procesando la solicitud entrante: buscar el espacio empresarial y el usuario

Antes de que se pueda procesar una llamada entrante o saliente, los mensajes OPTIONS se intercambian entre el proxy SIP y el SBC. Estos mensajes OPTIONS permiten que el proxy SIP proporcione las capacidades permitidas a SBC. Es importante que la negociación OPTIONS tenga éxito (respuesta 200OK), lo que permite una mayor comunicación entre SBC y proxy SIP para establecer llamadas. Los encabezados SIP en un mensaje OPTIONS a proxy SIP se proporcionan como ejemplo:

Nombre del parámetro	Ejemplo del valor
Request-URI	OPCIONES sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
A través del encabezado	A través de: SIP/2.0/TLS sbc1.adatum.biz:5058; Alias; branch=z9hG4bKac2121518978
encabezado de Max-Forwards	Max-Forwards:68
Desde encabezado	Desde el encabezado de: sip:sbc1.adatum.biz:5058
Al encabezado	Para: sip:sip.pstnhub.microsoft.com:5061
Encabezado CSeq	CSeq: 1 INVITACIÓN
Encabezado de contacto	Contacto: sip:sbc1.adatum.biz:50588; transport=tls

Nota

Los encabezados SIP no contienen userinfo en el URI del SIP en uso. Como se muestra en 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 una noción de usuarios o cuando el propio host es el recurso que se está identificando. Si el signo @ está presente en un URI de SIP, el campo de usuario NO DEBE estar vacío. El URI de SIPS no debe usarse con enrutamiento directo porque no es compatible. Compruebe la configuración del controlador de borde de sesión y asegúrese de que no está usando encabezados "Reemplaza" en solicitudes SIP. Enrutamiento directo rechazará solicitudes SIP que tengan los encabezados Replaces definidos.

En una llamada entrante, el proxy SIP necesita encontrar el inquilino al que se destina la llamada y encontrar el usuario específico dentro de este inquilino. El administrador de inquilinos puede configurar números no DID, por ejemplo +1001, en varios espacios empresariales. Por lo tanto, es importante encontrar el inquilino específico en el que realizar la búsqueda de números porque los números que no son DID pueden ser los mismos en varias organizaciones de Microsoft 365 o Office 365.

Esta sección describe cómo el proxy SIP encuentra el inquilino y el usuario, y realiza la autenticación del SBC en la conexión entrante.

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

Nombre del parámetro	Ejemplo del valor
Request-URI	INVITAR sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
A través del encabezado	A través de: SIP/2.0/TLS sbc1.adatum.biz:5058; Alias; branch=z9hG4bKac2121518978
encabezado de Max-Forwards	Max-Forwards:68
Desde encabezado	Desde el encabezado de: <sip:+17168712781@sbc1.adatum.biz; transport=udp; tag=1c747237679
Al encabezado	Para: sip:+183338006777@sbc1.adatum.biz
Encabezado CSeq	CSeq: 1 INVITACIÓN
Encabezado de contacto	Contacto: sip:+17168712781@sbc1.adatum.biz:5058; transport=tls

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

1. Compruebe el certificado. En la conexión inicial, el servicio de enrutamiento directo toma el nombre fqdn presentado en el encabezado del contacto y lo hace coincidir con el nombre común o el nombre alternativo del asunto del certificado presentado. El nombre de SBC debe coincidir con una de las siguientes opciones:

   • Opción 1. El nombre completo del FQDN que se presenta en el encabezado del contacto debe coincidir con el nombre común o el nombre alternativo del asunto del certificado presentado.

   • Opción 2. La parte del dominio del nombre FQDN que se muestra en el encabezado Contacto (por ejemplo, adatum.biz del nombre FQDN sbc1.adatum.biz) debe coincidir con el valor de carácter comodín en Nombre común o Nombre alternativo del asunto (por ejemplo, *.adatum.biz).

2. Intente buscar un inquilino con el nombre completo de FQDN que se muestra en el encabezado Contacto.

   Compruebe si el nombre fqdn del encabezado de contacto (sbc1.adatum.biz) está registrado como nombre DNS en cualquier Microsoft 365 o Office 365 organización. Si se encuentra, la búsqueda del usuario se realiza en el espacio empresarial que tiene el FQDN de SBC registrado como nombre de dominio. Si no se encuentra, se aplica el paso 3.

3. El paso 3 solo se aplica si se produce un error en el paso 2.

   Quite la parte del host del FQDN, que se muestra en el encabezado de contacto (FQDN: sbc12.adatum.biz, después de quitar la parte de host: adatum.biz) y compruebe si este nombre está registrado como nombre DNS en cualquier microsoft 365 o Office 365 organización. Si se encuentra, la búsqueda de usuarios se realiza en este espacio empresarial. Si no se encuentra, se produce un error en la llamada.

4. Con el número de teléfono que se muestra en el URI de solicitud, realice la búsqueda de número inverso dentro del espacio empresarial que se encontró en los pasos 2 o 3. Haga coincidir el número de teléfono presentado con un URI de SIP de usuario dentro del espacio empresarial encontrado en el paso anterior.

5. Aplicar la configuración de tronco. Busque los parámetros establecidos por el administrador de inquilinos para este SBC.

   Microsoft no admite tener un proxy SIP o servidor de agente de usuario de terceros entre el proxy SIP de Microsoft y el SBC emparejado, que podría modificar el URI de solicitud creado por el SBC emparejado.

   Los requisitos para las dos búsquedas (pasos 2 y 3) necesarios para el escenario en el que un SBC está interconectado a muchos inquilinos (escenario de operador) se tratan más adelante en este artículo.

Requisitos detallados para el encabezado de contacto y el URI de solicitud

Encabezado de contacto

Para todos los mensajes SIP entrantes (OPCIONES, INVITAR) al proxy SIP de Microsoft, el encabezado de contacto debe tener el FQDN SBC emparejado en el nombre de host URI de la manera siguiente:

Sintaxis: Contacto: <sip:phone o sip address@FQDN del SBC; transport=tls>

Como se indica en RFC 3261, sección 11.1, un campo de encabezado de contacto puede estar presente en un mensaje OPTIONS. En Enrutamiento directo, el encabezado de contacto es obligatorio. Para los mensajes DE INVITACIÓN en el formato anterior, para los mensajes OPTIONS, el userinfo se puede quitar del URI del SIP y solo el FQDN enviado en formato como sigue:

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

Este nombre (FQDN) también debe estar en los campos Nombre común o Nombre alternativo del asunto del certificado presentado. Microsoft admite el uso de valores comodín de los 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 o fragmento de componente. Por ejemplo, *.a.com coincide con foo.a.com pero no con bar.foo.a.com. f*.com coincide foo.com pero no bar.com".

Si el SBC envía más de un valor en el encabezado de contacto presentado en un mensaje SIP, solo se usa la parte FQDN del primer valor del encabezado de contacto.

Para el enrutamiento directo, es importante que el FQDN se use para rellenar el URI de SIP en lugar de IP. Un mensaje entrante INVITE u OPTIONS a proxy SIP con encabezado de contacto donde el nombre de host se representa mediante IP y no FQDN, la conexión se rechaza con 403 Forbidden.

Request-URI

Para todas las llamadas entrantes, el URI de solicitud se usa para hacer coincidir el número de teléfono con un usuario.

Actualmente, el número de teléfono debe contener un signo más (+) como se muestra en el ejemplo siguiente.

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

Desde encabezado

Para todas las llamadas entrantes, el encabezado De se usa para hacer coincidir el número de teléfono del autor de la llamada con la lista de números de teléfono bloqueados del destinatario de la llamada y se usa para realizar una búsqueda inversa de números para buscar el nombre del autor de la llamada en registros de usuario e inquilinos existentes.

Para que estas búsquedas funcionen, el número de teléfono debe contener un signo + como se muestra en el ejemplo siguiente.

From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679

Consideraciones de encabezados de Record-Route y contactos

El proxy SIP debe calcular el FQDN del próximo salto para las nuevas transacciones del cliente del cuadro de diálogo (por ejemplo, Bye o Re-Invite) y al responder a las opciones sip. Se usan Contacto o Record-Route.

Según RFC 3261, sección 8.1.1.8, el encabezado de contacto es obligatorio en cualquier solicitud que pueda dar lugar a un nuevo cuadro de diálogo. El Record-Route solo es necesario si un proxy quiere mantenerse en la ruta de las solicitudes futuras de un cuadro de diálogo. Si se usa un SBC de proxy con optimización de medios locales para el enrutamiento directo, es necesario configurar una ruta de registro, ya que el servidor proxy SBC debe permanecer en la ruta.

Microsoft recomienda usar solo el encabezado Contacto si no se usa un SBC de proxy:

• Según RFC 3261, sección 20.30, Record-Route se usa si un proxy quiere mantenerse en la ruta de futuras solicitudes en un cuadro de diálogo, lo que no es esencial si no se configura ningún servidor proxy SBC, ya que todo el tráfico va entre el proxy SIP de Microsoft y el SBC emparejado.

• El proxy SIP de Microsoft utiliza solamente el encabezado del contacto (no record-route) para determinar el salto siguiente al enviar las opciones de ping salientes. Configurar solo un parámetro (contacto) en lugar de dos (contacto y ruta-registro) simplifica la administración si un proxy SBC no está en uso.

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

• Prioridad 1. Ruta de registro de nivel superior. Si la Record-Route de nivel superior contiene el nombre fqdn, el nombre fqdn se usa para realizar la conexión saliente en el cuadro de diálogo.

• Prioridad 2. Encabezado de contacto. Si no existe Record-Route, el proxy SIP buscará el valor del encabezado contacto para realizar la conexión saliente. (Esta es la configuración recomendada).

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

Uso de nombre FQDN en Contacto o Record-Route

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

• Si se presenta una dirección IP en Ruta de registro 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 del asunto o común en el certificado presentado, se produce un error en la llamada.

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

En la tabla siguiente se resumen las diferencias y similitudes entre los modos de no omisión y de omisión:

Nombre del parámetro	Modo sin omisión	Modo de omisión
Candidatos a medios en 183 y 200 mensajes procedentes de	Procesadores multimedia	Clientes
Número de 183 mensajes que puede recibir SBC	Uno por sesión	Múltiples
La llamada puede ser con respuesta provisional (183)	Sí	Sí
La llamada puede ser sin respuesta provisional (183)	Sí	Sí

Flujo de omisión no multimedia

Un usuario de Teams puede tener varios puntos de conexión al mismo tiempo. Por ejemplo, Teams para el cliente de Windows, Teams para iPhone y Teléfono Teams (cliente de Teams para Android). Cada punto de conexión podría indicar un descanso HTTP de la siguiente manera:

• Progreso de la llamada – convertido por el proxy SIP al mensaje SIP 180. Al recibir el mensaje 180, el SBC debe generar llamada local.

• Respuesta multimedia: convertida por el proxy SIP al 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 de medios recibidos en el mensaje SDP.

  Nota

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

• Llamada aceptada – convertida por el proxy SIP al 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

  Enrutamiento directo no admite invitación a oferta con retraso (invitación sin SDP).

Varios puntos de conexión sonando 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 puntos de conexión del usuario final sobre la llamada entrante.

2. Tras la notificación, cada punto de conexión empieza a sonar y enviar mensajes de "Progreso de llamada" al proxy SIP. Como un usuario de Teams puede tener varios puntos de conexión, el proxy SIP podría recibir varios mensajes de progreso de llamada.

3. Para cada mensaje de progreso de llamada recibido de los clientes, el proxy SIP convierte el mensaje del progreso de la llamada al mensaje del SIP "SIP SIP/2.0 180 Ringing". El intervalo para enviar estos mensajes se define por el intervalo de recepción de mensajes del controlador de llamada. En el siguiente diagrama, hay dos 180 mensajes generados por el proxy SIP. Estos mensajes proceden de los dos puntos de conexión de Teams del usuario. Los clientes tienen un id. de etiqueta único. Cada mensaje procedente de un punto de conexión diferente es una sesión independiente (el parámetro "tag" del 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 siguiente diagrama.

4. Una vez que un punto de conexión genera un mensaje de respuesta multimedia con las direcciones IP de los candidatos multimedia del punto de conexión, el proxy SIP convierte el mensaje recibido en un mensaje "Progreso de sesión SIP 183" con el SDP del cliente reemplazado por el SDP del procesador multimedia. En el siguiente diagrama, el punto de conexión de Bifurcación 2 respondió a la llamada. Si el trunk es non-bypassed, el mensaje del SIP 183 se genera solamente una vez (anillar bot o punto final del cliente). 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 con los candidatos finales del punto de conexión que ha aceptado la llamada. El mensaje aceptación de llamadas se convierte en mensaje SIP 200.

Varios puntos de conexión sonando 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 puntos de conexión del usuario final sobre la llamada entrante.

2. Tras la notificación, cada punto de conexión empieza a sonar y envía el mensaje "Progreso de la llamada" al proxy SIP. Como un usuario de Teams puede tener varios puntos finales, el proxy SIP podría recibir varios mensajes de progreso de llamada.

3. Para cada mensaje de progreso de llamada recibido de los clientes, el proxy SIP convierte el mensaje del progreso de la llamada al mensaje del SIP "SIP SIP/2.0 180 trying". El intervalo para enviar los mensajes se define por el intervalo de recepción de los mensajes del controlador de llamada. En el siguiente diagrama, hay dos 180 mensajes generados por el proxy SIP, lo que significa que el usuario inició sesión en tres clientes de Teams y cada cliente envía el progreso de la llamada. Cada mensaje es una sesión independiente (el parámetro "tag" en el campo "Para" es diferente)

4. Se envía un mensaje de Aceptación de llamada con los candidatos finales del punto de conexión que ha aceptado la llamada. El mensaje aceptación de llamadas se convierte en mensaje SIP 200.

Flujo de omisión de medios

Los mismos mensajes (100 intentos, 180, 183) se usan en el escenario de omisión multimedia.

El siguiente esquema muestra un ejemplo del flujo de llamada de omisión.

Nota

Los candidatos a medios pueden proceder de diferentes puntos de conexión.

Opción Reemplazar

El SBC debe admitir La invitación con reemplazos.

Tamaño de consideraciones de SDP

La interfaz de enrutamiento directo pudo enviar un mensaje SIP que exceda 1.500 bytes. El tamaño del SDP causa principalmente esto. Sin embargo, si hay un tronco UDP detrás del SBC, podría rechazar el mensaje si se reenvía del 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, se pueden quitar los candidatos de ICE o los códecs sin usar.

Transferencia de llamada

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

• Opción 1. Procesos del proxy SIP Refiera del cliente localmente y actúa como árbitro 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 transferor como describe en la sección 6 de RFC 5589.

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

El proxy SIP selecciona el método basado en las capacidades notificadas por el SBC. Si el SBC indica que soporta el método "Refer", el proxy SIP utiliza la opción 2 para las transferencias de llamada.

El siguiente es un ejemplo de un SBC que envía el mensaje que indica que el método Refer es compatible:

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

Si el SBC no indica que Refer as a supported method, Direct Routing utiliza la opción 1 (proxy SIP actúa como árbitro). El SBC 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

Procesos del proxy SIP Referir desde el cliente localmente y actúa como árbitro

Si el SBC indica que el método Refer no es compatible, el proxy SIP actúa como árbitro.

La petición de referencia que viene del cliente se termina en el proxy DEL SIP. La petición de referencia del cliente se muestra como "Transferencia de llamada a Dave" en el siguiente diagrama. Para obtener más información, vea la sección 7.1 de RFC 3892.

El proxy SIP envía la referencia al SBC y actúa como transferibler

Este es el método preferido para las transferencias de llamadas y es obligatorio para los dispositivos que buscan la certificación de omisión multimedia. Transferencia de llamadas sin que el SBC pueda controlar La referencia no se admite en el modo de omisión de medios.

El estándar se explica en la sección 6 de RFC 5589. Las RFCs relacionadas son:

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

• Encabezado "Reemplaza" del Protocolo de inicio de sesión (SIP)

• Mecanismo "Referido por" del Protocolo de inicio de sesión (SIP)

Esta opción asume que el proxy SIP actúa como transferibler y envía un mensaje de referencia al SBC. El SBC actúa como Cesionario y maneja la Referencia para generar una nueva oferta para transferencia. Hay dos casos posibles:

• La llamada se transfiere a un participante de RTC externo.
• La llamada se transfiere de un usuario de Teams a otro usuario de Teams en el mismo espacio empresarial a través de SBC.

Si la llamada se transfiere de un usuario de Teams a otro a través de SBC, se espera que el SBC emita una nueva invitación (iniciar un nuevo cuadro de diálogo) para el destino de transferencia (el usuario de Teams) con la información recibida en el mensaje Referencia.

Para rellenar los campos To/Transferor 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 del SIP compuesto por un FQDN del proxy SIP en el nombre de host y cualquiera de los siguientes:

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

• Parámetros x-m y x-t que codifican la MRI de destino de transferencia completa y el id. de inquilino respectivamente

El encabezado REFERRED-BY es un URI sip con MRI transferor codificado en él y id. de inquilino del transferor y otros parámetros de contexto de transferencia como se muestra en la tabla siguiente:

Parámetro	Valor	Descripción
x-m	MRI	RMN completa del transferor/destino de transferencia tal y como se rellena con CC
x-t	Id. del espacio empresarial	x-t Id. de espacio empresarial opcional rellenado por CC
x-ti	Id. de correlación de transferor	Id. de correlación de la llamada al transferibler
x-tt	URI de llamada de destino de transferencia	URI de reemplazo de llamada codificado

El tamaño del encabezado de referencia puede ser de hasta 400 símbolos en este caso. El SBC debe admitir el control De referencia de mensajes con un tamaño de hasta 400 símbolos.

Desvío de llamadas

Un usuario de Teams puede desviar las llamadas entrantes a otro número o usuario de Teams, llamar a otros usuarios en paralelo (llamada simultánea) o llamar a un grupo de usuarios o números. Tenga en cuenta lo siguiente:

• Request-URI en la solicitud INVITE del proxy SIP al usuario C contiene el parámetro cause .

• Según las configuraciones de tronco (parámetro ForwardCallHistory ), el encabezado de History-Info se rellena.

• Cuando el usuario A es otro usuario RTC, el proxy SIP genera la respuesta provisional "SIP SIP/2.0 181 Call is being forwarded" al usuario A.

• Si el usuario A y el usuario C son usuarios RTC, el proxy SIP conserva la respuesta provisional "SIP SIP/2.0 181 Call is being forwarded".

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

Temporizador de sesión

El proxy SIP admite (siempre ofrece) el temporizador de sesión en llamadas sin omisión, pero no lo ofrece en llamadas de omisión. El uso del temporizador de sesión por parte de SBC no es obligatorio.

Uso del parámetro Request-URI user=phone

El proxy SIP analiza el URI de solicitud y, si el parámetro user=phone está presente, el servicio controla el URI de solicitud como 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 la llamada.

encabezado de History-Info

El encabezado History-Info se usa para volver a dirigir solicitudes SIP y "proporcionar(s) 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, vea RFC 4244: sección 1.1. Para Microsoft Phone System, este encabezado se usa en escenarios de Desvío de llamadas y Desenlazamiento de llamadas.

Si se envía, el History-Info se habilita de la siguiente manera:

• El proxy SIP inserta un parámetro que contiene el número de teléfono asociado en entradas de History-Info individuales que componen el encabezado History-Info enviado al controlador RTC. Usando solamente las entradas que tienen el parámetro de número de teléfono, el controlador RTC recompila un nuevo encabezado de History-Info, y lo pasa al proveedor del tronco SIP vía el proxy SIP.

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

• History-Info encabezado no se agregará para los casos de transferencia de llamadas.

• Una entrada del historial individual en el encabezado de History-Info reconstruido tendrá 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 agrega un parámetro de "user=phone" como parte del URI del SIP. Cualquier otro parámetro asociado con el encabezado de History-Info original, excepto los parámetros de contexto del teléfono, se pasa por el encabezado History-Info reconstruido.

  Nota

  Las entradas que son privadas (según determinen los mecanismos definidos en la sección 3.3 de RFC 4244) se reenvía tal y como es porque el proveedor del tronco SIP es un par de confianza.

• La History-Info de entrada se conserva cuando se habilita el parámetro ForwardCallHistory. Se pueden usar History-Info conservados para la prevención del bucle.

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, la información sobre cada redirección se incluye con la razón apropiada en orden cronológico, en una lista separada por comas.

Ejemplo de encabezado:

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

El URI de SIP en el encabezado de 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 Reason URI es SIP;cause=496;text="User Busy", que obtiene su ;, "y = los caracteres que se escapan a sus valores %3Bhexadecimales ASCII , %22y 3D, respectivamente.

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

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

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

Retry-After

Si un centro de datos de enrutamiento directo está ocupado, el servicio puede enviar un mensaje de Retry-After con un intervalo de un segundo al SBC. Cuando el SBC recibe un mensaje 503 con un encabezado de Retry-After en respuesta a una INVITACIÓN, el SBC debe finalizar esa conexión y probar 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 tronco RTC o SBC está mal configurado. Es necesario volver a configurar el SBC para detener los esfuerzos de reintento en la respuesta 603.

Reinicio de ICE: llamada de omisión de medios transferida a un punto de conexión que no admite omisión multimedia

El SBC debe admitir reinicios de ICE como se describe en RFC 5245, sección 9.1.1.1.

El reinicio en enrutamiento directo se implementa de acuerdo con los siguientes párrafos de RFC:

Para reiniciar ICE, un agente DEBE cambiar tanto el ice-pwd como el ice-ufrag para el flujo de medios en una oferta. Es permisible usar un atributo de nivel de sesión en una oferta, pero proporcionar el mismo ice-pwd o ice-ufrag como un atributo de nivel de medios en una oferta posterior. Esto no es un cambio de contraseña, solo un cambio en su representación y no provoca un reinicio de ICE.

Un agente establece el resto de los campos en el SDP para esta transmisión multimedia como lo haría en una oferta inicial de esta transmisión multimedia (consulte la sección 4.3). Por lo tanto, el conjunto de candidatos PUEDE incluir algunos, ninguno o todos los candidatos anteriores para esa transmisión, y PUEDE incluir un nuevo conjunto de candidatos recopilados como se describe en la sección 4.1.1.

Si la llamada se estableció inicialmente con omisión de medios y la llamada se transfiere a un cliente de Skype Empresarial, enrutamiento directo debe insertar un procesador multimedia; esto se debe a que el enrutamiento directo no se puede usar con un cliente de Skype Empresarial con omisión de medios. Direct Routing inicia el proceso de reinicio de ICE cambiando el ice-pwd y ice-ufrag y ofreciendo nuevos candidatos de medios en un revite.