Metadata deleted after call completes

[dancmsgit]

Metadata files are written but deleted shortly after the call completes, Using recording-method=proc

Is this intended/not intended?

[dancmsgit]

Did some more investigating and seems I was confused and this is normal. I am in need of correlating the audio files to call data that is contained in the meta files and expected them to be available well after calls complete.

[rfuchs]

This can be achieved by enabling the MySQL config section. The recording daemon will write appropriate metadata into the database. This isn't really documented yet, but the DB structure is

CREATE TABLE `recording_calls` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `call_id` varchar(250) NOT NULL,
  `start_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `end_time` datetime DEFAULT NULL,
  `start_timestamp` decimal(13,3) DEFAULT NULL,
  `end_timestamp` decimal(13,3) DEFAULT NULL,
  `status` enum('recording','completed','confirmed') DEFAULT 'recording',
  PRIMARY KEY (`id`),
  KEY `call_id` (`call_id`)
);

CREATE TABLE `recording_streams` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `call` int(10) unsigned NOT NULL,
  `local_filename` varchar(250) NOT NULL,
  `full_filename` varchar(250) NOT NULL,
  `file_format` varchar(10) NOT NULL,
  `output_type` enum('mixed','single') NOT NULL,
  `stream_id` int(10) unsigned NOT NULL,
  `start_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `end_time` datetime DEFAULT NULL,
  `sample_rate` int(10) unsigned NOT NULL DEFAULT '0',
  `channels` int(10) unsigned NOT NULL DEFAULT '0',
  `ssrc` int(10) unsigned NOT NULL,
  `start_timestamp` decimal(13,3) DEFAULT NULL,
  `end_timestamp` decimal(13,3) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `call` (`call`),
  CONSTRAINT `fk_call_id` FOREIGN KEY (`call`) REFERENCES `recording_calls` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
);

CREATE TABLE `recording_metakeys` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `call` int(10) unsigned NOT NULL,
  `key` char(255) NOT NULL,
  `value` char(255) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `prim_lookup` (`value`,`key`),
  KEY `fk_call_idx` (`call`),
  CONSTRAINT `fk_call_idx` FOREIGN KEY (`call`) REFERENCES `recording_calls` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
);

[dancmsgit]

Thanks for the table structure, I was working on building it based on the source code so this will save some time.

[dancmsgit]

Confirmed working. Couple issues I ran into:

I'm passing metadata information from kamailio as a test:

rtpengine_manage("record-call metadata=src:$fU|dst:$rU");

metadata file contains this while the call is in progress: METADATA 37: src:xxxxxxxxxx|dst:yyyyyyyyyy

However the database only reflects the src key:

'10', '11', 'src', 'xxxxxxxxxx'

An issue with my format or my understanding of this?

Also, the column 'end_time' is never populated, is this intended? (end_timestamp is populated)

[rfuchs]

You should get two entries in the metakeys table for each call, one for src and one for dst. If that doesn't work, try adding another pipe | at the end of the metadata= string. (If this works, but doesn't work without a trailing pipe, then it's a bug.)

The end_time field is deprecated and can be removed. In fact, start_time is also deprecated and only gets populated because there's a default value in the DB schema.

[denyspozniak]

Hello! My question is not related to current topic, but I would ask if it is good idea to add MOS/jitter/delay reporting into this MySQL database too.

[rfuchs]

Possibly in the future, even though MOS/etc calculations happens in the rtpengine primary daemon, not in the recording daemon.

[dancmsgit]

Confirmed adding a pipe at the end inserted both src and dst in the table. Without end pipe, only src is inserted.