Fix para casos en los que se detectaba loop en reinvites muy rápidos.
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.
*/
channels/chan_sip.c