====== SIP loop ======

===== Descripción =====

=== Resumen ===

Fix para casos en los que se detectaba loop en reinvites muy rápidos. 

=== Características ===

        if (reinvite && (p->invitestate == INV_TERMINATED || p->invitestate == INV_CONFIRMED)) {
        /* If these conditions are true, and the channel is still in the 'ringing'
         * state, then this likely means that we have a situation where the initial
         * INVITE transaction has completed *but* the channel's state has not yet been
         * changed to UP. The reason this could happen is if the reinvite is received
         * on the SIP socket prior to an application calling ast_read on this channel
         * to read the answer frame we earlier queued on it. In this case, the reinvite
         * is completely legitimate so we need to handle this the same as if the channel
         * were already UP. Thus we are purposely falling through to the AST_STATE_UP case.
         */

===== Estructura =====

=== Ruta / Archivo ===

channels/chan_sip.c

=== Funciones ===

===== Modificaciones Configuración =====

=== Aplicación modificada ===

=== Archivos configuración ===

===== Enlaces interés =====

  * Parches rsp: Enlace al parche [[http://asterisk-es-rsp.irontec.com/svn/branches/asterisk/1.4.24/rsp-patches/chan_sip_loop_12215.patch| chan_sip_loop_12215]]
  * BUGS: [[bug:Bug 12215]]
  * Discusiones:
  * Índice parches: [[patch:]]