[asterisk-bugs] [Asterisk 0012215]: Asterisk returns 482 Loop Detected upon receiving re-invite

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12215 
====================================================================== 
Reported By:                jpyle
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12215
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-03-14 11:45 CDT
Last Modified:              2008-08-28 11:00 CDT
====================================================================== 
Summary:                    Asterisk returns 482 Loop Detected upon receiving
re-invite
Description: 
Asterisk sends a 482 Loop Detected upon receiving a presumably valid
re-INVITE.  Pedantic is enabled globally in sip.conf.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0007403 [patch] allow SIP Spiral to work instea...
====================================================================== 

---------------------------------------------------------------------- 
 (0091871) mneuhauser (reporter) - 2008-08-28 11:00
 http://bugs.digium.com/view.php?id=12215#c91871 
---------------------------------------------------------------------- 
oje is right, the patch is not correct. Oh, and this is NOT a duplicate of
bug 7403 (as one can see from the analysis below this happens in
non-spiraling situations).

The problem is, that the channel has to be answered by queueing a
AST_CONTROL_ASNWER frame on the channel. The state is only changed in
__ast_read() when somebody is reading this control frame from the channel.
The Re-INVITE is handled directly by chan_sip and so it can happen that the
channel is not UP yet although the OK was received before the Re-INVITE.
Doing aast_setstate() instead of ast_queue_control() (as in the patch) is
not the corrrect fix: __ast_read() only changes the state of outgoing
channels and does CDR handling too, but even if all this would be done in
chan_sip too, it still is much too dangerous to not send this answer frame
(other frames that need to be handled before could already be queued!)

I think the information that the OK was received needs to be stored in the
sip_pvt struct (SIP_PAGE2_GOT_OK_FOR_INVITE?) and checking this flag in 
handle_request_invite() instead of checking the owner's state. Like this:

static int handle_request_invite(...) {
    ...
    /* Check if this is a loop */
    if (ast_test_flag(&p->flags[0], SIP_OUTGOING)
        && !ast_test_flag(&p->flags[1], SIP_PAGE2_GOT_OK_FOR_INVITE) ) {
       ...

static void handle_response_invite(...) {
    ...
    case 200:
        ...
	if (!ast_test_flag(req, SIP_PKT_IGNORE) && p->owner) {
			if (!reinvite) {
                                ast_set_flag(&p->flags[1],
                                    SIP_PAGE2_GOT_OK_FOR_INVITE);
				ast_queue_control(p->owner, AST_CONTROL_ANSWER);
			} else {	/* RE-invite */
                              ...

I will implement this and upload a patch (for 1.4.19). It seems to me,
that using the Asterisk channel state is unsafe anyway: what if an
unanswered channel is masqueraded into an answered one? Although no 200 OK
was received, the channel is UP ...

@oje: maybe you could ponder briefly the solution outlined above and tell
me if I'm on the right track regarding the use of SIP flags -thanks 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-28 11:00 mneuhauser     Note Added: 0091871                          
======================================================================