Changes between Version 7 and Version 8 of Symbian_AP_Reconnection

Timestamp:

Feb 25, 2009 5:57:52 PM (15 years ago)

Author:

bennylp

Comment:

--

Symbian_AP_Reconnection

@@ -106 +106 @@
 This is a problem with the socket in general and not PJSIP. Below are steps to reproduce with a plain UDP socket:
  1. Create RConnection, call Start() to connect to AP
- 1. Create UDP socket, call !SendTo() to send a packet
- 1. Disconnect the AP (Menu -> Connectivity -> Conn. mgr. -> Active data connections -> (highlight the AP) -> Options (menu) -> Disconnect).
- 1. Call udp.!SendTo() again
- 1. AP selection dialog appears, select different AP
- 1. !WaitForRequest() to the udp.!SendTo() operation now '''will get stuck for 1-2 minutes'''.
- 1. Now if you call udp.!SendTo() again, now !WaitForRequest() will get stuck indefinitely
+ 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:
@@ -117 +117 @@
  - 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.
+
 
 Currently we don't have a solution for this, except to only use one AP (perhaps to select the AP when PJSIP is started and lock the RConnection that is assigned to PJLIB to this AP).