ISUP 18 --> ¿cdr disposition "FAILED"?
Iñaki Baz Castillo
- Un Asterisk llama a través de un primario (tarjeta Digium) a un
Cisco que hace la conversión a SIP.
- El proveedor SIP devuelve código 480 tras N segundos de "ringing".
480 significa "User Not Available" o bien "User Not Responding", etc.
Y desde luego es el código SIP adecuado cuando el operador dueño del
número llamado (o uno intermedio) decide terminar la llamada por
llevar demasiados segundos en "ringing" sin que nadie conteste.
- El Cisco hace la conversión de SIP a ISUP siguiendo el RFC 3398
sección 8.2.6.1:
480 Temporarily unavailable --> 18 No user responding
- El Cisco por lo tanto envía causa ISUP 18 al Asterisk por el primario.
- Asterisk mapea el código 18 a "FAILED" así que marca "FAILED" en el
disposition del cdr de esa llamada.
Este último punto es el que me gustaría confirmar con vosotros.
Por otra parte, el problema parece venir de una mala especificación
del RFC 3398 (mapping SIP/ISUP) ya que por una parte sugiere que:
480 Temporarily unavailable --> 18 No user responding
pero a la inversa hace otra cosa:
18 no user responding --> 408 Request Timeout
Un 408 y un 480 no tienen mucho que ver, de hecho 408 puede indicar
(no necesariamente) que la transacción IVITE ha fallado y no se ha
obtenido ninguna respuesta, lo que podría dar pie a interpretar dicha
llamada como "failed".
La solución que barajo es modificar el mapeo SIP->ISUP del Cisco y poner:
480 Temporarily unavailable --> 19 no answer from the user
EMHO tiene más sentido que usar un código 18, ya que de hecho el ISUP
19 se mapea a SIP 480 (sección 7.2.4.1):
19 no answer from the user --> 480 Temporarily unavailable
Gracias si alguien puede confirmarme (o desmentirme) el punto de arriba.
Saludos.
--
Iñaki Baz Castillo
<i...@aliax.net>
Gelo
Cisco.
Si te fijas, en el RFC no hay ninguna asignación SIP hacia un 19, pero
en la sección 7.2.8 "igualan" 480 SIP a 19 ISUP, así que tácitamente
te dan el derecho de hacerlo :)
Sobre si el 18 debe ser failed o no: dahdi te va a dar un 18 cuando
envíe un setup por el primario y el otro extremo (de la RDSI, tu Cisco
en este caso) no responda nada a tiempo, y esto en mi opinión es un
FAILED como una casa, ya que no sería un error extremo a extremo y por
tanto no puede ser ninguno de los otros.
Un saludo
Iñaki Baz Castillo
> Estoy de acuerdo contigo, la mejor solución es cambiar el mapeo del
> Cisco.
> Si te fijas, en el RFC no hay ninguna asignación SIP hacia un 19, pero
> en la sección 7.2.8 "igualan" 480 SIP a 19 ISUP, así que tácitamente
> te dan el derecho de hacerlo :)
Sí, de hecho sugería al cliente que mapeasen en su Cisco el 480 al 19
y "mágicamente" les ha desaparecido el problema :)
> Sobre si el 18 debe ser failed o no: dahdi te va a dar un 18 cuando
> envíe un setup por el primario y el otro extremo (de la RDSI, tu Cisco
> en este caso) no responda nada a tiempo, y esto en mi opinión es un
> FAILED como una casa, ya que no sería un error extremo a extremo y por
> tanto no puede ser ninguno de los otros.
Sí, me temía algo así ya que el código SIP 408 (mapeado a ISUP 18)
indica timeout, aunque no especifica si es de transacción o si es un
408 recibido desde el server (en cuyo caso no sería un "local"
timeout).
Otro problema que veo ahora es que hay algunos operadores (por ejemplo
Jazzlel y su bodrio de Nortel CS2K) que cuando reciben una llamada y
el destino no contesta en N segundos, el propio operador corta la
llamada emitiendo un SIP 478. En realidad el 487 sólo debería
generarse una vez el *cliente* ha enviado un CANCEL. Cuando el
operador termina la llamada por "ringing timeout" debería usar un 480.
Este 487 también genera problemas de mapping en el maldito Cisco. Por
lo que veo lo mapea a 16 "normal call clearing", que en el RFC 3398 no
aparece como código de mapping (porque no tiene sentido, ya que cuando
el lado PSTN emite un 16 el gateway SIP debería generar un 480).