M. Ranganathan wrote: > [Discussion moved here from #sipx] > > Hello, > > I am putting together a library for third party call control in sipx > commons. That library can either be used stand alone or be > incorporated into a process (henceforth called the SipXCallController > ).
Nice - sipXconfig could use this library (or call a service) to implement its click-to-call needs. > > Lets say we are agreed on a stand alone process to which you can send > REST commands to make calls. This process needs to be able to access > the SIP password of the calling party so it can effective > "impersonate" that caller when it launches the third party call setup. > For this, I assume that the REST method will have the SIP password of > the user as one if its parameters. There are two separate problems here: you have to authorize the service users - and for that you need to implement some kind of REST/HTTP authentication method and once you authorize users you need to have access to their SIP credentials to initiate the calls. You do not need user PINs for the authorization (sipXconfig does not have them either) and Scott assures me that you do not need clear SIP passwords to initiate the calls either (the hash is sufficient - but he can probably explain it better than I can). Both PIN hash and SIP password hash are in credential IMDB. > > The other option is for the SipXCallController to read the database > that stores all the clear text passwords. In that case, I can make the > assumption that the caller is trusted (will use authenticated HTTPS to > make the call) and hence SipXCallController will just trust the > caller, retrieve the SIP passwords from the database and make the call > on the callers behalf. The caller in this case would just provide its > own SIP user name and the called party user name and domain. > > A third approach would be to just provide a java library that can be > imbedded into any trusted process that supplies user credentials drop > the notion of a stand alone SipXCallController. That does not really solve any problems: whoever is using such library still needs an access to users credentials... > > Which would be the preferred way to proceed on this? > I really like the idea (not mine) of the service that implements REST interface to initiate the calls. That would ensure that any service that needs it (including sipXconfig) can just initiate the call. It means that we can monitor and configure such service as any other service, we can for example easily set logging level. If that cannot be achieved having a higher level interface that using jain-sip directly would be also an improvement over having the entire thing embedded in the sipXconfig. And looks like a step in right direction to me. D. _______________________________________________ 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/
