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
