On Mon, 2010-03-01 at 11:17 -0500, M. Ranganathan wrote: > Thanks for laying things out. > > 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.
But that doesn't solve the problem of how to do recording when we don't have an ITSP connection, and I don't want to create a requirement that we route everything through the bridge just because we _might_ want to record it. > > 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. Yes, it's probably the easiest one - note that it does not depend on sipXbridge (though, as I said, it may share some technology). > > * 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. I don't understand how forwarded calls are related to that - what I described was how I begin recording a call _after_ it's been answered. At that point, forwarding is irrelevant. > > * 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. I don't think that we need to worry about having a customer that wants per-call user-controlled recording but doesn't have phones that support transfer. > > 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. While that's fine as an experiment, I don't think it's adequate as even an initial product design. Admins should not be needed - they are usually not the same people who need the 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? Some combination, probably. > > 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. I think that the question should be "why put in a conference mixer", not "why not put in a conference mixer". Recording should, like everything else, be as media neutral as we can figure out how to make it. Ideally, our solution should be capable of directing media to an external recorder that we don't even build (there are a few vendors of these things). There's also an IETF working group being chartered to standardize signaling flows for recording. _______________________________________________ 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/
