Cómo viaja realmente una llamada de negocios, salto por salto.

La versión corta

Un cliente marca un número de diez dígitos impreso en una camioneta. Unos segundos después, suena el celular de un técnico que va en su vehículo a dos pueblos de distancia, y en la pantalla aparece el número del propio cliente. Para el cliente fue "solo una llamada". En realidad, la llamada pasó por bases de datos de numeración que ninguna empresa controla por sí sola, fue entregada entre operadoras que nunca han tratado con ninguna de las dos partes, muy probablemente se convirtió de un formato de audio a otro, fue firmada criptográficamente en algún punto del camino y se transformó en una segunda llamada, independiente, antes de llegar al celular.

Este artículo recorre ese camino en orden y cita, en cada paso, al organismo que lo define. Cuando una parte del camino es propietaria, describimos únicamente lo que su dueño dice públicamente.

El camino completo en una página

El escenario de todo el artículo: una persona llama desde cualquier teléfono al número local de una empresa. El número lo tiene un proveedor que contesta con un menú telefónico. La persona oprime el 2 y la llamada se desvía al celular de un integrante del equipo, que está con otra operadora. Los números entre corchetes remiten a las secciones siguientes.

CALLER'S PHONE (mobile, landline or VoIP)
   |  dials 613-555-0100
   v
CALLER'S CARRIER  (originating switch / IMS core)
   |  [1] digits read as NPA-NXX-XXXX under the NANP
   |  [2] routing data: which carrier and switch hold that block
   |  [3] portability: has the number moved? local NPAC-fed copy -> LRN
   |  [8] STIR/SHAKEN: originating carrier signs the caller ID
   v
[5] SBC ---- [4] SIP INVITE + SDP offer ----> ( transit carrier[s], each with SBCs )
                                                  |
                                                  v
                                   BUSINESS NUMBER'S PROVIDER  [5] SBC
                                    [4] 100 Trying, 200 OK, SDP answer
                                    [6] RTP audio flows (G.711, AMR-WB, Opus ...)
                                    [7] caller presses 2 -> RFC 4733 DTMF event
                                   [10] starts a NEW call leg (B2BUA):
                                        From = the original caller's number
                                        Identity headers: original + "div"
                                                  |
                                                  v
                                    [3] portability query again, for the MOBILE
                                                  |
                                                  v
                                   TEAM MEMBER'S MOBILE CARRIER  [5] SBC / IMS
                                    [8] verifies the signature
                                    [9] looks up the caller's name (CNAM)
                                    [6] pages the handset; VoLTE audio in AMR-WB
                                                  |
                                                  v
                                   TEAM MEMBER'S MOBILE RINGS
                                   showing the caller's number

Audio, once both legs answer:            [11] delay and one-way audio live here
CALLER <==RTP==> [media relays / transcoders] <==RTP==> MOBILE

Dos cosas sorprenden a la mayoría de las personas. La señalización (quién llama a quién) y los medios (los paquetes de audio) son flujos separados que pueden tomar rutas distintas. Y el desvío no es la llamada original doblando una esquina: es una llamada nueva, hecha por el proveedor de la empresa y unida a la primera en el medio.

1. El número marcado: qué codifican diez dígitos

Estados Unidos y Canadá comparten un mismo plan de numeración. El Plan de Numeración de América del Norte (NANP) es "an integrated telephone numbering plan serving 20 North American countries that share its resources" (un plan de numeración integrado que atiende a 20 países norteamericanos que comparten sus recursos), entre ellos Estados Unidos y sus territorios, Canadá, Bermudas y buena parte del Caribe.1 Sus números son de diez dígitos: un código de área de tres dígitos (NPA) seguido de un número local de siete, escritos "NXX-NXX-XXXX where N is any digit from 2 through 9 and X is any digit from 0 through 9" (donde N es cualquier dígito del 2 al 9 y X, cualquiera del 0 al 9).1 La UIT asignó a todo el NANP el código de país 1.1

Los seis primeros dígitos, el NPA más el código de central (NXX), le decían históricamente todo a la red. El operador de la base de portabilidad lo dice sin rodeos: "Calls are routed based on the first six digits (NPA-NXX) of the telephone number. The NPA-NXX is the address of the switch serving the telephone number." (Las llamadas se enrutan según los primeros seis dígitos; el NPA-NXX es la dirección de la central que atiende el número.)2

