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.