[karl.relton]

The spa9000 seems to have a problem when an extension does a call-forward to another number that should be registered as a hunt group.

Basically the spa9000 does not start inviting the extensions in the hunt group, but instead sends a 'busy here' sip message to the original caller.

To illustrate, here is my scenario and two attached logs.

3 extensions, numbered 200, 250 and 500.

1 hunt group, numbered 600, which should call both 250 & 500 (in parallel).

From an internal extension, I can dial 600 which correctly calls 250 & 500 in parallel.

However, for an original caller coming in via spa400 which contacts the SPA9000 (line2). SPA9000 is set to contact extension 200. If extension 200 has its call-forward feature set to forward to 600 (after x seconds of no answer), then instead of getting 250 & 500 ringing in parallel, extension 200 briefly shows a 'missed call' and then starts ringing again. This cycle repeats every x seconds.

Looking at the sip trace, I see extension 200 (an spa941) send a sip 'moved temporarily' message, telling the spa9000 to contact 600. However the spa9000 responds to this by sending a 'busy here' message to the spa400, which in turn responds by simply re-inviting to the spa9000 (which in turn re-invites extension 200).

This can be seen in attached trace move_bad.log.

[karl.relton]

Changing the spa941 to call-forward to a regular extension number (rather than a number that is a hunt group) of course works okay - as this other attachment shows (just calls extension 500).

So it seems to me to be a bug in the SPA9000 not recognising its own hunt group numbers. Yet a straight-forward dial from an extension to a hunt group number works okay.