La administración se divide por país. NANPA "holds overall responsibility for the neutral administration of NANP numbering resources" y es el administrador nacional de EE. UU.; "COMsolve Inc. serves as the Canadian Numbering Administrator".1 NANPA también subraya que "is not a policy-making entity" (no es una entidad que fije políticas): las reglas las dictan la FCC y, en Canadá, el CRTC.1 Nuestra referencia de códigos de área enumera todos los códigos de EE. UU. y Canadá según esos administradores.

2. Datos de enrutamiento: quién tiene el bloque de números

Saber que 613-555 es un bloque de la zona de Ottawa no le dice a una operadora en Texas adónde enviar la llamada. Para eso, las operadoras recurren a datos de referencia de enrutamiento. La compilación más conocida es la LERG Routing Guide, un producto comercial. Es propietaria y se vende por suscripción, así que describimos solamente lo que su editor dice en la página pública del producto.

Según esa página, el LERG "contains current information about the local Public Switched Telephone Network (PSTN) as well as additional information about IP Networks and includes scheduled future activity".3 Fue "initially designed for the routing of Inter-Local Access and Transport Area calls" por las operadoras de larga distancia, y hoy sirve a CLEC, operadoras inalámbricas, ISP y proveedores VoIP.3 Entre su contenido figuran números de empresas operadoras, códigos de área, "NPA NXX Thousands-Blocks assignments for the United States and its territories, Canada, Bermuda, and 16 Caribbean countries", registros de centrales, "Switch Homing Arrangements (tandem and other switch-to-switch interconnections)", centros tarifarios (rate centers) y Location Routing Numbers.3 Se "produce" el primer día hábil de cada mes, con archivos diarios de cambios opcionales para los suscriptores.3

Material más antiguo presenta el LERG como producto de iconectiv; sus páginas ahora llevan la marca Transaction Network Services (TNS).3 No encontramos ninguna declaración pública que explique el cambio. Lo que los datos de enrutamiento no pueden decirle a una operadora es si este número en particular se ha mudado desde entonces. Ese es el paso siguiente.

3. La consulta de portabilidad: ¿se mudó este número?

Cuando una empresa porta su número a un proveedor nuevo (vea portar su número), el número conserva su NPA-NXX, pero cambia la central que lo atiende. La solución que la industria eligió en los años noventa es el Location Routing Number (LRN): "a ten-digit number designed to look like a telephone number" (un número de diez dígitos diseñado para parecer un número telefónico), "assigned to each ported telephone number and is used to route calls through the PSTN to the switch serving the ported number".2 "Calls to the ported number are instead routed based on the NPA-NXX of the 10 digit LRN." (Las llamadas al número portado se enrutan, en cambio, según el NPA-NXX del LRN de 10 dígitos.)2 El método LRN, desarrollado por AT&T y Lucent, "became the de facto industry standard and later was adopted by the Federal Communications Commission in 1997" (se convirtió en el estándar de facto de la industria y luego fue adoptado por la FCC en 1997).4

La mecánica en el momento de la llamada, con las palabras del propio operador: "the initiating service provider switch launches a query to its LNP call routing database to determine whether the telephone number has been ported. If it has, the database response provides the switch with the LRN needed to properly route the call. If the number is not ported, the database response indicates that the call should be routed based on the telephone number."2 Es decir, la central de origen consulta la base de datos de enrutamiento LNP y, según la respuesta, enruta por el LRN o por el número mismo. Fíjese en "its" (su propia base de datos): las operadoras consultan su propia copia, alimentada desde el sistema central, y no el sistema central en cada llamada.

Las reglas de EE. UU. hacen explícita la responsabilidad. La operadora "N-1", la anterior a la que termina la llamada, "is responsible for ensuring number portability queries are performed on a N-1 basis where 'N' is the entity terminating the call to the end user ... unless another carrier has already performed the query".5 Una operadora terminadora que recibe una llamada sin consultar "may block the unqueried call only if performing the database query is likely to impair network reliability" (solo puede bloquear la llamada no consultada si hacer la consulta pudiera perjudicar la confiabilidad de la red).5

