Aún recuerdo en uno de los primeros VoIP2DAY celebrados en Madrid, aprovechando que venía el jefe de desarrollo de Asterisk en aquel momento (Kevin P. Flemming), se hizo una mesa redonda donde usuarios de Asterisk pudieran plantear sus preguntas sobre Asterisk y debatir sobre cualquier tema de VoIP, prácticamente TODAS las preguntas que se hicieron fueron sobre lo mal que funcionaba el módulo chan_sip y lo necesario que era que mejorase urgentemente para todos los que estábamos allí presentes.
Ahí se plantearon soluciones como utilizar sistemas de test propios de Asterisk que permitiera verificar el código en lugar de subir nuevas versiones con fallos que ya se habían corregido, se vieron características muy importantes en España que apenas se utilizan en otros países, y se planteó que podría ser muy interesante utilizar un stack propio separado de Asterisk para llevar el SIP y que pudiera evolucionar y cambiar sin que tuviera que actualizar todo Asterisk.
Quizá fuera algo planteado previamente o que sirvió para apoyar una necesidad común, pero sea como fuere, a partir de ahí se empezó a mover el tema de que Asterisk necesitaba cambiar de stack SIP de chan_sip a otro que pudiera crecer y corregir los problemas básicos de Asterisk.
Puede que desde ese día, la preocupación por el sistema que gestiona las peticiones SIP se tuvieron bastante más en consideración y se preocuparon por solucionar grandes problemas que aparecieron y que afectaban a la estabilidad de un gran número de Asterisk 1.4. Razón por la cual, la gente de Irontec empezó a congelar una versión de Asterisk que se conoció como Asterisk-ES-RSP (Rock Solid Patchset).
Desde entonces se han hecho muchos cambios en chan_SIP y quizá desde entonces este stack ha ido mejorando todo lo posible, donde «todo lo posible» ha sido pese a sus limitaciones.
Tales han sido las limitaciones que Asterisk 12 ya empezó a incluir un nuevo stack basado en PJSIP, un stack SIP bastante robusto, que funciona por sí solo en multitud de aplicaciones (softphones, servidores, etc.) y que sería incorporado a Asterisk como un componente externo gracias a una colaboración entre los desarrolladores de PJProject (el proyecto del que sale PJSIP) y Asterisk.
Cada nueva versión de Asterisk ha aumentado la integración de PJSIP y disminuida la de chan_sip, hasta que Asterisk 16 ya incluía chan_pjsip como nuevo stack SIP por defecto y chan_sip pasaba a estar obsoleto («deprecated»), y no será hasta el próximo Asterisk 21 cuando realmente desaparezca chan_sip y sólo quede chan_pjsip.
PJSIP es sólo un poco más complejo que chan_sip, básicamente porque permite más cosas, es más flexible, más completo y elimina las restricciones nativas que traía chan_sip y que, para muchos, es algo intrínseco a SIP como por ejemplo, como me dijo hace poco un usuario:
«SIP no permite más de un registro simultaneo»
A lo que rápidamente tuve que saltar y corregirle indicándole que es chan_sip quien no permite más de un registro simultaneo… cualquier otra aplicación SIP soporta tantos registros como deseemos. Y es que la gente está tan acostumbrada a los sistemas Asterisk y a lo que se permite o no en Asterisk que no repara en lo que se permite o no en SIP y que Asterisk con chan_sip limita algunas cosas.
Aún así, la facilidad de chan_sip ha hecho que Asterisk llegue a prácticamente cualquier usuario y que pueda instalar, configurar y modificar una centralita de telefonía sin necesidad de saber de SIP, ni de dialplans, ni de telefonía. 😉