[Home]

Summary:ASTERISK-11643: [patch] Asterisk returns 482 Loop Detected upon receiving re-invite
Reporter:Jeff Pyle (jpyle)Labels:
Date Opened:2008-03-14 11:45:48Date Closed:2009-05-14 17:24:08
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 12215_confirmed.patch
( 1) 12215_temporary_patch_debug.txt
( 2) 12215_temporary.patch
( 3) 482loopreinvite.txt
( 4) asterisk-1.4.19-app_dial-force-loop-misdetection.patch
( 5) asterisk-1.4.19-chan_sip-loop-detection-fix.patch
( 6) asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch
( 7) asterisk-1.4.19-chan_sip-loop-detection-fix-v3.patch
( 8) chan_sip.c.patch
( 9) debug1-482Loop.txt
(10) loop-detection-sip-debug.txt
(11) loopsipmsg.cpe
(12) loopsipmsg.cpe
(13) loopsipmsg.mg
(14) sip.conf
(15) ugnd_01_ms-realtime.txt
Description:Asterisk sends a 482 Loop Detected upon receiving a presumably valid re-INVITE.  Pedantic is enabled globally in sip.conf.

****** ADDITIONAL INFORMATION ******

There are two Asterisk boxes in this scenario, ms1 and sip1.  ms1 is a transcoding box running 1.4.18, and sip1 is a core routing switch running 1.2.26.  A CPE (ugnd_01_ms) sends a call into ms1.  ms1 sends it to sip1.  sip1 processes it and routes it to a PSTN gateway.  After the call connects, sip1 sends re-INVITEs to the PSTN gateway and to ms1 to get them to exchange RTP directly.  Normally ms1 responds normally with a 100, 200, gets an ACK, and all is well.  Some of the time ms1 responds with a 482 Loop Detected.

We recently upgraded ms1 from 1.2.26.2 to 1.4.18 to solve the known RFC2833 problems in 1.2.  After we did, this problem became apparent.

Most of our CPEs communicate directly with sip1, which completes over 40k calls a day.  Only the small percentage of users that require transcoding come through ms1 on their way to sip1.  None of the other CPEs sip1 talks to have problems with the re-INVITEs, which is further evidence it's something on the ms1 side.
Comments:By: Jeff Pyle (jpyle) 2008-03-14 11:49:48

One more detail:  This occurs on calls from CPE through ms1 to sip1 only (outbound).  Calls from sip1 through ms1 to CPE are unaffected (inbound), although sip1-side re-INVITES still occur on every call.  ms1 is the 1.4.18 box exhibiting this problem.


By: Jeff Pyle (jpyle) 2008-03-14 12:47:35

I tried SVN-trunk-r108738.  Same problem.
By: Joshua C. Colp (jcolp) 2008-03-17 10:59:56

Is pedantic required in your environment? If you turn it off does this issue go away?
By: Jeff Pyle (jpyle) 2008-03-17 11:13:06

I don't know that pedantic is "required", but anytime calls have the potential of looping back to the same machine they started from, my thinking was that it was good idea to have it enabled.

In another 1.4 install, probably around the time of 1.4.14 or so, I also had a problem where 482s were returned.  I didn't have time to do thorough debugging then; I just returned to 1.2.  In that case, pedantic was not enabled when we noticed the problem.  Turning it on decreased the frequency dramatically of the 482s.

I've had to revert to 1.2.26.2 to alleviate this problem.  As soon as possible (perhaps as soon as tonight) I'll reload 1.4.18 and try pedantic=no.

Does anything in the debug immediately stand out to you?  My uneducated eyes weren't able to find anything particularly obvious.
By: Remi Quezada (remiq) 2008-03-19 08:39:07

I experienced this same issue when I upgraded to 1.4.17 and pedantic was turned off in my environment.
By: Jeff Pyle (jpyle) 2008-03-27 19:04:31

ping.  Almost done clearing the calendar so I can dedicate the time I'd like to this issue.
By: Jeff Pyle (jpyle) 2008-04-03 20:55:41