El sistema central es el Number Portability Administration Center (NPAC). Históricamente, "Eight regional LNP databases were established, the seven U.S. databases coinciding with the seven original Regional Bell Operating Company regions and a single database to serve Canada."4 Cada registro del NPAC contiene el número, el identificador del proveedor actual, el tipo de proveedor (inalámbrico o fijo), el LRN y los códigos de punto SS7 para servicios como CNAM.2 Cuando una portabilidad se activa, el registro se "broadcast to the telecommunications industry network within milli-seconds" (difunde a la red de la industria en milisegundos), según el operador del NPAC canadiense.2

En nuestro escenario la consulta de portabilidad ocurre dos veces: una para el número de la empresa en el tramo de entrada, y otra para el número celular del integrante del equipo en el tramo desviado, porque los números celulares también se portan entre operadoras.

4. Hacia SIP: el INVITE y sus respuestas

En algún punto entre la operadora de quien llama y el proveedor de la empresa, la llamada casi con certeza viaja como SIP. Algunas operadoras todavía se entregan las llamadas por troncales más antiguas de conmutación de circuitos con señalización SS7; las reglas de EE. UU. aún especifican lo que debe enviarse "in the SS7 ISUP (ISDN User Part) CPN field" y también en los "Session Initiation Protocol (SIP) header fields".8 Las plataformas de telefonía comercial alojada (hosted), según nuestra experiencia, usan SIP de punta a punta.

SIP es "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants", entre ellas las "Internet telephone calls" (llamadas telefónicas por internet).9 No transporta el audio. Transporta la conversación de establecimiento, en mensajes de texto que se parecen mucho a HTTP:

• INVITE: la solicitud para establecer una llamada, con una descripción de los medios que quien llama puede manejar.
• 100 Trying: "the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted)". Es salto a salto y "never forwarded upstream by a stateful proxy".9
• 180 Ringing: "The UA receiving the INVITE is trying to alert the user", y "MAY be used to initiate local ringback".9 183 Session Progress transmite otra información de progreso.9 El audio enviado antes de que se acepte la llamada se llama early media (medios tempranos), y sus "Typical examples ... are ringing tone and announcements".10
• 200 OK: la llamada fue contestada, con la descripción de medios de quien contesta. Quien llama confirma con un ACK.9

La negociación de medios dentro de esos mensajes es el modelo de oferta y respuesta de SDP. La oferta enumera "the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offerer would like to use to receive the media"; quien responde contesta con "a matching media stream for each stream in the offer".11 Recuerde ese detalle de las "direcciones ... para recibir los medios": es la raíz del problema de audio en un solo sentido que veremos más adelante.

Un INVITE ilustrativo, tal como podría llegar al proveedor de la empresa (direcciones y números de ejemplo; no capturado de ninguna red real):

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 203.0.113.10;branch=z9hG4bK74bf9
From: <sip:[email protected]>;tag=9fxced76sl
To: <sip:[email protected]>
P-Asserted-Identity: <sip:[email protected];user=phone>
Identity: eyJhbGciOiJFUzI1NiIs...;info=<https://cert.carrier.example/sti.pem>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Type: application/sdp

v=0
o=- 2890844526 2890844526 IN IP4 203.0.113.20
s=-
c=IN IP4 203.0.113.20
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Léalo de arriba abajo: a quién se llama, quién llama (dos veces: el From visible para el usuario y la identidad afirmada por la red), una firma sobre el identificador de llamada (el encabezado Identity, sección 8 más abajo) y una oferta de G.711 en sus dos variantes más eventos DTMF, para recibirse en 203.0.113.20, puerto 49170. P-Asserted-Identity permite que "a network of trusted SIP servers ... assert the identity of authenticated users", pero solo "inside an administrative domain with previously agreed-upon policies".12 Dicho de otro modo, es una promesa entre partes que confían entre sí, no una prueba.

La RFC 3261 también describe cómo un proxy puede enviar un INVITE "to a number of locations at the same time. This type of parallel search is known as forking." (a varios destinos a la vez; este tipo de búsqueda en paralelo se llama bifurcación).9 La bifurcación es una de las formas de construir "hacer sonar todos los teléfonos" dentro de la red de un proveedor.

