alexchengalan / csipsimple

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

STUN Resolution on Change between WiFi and Mobile Data #126

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
Related to r114

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

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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