Workaround for compatibility issue with Sylk client

CK
Crystal Kolipe
Mon, Dec 26, 2022 12:01 PM

Hi,

We were recently contacted by an end-user of Pjsua and asked to investigate an interoperability issue with the Sylk sip client [1] from AG Projects [2].

(Note, we are an independent research organisation and have absolutely no connection with AG Projects.)

Summary:

Set up of an SRTP media stream fails due to Pjsua receiving an out of range value for rem_tag in function sdes_media_start, triggering PJMEDIA_SRTP_ESDPINCRYPTOTAG.

Local end is Pjsua 2.12.1 running on OpenBSD 7.2, (previous versions show the same issue).
Remote end is Sylk 2.9.5 running on a variety of Android handsets.

Workaround:

Disable all encryption modes except one.

Details:

Client contacted us as we have a lot of experience with OpenBSD, and he suspected that the issue might be platform dependent as he hadn't seen other related bug reports.  He is a long time user of Pjsua on OpenBSD, mostly calling other Pjsua instances or Linphone instances.

Test calls to the Sylk client on Android with media encryption disabled completed without problems.

However once SRTP was enabled, call setup failed with PJMEDIA_SRTP_ESDPINCRYPTOTAG.  This was 100% reproduceable:

pjmedia_transport_media_start() failed for call_id 0 media 0: Invalid SRTP crypto tag (PJMEDIA_SRTP_ESDPINCRYPTOTAG)
Error updating media call00:0: Invalid SRTP crypto tag (PJMEDIA_SRTP_ESDPINCRYPTOTAG)

The client's main use case is calls originated from Pjsua, (rather than incoming calls), so we added some debugging code to sdes_media_start and observed that the value of rem_tag was consistently 3, whilst loc_cryto_count was set to 1.

For testing purposes we modified pjmedia/src/pjmedia/transport_srtp.c and disabled all crypto suites except AES_CM_128_HMAC_SHA1_80.

With this change, outbound calls from Pjsua to the Sylk client now complete and successfully negotiate an encrypted media channel.

At this point, since we have resolved the client's immediate problem, we thought it was best to throw the issue over to you for a propper fix :-).

[1] https://android.sylk.link
[2] https://ag-projects.com/webrtc/

Hi, We were recently contacted by an end-user of Pjsua and asked to investigate an interoperability issue with the Sylk sip client [1] from AG Projects [2]. (Note, we are an independent research organisation and have absolutely no connection with AG Projects.) Summary: Set up of an SRTP media stream fails due to Pjsua receiving an out of range value for rem_tag in function sdes_media_start, triggering PJMEDIA_SRTP_ESDPINCRYPTOTAG. Local end is Pjsua 2.12.1 running on OpenBSD 7.2, (previous versions show the same issue). Remote end is Sylk 2.9.5 running on a variety of Android handsets. Workaround: Disable all encryption modes except one. Details: Client contacted us as we have a lot of experience with OpenBSD, and he suspected that the issue might be platform dependent as he hadn't seen other related bug reports. He is a long time user of Pjsua on OpenBSD, mostly calling other Pjsua instances or Linphone instances. Test calls to the Sylk client on Android with media encryption _disabled_ completed without problems. However once SRTP was enabled, call setup failed with PJMEDIA_SRTP_ESDPINCRYPTOTAG. This was 100% reproduceable: pjmedia_transport_media_start() failed for call_id 0 media 0: Invalid SRTP crypto tag (PJMEDIA_SRTP_ESDPINCRYPTOTAG) Error updating media call00:0: Invalid SRTP crypto tag (PJMEDIA_SRTP_ESDPINCRYPTOTAG) The client's main use case is calls originated from Pjsua, (rather than incoming calls), so we added some debugging code to sdes_media_start and observed that the value of rem_tag was consistently 3, whilst loc_cryto_count was set to 1. For testing purposes we modified pjmedia/src/pjmedia/transport_srtp.c and disabled all crypto suites except AES_CM_128_HMAC_SHA1_80. With this change, outbound calls from Pjsua to the Sylk client now complete and successfully negotiate an encrypted media channel. At this point, since we have resolved the client's immediate problem, we thought it was best to throw the issue over to you for a propper fix :-). [1] https://android.sylk.link [2] https://ag-projects.com/webrtc/