Linphone - rtpengine hold/unhold long calls using SRTP

[Ihor Olkhovskyi]

Hello!

We are using rtpengine 8.4.1.1 and one of our endpoints is a Linphone. rtpengine is used as a SRTP - RTP terminator. In a case of long calls and using hold/unhold in this calls we have an issue with audio loss, means after off-hold audio is not being restored.
After investigation this issue with Linphone team, they came to this conclusion:

It is clearly related to ROC (rollover counter of SRTP context).
After several minutes, the sequence number of received RTP packets reaches above 65535 and resumes at 0.
In order to protect against replays, the receive-side SRTP context maintains a ROC counter which the number of rollover above 65535.
This ROC is part of the cryptographic context and used to decipher incoming packets. This means that if sender and receiver have unsynchronized ROC numbers, the receiver won't be able to decrypt.
And this is what happens here.
In Linphone, the SRTP context are kept during all the duration of the calls, as long as the SRTP master keys are not changed.
The scenario could be as follows:

• as long as the ROC of the receive context in Linphone is zero, everything goes well, it is possible hold and resume.
• after some time and while the call is active, the ROC increments to 1, and communication is still good (between Linphone and RTPEngine).
• after a hold and resume, the ROC is still 1 on Linphone side (because Linphone has the policy to keep SRTP context for all the duration of the call), but RTPEngine probably re-create its SRTP context with a ROC value of 0.
• as a result, Linphone is not able to decrypt incoming packets.

Please note that the policy of Linphone (consisting of keeping SRTP context for all the duration of the call unless there is a master key change) is the result of two things:

• interoperability with various SIP vendors who implement the same
• we could not identify any IETF RFC/draft that require to reset the crypto context after a pause/resume operation.

My recommendation would then be to try the following:

• have RTPEngine to keep its send SRTP context for all the duration of the call (as Linphone)
• if not possible (because RTP engine logic is to destroy it for example), then RTPEngine could change its master key, to force Linphone to re-initialize its receive crypto context.

Can this be an issue with RTPEngine?

Thanks in advance,
Ihor

[Richard Fuchs]

Hi,

Have you tried this with a newer version of rtpengine? 8.4 is not LTS and has been unsupported for a while, and there have been a few fixes related to ROC within the last year or so. I would suggest at least 9.5 or better yet 10.5.

Cheers

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/cc7e4400-44d7-4d24-89a1-adef353d52den%40googlegroups.com.

[Ihor Olkhovskyi]

Hi!

Thanks, will try to use newer version, but do recall some issues compiling 9 on CentOS 7 (this one I cannot change unfortunately).

[Ihor Olkhovskyi]

Hello!

Some feedback on this one:

Tested on versions mr8.5.10.2, mr9.5.6.2, mr10.5.2.8 - all are acting same, using Linphone and after a long talk with hold/off-hold on Linphone there is one-way audio.

OS used: 3.10.0-1160.80.1.el7.x86_64 (CentOS 7)

Thanks!

[Karsten Horsmann]

Hi Ihor,

you are sure that the signaling is not wrong? I had the same issue with re-invites and SRTP to
RTP and after investigation i found that i didnt send the correct rtpengine flags in case of the re-invite.

It was clearly in the signaling (htat was TLS, but the SDP shows RTP on RE-INVITE).

To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/9ef04917-3b5f-4c63-a622-57bf49f644b1n%40googlegroups.com.

--

Mit freundlichen Grüßen
*Karsten Horsmann*

[Ihor Olkhovskyi]

Karsten,

Yes, I'm sure about signalling as it's reproduces only on call duration longer than ~ 20 min (after 65536 RTP packets) when ROC changes. Before this time all is ok.

Cheers,

Ihor

[Richard Fuchs]

On 13/12/2022 05.21, [EXT] Ihor Olkhovskyi wrote:
>
> Hello!
>

> Some feedback on this one:
>
> Tested on versions mr8.5.10.2, mr9.5.6.2, mr10.5.2.8 - all are acting
> same, using Linphone and after a long talk with hold/off-hold on
> Linphone there is one-way audio.
> OS used: 3.10.0-1160.80.1.el7.x86_64 (CentOS 7)
>

Can you capture a pcap that demonstrates this? Then it should be
possible to reproduce it.

Cheers

[Ihor Olkhovskyi]

Richard,

Sure, it's here.

On a first hold on/off sound is there. On a minute ~ 16 of the call (2nd reINVITE) audio is getting one-way, means I can hear what Linphone is talking, but no sound on Linphone side

In a case I do also have rtpengine log (with loglevel 7), but it shows real IP addresses which I don't want to show public (sanitized in provided pcap)

Thanks in advance!

[Richard Fuchs]

On 15/12/2022 10.00, [EXT] Ihor Olkhovskyi wrote:
> Richard,
>
> Sure, it's here.
> On a first hold on/off sound is there. On a minute ~ 16 of the call
> (2nd reINVITE) audio is getting one-way, means I can hear what
> Linphone is talking, but no sound on Linphone side
>
> In a case I do also have rtpengine log (with loglevel 7), but it shows
> real IP addresses which I don't want to show public (sanitized in
> provided pcap)
>

Sorry for not having been precise. The pcap would have to include the
RTP. And yes, log from rtpengine would also be good to have.

Cheers

[Ihor Olkhovskyi]

Richard,

Sorry for possible dumb question, but how should I provide RTP traffic unencrypted or in SRTC flavor?

Cause I'm not sure how to deal in this case (means SRTP traffic)

Thanks!

[Richard Fuchs]

On 15/12/2022 14.44, [EXT] Ihor Olkhovskyi wrote:
> Richard,
>

> Sorry for possible dumb question, but how should I provide RTP traffic
> unencrypted or in SRTC flavor?
> Cause I'm not sure how to deal in this case (means SRTP traffic)
>

Encrypted is fine, just as it is on the wire, as long as it's SDES and
the keys are included in the log or SIP capture (in the SDP).

Cheers

[Ihor Olkhovskyi]

Dear Richard,

Logs are attached.

Thanks in advance!

[Richard Fuchs]

And you're saying the media flow to linphone is affected, correct? So in that pcap, this would be SSRC 24061B81, or Wireshark filter `udp.dstport == 7078 and rtp`, yes?

I've checked the logs and confirmed that linphone always used the same media port, that rtpengine always used the same media port (20146), that rtpengine always used the same crypto suite and key, and that rtpengine always used the same SSRC, which means that the same SRTP context was in use throughout the session.

I've also confirmed that the SRTP packets are correctly encrypted with that given SRTP key, and that the ROC in use was 0 before the sequence numbers rolled over, before the re-invite as well as after, and that the ROC was 1 after the sequence numbers rolled over, all the way through the end of the media session.

So I can't find a fault here and so I would say that linphone must be the problem.

Cheers

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/c8920081-c59d-4e15-b7ba-bcc7e90ed222n%40googlegroups.com.

[Ihor Olkhovskyi]

Richard,

Thank you for checking this!  Will get back to Linphone team.

Many thanks again!

Cheers,

Ihor