On Tue, May 27, 2008 at 3:21 PM, Martin Steinmann <[EMAIL PROTECTED]> wrote: >>> >>> On Tue, 2008-05-27 at 08:28 -0400, M. Ranganathan wrote: >>>> Hello, >>>> >>>> It would be of interest to record calls that pass through sipxbridge > . >>> >>> I'm curious - why do this in sipXbridge? Wouldn't a general > recording >>> service that could be inserted in any call be better? >> >>That would be true but since media flows direct end to end in our >>system, would that not be problematic? IMHO, the use case for >>sipxbridge recording is clear and the solution is easily accomplished. >>For use case, one can envision a scenario where where customers call >>in and are put on the park server till the next human attendant >>becomes available. When the human picks up, you would want to record >>the conversation for "quality assurance purposes". It is easy to >>accomplish this in sipxbridge because all the media is bridged and I >>can add a media leg to send data to the recorder when the human picks >>up ( presumably voicemail is the right place to send it ? ). Nothing >>prevents us from turning off recording in sipxbridge when we come up >>with a more general solution. >> >>Ranga > > +1 > > Adding recording to existing services that anchor media seems to be the > most obvious and pragmatic approach. Candidates are the ACD, sipXbridge, > or the conferencing server. > > For customers who use SIP trunks we would be able to record all incoming > and aoutgoing calls with a recording capability in sipXbridge. That > would be a highly desired feature, especially if it comes at a fairly > low engineering cost. > > --martin
There appear to be three ways to build a solution. 1. Build a general recording facility any service can use. Media recording can be achieved by putting the B2BUA in the path of the call but you would have to know apriori that a call needs to be recorded. Essentially you can incorporate a bridging service into the call setup path. This can reuse many of the features of sipxbridge such as the ability to anchor and relay media but not all features need to be implemented such as registration and call transfer. Essentially a phone would allocate a B2BUA and a symmitron bridge that would act as a straight media and signaling relay. It would be simpler than sipxbridge because the remote end understands call transfer (REFER, Replaces, Re-INVITE). It can simply relay the signaling and expect that far end understands what to do with it. Question : How do we tell this to start/stop recording? Is the control plane for this going to be sip? How do we store and retrieve the media? I think such a solution will take about 2-3 months to design, incorporate sipxconfig support for and build. 2. Incorporate recording into every service that anchors media. This is going to take work for each service but it is the simplest one to incorporate into sipxbridge as things stand. Also because sipxbridge knows about when media is being put on hold and redirected by AA etc. It can judiciously avoid recording those segments. This will take less time to build than solution 1. The open questions here are 1. how to store and retrieve the media. 2. We can build a sipxconfig enabled switch that tells sipxbridge to start recording media. I think such a solution can be built in a 1 month. The reason for it taking that long is I think we need to give sufficient thought to the design of the media storage and retrieval facilities as well as the User Interface. It is relatively easy to add a media leg and set up a session with a media recorder to start / stop recording media. 3. Reverse engineer the call setup to determine the media ports being used for the call and sniff packets as the call is in progress. This is the least obtrusive but also the least discriminating. Question - how can we signal this hypothetical daemon to start recording packets for a given call? Perhaps the User gets a screen while the call is in progress and is able to hit a button asking to record the call in progress. I think this solution will take at least as long as solution 1 ( 2-3 months and maybe a bit more). The advantage would be no performance / scalability impact for calls that do not need recording. You don't have to decide apriori whether a call needs recording or not. The disadvantage would be that you need to be able to sniff packets on the network. Please add your thoughts to the above so we can discuss the issues involved. We need to make a decision based upon cost and functionality about which one to pursue. After such a decision is made based upon a study of cost vs. complexity, if a JIRA issue can be opened and schedule assigned I'll step up to getting it done. Ranga > > >> >> >>> >>> -- >>> Scott Lawrence tel:+1.781.229.0533;ext=162 or > sip:[EMAIL PROTECTED] >>> sipXecs project coordinator - SIPfoundry >>http://www.sipfoundry.org/sipXecs >>> CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ >>> http://www.pingtel.com/ >>> >>> > > > -- 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
