Thanks for laying things out. On Mon, Mar 1, 2010 at 9:55 AM, Scott Lawrence <[email protected]> wrote: > On Fri, 2010-02-26 at 13:59 -0500, M. Ranganathan wrote: >> On Fri, Feb 26, 2010 at 1:37 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. >> > >> >> Any comments? What is the right approach to follow? >> > >> > Before getting into the level of detail in your note, let's start with >> > what the user interaction for the service needs to be. >> >> >> I will answer based on what my current thinking on the matter is: >> >> > >> > How does a user (or an administrator?) determine which calls are to be >> > recorded? >> >> it would be determined on a per ITSP basis or bridge wide basis. You >> can set a check box for an itsp account indicating that all calls to >> or from the given ITSP will be recorded. >> >> >> > >> > Where do recordings go? >> >> >> Into files stored locally or we have a voice mailbox option that posts >> recordings to a specified mail address so as to be able to remove them >> from the file system. >> >> > >> > How is access to those recordings controlled? >> >> Depends upon how they are stored. If they are stored in files and >> accessed through HTTP, then standard HTTP access protection. If they >> are sent to mailbox, then user name and password. >> >> >> >> > >> > What are the storage requirements for recordings? >> >> I do not know. It depends upon how many recordings you make and what >> the sample rate of the speech is and what compression you apply. >> >> >> > >> > What happens if there is not sufficient storage for a recording (how is >> > the user informed)? >> >> >> Same mechanism as is used for any other critical resource situation. >> >> Send an alarm. > > I think that from a product planing point of view those answers are not > really sufficient. > > As Peters post illustrated, there are a number of different views of how > a call recording service should be used. A service that unconditionally > records all of every call into the system is probably not what anyone > expects (or wants). Do we really want to record every call to an > auto-attendant? to voicemail? to a conference bridge (which may be > doing its own recording - 4 callers from outside into a bridge results > in 5 recordings of the same call)?
Very good points. We certainly do not want multiple recordings of the same call. > > I also think that putting this functionality in the bridge, just because > it's an existing B2BUA, is not the right approach. The reason for wanting to do some of this in sipxbridge is that as calls get transferred (for example an inbound call to a call center gets transferred), they are all logically the same call. We want a single recording of the entire call including all the transfers that happened during call handling which may have different call ID's but are logically related. This is easy to detect and do in sipxbridge. Initiating call recording from sipxbridge is not mutually exclusive of the the other methods you outline below. > > I think that's what's needed is a call recording service (for which we > have the building blocks) that supports accepting signaling such that it > can be inserted into a call either: > > * At call setup time by normal addressing. A dial plan or other > call target (users, hunt groups, aliases) could have a flag that > says "record calls". Internally, that generates addressing that > causes the insertion of a Route through the recorder. I like this approach. It does not exclude dynamic recording approaches that you have outlined below but this is the one I would pursue first. > > * Through phone-based conferencing - if I want to begin recording, > I put the existing call on hold, call a recorder number (*xx), > and then use the conferencing in the phone (most of our phones > can act as a three-party conference mixer) to connect the legs. This would not always work. Consider the use case when we want to record forwarded calls. > > * Through a transfer-based function at an endpoint - if i want to > start recording a call, I transfer that call to a fixed special > code (*xx); that triggers a routing decision that routes the > call to the recorder and then back to my phone. Again, this would not always work because the endpoint may not support transfer. Consider again the case of transfer to the PSTN. > > For any conferencing feature, we need to create an authorization model > that allows the administrators and/or the users to control who has > access to recordings. I would assume an initial model where only superadmin can access recordings. We also need a proactive storage management > strategy that is better than "when you run out of disk things break". I am trying to fill in the gaps here. Were you thinking about some mechanism that can free up space by deleting old recordings or mailing them to a mailbox or simply sending an alarm early? > > On the technology front, I'd like to find out if we can extend the > functionality of sipXrelay for this: rather than making every recording > go through a full blown B2BUA, can we just get something that clones the > RTP streams and diverts a copy to a recording service? Let me make sure I understand. When a call is going to be recorded, you would like to insert a media relay into the signaling path and divert a copy of all the RTP going through that relay. Sure that can be done. Why not place a "conferencing mixer" (i.e. conference which has the sole purpose of mixing two RTP streams ) in the media path? Not sure about the utility of sipxrelay in this context. I request you to elaborate. Thanks. Ranga > > > -- 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/
