Changes between Version 13 and Version 14 of Symbian_AP_Reconnection

Timestamp:

Mar 2, 2009 3:56:00 PM (15 years ago)

Author:

bennylp

Comment:

--

Symbian_AP_Reconnection

@@ -197 +197 @@
 The '''{{{pj_symbianos_set_connection_status()}}}''' API was added in PJSIP version 1.0.2/1.1. This function is used to tell PJLIB that it should not access any socket calls anymore since the connection has been down. Without this function, Symbian will pop up the access point selection dialog again in {{{pjsua_destroy()}}}, and if the user selects different access point then it will cause the socket to block indefinitely in {{{WaitForRequest()}}}.
 
-Note that the drawback with this approach is that it does not clean up the registration and calls properly, that is no SIP unregistration will be sent and if the application is in the middle of a call while the connection is down then no BYE will be sent either.
+Note that the drawback with this approach is that it does not clean up the registration and calls properly, that is no SIP unregistration will be sent and if the application is in the middle of a call while the connection is down then no BYE will be sent either. Currently we can't suggest any other solution, as we can't get rid of the socket get stuck problem.
+
+We think that this is a problem with the socket in general. Below are steps to reproduce with a plain UDP socket: 
+ 1. Create RConnection, call Start() to connect to AP 
+ 2. Create UDP socket, call !SendTo() to send a packet 
+ 3. Disconnect the AP (Menu -> Connectivity -> Conn. mgr. -> Active data connections -> (highlight the AP) -> Options (menu) -> Disconnect). 
+ 4. Call udp.!SendTo() again 
+ 5. AP selection dialog appears, select different AP 
+ 6. !WaitForRequest() to the udp.!SendTo() operation now '''will get stuck for 1-2 minutes''' before ''tcpip6_error_NoRoute'' error (-5105) is returned. 
+ 7. Now if you call udp.!SendTo() again, now !WaitForRequest() will get stuck indefinitely 
+
+The problem above does not occur if: 
+- the user selects the same AP. In this case the udp.!SendTo() should complete successfully 
+- the user cancels the AP selection dialog. In this case the udp.!SendTo() will fail immediately with KErrCancel without blocking the application. 
+- the socket is closed and re-opened. In this case the udp.!SendTo() should complete successfully 
+
+As additional info: 
+- the problem still persists even if the RConnection is restarted (RConnection.Start() is called to select new AP) in between step 3 and 4 above. 
+
+
+
 
 {{{