On Fri, Feb 26, 2010 at 2:12 PM, Scott Lawrence <[email protected]> wrote: > 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. > >
Any document I produce would depend upon the answer. Essentially the question is this: Would you want a separate process sipXrecording to handle interaction with freeSWITCH and handle management of the files that are recorded or would it suffice to have a library that takes care of this and send interactions to freeSWITCH directly. I think it makes sense to simply extend the function of sipXrecording. Your opinion on the matter would be of value. I'll produce a document after some experimentation. Thanks > -- M. Ranganathan _______________________________________________ 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/