I can now conclusively declare that it happens with pedantic=no as well.  I've upgraded to 1.4.19 -- no effect.

I now have as much time as required to put towards this issue.  Where to from here?
By: Jeff Pyle (jpyle) 2008-04-14 18:22:47

For me, at least, this is preventing me from upgrading some core servers from 1.2 to 1.4.  I've looked at chan_sip.c where the 482s are generated, but at my coding skill level I wasn't able to glean anything.  If there's anything I can do from the testing/troubleshooting perspective, I'm all for it.  Thanks.
By: Jeff Pyle (jpyle) 2008-04-24 09:12:39

Any thoughts?  We're going on 6 weeks now with virtually no activity.
By: Remi Quezada (remiq) 2008-05-30 16:03:11

I tried 1.4.20.1 and it is still detecting loop when receiving a reinvite.
By: Raj Jain (rjain) 2008-06-01 05:25:53

The INVITE-482 is not the actual problem here. The root of the problem here is that the initial call through 63.216.250.91 is not being set up correctly. The 200 OK from 63.216.250.82 is not being propagated by 63.216.250.91 to 66.61.7.219. Is this how the dial-plan has been programmed to work?

Since the call doesn't set up correctly, Asterisk doesn't mark the outbound channel 'UP'. And thus when it receives a RE-INVITE on the outbound leg from 63.216.250.82, it sends back a 482. While 482 is not an appropriate response code for this situation, the problem here really is to get the initial call to setup properly.
By: Remi Quezada (remiq) 2008-06-02 08:38:52

I uploaded two sip debug messages.  One from the mg server which is connected to the PSTN and one from cpe which is the phone.  I don't see any sip messages that aren't getting setup properly.  Its looks like the OK is propagating properly through each of the servers.  Maybe I am not understading what you meant in your last post.  Do you see this problem in my sip debug messages?
By: Remi Quezada (remiq) 2008-06-03 08:49:06

The problem started after this bug fix:

Revision 88826 - Directory Listing
Modified Mon Nov 5 23:29:29 2007 UTC (6 months, 4 weeks ago) by mmichelson
Reworked deadlock avoidance in __ast_read. Restored audio to
callback agents.

(closes issue ASTERISK-10606, reported by callguy, patched by me, tested by callguy and Ted Brown)

Once I reverted those changes I was not able to reproduce the issue.
By: Jeff Pyle (jpyle) 2008-06-03 09:21:05

remiq, great news!  I've love to test as well.  It wasn't so long ago I learned how to apply a patch; could you point me in the right direction to revert one?
By: Remi Quezada (remiq) 2008-06-03 09:37:04

Here the link to the patch that was applied that caused this bug:

http://svn.digium.com/view/asterisk/branches/1.4/main/channel.c?view=patch&r1=88826&r2=88825&pathrev=88826

I would just revert those changes.
By: Remi Quezada (remiq) 2008-06-03 14:21:27

I am still getting 482 loop but far less than before.  I'd say it improved 95%, before I was getting it for almost every call.  Looks like there is something else that is causing this.  Will post debug messages later.
By: Remi Quezada (remiq) 2008-06-06 09:02:53

Rjain was right about Asterisk not marking the channel UP after the 200 OK.  Asterisk usually marks the channel UP after it sends the ACK, but that is not happening.  Does anyone know what could possibly cause Asterisk not to mark the channel UP once it receive the 200 OK?  Do you guys think the channel is not getting locked and that is why it is handling the re-invite without the channel getting marked UP thus detecing a loop?  If so where should this change be?
By: Remi Quezada (remiq) 2008-06-10 11:43:42

Uploaded patch which fixes this isssue.  There was a race condition where channel was not getting marked UP when asterisk received a 200 OK.
By: Raj Jain (rjain) 2008-06-10 12:29:20

I don't see the patch file in the list of files attached to this bug report.
By: Jared Smith (jsmith) 2008-06-10 12:58:49

rjain,

It's looks like remiq's license agreement is still pending, which is why his patch doesn't show up.  This usually takes a day or two to get approved.
By: Remi Quezada (remiq) 2008-06-25 08:33:00

