On Fri, 2010-02-26 at 13:15 -0500, M. Ranganathan wrote: > I have been experimenting a bit with freeSWITCH conference as a way of > doing call recording. In order to effect recording, sipxbridge would > send an INVITE for a call that needs to be recorded to FreeSWITCH. It > will take the response returned from FreeSWITCH and forward that > response in the INVITE sent to the ITSP after appropriate re-writing. > The conference effectively becomes inserted into the media path. Once > the conference is created, it can do call recording. After the call is > done, we can fetch the recorded wav file and associate it with a call. > The details of all of this are TBD. > > I am wondering about some basic architectural questions at this point: > > I would like to consolidate this interaction with freeSWITCH into the > sipXrecording service which currently is not a SIP service in that it > accepts no SIP signalling. With my proposed enhancements, the call > recorder will become a SIP service. On initialization it wouldeither > REGISTER with sipx registrar or have a predefined registration. It > will field an INVITE from another service that wants calls to be > recorded and proxy that request to FreeSWITCH conference. The SIP OK > from freeSwitch conference would be sent back to the initiator of the > INVITE and the SDP therein can be sent forward in an INVITE as > previously described, thus putting the conference in the media path. > The advantage in having this intermediary service is we can give it > permissions that allow it to reject or accept recording requests and > also we can control resource usage.FreeSWITCH also wants to see a few > parameters encoded the URL that it sees and this recording service can > take care of all of that as well as file management and export via a > REST interface. > > > The first application of this is for sipxbridge but it can be made to > work elsewhere as well. > > Question: > > > > If I have to route an INVITE request to a sipXrecording from > sipXbridge then I would need credentials for sipxbridge (i.e. user > name and password ) as it has to now be routed by the proxy server to > that service. Further, sipXrecording would need to register with > sipXregistrar so it would also need credentials (or we can preload the > credentials into sipxregistrar). > > If I send the request directly to freeSWITCH then I do not. However, > the disadvantage is I do not know a-priori from sipxbridge, where > freeSWITCH would be running and further I do not think it is > architecturally consistent. > > Any comments? What is the right approach to follow?
I suggest that you produce a ladder diagram showing all the components and the flow for a call setup. Eventually, we'll want flows that show what happens with both blind and consultative transfers, too. _______________________________________________ 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/