5. Controladores de borde de sesión: las aduanas

Las operadoras rara vez permiten que el SIP de otra red toque directamente su núcleo. En cada frontera hay un controlador de borde de sesión (SBC). Formalmente, los SBC son un tipo de agente de usuario espalda con espalda (B2BUA), "the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC)": terminan la llamada de un lado y originan una llamada equivalente del otro.13 Las centrales IP (IP PBX) y los servidores de aplicaciones también son B2BUA.13

La descripción de la IETF sobre lo que hacen los SBC en la práctica es inusualmente franca, porque muchas de esas funciones doblan el diseño original de SIP:14

• Ocultamiento de topología: reescribir encabezados para que la otra red no vea las direcciones internas.
• Gestión del tráfico de medios: "By modifying the session description, the SBC can force the media to be sent through a media relay", por ejemplo para asegurar la calidad o imponer los códecs permitidos. "Since the media path is independent of the signaling path, the media may not traverse through the operator's network unless the SBC modifies the session description."
• Corregir incompatibilidades de capacidades: conectar terminales "that support different IP versions, different codecs, or that are in different address realms". La RFC lo llama "a fragile function in the long term" (una función frágil a largo plazo).
• Traspaso de NAT y control de acceso: mantener vivas las conexiones con dispositivos detrás de enrutadores de hogares y oficinas, y filtrar quién puede enviar llamadas.

Una llamada comercial desviada puede cruzar con facilidad cuatro o más de estas cajas: al salir de la operadora de quien llama, al entrar y salir de cualquier operadora de tránsito, al entrar y salir del proveedor de la empresa, y al entrar a la operadora del celular. Cada una es un lugar donde se puede reescribir un encabezado, cambiar un códec o reanclar un flujo de audio. Esta es buena parte de la razón por la que llamadas idénticas pueden comportarse distinto según las operadoras que toquen.

6. El audio en sí: RTP y códecs

Una vez contestada la llamada, el audio fluye en paquetes RTP. RTP "provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio", pero "does not address resource reservation and does not guarantee quality-of-service".15 Normalmente viaja sobre UDP, con un protocolo de control complementario (RTCP) para estadísticas de recepción.15 Los paquetes perdidos no se retransmiten; el lado receptor disimula el hueco y sigue adelante.

Para el audio empaquetado, el intervalo de paquetización predeterminado "SHOULD have a duration of 20 ms or one frame, whichever is longer"; el intervalo "determines the minimum end-to-end delay".16 Es decir, fluyen unos cincuenta paquetes por segundo en cada sentido.

Tres códecs importan en este camino:

Deslice la tabla hacia los lados para ver todas las columnas.

Cuando los dos extremos no comparten ningún códec, algo en el medio transcodifica: los SBC y las puertas de enlace de medios decodifican un formato y codifican otro.14 Quien llama desde un celular en AMR-WB, sobre una interconexión G.711, a un softphone en Opus, es transcodificado al menos dos veces, y cada paso agrega retardo y pierde calidad. Una vez que el audio de banda ancha se ha exprimido por G.711 de banda estrecha, el ancho de banda perdido no vuelve.

Creemos que este es el factor de calidad más subestimado en las llamadas de negocios. La "voz HD" existe de punta a punta solo cuando todos los tramos y todas las interconexiones acuerdan un códec de banda ancha, y el dueño del negocio casi nunca controla ninguna de esas negociaciones.

7. Oprimir el 2: cómo cruza una tecla una red IP

Un menú telefónico depende de que las teclas que oprime quien llama lleguen intactas. En la red antigua eran tonos audibles (DTMF). En un camino IP, enviarlos como sonido dentro del flujo de voz es frágil: la RFC 4733 explica que se necesitan formatos separados "since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition".21

Por eso el enfoque estándar es enviar las teclas como eventos: paquetes RTP pequeños que dicen "dígito 2, comenzó en este momento, duró tanto", usando el tipo de carga telephone-event negociado en el SDP (carga 101 en el ejemplo anterior).21 El formato también "permits higher redundancy while maintaining a low bit rate": los paquetes de eventos suelen repetirse, de modo que la pérdida de un solo paquete no se traga un dígito.21 Las redes celulares también lo admiten: el perfil de voz sobre LTE dice "The UE and the IMS core network must support DTMF events".20

