Media forking to multiple recorders

[Thibault Groisil]

Hi,

We are configuring media forking on our CUBE to record all SIP calls to an external recorder. We are using media classes with media recording dia-peer. This is working fine when we record to 1 external recorder (SIP signaling and RTP streams are received by the recorder). Here is an extract of the configuration:

media class 1
recorder parameter
media-recording 1098

dial-peer voice 1098 voip
media-class 1
destination-pattern 98
session protocol sipv2
sesstion target ipv4:10.0.0.1

dial-peer voice 1 voip
media-class 1
destination-pattern 0
session protocol sipv2
sesstion target ipv4:10.0.10.10

This issue we face is when we want to record simultaneously to a second external recorder (as a backup). We define a second media recording tag, but the CUBE only send the SIP signaling to the first dial-peer tag (1098 in our example). The second dial-peer never receives the SIP signaling. See configuration below:

media class 1
recorder parameter
media-recording 1098 1099

dial-peer voice 1098 voip
media-class 1
destination-pattern 98
session protocol sipv2
sesstion target ipv4:10.0.0.1

dial-peer voice 1099 voip
media-class 1
destination-pattern 99
session protocol sipv2
sesstion target ipv4:10.0.0.2

dial-peer voice 1 voip
media-class 1
destination-pattern 0
session protocol sipv2
sesstion target ipv4:10.0.10.10

According to the cisco documentation (chapter Network-Based recording), we can define up to 5 dial-peer tags in the media-recording parameters.

Anybody knows what those multiple tags are meant for? How should we modify our configuration to make it work?

Thanks for your help

Thibault

[Leszek Wojnarski · Accepted solution]

From what I know those dial-peer tags are there to provide redundancy  in the way that first is primary then secondary etc. So seconady will be used if primary is down or not avaliable. This is how redundancy is provided. And there is no way to send multiplayer stream to the same recorder. The Type of redundacy that you are thinking about is usually provided by the recording server itself, that can run as a cluster with multiplayer nodes that can store same recording. 

So the way you achevie additionally redunda cy world depend on the recording server you use.

Leszek

[Thibault Groisil]

Thank you all for your answers.

The issue is that we don't succeed to make the CUBE call the secondary recorder when the primary is out of order.

We defined the first dial-peer tag with a "fake" telephone number, and defined the second one with the "real" dial-peer tag. We can see the CUBE sending an INVITE to the fake telephone number, it never receives any SIP answer but it never sends the INVITE to the second telephone number as we would have expected (we waited for 10 minutes).

Do you have any idea of what is wrong?

We did the test because we wanted to see the CUBE behaviour in case of recorder failure during the recording: what will do the CUBE? At re-INVITE will it drop the recording call or will it try to call the secondary dial-peer tag?

Thibault

[Leszek Wojnarski · Accepted solution]

Hi for the first issue, can you check if second dial-peer will be chosen if you just do "shutdown" on the primary.

If yes, then you can try to apply "voice-class sip options-keepalive" on both dial-peers, then if first recording is down then dial-peer will be considered dow, as if it was shutdown - this is worth trying if the test with "shutdown" is successful.

Sending RE-INVITE so totally different  SIP call processing (different recording) doesn't happen as it will not understand it fully anyway, so the call should drop.

Leszek

[Thibault Groisil]

Thank you Leszek. The way we tested it was wrong indeed. Shutting down the second dial-peer lead to the expected behavior.

I confirm that the recording call is dropped in absence of reply to the re-invite message.

[Jaime Valencia]

Leszek is right, someone asked me some time ago the same, but with CUCM, and the answer is the same, you cannot fork to more than one recording app, the redundancy for the recordings, has to be achieved in the recording app, not by forking the stream to more than one place.

[balukr]

I know this is an old post but this is similar to what we are trying to achieve instead of NBR we are planning to use media forking from phone with BIB and redundancy in Route Group/Route List for Recording servers. I know this setup works if primary recorder server fails to failover recording server. Here is the question I have if we do SPAN and mirror the traffic of what we send to primary recording server to second recording server at the same time can we record both streams at the same time. I know this can be accomplished with Cisco Media Proxy but we need to be on CUCM 12.5 and dedicated CUBE for that but we are on 11.X CUCM and no dedicated CUBE for this and not planning to upgrade CUCM in near future. Just want to see this setup explained above will work like an Active-Active though it is not supported by Cisco.

CUCM 11.X

CUBE with SIP trunk (we are not doing media forking from CUBE)

NICE recording server

Thanks for your help.

[Elliot]

Hello balukr,

In short, yes.  This is how you can record to two recorders are the same time.  One utilizing SIP and BIB, and one receiving the same traffic via SPAN port.

[DANIEL COHEN-LAROQUE]

Just found this thread and was facing exacting the same issue. Cisco documentation does not clearly mention whether this is N+1 or 2N recording.

Eventually solved by creating 2 SIPRec media class (each corresponding to a dedicated recorder). Then I applied the 1st media class to the PSTN dial-peer, and the 2nd media class to the CUCM dial-peer. That way, 2N recording does work perfectly!