A situation that we run into constantly:
We have a phone in a “noisy” area. We need a paging speaker in the area, however, we also need a way to generate a “ring” if the phone in the area is called.
With competing products that we currently use. We can utilize a SIP account (or multicast) for paging. We can also program a SIP account on the speaker to be concurrent with the phone in the noisy area. When the phone is “called” both the phone and the speaker will emit a “ringtone”. When the phone answers the call, the ring is terminated on both the phone and the speaker.
As the 3510 is now, with the “auto-answer” being the way the speaker is designed, utilizing the speaker as a concurrent SIP account with a phone for the purpose of utilizing it as a “loud ringing” speaker is impossible. There are instances where we will use competing products with MULTIPLE speakers to cover a noisy area (ie: shop classes in schools, manufacturing and testing areas in factories, etc.)
By eliminating this “simple” and easy programming step in the firmware, you are severely limiting the use of the product and forcing use of competing products.
This feature also allows use of the 3510 as a “universal answer” device when a call is sent to the concurrent SIP account on the speakers, and then any phone hearing the “ringtone” from the speakers can dial a “pickup code” answering the call and terminating the ring…