[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