Enrutamiento directo: definiciones y estándares RFC
En este artículo se describe cómo Teléfono Teams enrutamiento directo usa protocolos estándar definidos por las solicitudes de comentarios del grupo de tareas de ingeniería de Internet (RFC). 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, consulte Teléfono Teams enrutamiento directo.
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:
-
RFC 5245 Interactive Connectivity Establishment (ICE) para omisión de medios. El SBC debe admitir los siguientes elementos de ICE:
- ICE Lite: los clientes de Teams son clientes de ICE completos
- ICE se reinicia. Obtenga más información sobre el caso de uso de los reinicios de ICE y ejemplos en Reinicio de ICE: Llamada de omisión de medios transferida a un punto de conexión que no admite omisión multimedia
- Rfc RFC 5589 Control de llamadas del Protocolo de inicio de sesión (SIP): transferencia.
- RFC 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP), see sections 3.1, Forking, and 3.2, Ringing Tone Generation
- Utilidades de recorrido de sesión RFC 5389 para NAT (STUN)
- RFC 5766 Traversal mediante relés alrededor de NAT (TURN): Extensiones de relé a utilidades de recorrido de sesión para NAT (STUN)
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 las RFCs en las que la implementación de LA SIP o de la pila de medios por parte de Microsoft 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 pueda recibir el SDP con una dirección de conexión de 0.0.0.0, que indique no enviar RTP o RTCP 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. |
| RFC 3264, sección 8.3.1 Un modelo de oferta o respuesta con SDP | RFC 3264 detalla un mecanismo de redestinación de medios MAY (opcional) que permite cambiar el puerto multimedia, la dirección IP o el transporte después de establecer la sesión. | No se admite el retarget multimedia opcional. Durante una llamada, no se admiten las solicitudes SIP para actualizar el puerto multimedia, la dirección IP o el transporte. Los elementos multimedia no se enviarán al destino de sesión actualizado; los elementos multimedia de Enrutamiento directo continúan fluyendo hasta el destino original. |
Nota de RFC que admite la elección; El oferante DEBE estar preparado para recibir medios tanto en los puertos antiguos como en los nuevos tan pronto como se envíe la oferta. El oferante NO DEBE dejar de escuchar a los medios en el puerto antiguo hasta que se reciba la respuesta y los medios lleguen al nuevo puerto.|
Consideraciones de transporte TCP/TLS
Cuando el proxy SIP de Microsoft envía una solicitud SIP (nueva o en diálogo), puede abrir una nueva conexión TCP/TLS o volver a usar una conexión existente si existe.
Se permiten 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.
El 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.
Tenga en cuenta que, en ciertas situaciones, las puertas de enlace o los SBCs de terceros pueden marcar restablecimientos de conexión TLS para los servicios de O365. Se espera un comportamiento de restablecimiento de conexión, ya que las nuevas conexiones se crean dinámicamente sin que esto afecte a la experiencia del usuario.
Directivas de tiempo de espera
El tiempo de espera de la inactividad tcp del proxy SIP 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 Client-Initiated Connections 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 transmiten al proveedor SBC por proxy SIP en aproximadamente 10 a 20 segundos.
Notas
El SBC debería reutilizar activamente las conexiones, como el 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
La pila de medios no admite DTMF en banda.