Donde falla es en las fronteras. Si un tramo negoció eventos y otro no, una puerta de enlace debe convertir entre eventos y tonos audibles, y si nadie convierte, el menú no oye nada. En nuestra experiencia, esta es la causa habitual de la queja "el menú no responde cuando los clientes oprimen un número", y por eso creemos que un proveedor debería probar el DTMF con cada operadora con la que se interconecta.

8. STIR/SHAKEN: firmar el identificador de llamada en el camino

El identificador de llamada en SIP es simplemente un encabezado que escribe la red de origen. STIR/SHAKEN agrega una firma. El mecanismo de la IETF define "a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer" (el encabezado Identity de nuestro ejemplo).22 El perfil SHAKEN agrega tres niveles de atestación: "full attestation when the service provider can fully attest to the calling identity, a partial attestation when the service provider originated a telephone call but cannot fully attest to the calling identity, and a gateway attestation" para llamadas recibidas de una puerta de enlace que no lo admite.23

En EE. UU., antes del 30 de junio de 2021 los proveedores de servicio de voz debían "fully implement the STIR/SHAKEN authentication framework in its internet Protocol networks", autenticando las llamadas que originan y verificando las que terminan.24 El marco solo funciona sobre SIP; para las redes que no son IP, la regla permitió a los proveedores, en cambio, documentar su participación en el trabajo sobre una "non-internet Protocol caller identification authentication solution".25 Por eso, cualquier segmento de conmutación de circuitos en medio de una llamada pierde la firma. En Canadá, el CRTC ordenó a los proveedores implementar STIR/SHAKEN "for Internet Protocol (IP)-based voice calls as a condition of offering and providing telecommunications services, effective 30 November 2021".26

La atestación en profundidad, la pantalla del teléfono y el etiquetado de spam son un tema aparte; la complicación del desvío está en la sección 10.

9. El nombre en la pantalla: el CNAM se consulta, no se envía

El número viaja con la llamada. En Estados Unidos, el nombre normalmente no. La documentación de soporte de un proveedor describe el mecanismo con claridad: "When the recipient receives a call, their carrier is responsible for displaying the assigned caller name by querying the appropriate databases containing CNAM data entries. These databases are known as CNAM repositories and collectively referred to as the Line Information Database (LIDB)."27 Las operadoras "may subscribe to one or more of the CNAM databases and perform lookups, also known as 'dips'".27

De ahí se desprenden tres consecuencias. El nombre tiene como máximo 15 caracteres, por convención en mayúsculas.27 La operadora terminadora puede tener datos desactualizados o estar suscrita a una base de datos distinta de la que actualizó su proveedor.27 Y en los celulares, es posible que el nombre no se muestre en absoluto si el plan del destinatario no lo incluye: "Mobile users in the US may need to subscribe with their carrier for CNAM to be displayed".27 Un nombre guardado en los contactos del propio destinatario no es CNAM en absoluto.

No encontramos una fuente de primera mano que describa cómo entregan las operadoras canadienses el nombre de quien llama, así que esta sección describe solo EE. UU.

10. El tramo desviado: una segunda llamada con el número de la primera

Este es el paso que hace distinta una llamada comercial desviada de una común. Cuando quien llama oprime el 2, el proveedor de la empresa no "pasa la llamada". Actuando como B2BUA, hace una llamada saliente totalmente nueva al número celular del integrante del equipo y une los dos tramos.13 Esa llamada nueva vuelve a recorrer las secciones 2 a 9: datos de enrutamiento, una consulta de portabilidad del número celular, interconexiones, SBC, una firma y las consultas de la operadora del celular.

El proveedor elige qué poner en los encabezados From y de identidad afirmada del tramo nuevo. La convención para los desvíos, y lo que casi todos quieren, es presentar el número de quien llamó originalmente, para que el técnico vea quién llama antes de contestar. Las reglas de EE. UU. exigen que los proveedores en el camino transmitan el número de origen, y que los proveedores intermedios "pass unaltered to subsequent providers in the call path signaling information identifying the telephone number ... of the calling party", incluyendo expresamente los "Session Initiation Protocol (SIP) header fields".8 (Si un servicio de desvío determinado actúa como proveedor intermedio o como originador de una llamada nueva para efectos regulatorios es una cuestión de clasificación que no intentamos resolver aquí.)

