Previously when SRTP was enabled on a channel it was not possible
to switch to T.38 as no crypto attributes would be present.
This change makes it so it is now possible. If a T.38 re-invite
comes in SRTP is terminated since in practice you can't encrypt
a UDPTL stream. Now... if we were doing T.38 over RTP (which
does exist) then we'd have a chance but almost nobody does that so
here we are.
ASTERISK-24449 #close
Reported by: Andreas Steinmetz
patches:
udptl-ignore-srtp-v2.patch submitted by Andreas Steinmetz (license 6523)
........
Merged revisions 429632 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429633 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429634
65c4cc65-6c06-0410-ace0-
fbb531ad65f3
goto process_sdp_cleanup;
}
+ if (p->srtp && p->udptl && udptlportno != -1) {
+ ast_debug(1, "Terminating SRTP due to T.38 UDPTL\n");
+ ast_sdp_srtp_destroy(p->srtp);
+ p->srtp = NULL;
+ }
+
if (secure_audio && !(p->srtp && (ast_test_flag(p->srtp, AST_SRTP_CRYPTO_OFFER_OK)))) {
ast_log(LOG_WARNING, "Can't provide secure audio requested in SDP offer\n");
res = -1;
goto process_sdp_cleanup;
}
- if (!(secure_audio || secure_video) && ast_test_flag(&p->flags[1], SIP_PAGE2_USE_SRTP)) {
+ if (!(secure_audio || secure_video || (p->udptl && udptlportno != -1)) && ast_test_flag(&p->flags[1], SIP_PAGE2_USE_SRTP)) {
ast_log(LOG_WARNING, "Matched device setup to use SRTP, but request was not!\n");
res = -1;
goto process_sdp_cleanup;