1400 frente a
0x1400 es nuevo para usted. Esta página trata de cómo se ejecutan.
Un tag puede venir de cuatro sitios
1
El submit_sm del cliente
Se extrae solo si
registered.tlvs.submit del listener lo declara. Los tags no declarados se
descartan, no se pasan.2
El defaultTlvs de su credencial
Rellena tags que el mensaje no llevaba.
3
El sello de whitelist
En modo
assign, rellena un tag que al mensaje le falta. En modo replace, sobrescribe lo
que el cliente envió. Y esa sobrescritura es la aprobación.4
El default.tlvs.submit del vendor
Rellena cualquier cosa aún sin establecer en el momento del envío.
replace, que está pensado para ganar.
Dos comprobaciones obligatorias, en puntos distintos
Averiguar qué faltará antes de que falte
El informe de cobertura de TLV del panel de control dice, por fila aprobada, qué tags obligatorios no suministrará nada. Ese informe es lo que hace descubrible en lugar de meramente silencioso el modo de sellado por defecto (off). Poner assign por defecto empezaría a escribir TLVs en paquetes que cruzan
listeners que nunca han escrito ninguno: un cambio silencioso en lo que llega a un operador.
El fallo que realmente ha ocurrido
El lado del cliente
Un cliente puede ver los TLVs que envió en sus propios mensajes, y puede proponer nuevas definiciones de tag para que un operador apruebe. Nunca ven lo que un vendor añadió aguas abajo. El registro de llamada guarda tres conjuntos (recibidos, enviados y lo que la whitelist selló) para que una disputa sobre lo que llegó al operador sea respondible en lugar de argumentada.Un caso trabajado: DLT indio
El id de entidad registrada va en la credencial, porque es una propiedad del cliente en lugar de de cualquier mensaje concreto:0xC3 en
lugar de ser rechazado por el operador más tarde, que es el sentido de comprobar en absoluto.