On Mon, Mar 1, 2010 at 12:43 PM, Scott Lawrence <[email protected]> wrote: > 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.
That was not what I was trying to say. If a call is going through sipXbridge, then it would be relatively easy to relate different legs of the call as all being logically related. That does not imply that all calls that are to be recorded must to through sipxbridge. Only that this is the easiest one to tackle at present. > >> > 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: > 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. Forwarded calls ( i..e call comes in via ITSP and gets forwarded to call target) is never answered except by the call target. If the called party or calling party has the ability to control recording then he can direct the call to the recording service. However consider that I have set up call forwarding for my extension and my call gets forwarded to an ITSP number ( I am on travel ). Then I have no means of recording that call because I cannot transfer as the ITSP does not support REFER. Thus the only option I have is to instruct sipxbridge via some non-SIP means (be that DTMF or pre-defined configuration) to record the call. The point is that there is a valid use case for "configuration based recording" and a valid use case for dynamically turning ON recording and one does not preclude the other. >> >> 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. You would need to mix the media at some point. We can store it and mix it off line. If you do not mix the media, you will hear two one way streams. We can potentially do the mixing off line if that is what you had in mind. > > 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. Any documents from them yet? 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/