Ran the patch for more than a week with no problems on 3 production servers.
By: Olle Johansson (oej) 2008-06-26 11:14:00

From looking at it briefly, the patch seems dangerous and seems to be a traditioinal patch - meaning it doesn't really solve the issue, but fixes the symptom... :-)

I feel we need to dig deeper into this.
By: Michael Neuhauser (mneuhauser) 2008-08-28 11:00:27

oej is right, the patch is not fully 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 ...

@oej: 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


By: Michael Neuhauser (mneuhauser) 2008-08-28 11:45:22

I've attached asterisk-1.4.19-chan_sip-loop-detection-fix.patch that implements the fix(?) outlined above. While going through chan_sip, I've seen a lot of checks for p->owner->_state ==/!= AST_STATE_UP -- I've got a feeling that at least some of these could have similar problems as the loop check, maybe they should check the new flag instead of the _state


By: Michael Neuhauser (mneuhauser) 2008-09-15 08:48:30

I've uploaded asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch which is an improved version of asterisk-1.4.19-chan_sip-loop-detection-fix.patch - I now combine the old _state-based criterion with the new got-OK-for-invite flag and the flag is also set in the re-invite case.
By: Remi Quezada (remiq) 2008-11-14 07:41:16.000-0600

That patch doesn't work too well I remember doing that initially and it caused some problems.  One problem is that when the far end hangs up the call, the call doesn't hangup in Asterisk.  Another one is that you stop getting sip debug messages after the call gets picked up.


By: Michael Neuhauser (mneuhauser) 2008-11-14 07:48:20.000-0600

>remiq
Are you talking about asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch? Because I have encountered none of the problems you describe.
By: Remi Quezada (remiq) 2008-11-14 08:07:29.000-0600

yeah... if the call re-invites and the CDN hangs up, it does not hang up in Asterisk.  Asterisk does show that the call was answered but I don't see any SIP debug messages.  I attached my debug so you can see what I am talking about.
By: Michael Neuhauser (mneuhauser) 2008-11-14 08:33:06.000-0600

Sorry, but I can see nothing suspicious in that trace. Anyhow, the changes in my patch can not be responsible for the behaviour you see: the only thing it CAN do wrong, is to not detect an actual loop (look at the code, it just adds one &&-clause to the if condition for the loop-detected case).

But it could be that another timing sensitive bug is exposed by fixing the loop-detection problem (in the original Asterisk, it would have been mis-detected as a loop and the new bug would not have had a chance to manifest itself).
By: Remi Quezada (remiq) 2008-11-14 09:06:46.000-0600

You could be right it could expose a bug, but what is wrong with that trace is that the far end hung up the call and asterisk still shows the channel up.  Also, the fact that you never see the 200 OK when the call gets answered in the logs.  Asterisk clearly answered the call and re-invited properly I verified that, but the logs don't show that at all.  All I see is this:

<------------>    -- SIP/fsa-fsdev-0a1d7da8 answered Zap/1-1

No SIP debug message showing 200 OK or even the re-INVITE.  And like I said before even when the far end hangs up nothing happens, the calling party has to hang up in order for asterisk to hang the call up.  So something is getting messed up.  I think more code has to be written when the channel is not marked UP and when asterisk is processing a re-INVITE because the call is not getting setup properly with the patch you are proposing.
By: Michael Neuhauser (mneuhauser) 2008-11-18 11:02:15.000-0600

You are right, asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch has some serious problems.

I have now found a way to reliable trigger the loop detection in a re-INVITE situation (asterisk-1.4.19-app_dial-force-loop-misdetection.patch). With this I was able to verify that just accepting the re-INVITE, even if the channel is not UP (i.e. what asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch does), is not the way to go. I didn't see the same behaviour as in your case, but it was definitely not OK (e.g., channel never went away).

Without changing the way OK/AST_CONTROL_ANSWER is handled completely, I can only think of two things to do in chan_sip's handle_request_invite() if a re-INVITE is received but the channel is not UP:
1) clean(?): decline re-invite with "488 Not acceptable here"; the call
  will continue with an unchanged RTP-path, but at least it will not be
  terminated
