Summary:	ASTERISK-25360: chan_sip:wrong ice candidate fails html5client on mobile connection
Reporter:	Fabrizio Lombardozzi (fabrizio_lombardozzi)	Labels:
Date Opened:	2015-08-31 11:45:32	Date Closed:	2017-12-12 15:45:21.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/WebSocket Resources/res_pjsip
Versions:	13.4.0 13.5.0 13.7.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	server: Centos 6.7 client: Ubuntu, Windows, Android with Chrome 44 and Firefox 40, sipML5, SIP.js	Attachments:	( 0) chan_sip-asterisk_13.7.0_webrtc_forced_use_of_media_address_.diff ( 1) full_bad.txt ( 2) rtp.txt ( 3) sip.log ( 4) sip.txt
Description:	Scenario: {noformat} asterisk server  <--nat--> internet <--nat--> html5client {noformat} Systematically, when using webrtc, chan_sip.c:add_ice_to_sdp() chooses only LAN_ADDRESS of the server, so the SDP INVITE reply reports only candidate addresses that the client can't reach (see log) "sip show settings" cli command reports that PUBLIC_ADDRESS specified sip.conf and local subnets, are set properly, even media_address is set  to PUBLIC_ADDRESS. Tcpdump running on the server reports no traffic to the stun server specified in rtp.conf In addition is to consider that the issue becomes actual only if the client uses a mobile connection (or is a mobile device using mobile connection), in all the other cases (pc with adsl router, mobile device with wifi-adsl) the client "understand" (don't know how or why) that is better to use the address specified in the sip header (or maybe where the traffic comes from). Brutely forcing PUBLIC_ADDRESS in add_ice_to_sdp() of chan_sip.c source code made the call possible from 3g mobile also. Multiple clients tested with sipML5, SIP.js in Firefox 40, Chrome44, on linux, windows and android with identical results.
Comments:	By: Asterisk Team (asteriskteam) 2015-08-31 11:45:34.521-0500 The severity of this issue has been automatically downgraded from "Blocker" to "Major". The "Blocker" severity is reserved for issues which have been determined to block the next release of Asterisk. This severity can only be set by privileged users. If this issue is deemed to block the next release it will be updated accordingly during the triage process. By: Asterisk Team (asteriskteam) 2015-08-31 11:45:35.116-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. 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: Fabrizio Lombardozzi (fabrizio_lombardozzi) 2015-09-01 08:30:26.639-0500 I can't download the patch... anyway I wonder if a simpler fix could be the use of the externaddr specified in sip.conf even for ICE (it works in sip/udp) By: Rusty Newton (rnewton) 2015-09-03 18:16:24.198-0500 {quote} I can't download the patch... {quote} What do you mean?  Do you mean that you cannot attach a patch? Please read through the documentation on the patch contribution process: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process You need to [sign the submission agreement|https://issues.asterisk.org/jira/secure/DigiumLicense.jspa] (and wait for it to be accepted) before you attach the patch. By: Fabrizio Lombardozzi (fabrizio_lombardozzi) 2015-09-04 07:01:38.915-0500 No,I really mean can't download, not can't attach, in the previous comment there's a submitted attachment named tcp_keepalive.patch. Do I need to sign the submission agreement for downloading also? By: Joshua C. Colp (jcolp) 2015-09-04 07:40:21.615-0500 According to the history the patch was removed almost immediately after attachment by Hiroaki Komatsu as it was for a separate issue. By: Rusty Newton (rnewton) 2015-09-05 11:07:45.736-0500 Fabrizio we need a bit more information. Please gather again the SIP trace you provided in sip.log, however please also include WARNING,ERROR, NOTICE, VERBOSE and DEBUG logging output. Please include them all in the same file, inline. Additionally include your sip.conf, rtp.conf and relevant dialplan required for reproduction. See: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Fabrizio Lombardozzi (fabrizio_lombardozzi) 2015-09-07 09:53:57.343-0500 Hi Rusty, here are more infos. Dialplan can be simply a simple echo test exten => _.,1,Answer exten => _.,2,echo exten => _.,3,wait(600) exten => _.,4,Hangup Let me know if I missed something Thanks Fabrizio By: Rusty Newton (rnewton) 2015-10-16 12:09:09.616-0500 Re-attaching some debug with different extension names for accessibility. By: Fabrizio Lombardozzi (fabrizio_lombardozzi) 2016-01-20 18:30:20.384-0600 I propose this patch to _kindly suggest_ {{chan_sip.c  add_ice_to_sdp()}} function to use *{{media_address}}* as specified in {{sip.conf}} By: Fabrizio Lombardozzi (fabrizio_lombardozzi) 2016-01-25 12:33:55.544-0600 committed on gerrit By: Sean Bright (seanbright) 2017-12-12 15:45:22.160-0600 Fixed in Asterisk 13.8.0 by https://gerrit.asterisk.org/#/c/2101/