[asterisk-dev] [Code Review] Don't set up a call forward when receiving a 482 Loop Detected

Olle E. Johansson oej at edvina.net
Wed Jul 7 03:11:34 CDT 2010


> 
> I have noticed an issue where if we make an outbound SIP call which is responded to with a 482 Loop Detected, instead of failing the call and letting the dialplan handle the error, we instead set chan->call_forward to a Local channel at the callers context with the extension that they were dialing. I can't think of a reason why we would want to do this. It makes it impossible to handle the error in any meaningful way. It appears Asterisk has done this since r3662:
> 
> $ svn log -r 3662
> ------------------------------------------------------------------------
> r3662 | markster | 2004-08-26 20:16:16 -0700 (Thu, 26 Aug 2004) | 2 lines
> 
> When detecting a hairpin, redirect to the appropriate local extension (bug #1974)
> 
> 
> (bug #1974 doesn't seem to be related, btw)
> 
> The code also has the note:
>                   /* \note SIP is incapable of performing a hairpin call, which
>                   is yet another failure of not having a layer 2 (again, YAY
>                    IETF for thinking ahead).  So we treat this as a call
>                    forward and hope we end up at the right place... */
> 
> which is clearly incorrect as RFC 3261 talks about how to handle spiralin, but if a *loop* (not a spiral) is detected by the destination, it is an error condition and I think should be treated as such. It is always "fun" changing behavior that "has always been there" but in my opinion this is just clearly wrong behavior.
> 
> This patch for 1.4 adds the sip option forwardloopdetected which defaults to yes (the old behavior). For trunk, I would just delete the existing behavior.
> 

Terry,
A big thank you for fixing this!

We should propably also look into the handling of 302's which in some cases can bybass the dialplan, which is a serious violation of the Asterisk architecture.

Greetings from Malaga, Spain!

/O




More information about the asterisk-dev mailing list