Hace unos años, en la época de Asterisk 1.2 en un sistema de un compañero empecé a ver unos mensajes de error bastante curiosos que se repetían continuamente en la consola CLI:
ERROR[6542] chan_zap.c: !! < Unknown IE 26 (cs5, len = 4)
Lo curioso es que este ensaje de error se repetía cada muy poco tiempo, así que un poco mosqueado, pese a que todo el sistema funcionaba correctamente, decidí investigar el porqué de este mensaje.
Tras hace un ‘pri intense debug span 1‘ durante varios minutos y revisar toda esa cantidad ingente de datos llegué al mensaje que provocaba el error:
< Informational frame: < SAPI: 00 C/R: 1 EA: 0 < TEI: 000 EA: 1 < N(S): 022 0: 0 < N(R): 061 P: 0 < 20 bytes of data Handling message for SAPI/TEI=0/0 -- ACKing all packets from 60 to (but not including) 61 -- Something left to transmit (61), restarting T200 counter < Protocol Discriminator: Q.931 (8) len=20 < Call Ref: len= 2 (reference 610/0x262) (Terminator) < Message type: INFORMATION (123) < [28 08 20 30 20 50 41 53 4f 53] < Display (len= 8) [ 0 PASOS ] < [95] < Locking Shift (len=01): Requested codeset 5 < [1a 02 c4 00] [Jun 5 11:52:03] ERROR[6542]: chan_zap.c:8248 zt_pri_error: !! < Unknown IE 26 (cs5, len = 4) -- Processing IE 40 (cs0, Display) -- Processing IE 26 (cs5, Unknown Information Element) !! Unknown IE 26 (cs5, Unknown Information Element) Sending Receiver Ready (23)
David Vossel
Por lo que me dí cuenta que ese error era simplemente la interpretación de un tipo de mensaje AOC (Advise of Charge) dentro del conjunto de mensajes ‘cs5‘ definidos como «Mensajes personalizados del Proveedor», por lo que estaba claro, un tipo de mensaje que envía el proveedor para informar los «pasos» o los «momentos en los que aumenta el coste de esa llamada» a fin de que el sistema pueda reconocerlo y sea capaz de mostrar el coste de la llamada en tiempo real (por ejemplo para una cabina de teléfono, un locutorio o cualquier otro caso).
Asterisk no lo reconocía como tal, así que rellené el ticket en issues.asterisk.org para comentar este mensaje y que, por lo menos dejase de aparecer como «mensaje de error«.
Pues me entero gracias a la lista Asterisk-DEV y a la web VentureVoIP que David Vossel está desarrollando el soporte de AOC para Asterisk de forma que sea capaz de entender y actuar en función de los mensajes que reciba del proveedor, por lo que David está interesado en encontrar a gente que necesite de este soporte para que pueda probar lo que lleva hecho y así que el soporte de esta característica sea lo más real, efectivo y útil posible.
Os dejo el mensaje que ha publicado:
Hello!
Good news for those of you who are interested in Advice Of Charge support in Asterisk, the AOC branches are ready for testing! Below are the locations of the LibPRI and Asterisk components of this feature.
Asterisk Branch: http://svn.digium.com/svn/asterisk/team/dvossel/generic_aoc
LibPRI Branch: http://svn.digium.com/svn/libpri/team/dvossel/aoc_send
A help document explaining how AOC works in Asterisk can be found in ‘docs/advice_of_charge.txt‘ within the root directory of the Asterisk checkout.
If you are interested in generating your own AOC using Asterisk, I am especially interested in how you imagine doing that. At the moment AOC-E and AOC-D can be generated via an AMI action (this is all documented in the help document), but we still haven’t decided on how we would like to expose AOC-S message generation. An AMI action is probably not a good option for AOC-S because AOC-S must be generated before call-setup takes place. I was thinking a dialplan function would be nice. This would allow the generation of the AOC-S message on the channel before calling the Dial app. Would that be useful to anyone? Is there anyone even interested in generating AOC-S? Any other suggestions are more than welcome!
We look forward to your feedback and any help you can offer to make this new feature set more useful!
David Vossel
Digium, Inc. | Software Developer, Open Source Software