In certain scenarios, calls transferred using *attended transfer (2) may cause the system to behave unexpectedly when extensions are configured with only one allowed incoming channel.
This article explains why this happens and what configuration can be used to avoid the issue.
Consider the following setup:
*2.The second call fails because the system still counts the original channel associated with the first call.
This occurs even though the call was transferred to another extension.
PBXware call handling is based on AGI (Asterisk Gateway Interface) processes.
AGI tracks the call from the perspective of the original channel.
Example:
Caller A → Extension B
AGI runs on channel A
When B performs an attended transfer:
Extension B → *2 → Extension C
The transfer internally swaps B with C, but the AGI process still tracks the original call channel.
From the system perspective:
Caller A is still considered part of the original call flow
Because of this:
This is a limitation of AGI-based call tracking, where the system does not fully track the final call participants after transfers.
If the goal is to prevent a device from handling more than one call at a time, the recommended approach is:
Example:
Incoming Channels = 2
Most SIP devices support settings such as:
This causes the device to reject additional calls at the SIP level, providing the same user experience while avoiding the AGI channel limitation.
Extension settings:
Incoming Channels: 2
Phone configuration:
Max Calls: 1
Call Waiting: Disabled
Result:
| Behavior | Explanation |
|---|---|
| Attended transfer keeps channel active | AGI tracks the original call channel |
| Channel limit reached after transfer | System still considers the call active |
| Second call fails | Incoming channel limit reached |
| Recommended workaround | Allow more channels and limit on SIP device |
This behavior is expected due to the way AGI-based call tracking works in the dialplan. Future architectures using other technologies (for example ARI) may allow more advanced call state awareness, but this would require significantly more complex dialplan logic.