All;
Its a trivial thing to setup failover from one SIP trunk to another or to a PSTN line in the event that there is a failure in connectivity. That's obvious. But what about in the event that a trunk is still up, but suffering from high latency, jitter, packet loss, etc? Is anyone looking at the quality of a connection rather than a binary status of up or down? It seems to me that it should not be that difficult to accomplish and is probably a more useful way of determining whether a trunk should failover or not.
FSD
Sure, I hear what you are
Sure, I hear what you are saying and you make some really good points, especially with failing over in mid-conversation. That's not something I thought of. What I imagined would be something like the following. There is a process or processes external to Asterisk that constantly monitors network status such as jitter, packet loss, delay, etc. You can add as many metrics as you want and set whatever criteria you want as to what constitutes a trunk connection that is excellent, good, fair, marginal, poor, or down. A line in the dialplan will call an AGI script that queries the network status and sets a global variable. If the global variable is set, the dialplan jumps to trunk two. I think that would work, and I think that it could be useful.
FSD
asterisk itself would have to change to accommodate this. A failover in dialplan can only occur when the Dial application ends and proceeds through the dialplan giving DIALSTATUS. In order to get what you want, the Dial application and channel drivers would have to undergo a rewrite in order for the channel drivers to give the dial application constant feedback of call quality and then have presets in Dial to fail if a threshold is reached. This behavior might be unsettling if, while on a call, you were disconnected and then had your phone ring again as a new call was delivered via a new route.
Another method, still requiring code change, would be to expand on the qualify= concept. Currently if latency exceeds the qualify delay the channel is marked unavailable. For this metric, this already exists. It would be useful if something like a jitter threshold in the channel driver could be set to mark it unavailable once the threshold reached.
both require changes to asterisk core, which, even if written and adopted today, wouldn't appear until 1.6.3