El destino original también puede registrarse, en History-Info, que captura "how and why a SIP request arrives at a specific application or user",28 o en el antiguo encabezado Diversion, "still used for this purpose by some operators today".29 Ninguno de los dos aparece en la pantalla normal de un celular.

El desvío crea un problema para las firmas del identificador de llamada. Una firma STIR cubre tanto el número llamado como el de quien llama, precisamente para que no se pueda copiar y pegar en otra llamada. Una llamada desviada llega a un número que no es el que marcó quien llamó, lo cual se parece exactamente a ese ataque. La respuesta de la IETF es el PASSporT "div": el proveedor que desvía agrega un segundo token firmado en el que el "dest" original pasa a ser la afirmación "div", el nuevo destino pasa a ser el "dest", y el "orig" (quien llama) "MUST be copied into the new PASSporT from the original".29 Así la operadora del celular puede verificar ambas firmas y ver una redirección legítima. No encontramos una fuente pública que mida qué tan ampliamente verifican hoy los tokens "div" las operadoras terminadoras de EE. UU. o Canadá, por lo que no afirmamos nada sobre su despliegue.

11. De dónde vienen el retardo y el audio en un solo sentido

Retardo. La guía de planificación de la UIT es que si el retardo en un sentido, de la boca al oído, "can be kept below" 150 ms, "most applications, both speech and non-speech, will experience essentially transparent interactivity", y que "it is recommended to not exceed a one-way delay of 400 ms for general network planning".30 El presupuesto se va llenando desde varios lugares:

• Distancia. La fibra óptica agrega unos 5 µs por kilómetro.30 Según nuestra aritmética, 4,000 km de fibra (más o menos una ruta de Montreal a Vancouver) cuestan unos 20 ms en un sentido.
• Paquetización. Cada paquete de audio de 20 ms debe llenarse antes de enviarse.16
• Códecs. Los codificadores tienen su propia anticipación; en Opus, entre 5 ms y 65.2 ms según el modo.18
• Búferes de jitter. Los receptores deliberadamente "impose a playout delay" para suavizar la llegada despareja de paquetes.21
• Cada transcodificación y relevo de medios. Cada uno decodifica, almacena y vuelve a codificar.14

Una llamada desviada paga varios de estos costos dos veces, una por tramo, más el retardo de acceso por radio del lado del celular. Por eso una llamada desviada a través de un centro de datos lejano a ambas partes puede sentirse ligeramente "retrasada" cuando una llamada directa de celular a celular no.

El audio en un solo sentido es una falla distinta, y casi siempre un problema de direccionamiento. La oferta y la respuesta SDP dicen cada una dónde quiere ese lado recibir el audio.11 Un dispositivo detrás de un enrutador de hogar u oficina (un NAT) puede poner su dirección privada, interna, en su SDP. El otro extremo envía el audio, obediente, a una dirección que no puede alcanzar, mientras el audio saliente del propio dispositivo sale sin problema. Un lado oye al otro; el otro oye silencio. La IETF señala que las sesiones que intercambian direcciones IP y puertos enfrentan "challenges when operated through Network Address Translators" y que las distintas soluciones funcionan cada una "in some network topologies, but a poor choice in others".31 Los softphones usan ICE para probar direcciones candidatas antes de que empiecen los medios;31 los SBC de las operadoras, en cambio, reescriben el SDP y "force traffic to go through a media relay for NAT traversal purposes", a veces relevando un solo sentido.14 En nuestra experiencia, cuando aparece audio en un solo sentido en llamadas a un celular, los sospechosos habituales son un softphone o un teléfono de escritorio en una red de oficina mal configurada, o un relevo de medios por el que uno de los tramos no pasó.

12. Dónde el 911 es diferente

Todo lo anterior se refiere a llamadas ordinarias, enrutadas por número. Las llamadas de emergencia se enrutan por ubicación, por una infraestructura aparte, hacia un punto de respuesta de seguridad pública (PSAP).

