8 thoughts on - Forward Loop Protection…

• Right after you have read the number to call forward to, compare it to the number you are call forwarding from. If it matches, play the user an error message and have them try again.

  And no matter what you do, the dumb people will come up with more creative ways to tank your phone system. A large amount of my dialplan code is taking into account the stupid things they have done and handling it properly if they do it again. I swear, if you could harness their creativity for good you could solve the world’s problems 10 times over.

• From: asterisk-users-bounces@lists.digium.com
  [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Kevin Larsen Sent: Tuesday, June 2, 2015 4:09 PM
  To: Asterisk Users Mailing List – Non-Commercial Discussion Subject: Re: [asterisk-users] Forward loop protection…

  Right after you have read the number to call forward to, compare it to the number you are call forwarding from. If it matches, play the user an error message and have them try again.

  And no matter what you do, the dumb people will come up with more creative ways to tank your phone system. A large amount of my dialplan code is taking into account the stupid things they have done and handling it properly if they do it again. I swear, if you could harness their creativity for good you could solve the world’s problems 10 times over.

  The loop checking is a bit more challenging than that. If Bob forwards to Fred and Fred forwards to Sue, all is well when Bob and Fred head out for a beer. A little later, we

• Could this possibly mean that any person who has CF set should never be available as CF Destination. Simple db entry/check can have this done.

• Pj4gVGhlIGxvb3AgY2hlY2tpbmcgaXMgYSBiaXQgbW9yZSBjaGFsbGVuZ2luZyB0aGFuIHRoYXQu IElmIEJvYiANCj4+IGZvcndhcmRzIHRvIEZyZWQgYW5kIEZyZWQgZm9yd2FyZHMgdG8gU3VlLCBh bGwgaXMgd2VsbCB3aGVuIEJvYiBhbmQgDQo+PiBGcmVkIGhlYWQgb3V0IGZvciBhIGJlZXIuIEEg bGl0dGxlIGxhdGVyLCB3ZeKAmXJlIGluIGRlZXAgZG9vLWRvMCB3aGVuDQo+PiBTdWUgZm9yd2Fy ZHMgdG8gQm9iLiANCg0KPiBDb3VsZCB0aGlzIHBvc3NpYmx5IG1lYW4gdGhhdCBhbnkgcGVyc29u IHdobyBoYXMgQ0Ygc2V0IHNob3VsZCBuZXZlcg0KPiBiZSBhdmFpbGFibGUgYXMgQ0YgRGVzdGlu YXRpb24uIFNpbXBsZSBkYiBlbnRyeS9jaGVjayBjYW4gaGF2ZSB0aGlzIA0KZG9uZS4NCg0KVGhh dCBqdXN0IGdvZXMgdG8gc2hvdyB0aGF0IHRoZSBwcm9ibGVtIGNhbiBnZXQgY29tcGxleCBwcmV0
  dHkgcXVpY2tseS4gDQpVc2luZyB0aGUgb3JpZ2luYWwgZXhhbXBsZSBhYm92ZSwgaXQgbWlnaHQg YmUgdGhhdCB5b3Ugd2FudCB0byBhbGxvdyB0aGUgDQpCb2IgdG8gRnJlZCB0byBTdWUgZm9yd2Fy ZHMsIGJ1dCBvbmx5IHN0b3AgaXQgaWYgdGhlIFN1ZSB0byBCb2IgbGluayBpcyANCmVzdGFibGlz aGVkLCB0aHVzIGNyZWF0aW5nIHRoZSBsb29wLiBJIHdvbmRlciBpZiB5b3UgY291bGQgZG8gc29t ZSBraW5kIG9mIA0KcmVjdXJzaXZlIGNoZWNrIHdoZXJlIHlvdSBmb2xsb3cgZWFjaCBmb3J3YXJk IGFuZCBpZiB5b3UgZXZlciBjb21lIGJhY2sgDQphcm91bmQgdG8gYSBudW1iZXIgeW91IGhhdmUg YWxyZWFkeSBjaGVja2VkIHlvdSBrbm93IHRoZXJlIGlzIGEgbG9vcC4NCg0KVG8gcmV1c2UgdGhl IGV4YW1wbGUgYWJvdmUsIG9uIHRoZSBjcmVhdGlvbiBvZiB0aGUgQm9iIHRvIEZyZWQgZm9yd2Fy ZCwgDQp0aGUgZGF0YWJhc2UgaXMgY2hlY2tlZCB0byBzZWUgaWYgRnJlZCBoYXMgYW55IGZvcndh cmRzLiBIZSBkb2Vzbid0LCBzbyBpcyANCmF0IHRoZSBlbmQgb2YgdGhlIGZvcndhcmRpbmcgY2hh aW4uIE5vdyBGcmVkIGZvcndhcmRzIHRvIFN1ZS4gQWdhaW4sIHNoZSANCmlzIGF0IHRoZSBlbmQg b2YgdGhlIGNoYWluLCBzbyBpdCBpcyBhbGxvd2VkLiBXaGVuIFN1ZSBnb2VzIHRvIGZvcndhcmQg dG8gDQpCb2IsIHRoZSBjaGVjayBzaG93cyB0aGF0IEJvYiBoYXMgYSBmb3J3YXJkLiBOb3QgYSBw cm9ibGVtLCBidXQgd2UgY3JlYXRlIA0KYSB0ZW1wb3JhcnkgbGlzdCB0aGF0IGhhcyBTdWUncyBu dW1iZXIgaW4gaXQuIFRoZW4gd2UgY2hlY2sgdGhlIG5leHQgc3RhZ2UgDQpvZiBmb3J3YXJkaW5n LiBCb2IgZm9yd2FyZHMgdG8gRnJlZC4gRnJlZCdzIGlzIGNoZWNrZWQgYWdhaW5zdCBvdXIgDQp0
  ZW1wb3JhcnkgbGlzdCBhbmQgZG9lc24ndCBtYXRjaCwgc28gd2UgYXJlIHN0aWxsIGdvb2QuIEJv YidzIG51bWJlciBpcyANCm5vdyBhZGRlZCB0byB0aGUgdGVtcG9yYXJ5IGxpc3QgYW5kIHdlIGNo ZWNrIHRoZSBmb3J3YXJkIEZyZWQgaGFzIGluIA0KcGxhY2UuIEZyZWQgZm9yd2FyZCdzIHRvIFN1
  ZS4gV2UgY2hlY2sgU3VlJ3MgbnVtYmVyIGFnYWluc3QgdGhlIHRlbXBvcmFyeSANCmxpc3QgYW5k IGl0IGRvZXMgZXhpc3QuIFRodXMgd2UgaGF2ZSBhIGxvb3AgZGV0ZWN0ZWQgYW5kIHRoZSBmb3J3
  YXJkIGNhbiANCm5vdyBiZSBkZW5pZWQuDQoNCkkgYW0gZ3Vlc3Npbmcgd2l0aCB0aGUgcmVjdXJz aW9uIGludm9sdmVkIHlvdSBtaWdodCB3YW50IHRvIGRvIHRoZSBjaGVjayANCm91dHNpZGUgb2Yg QXN0ZXJpc2sgYW5kIHBhc3MgdGhlIHJlc3VsdCBiYWNrIGluLiBJIHdpbGwgYWxzbyBzdGF0ZSB0
  aGF0IEkgDQpoYXZlIG5vdCBoYWQgdG8gZG8gdGhpcyBkZWVwIGNoZWNraW5nIGluIHRoZSBwYXN0
  LCBzbyB0aGVzZSBhcmUganVzdCBzb21lIA0KaW5pdGlhbCB0aG91Z2h0cyBvbiBob3cgSSB3b3Vs ZCBzdGFydCBhcHByb2FjaGluZyB0aGUgcHJvYmxlbS4gT2YgY291cnNlLCANCnRoaXMgYWxzbyBh c3N1bWVzIHRoYXQgQm9iLCBGcmVkLCBhbmQgU3VlIGFyZSBhbGwgb24gdGhlIHNhbWUgcGhvbmUg DQpzeXN0ZW0uIElmIHlvdSBkb24ndCBoYXZlIGEgc2hhcmVkIGRhdGFiYXNlIHRvIGxvb2sgYXQs IHRoZSBwcm9ibGVtIGp1c3QgDQpnb3QgaGFyZGVyIGluZGVlZC4NCg=

• From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Kevin Larsen Sent: Tuesday, June 2, 2015 5:12 PM
  To: Asterisk Users Mailing List – Non-Commercial Discussion Subject: Re: [asterisk-users] Forward loop protection…

  That just goes to show that the problem can get complex pretty quickly. Using the original example above, it might be that you want to allow the Bob to Fred to Sue forwards, but only stop it if the Sue to Bob link is established, thus creating the loop. I wonder if you could do some kind of recursive check where you follow each forward and if you ever come back around to a number you have already checked you know there is a loop.

  To reuse the example above, on the creation of the Bob to Fred forward, the database is checked to see if Fred has any forwards. He doesn’t, so is at the end of the forwarding chain. Now Fred forwards to Sue. Again, she is at the end of the chain, so it is allowed. When Sue goes to forward to Bob, the check shows that Bob has a forward. Not a problem, but we create a temporary list that has Sue’s number in it. Then we check the next stage of forwarding. Bob forwards to Fred. Fred’s is checked against our temporary list and doesn’t match, so we are still good. Bob’s number is now added to the temporary list and we check the forward Fred has in place. Fred forward’s to Sue. We check Sue’s number against the temporary list and it does exist. Thus we have a loop detected and the forward can now be denied.

  I am guessing with the recursion involved you might want to do the check outside of Asterisk and pass the result back in. I will also state that I have not had to do this deep checking in the past, so these are just some initial thoughts on how I would start approaching the problem. Of course, this also assumes that Bob, Fred, and Sue are all on the same phone system. If you don’t have a shared database to look at, the problem just got harder indeed.

  Classic Centrex forwarding required that the target party answer or that call forwarding is forced by repeating the attempt. If calls were provisionally forwarded and an attempt was made to complete a call from the forwarding party to the target, it wouldn’t be too challenging to see if the forwarded call ends up at the initiating extension. This would be effective even if there were multiple phone systems involved (if caller ID wasn’t messed with).

  –Don

• There currently is no easy way to prevent an infinite forwarding loop. If you come up with one, then you might well earn yourself a Nobel Prize for solving the Halting Problem …..

  The obvious bodge is to set a hard limit on depth of recursion; if an actual real, live person is not reached within, say, five hops then the call should go to (the originally-called party’s) voicemail.

  —
  AJS

  Note: Originating address only accepts e-mail from list! If replying off-
  list, change address to asterisk1list at earthshod dot co dot uk .

  —

• —–Original Message—–
  From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] There currently is no easy way to prevent an infinite forwarding loop. If you come up with one, then you might well earn yourself a Nobel Prize for solving the Halting Problem …..

  The obvious bodge is to set a hard limit on depth of recursion; if an actual real, live person is not reached within, say, five hops then the call should go to (the originally-called party’s) voicemail.

  —
  AJS

  Deciding on the mailbox to use is problematic! The dialed-party may be away for an extended period and wants voice mail handled by the forwarded-to party.

  –Don

  —

• And then you have the users who would work around this by sharing their voicemail passwords. Not quite as bad as sharing your computer log on credentials, but still, something I would like to avoid if possible.