[Freeswitch-users] Error in codec negotiation: What are all the places that specify accepted codecs for outgoing calls?

Mark Boots mark at votomobile.org
Wed Jul 16 03:20:21 MSD 2014


Hi Kristian,

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.

Thanks for the help and guidance!
+Mark

On Jun 10, 2014, at 2:34 PM, freeswitch-users-request at lists.freeswitch.org wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140715/5d91cbaf/attachment-0001.html 


Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list