Can CUBE with SIPREC fork to two recorders

[YAP51]

Hi, I like to know if CUBE using SIPREC can fork media to two recorders at the same time or one at a time with second as a redundant option.

SIPREC dialpeer has session-target <Rec. Server>, is it possible to have two of these or define a server group where it will fork to one and if that is not available then go to second.

I know CUBE in Media proxy can do this but I am looking to see if anyone has managed to get CUBE SIPREC to do this, such future that will keep setup simple where I don't need to fork to more than two recording servers.

Thanks!

[j.a.m.e.s]

According to my research you have to use the CUBE "Media Proxy" with it's associated licensing to fork the stream to multiple recorders.

This question was also asked here:

https://community.cisco.com/t5/ip-telephony-and-phones/multiple-media-forking-from-cube/td-p/4096049

EDIT: I was a bit confused about the CUBE recording options when I posted this originally. CUBE recording has been around a long time and is for recording of calls which already pass through the CUBE. Media-Proxy is for forking calls into recorders which are sent at a CUBE Media-Proxy specifically for recording purposes.

[TechLvr]

@YAP51 The scenario you are describing is not considered forking. You simply want to create a redundant path to a secondary recorder in case the primary is down. You can define a server group to achieve this as you mentioned yourself. See example below. 

voice class server-group 100
ipv4 10.10.10.5 preference 1
ipv4 10.10.10.6 preference 2

dial-peer voice 100 voip
description To_SIPREC
session protocol sipv2
destination-pattern 2...
session server-group 100
.
.
.

[j.a.m.e.s]

@TechLvr I wasn't so sure about using server-group towards multiple-recorders because the configuration guide says it isn't supported on SIPRec dial-peers towards the recorder:

Further down on that page there is an construct called Configuring SIPREC-Based Recording with Media Profile Recorder and it looks like this allows up to five outbound dial-peers towards the recorders like this:

media profile recorder profile-tag 1
  media-recording recorder-dp-X recorder-dp-Y [up to 5] <- Will CUBE hunt through these?
media class 1
  recorder profile 1 siprec
dial-peer voice 200 voip 
  description IN: Calls from PSTN
  session protocol sipv2
  incoming uri via 200
  destination dpg 200
  media-class tag 1 <- This means calls into this DP get sent to recorders using SIPRec. According to Verint, only set this on incoming DPs.
   [...]
dial-peer voice X voip
  descr DP1 towards recorder1
  destination-pattern 99999999 <- Any idea why we need to set this?
  session protocol sipv2
  session target ipv4:10.0.0.1:5060
  session transport tcp
   [...]
dial-peer voice Y voip
  descr DP1 towards recorder2
  destination-pattern 99999999 <- Any idea why we need to set this?
  session protocol sipv2
  session target ipv4:10.0.0.2:5060
  session transport tcp
   [...]

Presumably the SIPRec would go to DP X and then Y only if X is down. The documentation doesn't make this clear.

[helloguys]

I know this is an old post.  In enterprise environment, a scenario like this is usually handled by load-balancers.  Don't be confused by the name.  A load-balancer doesn't necessarily load-balance.  It can probe the recording server (by port number, by response, etc.) to determined which one is live and which one is dead.  Then it will direct the traffic to the live recording server.  A load-balancer can be a virtual machine as well.