Changes between Version 13 and Version 14 of Symbian_AP_Reconnection


Ignore:
Timestamp:
Mar 2, 2009 3:56:00 PM (10 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Symbian_AP_Reconnection

    v13 v14  
    197197The '''{{{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()}}}. 
    198198 
    199 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. 
     199Note 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. 
     200 
     201We think that this is a problem with the socket in general. Below are steps to reproduce with a plain UDP socket:  
     202 1. Create RConnection, call Start() to connect to AP  
     203 2. Create UDP socket, call !SendTo() to send a packet  
     204 3. Disconnect the AP (Menu -> Connectivity -> Conn. mgr. -> Active data connections -> (highlight the AP) -> Options (menu) -> Disconnect).  
     205 4. Call udp.!SendTo() again  
     206 5. AP selection dialog appears, select different AP  
     207 6. !WaitForRequest() to the udp.!SendTo() operation now '''will get stuck for 1-2 minutes''' before ''tcpip6_error_NoRoute'' error (-5105) is returned.  
     208 7. Now if you call udp.!SendTo() again, now !WaitForRequest() will get stuck indefinitely  
     209 
     210The problem above does not occur if:  
     211- the user selects the same AP. In this case the udp.!SendTo() should complete successfully  
     212- the user cancels the AP selection dialog. In this case the udp.!SendTo() will fail immediately with KErrCancel without blocking the application.  
     213- the socket is closed and re-opened. In this case the udp.!SendTo() should complete successfully  
     214 
     215As additional info:  
     216- 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.  
     217 
     218 
     219 
    200220 
    201221{{{