Resumen

  • El usuario de una URL H.323 es Unicode codificado en UTF-8: los caracteres por debajo de 0x80 se comparan sin distinguir mayúsculas, mientras que los superiores sí distinguen; una normalización global privada cambia la identidad de búsqueda.
  • La coincidencia es solo un paso: hacen falta recibos distintos para fuente del alias, host funcional, transporte seguro, traducción, admisión, señalización, medios, destinatario y resultado.

Dos motores recibieron el mismo texto visible. El primero convirtió todos los caracteres a minúsculas y encontró una única cuenta. El segundo conservó la distinción por encima de ASCII y encontró dos alias. La divergencia nació antes de DNS y antes de cualquier paquete de llamada.

RFC 3508 no resuelve todas las cuestiones modernas de equivalencia Unicode. Sí deja una regla concreta que impide describir cualquier canonicalización privada como si fuera el identificador original.

Publicado en abril de 2003 como RFC Informational, el documento reproduce la definición H323-URL de H.323 versión 4 para facilitar su consulta y registro IANA. No especifica un Internet Standard ni prueba una implementación actual.

El registro coordina el prefijo, no las cuentas

IANA mantiene h323 como esquema permanente con RFC 3508 como referencia. El propósito declarado era impedir que otro esquema duplicara el nombre.

Ese registro hace estable la asociación entre prefijo y especificación. No asigna alias de usuario, no opera un directorio, no valida un gatekeeper y no comprueba llamadas.

Un control puede verificar que el esquema está registrado y aun carecer de evidencia sobre quién controla usuario, qué zona lo interpreta o qué software lo admite. El inventario de namespaces y el inventario de servicios son registros distintos.

La URL admite tres formas con obligaciones diferentes

La dirección puede ser usuario, @hostport o usuario más hostport. El host acepta nombre de dominio, IPv4 o referencia IPv6 entre corchetes, y el puerto es opcional. Después pueden aparecer parámetros con punto y coma.

El usuario solo es un alias sin localización. Necesita un contexto externo. El host solo lleva a una función, pero no necesariamente identifica el servicio final. La forma combinada reduce ambigüedad sin demostrar que el host posee el alias.

El parser debe producir campos y necesidades pendientes. No debe convertir automáticamente una forma válida en endpoint autenticado.

Cuatro representaciones antes de comparar

La evidencia empieza con octetos recibidos. Después vienen escapes porcentuales, bytes UTF-8, cadena Unicode y clave de comparación. Cada transición puede fallar o cambiar el valor.

El host no distingue mayúsculas. En el usuario, los caracteres con valor inferior a 0x80 tampoco; los de valor igual o superior sí. Un lowercasing Unicode total puede fusionar cuentas. Una comparación byte a byte puede separar variantes ASCII que deben coincidir.

Guarde las cuatro representaciones, algoritmo, versión y resultado. Si el directorio normaliza acentos, anchura o composición, esa regla pertenece al directorio y necesita su propio propietario.

El hecho de que dos claves coincidan no certifica que una persona sea la otra. Solo prueba equivalencia bajo ese procedimiento.

El alias no contiene ubicación ni propiedad

El RFC describe entidades que pueden ser personas, dispositivos o servicios. La parte usuario es su alias y no lleva información de ubicación.

Por eso equipo puede significar cosas distintas en dos zonas. Un servicio puede ser un pool. Una asignación puede cambiar. Nada en la cadena lleva fecha de emisión, titular o firma de la autoridad.

La resolución debe registrar fuente, alcance, propietario, revisión, frescura y autenticación. Conservar únicamente el IP final borra el contexto que convirtió una palabra en una ruta.

El hostport identifica una función

El hostport puede señalar Endpoint, Gatekeeper, Border Element u otra función a la que se dirigen llamadas o servicios.

