"Deep" trunk group hunting

[plugger2]

From my reading of the admin guide (and someone please correct me if I'm wrong), the way a hunt through a trunk group is conducted is currently "shallow" in the sense that the hunt stops once it is determined the next port in the trunk group list is free to take another call, and that the number matches the DigitMap associated with that port. There is no guarantee that there is any service available on that port, however. If it is a SIP port, for example, an INVITE request might yet fail for any number of reasons.

On the other hand, a "deep" trunk group hunt would wait for verification that service _is_ available on a port before concluding the hunt. In the context of a SIP service, I think this would be at the stage of the call having progressed to "ringing" or "busy". At that stage, the service has proven itself to be up and running and available. On the other hand, if the connection to a SIP service provider, (whether a registered service or via a gateway or even URI dialling) does not proceed to the "ringing" or "busy" stage, then the connection attempt is deemed unsuccessful and the hunt should continue on to the next port in the list.

I appreciate this would not be trivial to implement, but my feeling is that this would raise the usefulness of the trunk group concept (which I think is a great one) up to the next level. Lets face it, no ITSP has 24/7 uptime, but the ability to automate some redundancy via trunk groups would be a great step towards creating "virtual" 24/7 availability. And I believe the feature would be truly unique for the consumer ATA market -- I think you'd have to go to something like an Asterisk box set-up to get this sort of sophistication otherwise.

Anyway, another feature request for the OBiHAI team's consideration. What do other forum members think?

[plugger2]

So, yesterday encountered a situation when "deep" trunk hunting would have worked very nicely.

I was making a call which was routed to the first available port in my trunk group (sp1). The port was free as far as the OBi110 was concerned, but attempting to place the call resulted in a SIP 480 error from the SIP server ("temporarily unavailable").

This is exactly where "deep" trunk group hunting would have been useful. "Deep" trunk hunting would have waited to get the result of the SIP dialog, detected this problem, and continued the hunt to the next trunk in the list, instead of simply stopping when a free port (sp1 in this case) was found.

The trunk group hunt implementation as it stands is useful, but for trunk group hunting to be really useful, it's availability of _service_ that matters, not merely _port_ availability. I appreciate this would require a substantially different approach to way the current system is implemented, but I think the effort to extend the functionality this way would be worthwhile, as it really would set the OBi1x0 apart from other devices in yet another important aspect. I think to get this level of sophistication currently would require an asterisk box or equivalent -- no other consumer level device I know of comes close.