[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