Summary:	ASTERISK-29438: TURN Server never added to ICE candidate list.
Reporter:	Chris (ccasterisk)	Labels:	webrtc
Date Opened:	2021-05-20 07:42:26	Date Closed:	2021-05-21 06:48:22
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	pjproject/pjsip Resources/res_rtp_asterisk
Versions:	16.17.0	Frequency of Occurrence	Frequent
Related Issues:
Environment:	Network topology requiring TURN using PJSIP	Attachments:	( 0) no-turn-candidates.zip
Description:	The configured TURN server is never added to the ICE candidate list offered via SIP/SDP The assumed reason is that, after receiving status 400 (Bad request) Asterisk stops sending request and shuts down the According to the RFC, a status 400 does not necessary means the procedure has to stop. See: https://tools.ietf.org/id/draft-ietf-tram-stunbis-13.html#section.bid-down NOTE : The PCAP contains 4 requests,  these are for audio, video and their 2 RTCP counterparts. But each of those 4 are only tried once.
Comments:	By: Asterisk Team (asteriskteam) 2021-05-20 07:42:27.375-0500 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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. 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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Chris (ccasterisk) 2021-05-20 07:43:11.385-0500 PCAP and Asterisk logs By: George Joseph (gjoseph) 2021-05-20 13:50:14.738-0500 If I'm reading https://datatracker.ietf.org/doc/html/rfc8489#section-9.2.5 right... {code} If the response is an error response with an error code of 400 (Bad   Request) and does not contain either the MESSAGE-INTEGRITY or   MESSAGE-INTEGRITY-SHA256 attribute, then the response MUST be   discarded, as if it were never received.  This means that   retransmits, if applicable, will continue.      Note: In this case, the 400 response will never reach the      application, resulting in a timeout. {code} and i'm reading the logs correctly... {code} |--- begin STUN message --- STUN Allocate error response Hdr: length=28, magic=2112a442, tsx_id=000078b651c38d7a7f46d5ca Attributes:  ERROR-CODE: length=16, err_code=400, reason="Bad Request"  SOFTWARE: length=4, value="None" --- end of STUN message --- {code} then doesn't mean a retransmitting the existing request from the transport layer as opposed to recreating the request with additional info? By: Chris (ccasterisk) 2021-05-21 02:55:05.140-0500 We suspect that, when error 400 is received without INTEGRITY attributes, this response should be ignored. It's unclear what the reaction of Asterisk/pjsip should be in this case. Retransmit, the same packet? Or re-transmit a packet with additional attributes ? In any case, we believe the TURN procedure should not stop here. By: Chris (ccasterisk) 2021-05-21 04:46:03.820-0500 Ok, we found the issue. It was due to a misconfiguration. The turnusername and password were surrounded by by double-quotes. These doublequotes were not stripped from the turnusername, resulting in a BAD REQUEST error . The reason that we get a BAD REQUEST and not an auth failure is that the turn server first checks for the attribute fields to be valid. A username with quotes is of-course, invalid. Our usernames and passwords are generated daily, and might contain special characters like a colon ':' , semicolon or others. In the past we had issues where Asterisk stopped parsing the password when it encountered a ':' Therefore we used quotes to protect the password parsing. When I look at the code, apparently *ast_strip_quoted* is never used for turnusername or turnpassword. What is the recommended way to ensure that generated passwords with specials charactes are parsed properly ? By: Joshua C. Colp (jcolp) 2021-05-21 05:11:39.408-0500 The only special character that I'm aware of for configuration file is ";" which is for comments. If it needs to be part of a value it has to be escaped with a "\" in front of it. From a configuration parser perspective there's no issue with ":". By: Chris (ccasterisk) 2021-05-21 06:28:44.027-0500 We don't have control on the password generation, we'll see if we can escape it on our side somehow. Unfortunately there is no formal list anywhere in the docs on what chars to escape. So it's kind of a wild guess. Cleaner would be that all string-value configuration parsing is threatened the same way in Asterisk. chan_sip accepts the double-quotes and removes them. The stun/turn settings don't remove the quotes. By: Joshua C. Colp (jcolp) 2021-05-21 06:41:24.809-0500 The ";" character is the only one I can find according to the code. As for changing things globally, that would be a substantial behavior change, and I could certainly see it breaking things. As well for chan_sip it may or may not, depending on the configuration options. It uses the same underlying parser and is up to each option to behave differently - it does NOT strip " for everything, and does not treat them as quoted for everything. It is entirely option behavior specific. By: Chris (ccasterisk) 2021-05-21 06:46:07.353-0500 Ok, understood. We will handle the ';' parsing and escaping at our side. This ticket can be closed. Thanks for the help and insights !