STUN Resolution on Change between WiFi and Mobile Data

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable WiFi and 3G in CSipSimple
2. Enable NAT and fill in NAT server:port
3. Turn on WiFI, let CSip register
4. Test to see if NAT is working (2-way audio). If not, Kill CSip and try again 
until you have a good NAT info.
5. Turn off WiFi, let CSip re-register over 3G
6. Try a call

What is the expected output? What do you see instead?

Expected: 2-way audio, indicating that NAT is working again
Found: One-way or no audio - NAT is not working

If CSip is killed and re-started at this point, it will get valid NAT info and 
calls will succeed with 2-way audio.

FURTHER INFO

I think we need to implement NAT re-resolution on connectivity change. The 
functions that are (apparently) needed are not in JNI. They seem to be (at 
least) pjsua_resolve_stun_servers() and its callback pj_stun_resolve_cb(). It 
may also be necessary to implement pjsua_detect_nat_type() and 
pjsua_get_nat_type(), as well as the on_nat_detect() callback.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by dc3de...@gmail.com on 3 Aug 2010 at 5:12

[GoogleCodeExporter]

Related to r114

Original comment by dc3de...@gmail.com on 3 Aug 2010 at 5:19

[GoogleCodeExporter]

Corrections: In my original post, many references to NET should be to STUN. 
Detection of NAT type is deprecated. pjsua_detect_nat_type() and 
pjsua_get_nat_type() should not be used. Use RFC5389 STUN.

Original comment by dc3de...@gmail.com on 3 Aug 2010 at 6:00

[GoogleCodeExporter]

Last version -12-29 should be better regarding this issue since the stack is 
now completely restarted (as it's done on the symbian implementation of pjsip 
and advised by pjsip guys).

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 8:39

• Changed state: NextRelease