Enrutamiento directo: definiciones y estándares RFC

  • Artículo
  • Se aplica a:
    Microsoft Teams

En este artículo se describe cómo Teams Phone Direct Routing implementa protocolos rfc-standard. Este artículo está destinado a los administradores de voz responsables de configurar la conexión entre el controlador de borde de sesión local (SBC) y el servicio proxy sip (Protocolo de inicio de sesión).

El cliente SBC se conecta con los siguientes componentes en el back-end de Microsoft Teams:

  • El proxy SIP para señalización. Este componente es el componente orientado a Internet del enrutamiento directo que controla las conexiones SIP (TLS) entre los SCS y el enrutamiento directo.

  • Procesadores multimedia para medios. Este componente es el componente orientado a Internet del enrutamiento directo que controla el tráfico multimedia. Este componente utiliza protocolos SRTP y SRTCP.

Para obtener más información sobre el enrutamiento directo, vea Enrutamiento directo de Teléfono de Teams.

Para obtener más información sobre cómo Direct Routing implementa el protocolo SIP, vea Direct Routing - PROTOCOLO SIP.

Estándares RFC

Direct Routing cumple con los estándares RFC. El SBC conectado al enrutamiento directo también debe cumplir con las siguientes RFCs (o sus sucesoras).

Estándares aplicables a dispositivos que admiten el modo de omisión no multimedia

Los siguientes estándares son aplicables a los dispositivos que admiten solo el modo de omisión no multimedia:

  • RFC 3261 SIP: Protocolo de inicio de sesión
  • RFC 3325. Extensión privada al Protocolo de inicio de sesión para la identidad aserda en redes de confianza: secciones sobre el tratamiento del encabezado P-Asserted-Identity. Direct Routing envía P-Asserted-Identity con encabezados de Id. de privacidad.
  • RFC 4244 Una extensión al Protocolo de inicio de sesión (SIP) para la información del historial necesaria. Vea también: Descripción del Protocolo SIP de enrutamiento para obtener más información.
  • RFC 3892 Mecanismo de Referred-By del Protocolo de inicio de sesión
  • RFC 3891 El encabezado "Reemplaza" del Protocolo de inicio de sesión (SIP)
  • RFC 6337 Uso del modelo de oferta/respuesta del Protocolo de inicio de sesión (SIP). Consulte la sección "Desviaciones de RFC".
  • RFC 3711 y RFC 4771. Proteja el tráfico RTP con SRTP. El SBC debe ser capaz de establecer claves mediante SDES.
  • RFC 8035 Descripción de sesión Protocolo de descripción (SDP) Ofrece/responde aclaraciones para multiplexación RTP/RTCP

Estándares aplicables a dispositivos que admiten el modo de omisión multimedia

Además de los estándares enumerados como aplicables al modo nonbypass, se utilizan los siguientes estándares para el modo de derivación multimedia:

Estándares aplicables para admitir la transmisión de información de ubicación a proveedores E911

Desviaciones de las RFCs

En la tabla siguiente se enumeran las secciones de rfc(s) en las que la implementación de Microsoft de la pila de medios o SIP se desvía del estándar:

RFC y secciones Descripción Desviación
RFC 6337, sección 5.3 Suspensión y currículum vítae de medios RFC permite usar "a=inactive", "a=sendonly", a=recvonly" para poner una llamada en espera. El proxy SIP solo admite "a=inactivo" y no comprende si el SBC envía "a=sendonly" o "a=recvonly".
RFC 6337, sección 5.4 Comportamiento en la recepción de SDP con c=0.0.0.0 RFC3264 requiere que un agente sea capaz de recibir el SDP con una dirección de conexión de 0.0.0.0, en cuyo caso significa que ni RTP ni RTCP deben enviarse al par. El proxy SIP no admite esta opción.
RFC 3261, sección 25 BNF aumentada para el protocolo SIP El carácter '#' debe enviarse como '%23' El proxy SIP envía el carácter "#" en un URI de solicitud sin formato.

Consideraciones de transporte TCP/TLS

Al enviar una solicitud SIP (nueva o en diálogo), proxy SIP de Microsoft puede abrir una nueva conexión TCP/TLS o reutilizar una conexión existente si existe una.

  • Hay un máximo de dos conexiones TCP/TLS por FQDN/IP remoto, por cada máquina virtual de proxy SIP. Antes de enviar una solicitud SIP, el proxy SIP comprueba si hay conexiones TCP activas con la dirección IP resuelta del SBC/Trunk FQDN de destino. Si existen dos conexiones, se reutilizan. Si no existen dos conexiones, se abre una nueva conexión.

    • Esta lógica es por máquina virtual de proxy SIP.

    • Varias máquinas virtuales por región realizan el mantenimiento de las IP del proxy SIP.

    • Desde la perspectiva de SBC, puede haber varias conexiones de proxy entrantes desde todas las regiones de proxy SIP.

  • Las conexiones TCP/TLS abiertas por proxy SIP no permanecen abiertas siempre que la llamada lo haga. Sin embargo, la conexión no se cierra inmediatamente después de una respuesta a una solicitud SIP. Si no se agota el tiempo de espera de una conexión, puede volver a usarse para otras solicitudes SIP.

  • Proxy SIP no admite el alias de conexión, como se describe en RFC 5923: Reutilización de la conexión en el Protocolo de inicio de sesión (SIP).

    • Las conexiones TCP de proxy SIP salientes solo prestan servicio a las solicitudes de proxy SIP salientes (a SBCs) y a las respuestas relacionadas.

    • Las conexiones TCP de proxy SIP entrante (desde SBCs) solo realizan el servicio de las solicitudes SIP entrantes y las respuestas relacionadas.

Directivas de tiempo de espera

  • El tiempo de espera de inactividad de proxy SIP TCP es de dos minutos. El temporizador restablece cuando se produce una transacción SIP a través de la conexión.

  • El proxy SIP envía la aplicación CRLF keep-alive por RFC 5626: Administrar conexiones de Client-Initiated en el Protocolo de inicio de sesión (SIP).

    • El keep-alive no restablece el temporizador de inactividad tcp.

    • El keep-alive CRLF enviado por el proveedor SBC restablece el temporizador de inactividad TCP.

  • Debido a la restricción de alias mencionada anteriormente, el proveedor SBC no debe utilizar solicitudes SIP en diálogo para restablecer el temporizador en las conexiones creadas por el proxy SIP saliente al proveedor SBC.

  • Después de dos minutos de idling, (FIN, ACK) se transmite al proveedor SBC por proxy SIP en aproximadamente 10 a 20 segundos.

Notas

  • Se recomienda que el SBC reutilice activamente las conexiones, como proxy SIP. Este método ahorra tiempo, que es necesario para las conexiones TCP y TLS.

  • El SBC debe renovar la conexión al menos una vez por hora.

  • Cuando se carga un nuevo certificado de SBC, el SBC debe renovar todas las conexiones.

  • Cuando se actualizan las configuraciones de dominio, se recomienda renovar las conexiones de SBC. De lo contrario, se aplicará una nueva configuración después de renovar la memoria caché interna del proxy SIP ( hasta cuatro horas).

Modos operativos

Existen dos modos operativos para el enrutamiento directo:

  • Sin la omisión de medios en la que todo el tráfico RTP fluye entre el cliente de Teams, los procesadores multimedia y el SBC.

  • Con la omisión de medios en la que todos los medios RTP fluyen entre los puntos de conexión de Teams y el SBC.

El tráfico SIP fluye siempre a través del proxy SIP.

DTMF

DtMF en banda no es compatible con la pila de medios.