[asterisk-dev] [Code Review] Allow transfer loops w/o allowing forwarding loops

Terry Wilson reviewboard at asterisk.org
Fri Apr 22 18:12:01 CDT 2011


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1195/
-----------------------------------------------------------

(Updated 2011-04-22 18:12:01.839052)


Review request for Asterisk Developers, Mark Michelson and David Vossel.


Changes
-------

Attempt to address mmichelson's review. Remove datastore removal from app_dial/app_queue and and remove both chan and peer from ast_bridge_call()


Summary
-------

We try to avoid the situation where two phones may be forwarded to each other causing an infinite loop by storing each dialed interface in a channel datastore and checking the list before dialing out. This works, but currently breaks situations like A calls B, A transfers B to C, B transfers C to A, and A transfers C to B. Since human interaction is happening here and not an automated forwarding loop, it should be allowed.

This patch removes the dialed_interfaces datastore when a call is bridged (a suggestion from the brilliant mmichelson). If a call is being bridged, it should be safe to assume that we aren't stuck in a loop.

I determined that it was "peer" and not "chan" where the datastore was stored by trial and error. No matter what I tried, "chan" never had the datastore. I will fully admit that the features code still confuses the hell out of me even after all of these years.

Note: This bug exists also up to 1.8 (probably trunk, I just haven't tried yet)


Diffs (updated)
-----

  /branches/1.4/apps/app_dial.c 314725 
  /branches/1.4/apps/app_queue.c 314725 
  /branches/1.4/res/res_features.c 314725 

Diff: https://reviewboard.asterisk.org/r/1195/diff


Testing
-------

I tried the above scenario and it now works. I also tried forwarding a couple of phones to each other and it still broke out of the loop.


Thanks,

Terry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110422/89f7f8f7/attachment.htm>


More information about the asterisk-dev mailing list