<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Kristian,<div><br></div><div>Sorry for the delay. Just to finally close off this thread, I tested with the 1.4 branch and that solved it. I haven’t seen any more of these INCOMPATIBLE_DESTINATION errors after the proxy fork and renegotiation. 100rel didn’t turn out to be necessary.</div><div><br></div><div>Thanks for the help and guidance!</div><div>+Mark</div><div><br><div><div>On Jun 10, 2014, at 2:34 PM, <a href="mailto:freeswitch-users-request@lists.freeswitch.org">freeswitch-users-request@lists.freeswitch.org</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Send FreeSWITCH-users mailing list submissions to<br><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:freeswitch-users@lists.freeswitch.org">freeswitch-users@lists.freeswitch.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><span class="Apple-tab-span" style="white-space:pre"> </span>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>or, via email, send a message with subject or body 'help' to<br><span class="Apple-tab-span" style="white-space:pre"> </span>freeswitch-users-request@lists.freeswitch.org<br><br>You can reach the person managing the list at<br><span class="Apple-tab-span" style="white-space:pre"> </span>freeswitch-users-owner@lists.freeswitch.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of FreeSWITCH-users digest..."<br>Today's Topics:<br><br> 1. Re: Error in codec negotiation: What are all the places that<br> specify accepted codecs for outgoing calls? (Kristian Kielhofner)<br> 2. Re: STUN Binding request times out after 200 OK<span class="Apple-tab-span" style="white-space:pre"> </span>received on<br> client (Michael Jerris)<br><br><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica';">Kristian Kielhofner <kris@kriskinc.com><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica';"><b>Re: [Freeswitch-users] Error in codec negotiation: What are all the places that specify accepted codecs for outgoing calls?</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica';">June 10, 2014 at 2:28:27 PM CST<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica';">FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Reply-To: </b></span><span style="font-family:'Helvetica';">FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org><br></span></div><br><br>Mark,<br><br> Have you tried any of my original suggestions?<br><br> You have a good point on the behavior of FreeSWITCH for codec<br>negotiation in this specific scenario and although I can't point to a<br>commit I seem to recall that 1.4/master tweaked this behavior<br>significantly; it may "just work" for you. 100rel might be a good<br>option too but that could come with some other unintended effects.<br><br>On Tue, Jun 10, 2014 at 11:12 AM, Mark Boots <mark@votomobile.org> wrote:<br><blockquote type="cite">Given that our provider does this 40% of the time in multiple countries, is<br>there anything we can do to get this working with Freeswitch?<br><br>It seems logical for this to work: we offered a range of codecs, the other<br>end chose one, then for another part of the call chose another. Both codecs<br>are supported by our end, so why should we reject the second just because<br>another was used first?<br><br>According to the console, Freeswitch is doing a codec renegotiation<br>process... It's just not accepting anything other than 1 codec at this<br>point.<br><br>+Mark<br><br>From: Michael Jerris <mike@jerris.com><br>Subject: Re: [Freeswitch-users] Error in codec negotiation: What are all the<br>places that specify accepted codecs for outgoing calls?<br>Date: 10 June 2014 12:42:31 GMT<br>To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org><br>Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org><br><br><br>Hmm, not sure thats true. You are not supposed to change codecs before the<br>dialog is complete like this, its a violation of sdp o/a.<br><br>On Jun 10, 2014, at 4:50 AM, Kristian Kielhofner <kris@kriskinc.com> wrote:<br><br>Hi Mark,<br><br> Thanks for providing the full log.<br><br> While goofy this is perfectly valid behavior. Because your instance of<br>Freeswitch offers pcma and pcmu it's ok for the other side to switch between<br>the two in 183.<br><br> A few things to try:<br><br>- Limit your outbound offers to pcma or pcmu only (one codec).<br><br>- The remote side appears to support 100rel (PRACK). Try enabling it in<br>Freeswitch. While a long shot it's possible that PRACK'ing the initial<br>received 183 might change the codec swap behavior of the remote end.<br><br>- Try Freeswitch 1.4 or master. There's been some significant changes in<br>media/SDP behavior, particularly when the remote end does technically<br>standards compliant but goofy things with multiple codec offers.<br><br> If none of these works you're only option may be to have the carrier take<br>some action.<br><br>On Monday, June 9, 2014, Mark Boots <mark@votomobile.org> wrote:<br><blockquote type="cite"><br>Hi Kristian,<br><br>I've narrowed this INCOMPATIBLE_DESTINATION error down to a specific case:<br><br>1 - Freeswitch sends the outgoing call, and offers PCMU/PCMA/GSM<br>2 - Other end accepts only PCMU<br>3 - At some point after Pre-answer, the other end issues a 183 Session<br>Progress, changing to only accept PCMA.<br>4 - Freeswitch attempts to select new codecs but only looks at PCMU, and<br>cancels the call with INCOMPATIBLE_DESTINATION.<br><br><br>Here is the console log and sip trace... Hope it helps!<br><br>+Mark<br><br>2014-06-09 21:35:39.615207 [DEBUG] switch_ivr_originate.c:2069 Parsing<br>global variables<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[plivo_request_uuid]=[004fd8a2-f01e-11e3-844d-22000ad937f0]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[plivo_answer_url]=[http://10.8.0.1/deliverylogs/answer/752471]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[plivo_ring_url]=[http://127.0.0.1/callqueue/ring.php]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[plivo_hangup_url]=[http://127.0.0.1/callqueue/hangup.php]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[origination_caller_id_number]=[12026004299]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[plivo_from]=[12026004299]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[plivo_to]=[0011104555592211972]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[plivo_app]=[true]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[originate_timeout]=[60]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable<br>[ignore_early_media]=[true]<br>2014-06-09 21:35:39.615207 [NOTICE] switch_channel.c:1049 New Channel<br>sofia/external/0011104555592211972 [005052e6-f01e-11e3-bbae-cbf0f4eac998]<br>2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:5237<br>(sofia/external/0011104555592211972) State Change CS_NEW -> CS_INIT<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1351 Send signal<br>sofia/external/0011104555592211972 [BREAK]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:418<br>(sofia/external/0011104555592211972) Running State Change CS_INIT<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:458<br>(sofia/external/0011104555592211972) State INIT<br>2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:87<br>sofia/external/0011104555592211972 SOFIA INIT<br>2014-06-09 21:35:39.615207 [DEBUG] sofia_glue.c:2746<br>sofia/external/0011104555592211972 sending invite version: 1.2.24 git<br>7b74ee3 2014-06-03 00:26:24Z 32bit<br>Local SDP:<br>v=0<br>o=FreeSWITCH 1402325141 1402325142 IN IP4 54.203.245.50<br>s=FreeSWITCH<br>c=IN IP4 54.203.245.50<br>t=0 0<br>m=audio 24598 RTP/AVP 0 8 3 101 13<br>a=rtpmap:101 telephone-event/8000<br>a=fmtp:101 0-16<br>a=ptime:20<br>a=sendrecv<br><br>2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:127<br>(sofia/external/0011104555592211972) State Change CS_INIT -> CS_ROUTING<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1351 Send signal<br>sofia/external/0011104555592211972 [BREAK]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:458<br>(sofia/external/0011104555592211972) State INIT going to sleep<br>send 1071 bytes to udp/[108.59.2.133]:5060 at 21:35:39.620673:<br><br>------------------------------------------------------------------------<br> INVITE sip:0011104555592211972@108.59.2.133 SIP/2.0<br> Via: SIP/2.0/UDP 54.203.245.50:5080;rport;branch=z9hG4bKUNeNtZcZp5ZmB<br> Max-Forwards: 70<br> From: "" <sip:12026004299@54.203.245.50>;tag=9Z1HtD145Qv3K<br> To: <sip:0011104555592211972@108.59.2.133><br> Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0<br> CSeq: 60838805 INVITE<br> Contact:<br><sip:gw+voxbeam_outbound@54.203.245.50:5080;transport=udp;gw=voxbeam_outbound><br> User-Agent:<br>FreeSWITCH-mod_sofia/1.2.24+git~20140603T002624Z~7b74ee3955~32bit<br> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,<br>REGISTER, REFER, NOTIFY<br> Supported: timer, path, replaces<br> Allow-Events: talk, hold, conference, refer<br> Content-Type: application/sdp<br> Content-Disposition: session<br> Content-Length: 207<br> X-FS-Support: update_display,send_info<br> Remote-Party-ID:<br><sip:12026004299@54.203.245.50>;party=calling;screen=yes;privacy=off<br><br> v=0<br> o=FreeSWITCH 1402325141 1402325142 IN IP4 54.203.245.50<br> s=FreeSWITCH<br> c=IN IP4 54.203.245.50<br> t=0 0<br> m=audio 24598 RTP/AVP 0 8 3 101 13<br> a=rtpmap:101 telephone-event/8000<br> a=fmtp:101 0-16<br> a=ptime:20<br><br>------------------------------------------------------------------------<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1016 Send signal<br>sofia/external/0011104555592211972 [BREAK]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:418<br>(sofia/external/0011104555592211972) Running State Change CS_ROUTING<br>2014-06-09 21:35:39.615207 [DEBUG] sofia.c:5845 Channel<br>sofia/external/0011104555592211972 entering state [calling][0]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:474<br>(sofia/external/0011104555592211972) State ROUTING<br>2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:150<br>sofia/external/0011104555592211972 SOFIA ROUTING<br>2014-06-09 21:35:39.615207 [DEBUG] switch_ivr_originate.c:67<br>(sofia/external/0011104555592211972) State Change CS_ROUTING -><br>CS_CONSUME_MEDIA<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1351 Send signal<br>sofia/external/0011104555592211972 [BREAK]<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:474<br>(sofia/external/0011104555592211972) State ROUTING going to sleep<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:418<br>(sofia/external/0011104555592211972) Running State Change CS_CONSUME_MEDIA<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:493<br>(sofia/external/0011104555592211972) State CONSUME_MEDIA<br>2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:493<br>(sofia/external/0011104555592211972) State CONSUME_MEDIA going to sleep<br>recv 367 bytes from udp/[108.59.2.133]:5060 at 21:35:39.725204:<br><br>------------------------------------------------------------------------<br> SIP/2.0 100 Giving a try<br> Via: SIP/2.0/UDP<br>54.203.245.50:5080;received=54.203.245.50;rport=5080;branch=z9hG4bKUNeNtZcZp5ZmB<br> From: "" <sip:12026004299@54.203.245.50>;tag=9Z1HtD145Qv3K<br> To: <sip:0011104555592211972@108.59.2.133><br> Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0<br> CSeq: 60838805 INVITE<br> Server: OpenSIPS (1.8.2-notls (x86_64/linux))<br> Content-Length: 0<br><br><br>------------------------------------------------------------------------<br>recv 657 bytes from udp/[108.59.2.133]:5060 at 21:35:41.191275:<br><br>------------------------------------------------------------------------<br> SIP/2.0 183 Session Progress<br> Via: SIP/2.0/UDP 54.203.245.50:5080;rport;branch=z9hG4bKUNeNtZcZp5ZmB<br> From: "" <sip:12026004299@54.203.245.50>;tag=9Z1HtD145Qv3K<br> To: <sip:0011104555592211972@108.59.2.133>;tag=9312047651043624688<br> Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0<br> CSeq: 60838805 INVITE<br> Content-Type: application/sdp<br> Contact: <sip:callee@108.59.2.133;did=795.65454242><br> Supported: timer,100rel<br> Content-Length: 226<br><br> v=0<br> o=RISNEXT02 869 1999 IN IP4 80.84.30.41<br> s=sip call<br> c=IN IP4 80.84.30.41<br> t=0 0<br> m=audio 42108 RTP/AVP 0 13 101<br> a=rtpmap:0 PCMU/8000<br> a=rtpmap:13 CN/8000<br> a=rtpmap:101 telephone-event/8000<br> a=fmtp:101 0-16<br> a=ptime:20<br><br>------------------------------------------------------------------------<br>2014-06-09 21:35:41.175213 [DEBUG] switch_core_session.c:1016 Send signal<br>sofia/external/0011104555592211972 [BREAK]<br>2014-06-09 21:35:41.175213 [DEBUG] switch_core_session.c:1016 Send signal<br>sofia/external/0011104555592211972 [BREAK]<br>2014-06-09 21:35:41.175213 [DEBUG] sofia.c:5845 Channel<br>sofia/external/0011104555592211972 entering state [proceeding][183]<br>2014-06-09 21:35:41.175213 [DEBUG] sofia.c:5858 Remote SDP:<br>v=0<br>o=RISNEXT02 869 1999 IN IP4 80.84.30.41<br>s=sip call<br>c=IN IP4 80.84.30.41<br>t=0 0<br>m=audio 42108 RTP/AVP 0 13 101<br>a=rtpmap:0 PCMU/8000<br>a=rtpmap:13 CN/8000<br>a=rtpmap:101 telephone-event/8000<br>a=fmtp:101 0-16<br>a=ptime:20<br><br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:5284 Audio Codec Compare<br>[PCMU:0:8000:20:64000]/[PCMU:0:8000:20:64000]<br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3192 Set Codec<br>sofia/external/0011104555592211972 PCMU/8000 20 ms 160 samples 64000 bits<br>2014-06-09 21:35:41.175213 [DEBUG] switch_core_codec.c:111<br>sofia/external/0011104555592211972 Original read codec set to PCMU:0<br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:5444 Set 2833 dtmf send<br>payload to 101<br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3451 AUDIO RTP<br>[sofia/external/0011104555592211972] 10.217.55.240 port 24598 -> 80.84.30.41<br>port 42108 codec: 0 ms: 20<br>2014-06-09 21:35:41.175213 [DEBUG] switch_rtp.c:2040 Starting timer [soft]<br>160 bytes per 20ms<br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3718 Set 2833 dtmf send<br>payload to 101<br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3724 Set 2833 dtmf receive<br>payload to 101<br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3751<br>sofia/external/0011104555592211972 Set rtp dtmf delay to 40<br>2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3757 Set comfort noise<br>payload to 13<br>2014-06-09 21:35:41.175213 [NOTICE] sofia_glue.c:4362 Pre-Answer<br>sofia/external/0011104555592211972!<br></blockquote><br><br><br><br><br>_______________________________________________<br>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org<br><br>_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br>consulting@freeswitch.org<br>http://www.freeswitchsolutions.com<br><br>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>http://www.cudatel.com<br><br>Official FreeSWITCH Sites<br>http://www.freeswitch.org<br>http://wiki.freeswitch.org<br>http://www.cluecon.com<br><br>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org<br><br></blockquote><br><br><br>-- <br>Kristian Kielhofner<br><br><br><br><br><br><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica';">Michael Jerris <mike@jerris.com><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica';"><b>Re: [Freeswitch-users] STUN Binding request times out after 200 OK received on client</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica';">June 10, 2014 at 2:33:30 PM CST<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica';">FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Reply-To: </b></span><span style="font-family:'Helvetica';">FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org><br></span></div><br><br><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">so that for sure doesn't have the fix i'm thinking in it. Can you try git master on freeswitch and see if that works any better?<div><br><div><div>On Jun 10, 2014, at 8:25 PM, Peter Villeneuve <<a href="mailto:petervnv1@gmail.com">petervnv1@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I'm using FreeSWITCH Version 1.5.13b+git~20140515T183425Z~ebc0a99f1c~64bit.<div>Server is on a public IP. What version of CSipSimple did Tony use to test?</div><div><br></div><div>There have been some changes recently to ICE in CSip. I'm using latest nightly release (2414) <a href="http://nightlies.csipsimple.com/trunk/">http://nightlies.csipsimple.com/trunk/</a> with ICE set to aggressive mode.</div>
<div><br></div><div>Also, I have Kamailio in front of FS on the same server, but that shouldn't really be an issue, no?</div><div><br></div><div>Anyway, I have some FS logs posted here if you want to take a closer look <a href="http://pastebin.com/WNGcpTqB">http://pastebin.com/WNGcpTqB</a></div>
<div><br></div><div>But I did just confirm that all works as expected with ICE turned off in CSip.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 10, 2014 at 9:13 PM, Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Tony just tested this and it worked with csipsimple. Can you confirm if you are testing with freeswitch from latest git master? is the server side on a public ip or behind nat?<div>
<br></div><div>Mike</div><div><div class="h5"><br><div><div>On Jun 10, 2014, at 5:43 PM, Peter Villeneuve <<a href="mailto:petervnv1@gmail.com" target="_blank">petervnv1@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">I think Michael's insight appears to be correct.<div>I say this because I also can't seem to get ICE to work correctly with FS when using the CSipSimple client with ICE support.</div><div><br></div>
<div>
As you can see in the CSipSimple logs here, it seems that FS fails to correctly respond to the STUN binding request, and thus ICE negotiation fails:</div><div><br></div><div><div>17:17:58.927 icetp00 ..Triggered check for check 1 not performed because it's in progress. Retransmitting</div>
<div>17:17:58.927 utsx0x5dee930c ...STUN sending message (transmit count=7)</div><div>17:17:59.040 timer_android. !FIRE timer 26 of heap 16</div><div>17:17:59.040 utsx0x5f6e659c STUN timeout waiting for response</div><div>
17:17:59.040 icetp00 .Check 2: [2] 192.168.1.4:4037-->79.my.serverIP:62203 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)</div><div>17:17:59.040 icetp00 ..Check 2: [2] 192.168.1.4:4037-->79.my.serverIP:62203: state changed from In Progress to Failed</div>
<div>17:17:59.040 stun_session.c .tdata 0x5f6e6484 destroy request, force=1, tsx=0x5f6e659c</div><div>17:17:59.040 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5f6e65dc</div><div>17:17:59.040 utsx0x5f6e659c .STUN client transaction 0x5f6e659c stopped, ref_cnt=46</div>
<div>17:17:59.041 timer_android. FIRE done and released</div><div>17:17:59.238 timer_android. FIRE timer 27 of heap 16</div><div>17:17:59.238 utsx0x5d9a080c STUN timeout waiting for response</div><div>17:17:59.238 icetp00 .Check 0: [1] 192.168.1.4:4001-->79.my.serverIP:62202 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)</div>
<div>17:17:59.239 icetp00 ..Check 0: [1] 192.168.1.4:4001-->79.my.serverIP:62202: state changed from In Progress to Failed</div><div>17:17:59.239 stun_session.c .tdata 0x5d9a06f4 destroy request, force=1, tsx=0x5d9a080c</div>
<div>17:17:59.239 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5d9a084c</div><div>17:17:59.239 utsx0x5d9a080c .STUN client transaction 0x5d9a080c stopped, ref_cnt=45</div><div>17:17:59.239 timer_android. FIRE done and released</div>
<div>17:17:59.257 timer_android. FIRE timer 28 of heap 16</div><div>17:17:59.257 utsx0x5dee930c STUN timeout waiting for response</div><div>17:17:59.257 icetp00 .Check 1: [1] 79.my.serverIP:56378-->79.my.serverIP:62202 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)</div>
<div>17:17:59.257 icetp00 ..Check 1: [1] 79.my.serverIP:56378-->79.my.serverIP:62202: state changed from In Progress to Failed</div><div>17:17:59.258 stun_session.c .tdata 0x5dee91f4 destroy request, force=1, tsx=0x5dee930c</div>
<div>17:17:59.258 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5dee934c</div><div>17:17:59.258 utsx0x5dee930c .STUN client transaction 0x5dee930c stopped, ref_cnt=44</div><div>17:17:59.258 timer_android. FIRE done and released</div>
<div>17:17:59.273 timer_android. FIRE timer 34 of heap 16</div><div>17:17:59.274 utsx0x5da8db64 STUN timeout waiting for response</div><div>17:17:59.274 icetp00 .Check 3: [2] 79.my.serverIP2:54506-->79.my.serverIP:62203 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)</div>
<div>17:17:59.274 icetp00 ..Check 3: [2] 79.my.serverIP2:54506-->79.my.serverIP:62203: state changed from In Progress to Failed</div><div>17:17:59.274 timer_android. ..Ask to cancel something already fired or cancelled : -1 @ 0x5dc0b400</div>
<div>17:17:59.274 icetp00 ..ICE process complete, status=All ICE checklists failed (PJNATH_EICEFAILED)</div><div>17:17:59.274 icetp00 ..Valid list</div><div>17:17:59.274 timer_android. ..Scheduling timer 30 of 16 in 0 ms @ 0x5dc0b400</div>
<div>17:17:59.278 stun_session.c .tdata 0x5da8da4c destroy request, force=1, tsx=0x5da8db64</div><div>17:17:59.278 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5da8dba4</div><div>17:17:59.278 utsx0x5da8db64 .STUN client transaction 0x5da8db64 stopped, ref_cnt=45</div>
<div>17:17:59.278 timer_android. FIRE done and released</div><div>17:17:59.289 timer_android. FIRE timer 30 of heap 16</div><div>17:17:59.289 icetp00 ICE negotiation failed after 8s:424: All ICE checklists failed (PJNATH_EICEFAILED)</div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 10, 2014 at 3:27 PM, Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Its possible that we have some conditions wrong for non-webrtc ice. You are going to need to trace the switch_core_media code a bit and see how we parse the sdp, what we are expecting, and how we turn on ice. I suspect we have conditions that tie some of the ice functionality incorrectly to other things required for webrtc.<br>
<div><br>
<br>
On Jun 10, 2014, at 2:09 PM, Jayesh Nambiar <<a href="mailto:jayesh1017@gmail.com" target="_blank">jayesh1017@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
> I am developing an iOS calling App with libnice for ICE capabilities. The calls go through freeswitch and since freeswitch supports ICE, I expected it to work out of the box. But I have a problem. The way libnice works is as follows:<br>
> 1) The client sends INVITE with his candidates.<br>
> 2) Freeswitch parses the candidates.<br>
> 3) Immediately after 200 OK is received, I can see FreeSWITCH choosing an ICE candidate and logging "Activating Audio ICE" indicating the IP and Port and it sends media/RTP to.<br>
> 4) But the libnice agent tries to look at the candidates received in 200 OK and tries to send a STUN binding request to FreeSWITCH IP as that IP is mentioned as ICE candidate in the 200 OK coming from freeswitch.<br>
> 5) The FreeSWITCH doesn't respond to that STUN binding request and libnice agent times out.<br>
> 6) Ideally, if libnice gets back a response from the freeswitch, it should initiate a Re-INVITE with the candidate pair selected.<br>
><br>
> Now here, the freeswitch starts sending RTP to client's candidate, but the client gets stuck because the candidate pair is not formed as the libnice agent keeps waiting for a response for the STUN Binding Request.<br>
> Is there anything that I am missing here. Any help is highly appreciated.<br>
<br>
<br>
</div>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com/" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com/" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org/" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br></div>
_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br><a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br><a href="http://www.freeswitchsolutions.com/" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br><a href="http://www.cudatel.com/" target="_blank">http://www.cudatel.com</a><br><br>Official FreeSWITCH Sites<br><a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org/" target="_blank">http://wiki.freeswitch.org</a><br><a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com</a><br><br>FreeSWITCH-users mailing list<br><a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div></div></div><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com/" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com/" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org/" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>
_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br><a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>http://www.freeswitchsolutions.com<br><br>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>http://www.cudatel.com<br><br>Official FreeSWITCH Sites<br>http://www.freeswitch.org<br>http://wiki.freeswitch.org<br>http://www.cluecon.com<br><br>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org<br></blockquote></div><br></div></div><br><br>_______________________________________________<br>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org<br></blockquote></div><br></div></body></html>