Hi all, Dara (cc'd) is investigating using sipXecs with a Contact Centre.
There is a feature which he feels is critical, which we don't seem to have. The contact center must be able to INVITE an agent such that the call is automatically picked up at the agent's phone if it isn't manually picked up before a specified "answer after" timeout. Sounds perfect for the sipXecs Intercom feature, except for one thing. The "answer after" timeout must be dynamic, and specified in the INVITE message. Our Intercom feature has a single system-wide "Ring time", which requires rebooting the phones in order to change. It's implemented using the (RFC 3261 standard) Alert-Info header, in which a number of phones accept a pre-defined secret value as a trigger for the non-standard behaviour. (Polycom and Nortel IP 12x0 phones support this.) Dara had suggested using the (RFC 3261 standard) Call-Info header, but with the Broadsoft Talk and Hold non-standard "Answer-After" Info-parameter (http://tinyurl.com/ye58rtc, Section 2.3.) This approach is less secure, because there is no pre-defined secret value. But the timeout value can be dynamic. (Polycoms do not support this, but Nortel IP 12x0 phones may in the near future.) So, how should we handle delivering this functionality in sipXecs? Should we advise that phones implement the Call-Info "Answer-After" Info-parameter? On a practical note, I'm not sure if that would work for Polycom. Their Alert-Info functionality is already quite extensive, and could easily be used to deliver the functionality. (Multiple pre-defined secrets can be configured, each with a different "Ring time." The INVITE can then just dynamically send the Alert-Info secret corresponding to the desired timeout.) I doubt Polycom would be keen on developing a second mechanism for delivery functionality they already support. How else could we deliver the functionality? Maybe we could enhance the Intercom feature, so that it accepts the Call-Info "Answer-After" Info-parameter, but uses the Polycom mechanism in the resulting transformed INVITE? This would keep the security problem out of the phones, and the Intercom feature can be left off in deployments that do not require it. I think Intercom calls are also authenticated, which means there could be authorization over who can force an endpoint to auto-answer. Thoughts? -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
