Summary:	ASTERISK-23634: With TURN Asterisk crashes on multiple (7-10) concurrent WebRTC (avpg/encryption/icesupport) calls
Reporter:	Roman Skvirsky (RomanSk)	Labels:
Date Opened:	2014-04-15 06:30:33	Date Closed:	2014-09-16 06:12:20
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip_nat
Versions:	12.0.0 12.1.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	Asterisk (12.1.1, 12.0.0, trunk-412327), Ubuntu 12.04 (Linux i3.8.0-35-generic #52~precise1-Ubuntu SMP Thu Jan 30 17:24:40 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux), pjproject (https://github.com/asterisk/pjproject/) - dated 15.05.2014, libsrtp-1.4.4	Attachments:	( 0) backtrace.txt
Description:	Crashes on multime (7-10 concurrent calls). Can be reproduced with sipp tester. Calls made via SIP/UDP Prerequisites: sip.conf: avpf=yes nat=yes encryption=yes icesupport=yes SDP to send: v=0 o=- 859838542390661385 2 IN IP4 [local_ip] s=- t=0 0 a=group:BUNDLE audio a=msid-semantic:WMS ARDAMS m=audio [media_port] RTP/SAVPF 103 111 9 102 0 8 106 105 13 127 126 c=IN IP4 [local_ip] a=rtcp:46718 IN IP4 [local_ip] a=candidate:1073307297 1 udp 2122129151 [local_ip] 46718 typ host generation 0 a=candidate:1073307297 2 udp 2122129151 [local_ip] 46718 typ host generation 0 a=candidate:1903862353 1 tcp 1518149375 [local_ip] 32995 typ host generation 0 a=candidate:1903862353 2 tcp 1518149375 [local_ip] 32995 typ host generation 0 a=ice-ufrag:Vct0L5nW18FBbUaj a=ice-pwd:29EebhS1pD2bKbFR4IQ80J9F a=ice-options:google-ice a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:T6m3YKv7XtaCND/XrFl7ExsDRdAGXw227NQSCByA a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:7WyR0QSShX6pVeXTD3+GSmJf/2XP+DDz53zQZDt7 a=rtpmap:103 ISAC/16000 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:9 G722/8000 a=rtpmap:102 ILBC/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:127 red/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:3000605325 cname:yk9j/ZBeDy5G9V2a a=ssrc:3000605325 msid:ARDAMS ARDAMSa0 a=ssrc:3000605325 mslabel:ARDAMS a=ssrc:3000605325 label:ARDAMSa0 Backtrace: [Edit - removed as per the guidelines, attaching as .txt]
Comments:	By: Roman Skvirsky (RomanSk) 2014-04-15 06:44:21.651-0500 STUN and TURN are also enabled: rtp.conf ; Address to use for the STUN server when determining the external IP address and port ; an RTP session can be reached at. This option is disabled by default. stunaddr=stun.l.google.com:19302 ; ; Address to use for the TURN relay server when creating a TURN relay session. This option ; is disabled by default. turnaddr=x.x.x.x ; ; Port used to contact the TURN relay server on. This option is set to 34780 by default. turnport=3478 ; ; Username used to authenticate with TURN relay server. turnusername=xxxxx ; ; Password used to authenticate with TURN relay server. turnpassword=xxxxx By: Roman Skvirsky (RomanSk) 2014-04-15 06:57:14.120-0500 TURN is the reason of crash. Without TURN and with STUN Asterisk works fine. By: Rusty Newton (rnewton) 2014-04-23 16:49:14.889-0500 I've got a few questions. Do you need a real TURN setup to reproduce the crash? Or do you simply need the various TURN options populated?  I ask because I'd like to see if I can provide an easy way for the developers to reproduce without much trouble. Do you have a sipp scenario that you used to reproduced this? Can you provide a pcap to aid us in reproduction? By: Igor Skomorokh (ISkomorokh) 2014-10-08 04:26:56.123-0500 Latest CentOs; Asterisk 11.13. STUN and TURN a commented in rtp.conf. Same problem while testing under sipp. By: Matt Jordan (mjordan) 2014-10-08 07:44:32.265-0500 [~ISkomorokh]: You'll need to provide a backtrace for your most recent crash on the version that has this fix. Without that, we can't verify if it is the same problem or not. By: Igor Skomorokh (ISkomorokh) 2014-10-08 07:47:29.653-0500 @Matt Jordan Ok, I'll try to provide that. BTW, I have found this in system logs: localhost kernel: asterisk[17387]: segfault at 0 ip 00007f12b7999cda sp 00007f1255ba5690 error 4 in libssl.so.1.0.1e[7f12b796b000+61000] And all the peers use the same certificate for DTLS. Could this be a problem?