rtpengine-recording stream channel allocation

[Pete Kelly]

Hi

I am experimenting with using rtpengine-recording to record some calls, using the output-mixed=1 and mix-method=channels configuration values.

This nicely puts each SSRC from a call into its own channel within the wav container, however I was wondering if it is documented anywhere how rtpengine-recording decides which "side" of the call to put into channel 0,1,2,3 etc?

From my experimentation it seems that the initial rtpengine_offer side will always get put into channel 0 regardless of which side actually sends media first, however if there is a reinvite and a change of SSRC, it does not seem to follow the same logical pattern. It *seems* like the reverse happens and the offer side is put into channel 3 and the answer side is put into channel 2.

Is there a known order that I can look into or glean from any outputs at all, and indeed is the behaviour that I have seen correct behaviour?

Thanks 

Pete

[Richard Fuchs]

On 01/07/2024 08.01, Pete Kelly wrote:

Hi

I am experimenting with using rtpengine-recording to record some calls, using the output-mixed=1 and mix-method=channels configuration values.

This nicely puts each SSRC from a call into its own channel within the wav container, however I was wondering if it is documented anywhere how rtpengine-recording decides which "side" of the call to put into channel 0,1,2,3 etc?

From my experimentation it seems that the initial rtpengine_offer side will always get put into channel 0 regardless of which side actually sends media first, however if there is a reinvite and a change of SSRC, it does not seem to follow the same logical pattern. It *seems* like the reverse happens and the offer side is put into channel 3 and the answer side is put into channel 2.

Normally the first SSRC to appear gets the first channel, and so on. Offer direction or call leg side isn't taken into account.

There is a new(ish) option `output-mixed-per-media` which was contributed in PR #1808 which AFAIK assigns channel slots based on SDP media indexes. So the first SDP media to appear (which would be the offer media) would get the first channel. AFAIK re-invites would not renumber the SDP indexes. Each different SSRC would still require its own channel slot, so I'm not sure what happens when multiple SSRCs are seen from a single SDP media with this option set. It would probably fall back to assigning them round-robin I guess.

Cheers

[Pete Kelly]

Thanks for the link to the patch - it doesn't achieve quite what I need AFAIK, it looks like it assigns the channel based on the number of media items in the SDP for the original invite:

https://github.com/dvillaume/rtpengine/blob/83af737fa0389819554c194fec3048114a425141/daemon/sdp.c#L1338

I did a quick patch+test to confirm and  both sides (rtpengine_offer/rtpengine_answer) of my test calls end up in channel 0.

What I really need to say (perhaps via an offer/answer param "recording-mix-channel=N" ?) is "Please associate the ssrc from this offer/answer" to channel 0/1/2/3 - Does that sound viable?

Pete

[Richard Fuchs]

On 01/07/2024 11.18, Pete Kelly wrote:
>
> Thanks for the link to the patch - it doesn't achieve quite what I
> need AFAIK, it looks like it assigns the channel based on the number
> of media items in the SDP for the original invite:
>
> https://github.com/dvillaume/rtpengine/blob/83af737fa0389819554c194fec3048114a425141/daemon/sdp.c#L1338
>
> I did a quick patch+test to confirm and  both sides
> (rtpengine_offer/rtpengine_answer) of my test calls end up in channel 0.
>
> What I really need to say (perhaps via an offer/answer param
> "recording-mix-channel=N" ?) is "Please associate the ssrc from this
> offer/answer" to channel 0/1/2/3 - Does that sound viable?

It's certainly doable, with the caveat that you'd have to decide what to
do if multiple SSRCs appear on the same side of a call. Another option
would be to use a stride-and-offset approach (e.g. SSRCs from one side
get slots 0,2,4,... and from the other side 1,3,5,...). Either way, PRs
welcome, so feel free to give it a shot if you feel adventurous.

Cheers

[Pete Kelly]

I got a little POC working last night by hardcoding the media_sdp_id in monologue_offer_answer, and it seemed to work, something like this:

if (flags->opmode == OP_OFFER ) {
media->media_sdp_id = 1
}

if (flags->opmode == OP_ANSWER ) {
media->media_sdp_id = 2
}

Obviously very crude but it seemed to work - however I am not sure if this is the right place to be setting media properties as I notice media and other_media are retrieved using the same flags, and the comment then goes on to say that the flags may be overwritten. 

Any tips on where the correct/final place to set media properties is would be appreciated.

I like the stride-and-offset idea, it then gives a lot of control at the ng level, for example if the initial offer comes from party A (slots, 0,2,4) but a subsequent reinvite means that the *answer* part is party A, the channel slots can still be controlled at script level.

Pete

[Richard Fuchs]

On 02/07/2024 10.54, Pete Kelly wrote:

I got a little POC working last night by hardcoding the media_sdp_id in monologue_offer_answer, and it seemed to work, something like this:

if (flags->opmode == OP_OFFER ) {
media->media_sdp_id = 1
}

if (flags->opmode == OP_ANSWER ) {
media->media_sdp_id = 2
}

Obviously very crude but it seemed to work - however I am not sure if this is the right place to be setting media properties as I notice media and other_media are retrieved using the same flags, and the comment then goes on to say that the flags may be overwritten.

I would suggest to do it in __media_init_from_flags(). You're right about this being called twice and the flags possibly being overwritten, so care must be taken to set these correctly. "Other" corresponds to the sender of the message (i.e. the offerer in an offer), while the `media` is the receiver, which can possibly be empty. The usual MOD is to do things like these if explicitly requested by the user, either through a global config option, or through a flag passed to rtpengine in the offer/answer, which are kept in the `sdp_ng_flags` and parsed in `call_ng_main_flags()` or one of its child functions.

Cheers

[Pete Kelly]

That's great, thank you. I am going to give it a try.

Out of interest do you know why the maximum number of channels (SSRC) is set to 4?

[Richard Fuchs]

On 03/07/2024 11.47, Pete Kelly wrote:
> That's great, thank you. I am going to give it a try.
>
> Out of interest do you know why the maximum number of channels (SSRC)
> is set to 4?

I think that's just a remnant from when the `mix-num-inputs` option was
introduced. It used to be a compile-time constant, defaulting to 4. I
don't see why it couldn't be increased to some sensible higher upper limit.

Cheers