Nicholas Welcome. We are very interested in adding a CTI capability to sipXecs and we also reached the conclusion that CSTA phase III or uaCSTA is the best standard to use. Our initial main use case would be integration with Microsoft OCS and Office Communicator, and this might as well be your motivation for doing so.
Our presence server is called RLS - resource list server. As the name suggests it implements resource lists primarily used for BLF by subscribing to line state of phones. This might be a good starting point to extend the system to eventually support CSTA. A CTI interface has to support two primary functions: a) Allow applications to subscribe to events and presence. b) Offer 3PCC to subscribers to the CTI interface The first functionality could be implemented by extending the RLS and this is where we would suggest starting. In addition to solely relying on the phones to provide presence information, the RLS should listen to the proxies signaling traffic and synchronize line state information received from the proxies with what the phones say. This would also allow supporting phones that are not capable of interacting properly with the RLS server. In addition, the proxies would deliver called party or calling party information (caller ID) to subscribing applications. Special attention has to be paid to the fact that the sipXecs call control system (proxy / registrar) can be redundant. The CSTA interface would be offered northbound from the RLS. Implementing 3PCC could then be done in a second phase as another extension to the RLS or as a separate new service. There are several options for a SIP stack you can use as we already use the sipX SIP stack and Jain SIP. Hope this helps --martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Lawrence Sent: Monday, June 02, 2008 10:52 AM To: Nicholas Gill Cc: [email protected] Subject: Re: [sipX-dev] CSTA Third Party Call Control On Tue, 2008-06-03 at 00:04 +1000, Nicholas Gill wrote: > Hello All, > > My name is Nicholas Gill. I have been asked to investigate the > possibility of adding third party call control and monitoring (in the > form of a CSTA [1] interface) to sipXecs. > > I have been playing with sipX over the last few days [2] and after > looking at the architecture, i realise that a centralised structure (as > is common with most legacy PBX systems (and a precursor to implementing > 3pcc)) doesn't really fit in this scenario. > > Even given this, some form of call control could be generally useful in > a number of scenarios. I can see in the roadmap that a form of 3pcc is > planned for the ACD module, but this does not cover normal user > extensions and calls which is useful for the implementation of > UserPortals and other CRM integration/screen pop applications. > > Essentially system-wide CSTA would be a superset of the desired > functionality for the ACD, CSTA generally uses the ASN.1 BER [3] however > Phase III introduces an XML encoding that (i believe) would meet the > requirements described, while additionally providing flexibility for > other applications. > > I can imagine that such a CSTA interface could leverage uaCSTA (with > UA's that support it) to provide remote AnswerCall and other requests > that require interaction of the UA, however i don't know where i may > start looking at this or what the best way to approach this may be.. > > My experience with SIP and uaCSTA so far is limited to reading their > specifications (although uaCSTA is really very similar to CSTA Phase III > with which i am very familiar), and my experience with sipX is even more > limited. Any help about approaches to implementing this or ideas if it's > even feasible are most welcome. > > Browsing sipXcallLib looks promising, esp. cp/Connection.h which appears > to have most of the requests, events and call states that would be used > in implementing a csta interface, however i am not sure where this > library fits into the sipx architecture. > > In any case, any ideas about how this would be planned/implemented are > most welcome. Welcome Nicholas. Before starting on a design, I suggest that a bit more refinement is needed in terms of end user functional description. As you've seen, a SIP system like sipXecs has some conceptual mismatches with a standard that assumes a traditional centralized phone system. I think that the most immediate of these differences is that a "line" in a traditional PBX becomes a "user" in sipXecs, and may map to any number of actual phones. The second big difference is that sipXecs supports many different UAs with widely differing capabilities. Almost certainly, those UAs differ in the extent to which (and probably the mechanisms by which) they will respond to third party call control. Putting CSTA features into the ACD is probably not too difficult, because as a B2BUA it can manipulate the calls directly. Do you envision CSTA functions for non-ACD calls? -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ http://www.pingtel.com/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