2) hack: just ignore the re-INVITE request and hope that the other side
  retransmits the request and that our channel is UP when the re-transmitted
  packet is received by us; this allows the re-INVITE to happen, if everything
  goes like expected. The problems with this approach:
  * we do something that is not 100% SIP-RFC conform
  * requests are not ignored anywhere else in chan_sip (at least to
    my knowledge) and so I did not have a template of how to do it, so there
    could be side effects that I have missed
  * I haven't tested what happens if the other side does NOT retransmit its
    re-INVITE, but Asterisk should already be able to handle this (connectivity
    to a SIP UA can be lost any time ...)
  * 1.6 outlook: I do not know if re-INVITES are re-transmitted if TCP
    transport is used

The new asterisk-1.4.19-chan_sip-loop-detection-fix-v3.patch patch implements
Method 2. I've tested it with the aid of asterisk-1.4.19-app_dial-force-loop-misdetection.patch and had no problems (re-invite works, no hung channels). Would be great if you could give it a try.
By: Leif Madsen (lmadsen) 2009-02-02 15:39:10.000-0600

Pinging this issue as it looked like it was starting to come to a conclusion. Anyone able to move this forward?
By: Michael Neuhauser (mneuhauser) 2009-02-25 07:28:49.000-0600

I just wanted to add, that asterisk-1.4.19-chan_sip-loop-detection-fix-v3.patch is working for me and has not shown any negative effects in over 3 month of usage on various servers (used as PBX, some pure SIP, some ISDN/SIP) and one embedded device (used as an ISDN/SIP gateway).
By: Leif Madsen (lmadsen) 2009-02-25 11:40:58.000-0600

I'm going to mark this ready for review, in order to maybe get it onto reviewboard.

jpyle: sine you are the original reporter, do you have any interest in getting this latest patch tested?
By: Mark Michelson (mmichelson) 2009-03-03 12:26:11.000-0600

I would have put some comments on this soon after it was assigned to me, but I came down with the flu and didn't get a chance to comment on this until now. After reading through things a bit here, I have a couple of comments.

First of all, the new flag used in the patches, SIP_PAGE2_GOT_OK_FOR_INVITE, can probably be done away with. The invitestate variable on the sip_pvt could probably be used for this. Specifically, checking if p->invitestate is INV_TERMINATED should do the trick there.

Looking through the patch history, what *seems* like the most correct way to do things is similar to asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch. The comments indicate that that particular patch caused problems such as the channel never going away, but the idea of why that happened wasn't explored too heavily. Based on the trace that remiq uploaded, my guess is that Asterisk is not properly detecting this re-INVITE as a re-INVITE and instead thinks that there is a new dialog being started.

I'm going to take a closer look at handle_request_invite to see if I can find why this may be happening.
By: Mark Michelson (mmichelson) 2009-03-03 12:32:02.000-0600

Well, taking a quick look at things a bit further down in handle_request_invite, there is a large switch statement which uses the channel's state as a means to gauge what action to take. My guess is that since the re-INVITE is being handled while the channel is still in the AST_STATE_RINGING state, we send back a 180 Ringing response instead of actually doing what we should with a re-INVITE.

More updates will come from me as I make more discoveries.
By: Mark Michelson (mmichelson) 2009-03-03 14:29:54.000-0600

I've uploaded a patch called 12215_temporary.patch. This patch takes the basic idea behind asterisk-1.4.19-chan_sip-loop-detection-fix-v2.patch but also adds some amended logic later in handle_request_invite to make sure that we actually process the reinvite correctly if the channel is still in the AST_STATE_RINGING state.

This, specifically, should make remiq's failed test work properly. The reason I've placed the word "temporary" in the patch's name is that there may need to be other cases in the switch statement that are handled differently depending on the invitestate. This specific patch will handle the case of receiving a re-INVITE on an outbound call before the channel's state has been changed to UP.

