We are attempting to do split stream recording with Service Observing. We have single stream (mono) recording working with Service Observing (SO) and we have split stream recording working with Multiple Registrations (MR). Understand the documentation says MR is the preferred method for split stream recording.

With SO if I only initialize with a single device instance recording will start but the recording will have issues, as we would expect since only one side will be sent. If I initialize with device instance 0 and then 1 as we do with MR I never see the SO light and I don't see the Media Start event. Eventually it times out. The button presses for FAC and the target DN appear to work (using dev instance 0).

So, my question is how are we supposed to do this? Do we need to do the button presses for both device instances? I couldn't find anything documented on this specifically. Is it even recommended?

thanks

Service Observe Split Stereo Dual Recording Multiple Registration

Each SO observer should be given a unique extension, so each SO observer should be able to use device instance 0.
So you lose me in your writeup when you talk about device instance 0 and 1, it is as if you are using a single extension for both of the SO recorders... Use two separate extensions.

I would not say that a single SO observer 'has issues' because you configure it to only get one of the media streams. To me that is doing exactly what I expect.

Thanks for quick reply.

Oh so I need two SO extensions to monitor a single target extension if I want to do split stream? I assume one would register MAIN_STATION_ONLY and the other ALL_BUT_MAIN_STATION?

That would be my approach. By using a single extension and two devices - you only have one logical observer, and while one observer can activate and deactivate observing (I would do it from the MAIN device, but it should not matter) and I guess in theory each of the devices might be able to request separate media, it is really bending my brain to think of it that way. My belief is that when custom media was developed the expectation was not to hook things up the way I beleve you are (I should know, I was part of the requirements team, but I would have naturally assumed you if you were going to use SO you would use two station extensions since that is how the SO feature is built in CM to have two observers of one station). I can see how you fell into this configuration thou - I suspect the requirements team were somewhat locked into some legacy thinking related to CM feature usage.

After writing that I am tempted to ask for a more complete explanation of this paragraph: "With SO if I only initialize with a single device instance recording will start but the recording will have issues, as we would expect since only one side will be sent. If I initialize with device instance 0 and then 1 as we do with MR I never see the SO light and I don't see the Media Start event. Eventually it times out. The button presses for FAC and the target DN appear to work (using dev instance 0)."

You have a single extension 1000
You register Device Instance (DI) 0 as a MAIN device configuring it for MAIN_STATION_ONLY media receipt - see subsequent post from Martin - it will need configured once media starts for the observed station
You register Device instance 1 as a DEPENDANT or INDEPENDANT device (I would use INDEPENDANT) - configuring it for ALL_BUT_MAIN_STATION media receipt - see subsequent post from Martin - it will need configured once media starts for the non-observed station
You activate SO from 1000 to moitor extension 2000 from extension 1000 Device Instance 0.
SO button lights up?
From 2001 you call 2000 and 2000 answers.
What media does extension 1000 DI 0 get?
What media does extension 1000 DI 1 get?

I am actually now thinking that this should work. alibet it is a bit different than I believe our thought process was at the time. If it doesn't, I recommend trying the two extension SO configuration.

So to provide a bit more context, the first test I did was to run our current code, that supports mono recording with SO and split stream (stereo) recording with MR, but configured for split stream with SO, just to see what would happen. In this case since its configured for SO it will only initialize one device instance on the SO extension. This one sided stream actually exposed a bug in the "mix" code we use to write the two channel wav file. The stream from DMCC is clean. Once I fixed the bug we got a clean recording with one side of the call. So that is a correction to my original statement concerning the recording.

The second test was to modify the code to do the same initialization we do for MR, for SO where we initialize both device instance 0 and 1. This time on the SO extension instead of the target extension. The button presses were only on device instance 0. In this case we never got the Media Start nor the SO light. Actually we got nothing from DMCC after that even with target extension receiving calls.

I will do a quick test to see how an SO recorder interacts with Split Stream recording later today. But first, I want to try to clear up an misunderstanding that you seem to have.

For MAIN_STATION_ONLY and ALL_BUT_MAIN_STATION, the "MAIN" refers to the station of the RECORDER terminal. That is, if the DMCC terminal(s) used as a SSC/SO recorder are 1000 then:
- The MAIN_STATION_ONLY terminal will receive only media from 1000 - i.e. nothing
- The ALL_BUT_MAIN_STATION will receive media from everybody else - i.e. everybody in the call.

MAIN_STATION_ONLY and ALL_BUT_MAIN_STATION are only useful for Multiple Registration recorders. SSC and SO recorders must use a SelectiveStreamRequest with an SELECTIVE_EXCLUDE or SELECIVE_INCLUDE list.

I performed the following test:

1. Use DMCC Dashboard to register two DMCC terminals in Independent & Client/FULL media mode (Instance 0 & 1), each with a different RTP/RTCP port.
2. Use one terminal to go off-hook & dial SO Listen Only access code + number of monitored station.
3. Make call to the monitored station from other station.
4. Use Wireshark to verify that both DMCC terminals receive media from both stations in the call.
5. Use the Dashboard to make SelectiveStreamRequest for each DMCC terminal. For Instance 0, the SELECTIVE_EXCLUDE list includes only the other station. For instance 1, the SELECTIVE_EXCLUDE list includes only the monitored station.
6. Use Wireshark to verify that instance 0 receives media only from the monitored station. Instance 1 receives media only from the other station.

So, working as expected.

Martin

Thank you for the update and taking a look at this. Yes, I was not aware of SelectiveStreamRequest though I do see it mentioned in the 8.0.1 What's New.

So, what I am gathering from this is we can use SO split stream with a single recording DN per target extension. For example I could configure 17001 with device instances 0 and 1 and monitor say DN 6201 split stream. I'm not clear on how I would use the SelectiveStreamRequest if I want to record all calls going to or from the target extension. In the example the calling extension was specifically set. For incoming calls do we wait until a call comes in and determine the calling party and then call SelectiveStreamRequest? Or can we set it up to always stream for all calls from or to any other DN?

You will need to configure the SO recorders on a call by call basis once the call establishes. I would set them up to record all audio by default and as the call is answered reconfigure them to record the target extension and 'everyone else'. As Martin points out the MAIN and ALL-BUT-MAIN relate to the extension 17001 (in your example), not the SO target of 6201.

I attempted to recreate the DMCC Dashboard test posted previously. With a single device instance 0 registration I was getting the correct light states and rtp traffic. When I added in the second device instance, if I did the off hook button presses after the second registration I got nothing back from the switch after that. If I did the off hook and button presses after the dev instance 0 but prior to the dev instance 1 registration I would get rtp for only the next call but then it would revert to rtp to only one port. Now in this case our SO device is a virtual extension. When we changed it to a physical phone then it worked, we would get rtp on both ports on all calls. Would this be expected? For your test did you use a virtual or physical device?

I think it would be best if you were to open a technical support ticket for this query. Please include the XML sent to/from the dashboard and the output of the SAT command "list trace station <service observing station" . The list trace should cover the registration of the service observer DMCC terminals and the calls.

Martin