Una conexión a un gatekeeper no es conexión al usuario. Un border element puede enrutar sin conocer la identidad final. DNS demuestra una respuesta de nombres dentro de su contrato, no autoridad sobre el alias H.323.

Registre el rol esperado, la dirección elegida y la política. Aún faltan registro, admisión, señalización y medios.

Los parámetros son una superficie de extensión incompleta

RFC 3508 reserva parámetros separados por punto y coma, pero deja definiciones concretas para estudio posterior. Cada parámetro define juego de caracteres y sensibilidad a mayúsculas.

Un intermediario puede conservar un parámetro desconocido y el receptor puede ignorarlo. Otra implementación puede interpretarlo de forma local. La transmisión exacta no prueba semántica compartida.

Un recibo necesita definición, versión, soporte, tratamiento de desconocidos y efecto. Ningún parámetro genérico debe adquirir autoridad de ruta o seguridad solo por pasar la gramática.

Cada portador crea una procedencia diferente

La URL puede viajar en H.225.0, SIP, TRIP, web o XML. RFC 3508 delega seguridad a H.235 para H.225.0 y al protocolo correspondiente en otros casos.

SIP puede autenticar un peer sin certificar el dueño del alias H.323. TRIP puede propagar ruta de telefonía sin obtener admisión. XML puede preservar texto mientras el parser receptor aplica otra normalización.

RFC 3880 permite mapear usuario, host y puerto a CPL. La coincidencia en un address-switch es una decisión de script, no recibo de llamada.

Guarde portador, remitente, peer autenticado, campos protegidos y transformación.

La pasarela elige una base de traducción

RFC 4123 permite que una función SIP-H.323 use tablas del gatekeeper, registrar SIP u otra base, LDAP, DNS o TRIP. Estas fuentes tienen autoridades y relojes distintos.

Dos pasarelas pueden transformar la misma URL de manera diferente sin violar la sintaxis. Una tabla antigua puede producir una dirección todavía válida pero ya no autorizada.

El registro debe conservar entrada, salida, fuente, versión, prioridad y hora. La traducción correcta según una tabla no demuestra que la tabla correcta fue elegida.

Resolver precede a admitir y comunicar

Después de comparar y resolver quedan transporte, registro, admisión, señalización, negociación, medios, identidad del receptor, efecto y liberación de recursos.

La resolución puede tener éxito y el gatekeeper negar la llamada. La señalización puede conectar sin audio. Los medios pueden ir a una identidad equivocada. La aplicación puede fallar después de que una persona responda.

Los estados deben nombrarse: resuelto, alcanzable, admitido, señalizado, medio establecido, destinatario autenticado, resultado confirmado, cierre completado.

Cadena de evidencia

Preserve URL, portador y octetos; escapes, UTF-8, Unicode y clave; campos, reglas de comparación, parámetros y versión de especificación. Separe registro IANA de soporte runtime.

Registre fuente del alias, frescura, consultas de directorio/DNS/TRIP/LDAP/registrar/gatekeeper, función seleccionada y conexión. Mantenga traducción, admisión, señalización final, negociación, claves, camino de medios, identidad y autorización.

Termine con resultado autenticado, teardown y replay mediante una fuente alternativa. Ninguna etapa hereda automáticamente la prueba de la siguiente.

Límite de evidencia

No se afirma nada sobre producto, endpoint, gatekeeper, operador, usuario, llamada, incidente, despliegue o adopción actual. La fila permanente de IANA no es telemetría.

Este artículo no repite la taxonomía URL/URN, ipn, Gopher, VEMMI ni voicemail SIP. Posee la regla mixta de comparación de RFC 3508 y su efecto antes de la resolución H.323.

Los principios de especificación inicial mínima y código en ejecución de Heng Lu son lentes editoriales declaradas. Favorecen un contrato común estrecho y pruebas del camino ejecutado; no miden H.323.

La conclusión: antes de discutir si la llamada llegó, hay que demostrar qué nombre comparó realmente cada sistema.

Sources