Summary:	ASTERISK-27397: res_srtp / res_pjsip_sdp_rtp: New key on answer to reinvite not applied correctly
Reporter:	basildane (basildane)	Labels:	pjsip
Date Opened:	2017-11-06 13:07:37.000-0600	Date Closed:	2017-12-26 13:41:11.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Resources/res_pjsip_sdp_rtp Resources/res_srtp
Versions:	15.1.3	Frequency of Occurrence
Related Issues:	is related to ASTERISK-27482 SRTCP unprotect failed because of authentication failure
Environment:	FreePBX distro 14	Attachments:	( 0) debug.log ( 1) pjsip.conf ( 2) pjsip.endpoint.conf
Description:	Call between two SRTP endpoints work ok until transferred to a device that does not have SRTP.  Then Asterisk logs: {panel} res_srtp.c: SRTP unprotect failed with: authentication failure 110 {panel} Audio is lost from the call at this point.
Comments:	By: Asterisk Team (asteriskteam) 2017-11-06 13:07:37.927-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: George Joseph (gjoseph) 2017-11-06 17:47:18.744-0600 I'm trying to reproduce By: George Joseph (gjoseph) 2017-11-06 17:52:17.306-0600 What were the 3 devices involved in the transfer scenario?   Phones? Makes, models? Also can you provide the PJSIP configuration for each of the endpoints? By: basildane (basildane) 2017-11-06 17:52:34.295-0600 If it helps, most of my endpoints are pjsip.  The failure also occurs when the destination is sip (our exchange unified messaging server), or a DAHDI extension. Also, I get "failure 10" in addition to "failure 110" in some scenarios. By: basildane (basildane) 2017-11-07 12:10:40.524-0600 I have attached a sample pjsip.endpoint.conf. 207 is the starting point.  That is Jitsi, and SRTP. 207 calls 202. 202 is a Grandstream 2160, not encrypted. This leg of the call works. 202 transfers the call to 225. 225 is a Snom M3, not encrypted. The call fails at this point. I wish to point out that I have tested this with multiple devices in multiple combinations, and I found that the problem is not related to what kind of phone it is.  The same problem occurs regardless of the manufacture of the endpoint.  The only common denominator seems to be when the call starts out in SRTP, then gets moved through Asterisk paths that are not SRTP. By: George Joseph (gjoseph) 2017-11-07 14:58:38.054-0600 Well, I've tried reproducing this with various combinations of secure and insecure endpoints and cannot get it to fail.  Even the scenario you supplied the config for, where 225 doesn't have G722 but the first 2 do, works. So, more info is needed.... The transport configurations for all transports involved. The logs with... {noformat} core set debug 3 res_pjsip.so core set debug 3 res_pjsip_session.so core set debug 3 res_srtp.so pjsip set logger on {noformat}   By: basildane (basildane) 2017-11-09 10:43:04.375-0600 I attached "debug.log" which captures what you asked for. To be consistent I used the same endpoints.  207 calls 202.  202 transfers to 225 - fail. You also asked for "transport configurations", but I'm not clear on exactly what that means.  Could you please name some conf files? I'll upload them right away. Thanks. By: Richard Mudgett (rmudgett) 2017-11-13 11:56:14.209-0600 The transport configurations are part of pjsip's configuration in {{pjsip.conf}}.  They are the sections with {{type=transport}} in them.  The 207 endpoint you supplied in [^pjsip.endpoint.conf] contains an explicit transport reference {{transport=0.0.0.0-tls}}.  The other two endpoints don't have an explicit transport so they are free to pick an appropriate transport. By: basildane (basildane) 2017-11-14 17:59:59.518-0600 I uploaded pjsip.conf as requested. I also changed 207 to not have explicit transport=0.0.0.0-tls, in order to simplify testing.  The problem remains when 207 has the same "auto" setting as the other extensions. By: Joshua C. Colp (jcolp) 2017-12-05 11:45:21.807-0600 At least in the debug provided the problem appears to stem from the connected line update which is being sent as a re-invite. We send a re-invite which uses the same keys as before. Jitsi, however, answers with different keys as to what they initially provided. This means that either we aren't applying the key to the SRTP session in this instance or they aren't applying it to their own. By: Joshua C. Colp (jcolp) 2017-12-05 11:46:02.836-0600 What other endpoints have you used in place of Jitsi for this test? By: basildane (basildane) 2017-12-05 11:50:07.164-0600 I have Grandstream desk phones, most of their product line.  I have a Snom M3, Jitsi on Windows, Linux and iphone clients, Grandstream Wave running on a Galaxy S8. By: basildane (basildane) 2017-12-05 11:50:55.448-0600 I can try a re-test tonight and remove Jitsi from the test completely. By: Joshua C. Colp (jcolp) 2017-12-05 12:32:44.075-0600 I've reproduced this with the following dialplan logic: {noformat} exten => service,1,Answer exten => service,n,Set(CONNECTEDLINE(name,i)=Boom) exten => service,n,Set(CONNECTEDLINE(num)=500) exten => service,n,Echo {noformat} This causes a connected line update to occur which results in a new key from Jitsi. This is seemingly not applied correctly as of Asterisk 14, and the SDP negotiation isn't quite right either in 15. Accepting this issue. By: Joshua C. Colp (jcolp) 2017-12-13 06:21:39.526-0600 [~basildane] I've done further testing as I thought the new key wasn't getting applied, but after further investigation it appears it is - and that is what breaks Jitsi. It does not appear to be applying its own new key to its outgoing media. It only applies it to RTCP. If I modify the code so that the new key isn't applied on the Asterisk side either then RTP works and I hear audio but RTCP fails to unprotect. This appears to be a bug in Jitsi. Can you please provide another device that also exhibits the same issue and provide a sip trace as well for it? By: basildane (basildane) 2017-12-26 13:36:42.841-0600 I ran a new test using Grandstream Wave in place of Jitsi. The test was successful. I'm going to open a ticket with Jitsi now. Thanks for your insight into this problem.