Please test this if possible and let me know if this is a move in the right direction. Thanks!
By: Remi Quezada (remiq) 2009-03-10 10:31:20

mmichelson,

I tested your patch and I found that when Media Gateway receives the re-invite it immediately sends a BYE message which causes the call to disconnect.
By: Mark Michelson (mmichelson) 2009-03-11 13:08:44

Thanks for the update remiq. I think what I'm going to have to do here is to set up a sipp scenario to imitate the conditions instead of trying to write more patches for others to test. When I have something that is working for me, I'll upload my changes here.
By: Mark Michelson (mmichelson) 2009-05-13 14:35:46

After working on other issues/projects for a while, I finally came back to this one. I have labbed this up and can reproduce the issue fairly easily. The last patch I uploaded was mostly correct but did not quite get the job done. I have now uploaded 12215_confirmed.patch which, in my tests anyway, fixes this issue completely. The patch was made against the current tip of the 1.4 branch.

On a side note, I sometimes have an issue with one-way audio when passing calls through multiple Asterisk boxes, but that is a separate issue and was occurring even without this patch applied.
By: Leif Madsen (lmadsen) 2009-05-14 13:44:44

Seems to work for me! I could reproduce about 1-2 times per 10 calls, and after patching and testing with about 30+ calls, I have not seen the issue happen at all.

I am also seeing the audio issues that Mark is talking about, but that is a separate issue as he stated. I was also getting it prior to the patch. Do we need to open a new issue for that?

Ship it!
By: Leif Madsen (lmadsen) 2009-05-14 16:26:18

Assigned back to mmichelson for review and commit.
By: Digium Subversion (svnbot) 2009-05-14 17:18:03

Repository: asterisk
Revision: 194484

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r194484 | mmichelson | 2009-05-14 17:18:02 -0500 (Thu, 14 May 2009) | 24 lines

Fix a race condition where a reinvite could trigger a 482 response.

The loop detection/spiral detection code in chan_sip used the owner
channel's state as a criterion for determining if the incoming INVITE
is a looped request. The problem with this is that the INVITE-handling
code happens in a different thread than the thread that marks the owner
channel as being up. As a result, if a reinvite were to come in very quickly,
say from another Asterisk on the same LAN, it was possible for the reinvite
to arrive before the owner channel had been set to the up state.

This patch corrects the problem by using the invitestate of the sip_pvt
instead, since that can be guaranteed to be set correctly by the time
the reinvite arrives. Since there is a switch statement further in the
INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
of the sip_pvt in case we should actually be treating the channel as if it were
up already.

(closes issue ASTERISK-11643)
Reported by: jpyle
Patches:
     12215_confirmed.patch uploaded by mmichelson (license 60)
Tested by: lmadsen


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194484
By: Digium Subversion (svnbot) 2009-05-14 17:20:58

Repository: asterisk
Revision: 194496

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r194496 | mmichelson | 2009-05-14 17:20:58 -0500 (Thu, 14 May 2009) | 30 lines

Merged revisions 194484 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines
 
 Fix a race condition where a reinvite could trigger a 482 response.
 
 The loop detection/spiral detection code in chan_sip used the owner
 channel's state as a criterion for determining if the incoming INVITE
 is a looped request. The problem with this is that the INVITE-handling
 code happens in a different thread than the thread that marks the owner
 channel as being up. As a result, if a reinvite were to come in very quickly,
 say from another Asterisk on the same LAN, it was possible for the reinvite
 to arrive before the owner channel had been set to the up state.
 
 This patch corrects the problem by using the invitestate of the sip_pvt
 instead, since that can be guaranteed to be set correctly by the time
 the reinvite arrives. Since there is a switch statement further in the
 INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
 of the sip_pvt in case we should actually be treating the channel as if it were
 up already.
 
 (closes issue ASTERISK-11643)
 Reported by: jpyle
 Patches:
       12215_confirmed.patch uploaded by mmichelson (license 60)
 Tested by: lmadsen
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194496
By: Digium Subversion (svnbot) 2009-05-14 17:22:52

