[Home]

Summary:ASTERISK-13950: [SRTP branch] RTP Read error: Success: Hanging up. If res_timing_pthread.so is loaded
Reporter:Kristijan Vrban (vrban)Labels:
Date Opened:2009-04-14 16:08:56Date Closed:2011-06-07 14:08:18
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Phone for this test: snom 320 FW_7.3.14

If the res_timing_pthread.so is loaded, rtp.c hangup the channel beacause:

[Apr 14 22:40:50] DEBUG[29841]: res_srtp.c:301 res_srtp_unprotect: SRTP unprotect: authentication failure
WARNING[29727]: rtp.c:1723 ast_rtp_read: RTP Read error: Success. Hanging up.

But this i a bit hasty, because this happen only with the very first frame that is comming from the phone. All following ones are ok. (tested this by replacing return NULL; with return &ast_null_frame;)

Then you get the warning only once, and the srtp audio is ok between ast<->snom

UPDATE:
this issue has it's origin probably here:
res_srtp_unprotect: SRTP unprotect: authentication failure

and again only the very first frame from the snom phone caused
the "RTP unprotect: authentication failure"

so there are two options, let the ast_rtp_read function from rtp.c be a bit more relaxed, and hangup only if there are more the one bad frames from the phone consecutively and/or let snom check if they do something wrong with there first srtp packet they send to asterisk.

this issue has been also reported in 14649 by me. But was closed because i did a formal error using this bug tracker. if i do again a formal error, then please correct it instead of just closing the report please.

this report is certainly for twilson

p.s. a category Channels/chan_sip/SRTP would be useful

****** ADDITIONAL INFORMATION ******

source from: https://svn.digium.com/svn/asterisk/team/group/srtp
Comments:By: Joshua C. Colp (jcolp) 2009-04-15 14:51:07

As I was mentioned in the other issue please report this problem as a note on the original SRTP issue. We don't accept issue reports for a branch that is still in progress in another issue like this.