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@lists.freeswitch.org wrote:

Send FreeSWITCH-users mailing list submissions to
freeswitch-users@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@lists.freeswitch.org

You can reach the person managing the list at
freeswitch-users-owner@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@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@lists.freeswitch.org>
Reply-To: FreeSWITCH Users Help <freeswitch-users@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@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@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@lists.freeswitch.org>
Reply-To: FreeSWITCH Users Help <freeswitch-users@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@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@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@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@54.203.245.50>;tag=9Z1HtD145Qv3K
  To: <sip:0011104555592211972@108.59.2.133>
  Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0
  CSeq: 60838805 INVITE
  Contact:
<sip:gw+voxbeam_outbound@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@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@54.203.245.50>;tag=9Z1HtD145Qv3K
  To: <sip:0011104555592211972@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@54.203.245.50>;tag=9Z1HtD145Qv3K
  To: <sip:0011104555592211972@108.59.2.133>;tag=9312047651043624688
  Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0
  CSeq: 60838805 INVITE
  Content-Type: application/sdp
  Contact: <sip:callee@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@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@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@lists.freeswitch.org>
Reply-To: FreeSWITCH Users Help <freeswitch-users@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@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@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@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@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@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org