Repository: asterisk
Revision: 194504

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r194504 | mmichelson | 2009-05-14 17:22:52 -0500 (Thu, 14 May 2009) | 37 lines

Merged revisions 194496 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r194496 | mmichelson | 2009-05-14 17:20:51 -0500 (Thu, 14 May 2009) | 30 lines
 
 Merged revisions 194484 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines
   
   Fix a race condition where a reinvite could trigger a 482 response.
   
   The loop detection/spiral detection code in chan_sip used the owner
   channel's state as a criterion for determining if the incoming INVITE
   is a looped request. The problem with this is that the INVITE-handling
   code happens in a different thread than the thread that marks the owner
   channel as being up. As a result, if a reinvite were to come in very quickly,
   say from another Asterisk on the same LAN, it was possible for the reinvite
   to arrive before the owner channel had been set to the up state.
   
   This patch corrects the problem by using the invitestate of the sip_pvt
   instead, since that can be guaranteed to be set correctly by the time
   the reinvite arrives. Since there is a switch statement further in the
   INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
   of the sip_pvt in case we should actually be treating the channel as if it were
   up already.
   
   (closes issue ASTERISK-11643)
   Reported by: jpyle
   Patches:
         12215_confirmed.patch uploaded by mmichelson (license 60)
   Tested by: lmadsen
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194504
By: Digium Subversion (svnbot) 2009-05-14 17:23:29

Repository: asterisk
Revision: 194507

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r194507 | mmichelson | 2009-05-14 17:23:28 -0500 (Thu, 14 May 2009) | 37 lines

Merged revisions 194496 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r194496 | mmichelson | 2009-05-14 17:20:51 -0500 (Thu, 14 May 2009) | 30 lines
 
 Merged revisions 194484 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines
   
   Fix a race condition where a reinvite could trigger a 482 response.
   
   The loop detection/spiral detection code in chan_sip used the owner
   channel's state as a criterion for determining if the incoming INVITE
   is a looped request. The problem with this is that the INVITE-handling
   code happens in a different thread than the thread that marks the owner
   channel as being up. As a result, if a reinvite were to come in very quickly,
   say from another Asterisk on the same LAN, it was possible for the reinvite
   to arrive before the owner channel had been set to the up state.
   
   This patch corrects the problem by using the invitestate of the sip_pvt
   instead, since that can be guaranteed to be set correctly by the time
   the reinvite arrives. Since there is a switch statement further in the
   INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
   of the sip_pvt in case we should actually be treating the channel as if it were
   up already.
   
   (closes issue ASTERISK-11643)
   Reported by: jpyle
   Patches:
         12215_confirmed.patch uploaded by mmichelson (license 60)
   Tested by: lmadsen
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194507
By: Digium Subversion (svnbot) 2009-05-14 17:24:05

Repository: asterisk
Revision: 194510

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r194510 | mmichelson | 2009-05-14 17:24:05 -0500 (Thu, 14 May 2009) | 37 lines

Merged revisions 194496 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r194496 | mmichelson | 2009-05-14 17:20:51 -0500 (Thu, 14 May 2009) | 30 lines
 
 Merged revisions 194484 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines
   
   Fix a race condition where a reinvite could trigger a 482 response.
   
   The loop detection/spiral detection code in chan_sip used the owner
   channel's state as a criterion for determining if the incoming INVITE
   is a looped request. The problem with this is that the INVITE-handling
   code happens in a different thread than the thread that marks the owner
   channel as being up. As a result, if a reinvite were to come in very quickly,
   say from another Asterisk on the same LAN, it was possible for the reinvite
   to arrive before the owner channel had been set to the up state.
   
   This patch corrects the problem by using the invitestate of the sip_pvt
   instead, since that can be guaranteed to be set correctly by the time
   the reinvite arrives. Since there is a switch statement further in the
   INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
   of the sip_pvt in case we should actually be treating the channel as if it were
   up already.
   
   (closes issue ASTERISK-11643)
   Reported by: jpyle
   Patches:
         12215_confirmed.patch uploaded by mmichelson (license 60)
   Tested by: lmadsen
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194510