Skip to content
Snippets Groups Projects
Commit 745f4edb authored by Terry Wilson's avatar Terry Wilson
Browse files

Merged revisions 274280 via svnmerge from

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r274280 | twilson | 2010-07-06 17:08:20 -0500 (Tue, 06 Jul 2010) | 9 lines
  
  Add option to not do a call forward on 482 Loop Detected
  
  Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
  This prevents handling the call failure by just continuing on in the dialplan.
  Since this would be a change in behavior, the new option to disable this
  behavior is forwardloopdetected which defaults to 'yes'.
  
  Review: https://reviewboard.asterisk.org/r/764/
........

(no option for trunk, just changing the behavior)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
parent 57549330
No related branches found
No related tags found
No related merge requests found
...@@ -92,6 +92,10 @@ From 1.6.2 to 1.8: ...@@ -92,6 +92,10 @@ From 1.6.2 to 1.8:
definition specifies those fields as float,double or similar they will now definition specifies those fields as float,double or similar they will now
be logged with microsecond accuracy instead of a whole integer. be logged with microsecond accuracy instead of a whole integer.
* chan_sip will no longer set up a local call forward when receiving a
482 Loop Detected response. The dialplan will just continue from where it
left off.
From 1.6.1 to 1.6.2: From 1.6.1 to 1.6.2:
* SIP no longer sends the 183 progress message for early media by * SIP no longer sends the 183 progress message for early media by
......
...@@ -19132,16 +19132,7 @@ static void handle_response(struct sip_pvt *p, int resp, const char *rest, struc ...@@ -19132,16 +19132,7 @@ static void handle_response(struct sip_pvt *p, int resp, const char *rest, struc
ast_queue_control(p->owner, AST_CONTROL_BUSY); ast_queue_control(p->owner, AST_CONTROL_BUSY);
} }
break; break;
case 482: /*! case 482: /* Loop Detected */
\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... */
ast_debug(1, "Hairpin detected, setting up call forward for what it's worth\n");
if (p->owner)
ast_string_field_build(p->owner, call_forward,
"Local/%s@%s", p->username, p->context);
/* Fall through */
case 480: /* Temporarily Unavailable */ case 480: /* Temporarily Unavailable */
case 404: /* Not Found */ case 404: /* Not Found */
case 410: /* Gone */ case 410: /* Gone */
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment