Cellular Network Infrastructure » Radio Access Network » OsmoBTS

libortp has a function called rtp_session_set_ssrc_changed_threshold which is documented as "Sets the number of packets containing a new SSRC that will trigger the "ssrc_changed" callback."

In reality, the code in rtp_session_rtp_parse() not only uses this threshold to call the call-back, but also to decide if this new SSRC is going to be accepted from now on.

The default value is "50" which in our 20ms codec frame duration means one second of silence at a SSRC change.

We could and probably should use rtp_session_set_ssrc_changed_threshold with a much lower threshold to be more tolerant/welcoming to SSRC changes.

Even with #3104 properly fixed (no SSRC change during start-up), we wills till see SSRC changes during hand-over between BTSs, so it's important to also fix this on the BTS/ORTP side.

Unfortunately, the "BYE" RTCP packet would not reset the libortp state into a state where it would blindly accept any new/different SSRC. It's basically simply discarded, as far as I read libortp source. So I guess rtp_session_set_ssrc_changed_threshold() is our only option. The question is if we set it to 0,1 or something like 5 (100ms). I'd probably go for "0".

I think I have narrowed down the problem a little bit.

In rtp_session_recvm_with_ts() we can see that there are three ways to obtain rtp data:

    /*calculate the stream timestamp from the user timestamp */
    ts = jitter_control_get_compensated_timestamp(&session->rtp.jittctl,user_ts);
    if (session->rtp.jittctl.enabled==TRUE){
        if (session->permissive) {
            mp = rtp_getq_permissive(&session->rtp.rq, ts,&rejected);
        }
        else{
            mp = rtp_getq(&session->rtp.rq, ts,&rejected);
        }
    }else mp=getq(&session->rtp.rq);/*no jitter buffer at all*/

At the moment we are using rtp_getq(). This function checks the timestamp and then discards the packet - at least in our case. Then there is rtp_getq_permissive() which seems to be less strict here. I think it would work. To use the permissive mode we need to set the session->permissive flag, but it appears to be an internal flag and I am not sure if we should touch it from libosmocore. This probably messes everything up.

We can also see that when jittctl.enabled is setto fals we use getq() to get rtp data. We have control this flag from outside using rtp_session_enable_jitter_buffer(). In osmo_rtp_socket_set_param() we are calling rtp_session_enable_jitter_buffer(). When I hardcode rtp_session_enable_jitter_buffer(rs->sess, FALSE); in there (I do know enough about this yet), then the problem vanishes.

However, I think we use the jitter buffer feature for a reason, so disabling will be presumably not an option.

The problem is definitely related to the jitter buffer. When I disable the jitter buffer via VTY, then the problem vanishes. However, this is no solution anyway.

Presumably the problem has something to do with packets which are still in some queue after the timestamp has jumped. Then probably this queue has to run empty first until libortp detects the timestamp change. I also see that we have a callback that handles timestamp changes by calling void rtp_session_resync (RtpSession *session). Since a changed SSRC means that the entire stream changed we should definitely do a resync on those events as well.

The ssrc change threshold is now changed to zero, so we detect ssrc changes immediately. Also when an ssrc change is detected we call rtp_session_resync() now. The audio dropouts are now gone.
https://gerrit.osmocom.org/#/c/libosmo-abis/+/9379 ortp: resynchronize rtp session on timestamp changes
https://gerrit.osmocom.org/#/c/libosmo-abis/+/9380 ortp: detect ssrc changes immediately