Problem:
When extension is forwarded, dialparties.agi replaces
the target extension and bridges the call to
Local/TN@from-internal, (TN="target number") -
where 'from-internal' is hard-coded; as opposed to
using the appropiate context from which the forwarded
call "would" originate.
Consider the following situation:
Different extensions can dial different pattern sets.
This may be used if different set of outbound or other
restrictions are applied to different users.
The natural way to achieve this is placing extensions
A and B into different (predefined) contexts which
determine their calling abilities.
Concrete example:
Ext. B has no overseas calling permission.
This is to say, ext. B is placed in such default
context (call it from-internal-local) which can NOT
dial overseas (i.e. 011... pattern does not belong to
from-internal-local context)
However, as it stands currently the user B can
passthrough his blocking of overseas calls, simply
forwarding his extension to 011... number (using *72
for example), and further dialing his own extension.
Dialparties.agi would bridge the call using
predefined 'from-internal' context, and what user can
dial this way depends on 'from-internal' context,
rather than the context of his extension B.
I see two ways (simple and complex) for deailing with
this:
- Simple: Call forwarding process must take into
account the dialing abilities of the forwarded
extension. I.e. extension should not be able to be
forwarded by its owner to a # that this extension can
not dial naturally.
- More complex (the one I used): Upon extension
forward, the "context of the person who forwarded the
extension" is stored in DB, and further used by
dialparties.agi as "authoritative context", i.e. the
context into which the chan_local bridging should
occur. It works like that:
1) B can not dial overseas 011... (belongs to from-
internal-local context)
2) B forwards its extension to 011... overseas #.
(saving in DB not only the fw number but altogether
its context as "auth context" under which CF should be
done)
3) B dials its own extension.
4) dialparties.agi expands the call to
Local/011...@from-internal-local, thereby
using "authoritative context for forwarding" instead
of hardcoded "from-internal"
5) But from-internal-local can not dial 011..., so
chan_local expanded call fails
6) The original call to B also fails
As alternative scenario:
1) B can dial overseas 011... (belongs to from-
internal-everywhere context)
2) B forwards its extension to 011... overseas #.
(saving in DB not only the fw number but altogether
its context from-internal-everywhere as "auth context"
under which CF should be done)
3) A can NOT dial overseas.
4) A dials extension of B.
4) dialparties.agi expands the call to
Local/011...@from-internal-everywhere, thereby
using "authoritative context for forwarding"
(belonging to B) instead of hardcoded "from-internal"
5) Because from-internal-everywhere context can dial
011..., the chan_local expanded call succeeds
6) The original call of A also succeeds, although A
has no overseas rights. Because the expanded call
proceeded under rights of B, not A. Obviously, in the
CDR we will have one call originating from A-to-B
(pure internal call); and second call originating from
B-to-011.... I.e. B is responsible (and in charge) to
where he forwards his own extension. If B is to be
billed for his calls, such forwarded calls are charged
to B, as it should be naturally.
Obviously the second approach requires also changes to
dialparties.agi (which I did). Some additional
trickeries are needed to deal properly with righths
for chained forwarding (A->B->C->...) where
dialparties.agi recursively expands the calls.
I was unable to use the 1st approach as I do not know
how to "check the ability to dial the number to which
forwarding is about to be set", without
actually "ringing" this number.