• VoIP interconectado, EE. UU. Los proveedores deben enviar las llamadas al 911, el número de quien llama (ANI) y su ubicación a "the PSAP ... that serves the caller's dispatchable location", y "All 911 calls must be routed through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network"; la ubicación debe estar disponible para el PSAP mediante la "automatic location information (ALI) database".32
• Celular, EE. UU. Las operadoras celulares deben "transmit all wireless 911 calls without respect to their call validation process to a Public Safety Answering Point".33
• Canadá. El CRTC exige a los proveedores de VoIP local ofrecer "either Basic or Enhanced 9-1-1 service", informar a los clientes de cualquier limitación, y remite a los proveedores a su decisión sobre el 9-1-1 de próxima generación.34

Para nuestro escenario esto tiene un significado práctico. Un servicio de desvío está solo en el camino de entrada. Cuando el integrante del equipo marca el 911 desde el celular, esa llamada es de la operadora celular, bajo las reglas de telefonía celular, y nunca toca al proveedor del número de la empresa. Quien llama y cuelga para marcar el 911 también es atendido por su propia operadora. El menú telefónico de la empresa simplemente no está en el camino de emergencia, y por eso creemos que una configuración centrada en el celular es más fácil de razonar que una central de teléfonos de escritorio. Nuestra página de llamadas de emergencia expone en detalle la Ley de Kari (Kari's Law) y las reglas de ubicación despachable, junto con las reglas canadienses del 9-1-1.

Nuestra opinión: una docena de empresas detrás de un timbre

Cuente las organizaciones independientes en una sola llamada desviada. La operadora de quien llama. Posiblemente una o más operadoras de tránsito. Los administradores de numeración (NANPA, o COMsolve en Canadá). El editor de los datos de enrutamiento. El administrador de portabilidad (iconectiv en EE. UU., Neustar en Canadá) y las copias locales que mantiene cada operadora. El proveedor del número de la empresa. Su operadora de respaldo, si no lo es él mismo. El administrador de políticas y las autoridades de certificación detrás de STIR/SHAKEN.24 Una o más bases de datos CNAM. La operadora celular del integrante del equipo. Son aproximadamente una docena, sin contar a los fabricantes cuyo software de SBC y de puertas de enlace de medios funciona en cada frontera.

Creemos que esto importa para la confiabilidad de tres maneras.

1. Las fallas suelen estar en las uniones, no en las cajas. Cada organización prueba su propio sistema. Las fallas comunes de la telefonía comercial (dígitos no reconocidos, audio en un solo sentido, el nombre equivocado, una llamada desviada marcada como sospechosa) surgen donde se encuentran los supuestos de dos redes: un modo DTMF, una dirección SDP, una base de datos a la que un lado está suscrito y el otro no, una firma que no sobrevivió a un salto.
2. El dueño del negocio tiene un solo contrato. Cuando una llamada falla, la única parte con un deber hacia la empresa es el proveedor al que le paga. Un buen proveedor puede rastrear una llamada a través de sus interconexiones usando Call-ID y marcas de tiempo; uno débil dice "debe ser la otra operadora". Pregunte cuál está comprando antes de necesitarlo.
3. El desvío duplica la exposición. Una llamada desviada son dos llamadas, cada una con su propia cadena. La comodidad de hacer sonar celulares comunes es real, y es el modelo sobre el que está construido nuestro propio servicio. Pero significa que tanto el tramo de entrada como el de salida tienen que funcionar, y un proveedor debería poder mostrarle cómo monitorea ambos.

Preguntas que vale la pena hacer por escrito a cualquier proveedor de telefonía comercial: ¿Qué códecs negocian en las llamadas a celulares y dónde transcodifican? ¿Envían el DTMF como eventos RFC 4733 y convierten cuando una operadora no los admite? ¿El número de quién aparece en una llamada desviada, y firman las llamadas desviadas con un token "div"? ¿Quién actualiza el CNAM de mi número y en qué bases de datos? ¿Qué pasa con una llamada si su operadora de respaldo tiene una caída? Un proveedor honesto responderá cada una de estas preguntas con precisión, incluido un "no lo sabemos" cuando esa sea la verdad.