# Dos llamadas en el mismo milisegundo y la troncal solo tramita una: 100 Trying no promete nada > La troncal responde 100 Trying a dos INVITE enviadas a la vez y solo tramita una. Por qué el acuse de recibo no sirve como estado de la llamada y qué decidimos en su lugar. - Publicado: 12 de octubre de 2026 - Autor: Equipo de IntegraLaIA - Categoría: Ingeniería - Temas: Voz, Producción, Agentes - Original: https://integralaia.com/blog/100-trying-llamadas-simultaneas-troncal-sip - Cómo se hizo: Borrador asistido por IA (Claude); revisado, editado y verificado por Equipo de IntegraLaIA el 12 de octubre de 2026. Ilustración generada con IA. --- Dos llamadas salieron con un milisegundo de diferencia. En los registros las dos quedaron como marcadas, y una de las dos nunca sonó en el teléfono de destino. Ningún error, ningún rechazo, ninguna traza de la que tirar: la llamada que no existió se veía exactamente igual que la que sí. ## La restricción: acusa recibo de las dos y tramita una La causa salió de mirar la señalización en crudo, que es el único sitio donde estaba. La troncal responde `100 Trying` a las dos peticiones enviadas en el mismo milisegundo, y después solo una de ellas sigue viva: la otra no vuelve a recibir nada, y se cancela sola cuando se agota el tiempo de espera de la marcación. Separadas tres segundos, las dos progresan con normalidad y las dos suenan, aunque la primera todavía esté timbrando. Esa segunda prueba es la que cambia el diagnóstico. No es un límite de "una llamada a la vez", que es la primera lectura y la que habríamos arreglado mal: es un límite de **ráfaga**. Lo que la troncal no tolera es recibir dos peticiones en el mismo instante, no tener dos llamadas en curso. La trampa está en qué significa ese `100 Trying`. RFC 3261 lo define como la respuesta que indica que la petición fue recibida por el siguiente servidor del camino, y clasifica cualquier respuesta `1xx` como "petición recibida, sigo procesando". Una respuesta provisional, dice el mismo documento, sirve para indicar progreso y no termina la transacción. Nada de eso promete una llamada. Es un acuse de recibo de la pregunta, y nosotros lo estábamos leyendo como una confirmación de la respuesta. ## El estándar permite el silencio, así que no esperes un error Lo primero que uno piensa es que el proveedor debería haber devuelto un error, y que algo está roto de su lado. El protocolo tiene esa respuesta: el `503 Service Unavailable` existe, según RFC 3261, para cuando "el servidor es temporalmente incapaz de procesar la petición por una sobrecarga temporal o un mantenimiento", y puede acompañarse de una cabecera que dice cuánto esperar antes de volver a intentarlo. Pero el mismo documento cierra esa puerta en la frase siguiente: los servidores **pueden** rechazar la conexión o descartar la petición en lugar de responder con un `503`. El silencio es conforme al estándar. Quien recibe tu llamada no tiene ninguna obligación de contarte que no la va a tramitar, y eso convierte la ausencia de progreso en un estado que te toca detectar a ti. Es el mismo patrón que cuando [la red del cliente bloquea una URL firmada](/blog/red-del-cliente-bloquea-s3-url-firmada): el fallo ocurre donde tus registros no llegan, así que tus registros dicen que todo salió bien. ## Las dos decisiones, y cuál de las dos importa más La primera es la obvia y la más barata: marcar de a una por troncal, con unos segundos entre una petición y la siguiente. Reintentar enseguida habría empeorado el problema, porque el reintento es otra ráfaga. La segunda es la que de verdad valía la pena. Una fila que pasa a "llamada realizada" en el momento de pedirla está registrando una intención, no un hecho, y eso es lo que hizo que el fallo fuera invisible durante dos días. El estado ahora sale de la señalización: si la llamada no progresa, se cierra al instante con la causa de por qué, en lugar de quedarse marcada como buena mientras un temporizador corre por detrás. Es la misma lección que cuando [un agente dijo haber verificado una identidad](/blog/verificacion-identidad-agente-ia) sin haberlo hecho: el registro vale lo que vale su fuente. ## Qué se lleva cualquiera que dependa de un tercero Esto no es un problema de telefonía, es un problema de acuses de recibo. Un `202 Accepted` de una API, un `200` con el que respondes un webhook, un mensaje encolado, un `100 Trying`: los cuatro dicen "lo recibí" y ninguno dice "lo hice". Si el estado de tus operaciones se escribe en el momento de pedirlas, estás midiendo tu propia intención. Tres preguntas que valen para cualquier integración: ¿qué respuesta estás tratando como confirmación, y eso es lo que dice su especificación? ¿Qué pasa si no llega nada, ni error ni éxito? ¿Y tu límite real es de concurrencia o de ráfaga, que casi nunca son el mismo número? Nosotros operamos un agente de voz que hace llamadas salientes en producción, con la misma gobernanza que el resto de los [agentes](/agentes): un dueño humano, permisos acotados y registro de cada llamada. Encontrar esto costó una captura de señalización y dos días de llamadas que parecían hechas, y es la clase de cosa que solo aparece operando. --- ## Sobre qué se escribió - IETF, RFC 3261 (SIP: Session Initiation Protocol), sección 21.1.1 (100 Trying), consultada el 12 de octubre de 2026: https://www.rfc-editor.org/rfc/rfc3261.html#section-21.1.1 - IETF, RFC 3261, sección 21.5.4 (503 Service Unavailable), consultada el 12 de octubre de 2026: https://www.rfc-editor.org/rfc/rfc3261.html#section-21.5.4 - IETF, RFC 3261, sección 7.2 (Responses) y sección 6 (Definitions, provisional response), consultadas el 12 de octubre de 2026: https://www.rfc-editor.org/rfc/rfc3261.html#section-7.2 IntegraLaIA (https://integralaia.com). Publicado bajo el enlace original; cítalo si lo reutilizas.