#126 STUN Resolution on Change between WiFi and Mobile Data

[Anonymous]

Originally created by: dc3de...@gmail.com
Originally owned by: dc3de...@gmail.com

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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

Related to [r114]

[Anonymous]

Originally posted by: dc3de...@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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).

Status: NextRelease