Resumen

  • RFC 9878 permite P-Access-Network-Info y P-Charging-Vector en el ACK provocado por una respuesta 2xx, y los excluye del ACK ligado a una respuesta no 2xx.
  • Esa regla acredita la posición protocolaria, no la identidad de quien escribió el valor, su actualidad, la modificación efectiva del bearer ni el importe facturado.
  • La evidencia completa enlaza el contexto SIP con la custodia entre saltos, NPLI, ruta direccional, evento de red, CDR, regla de rating y revisión humana.

Imagine dos mensajes llamados ACK. Uno confirma el resultado satisfactorio de un INVITE; el otro acompaña un resultado adverso. A simple vista comparten método. En SIP no comparten todas las reglas, y desde noviembre de 2025 tampoco pueden transportar indistintamente ciertos P-Headers de 3GPP.

RFC 9878 corrige una contradicción histórica de RFC 7315 y deja obsoleto RFC 7976. La tabla corregida resuelve qué implementación debe aceptar o enviar cada campo. Esa claridad es valiosa precisamente si no se le atribuye una facultad que el documento no concede: juzgar la verdad semántica o la factura posterior.

El ACK necesita apellido

La excepción nueva afecta a P-Access-Network-Info y P-Charging-Vector. Ambos pueden entrar en un ACK cuando lo desencadenó una respuesta 2xx. No deben entrar cuando el ACK corresponde a una respuesta no 2xx. Por eso un registro que conserva solamente “ACK” no basta para comprobar conformidad.

Hay que retener el estado que lo originó: código de respuesta final, Call-ID, tags, CSeq, sentido y elemento SIP que tomó la decisión. RFC 3261 separa el tratamiento transaccional de los ACK de éxito y de fracaso. El contexto perdido no puede recuperarse mirando después el nombre del campo.

El caso NPLI muestra la razón práctica. Una respuesta SDP dentro del 2xx a INVITE puede provocar una modificación del bearer. El proxy obtiene entonces información de localización proporcionada por la red y la entrega en el ACK para que el CDR refleje ese momento. El mecanismo evita que el dato necesario quede sin vehículo.

Pero “necesario para una facturación correcta” no significa “suficiente para probar una factura”. La cabecera no demuestra por sí sola que la NPLI fuera reciente, que procediera de un proxy autorizado, que el bearer cambiara, que el CDR la uniera al diálogo correcto o que el precio aplicado estuviera pactado.

La matriz corregida es deliberadamente estrecha

Los demás cambios confirman esa precisión. P-Associated-URI aparece en respuestas 2xx a REGISTER. P-Called-Party-ID se limita a determinadas solicitudes, con REFER añadido a la lista. P-Visited-Network-ID puede aparecer en respuestas distintas de 100, pero no en varios métodos enumerados. P-Charging-Function-Addresses sigue fuera de ACK y CANCEL.

Un parser puede decidir con esa matriz si el campo es admisible. No puede decidir si el actor tenía mandato para ponerlo. El registro IANA de parámetros SIP normaliza nombres y parámetros; no audita el mensaje capturado.

RFC 9878 advierte además que algunas instalaciones quizá no estén actualizadas. La ausencia de un campo puede ser versión antigua, política local, caso no aplicable o fallo de enriquecimiento. Su aparición inesperada puede ser otra versión, una lectura anterior o entrada no fiable. Saltar directamente a “cumple” o “fraude” elimina las hipótesis que la operación debe resolver.

Un campo modificable exige historia de custodia

RFC 7315 restringe estos P-Headers a dominios administrativos privados y relaciones de confianza. Un proxy con información adecuada puede insertar su propio valor network-provided; al salir hacia una entidad no fiable debe retirar el dato sensible. Si recibe contenido desde un origen no fiable, no puede garantizarlo.

P-Charging-Vector está pensado para cambiar. Proxies de confianza insertan, consultan, modifican y a veces suprimen parámetros. La integridad se protege salto a salto porque cada intermediario legítimo necesita acceso. Por tanto, la copia final no demuestra su genealogía. Hace falta un evento firmado o protegido por cada transformación, con huellas anterior y posterior.

Los transit-ioi tampoco forman una lista universal. Pueden ser filtrados, borrados o sustituidos por valores vacíos. RFC 9878 señala que cada método y cada sentido puede elegir un transitario distinto por carga, coste, porcentaje u hora. El camino del INVITE no representa automáticamente el del ACK ni toda la sesión.

Con NPLI aparece una obligación adicional: privacidad. Puede incluir datos de célula o acceso sensibles. El modelo confía en que la información no abandone el dominio previsto. Volcar todas las cabeceras en un lago de datos abierto a muchos equipos conserva bytes y pierde control.

De la señal a la línea de factura

Un expediente defendible conserva el mensaje bruto, hora, clase de respuesta, coordenadas de diálogo y transacción, dirección, versión de cada proxy y política activa. Para cada P-Header registra dominio de entrada, actor que insertó o modificó, protección del salto y huellas de cambio. Para NPLI añade fuente, fecha, precisión y finalidad permitida.

Después necesita un join independiente con la respuesta SDP, el evento de establecimiento, modificación o desactivación del bearer, el CDR, la regla tarifaria y el cálculo de la línea. ICID ayuda a correlacionar; no otorga derecho ni fija importe. Si el join no cierra, el estado correcto es “pendiente de reconciliación”, no “validado por cabecera”.