Changes between Version 17 and Version 18 of Symbian_AP_Reconnection


Ignore:
Timestamp:
Mar 3, 2009 10:52:11 AM (15 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Symbian_AP_Reconnection

    v17 v18  
    1010[[PageOutline(2-3,,inline)]] 
    1111 
    12 This article describes some issues and their corresponding solutions related to access point disconnection, reconnection, and change in your PJSIP applications. The general issues related to the discussion will be explained, along with some specific issues to Symbian applications. 
     12This article describes some issues and their corresponding solutions related to access point disconnection, reconnection, IP address change, and how to handle these events in your PJSIP applications. The general issues related to the discussion will be explained, along with some specific issues to Symbian applications. 
    1313 
    1414[[BR]] 
    … …  
    3333 - if there is ongoing dialog, the remote party needs to be informed with new Contact URI as well as new media (RTP/RTCP) addresses. 
    3434 
    35 Note that at this time of writing (2009/02/25, PJSIP v1.1), PJSIP does not have the capability to monitor the status of the underlying IP connection used by the application, so the application must implement the detection itself (for example using connection progress monitor in Symbian). Having said that, PJSIP does have some capability to detect some IP address change scenarios, for example by monitoring the IP address in SIP REGISTER response or in STUN Binding response when ICE transport is used and STUN is enabled. 
     35Note that the monitoring of connection/interface status is outside the scope of PJSIP, so the application must implement this itself (for example using connection progress monitor in Symbian). Having said that, PJSIP does have some capability to detect some IP address change scenarios, for example by monitoring the IP address in SIP REGISTER response or in STUN Binding response when ICE transport is used and STUN is enabled. 
    3636 
    3737Once the application has detected that the IP interface address has changed, there are two solutions to inform PJSIP about this. 
    … …  
    3939[[BR]] 
    4040 
    41 === Restart everything === 
     41=== Approach 1: Restart everything === 
    4242 
    4343The most straightforward solution is of course to restart everything, which means in pjsua terms to call {{{pjsua_destroy()}}} and followed by {{{pjsua_create()}}}, {{{pjsua_init()}}}, and so on. While this solution may sound crude, it is the easiest to do and as will be explained later it is not considerably worse then the more refined alternative. 
    … …  
    4545[[BR]] 
    4646 
    47 === Selective update === 
     47=== Approach 2: Selective update === 
    4848 
    4949Alternatively there may be a way to allow the stack to continue to run, updating the address information when necessary. This approach will require some specific features to be used, as well as some actions by the application when it detects that the IP address has changed.  
    … …  
    9696 
    9797 
    98 [[BR]] 
    99  
    100 == Symbian specific solution == #sym 
    101  
    102 In Symbian, the {{{RConnection.ProgressNotification()}}} method can be used to register an Active Object to be run when the connection status has changed. Below is a sample code taken from {{{symbian_ua\ua.cpp}}} file to restart PJSIP when the connection is down. 
     98 
     99[[BR]] 
     100 
     101== Symbian specific issues and solution == #sym 
     102 
     103Being a mobile operating system, Symbian has a good support in managing access point connection. In Symbian, the {{{RConnection}}} object is used to manage the connection, and each socket ''handle'' ({{{RSocket}}}) is created in a context of an {{{RConnection}}}. The {{{RConnection.ProgressNotification()}}} method can be used to register an Active Object to be run when the connection status has changed, so the application has good control over the connection. 
     104 
     105However there are still couple of unsolved issues remaining (probably due to lack of knowledge in our part): 
     106 - when the connection in {{{RConnection}}} is down, it seems that the sockets created with that RConnection will detach themselves from the connection, so even though the RConnection is reconnected, this will not automatically make the sockets recover to a "good" state. If the application tries to make use of the socket, for example, to call {{{!SendTo()}}}, it will cause the socket to pop up the access point selection dialog again 
     107 - more over, if user selects different access point in the dialog, this will put the sockets in somewhat worse state. If the application tries to make use of the socket, for example, to call {{{!SendTo()}}}, it will cause the !TRequestStatus associated with the operation to block for a long time (about one and half minute). And even worse, a second call to {{{!SendTo()}}} will cause the !TRequestStatus to block indefinitely! 
     108 
     109At the moment we are not aware of any solutions for the above issues. Lacking this, we created a workaround in PJLIB to prevent it from accessing any Symbian socket API's when the connection has been down and reconnected. The API is '''{{{pj_symbianos_set_connection_status()}}}''' and it was added in PJSIP version 1.0.2/1.1 (ticket #733 and #732 respectively).  
     110 
     111Below is a sample code, implemented in {{{symbian_ua\ua.cpp}}} sample application, to restart PJSIP and use the {{{pj_symbianos_set_connection_status()}}} function. 
    103112 
    104113 {{{ 
    … …  
    195204What the code in {{{RunL()}}} above does is it shuts down PJSIP when the connection is down, ask user to reconnect by showing up the access point dialog, and (re)start the application. 
    196205 
    197 The '''{{{pj_symbianos_set_connection_status()}}}''' API was added in PJSIP version 1.0.2/1.1 (ticket #733 and #732 respectively). 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()}}}. 
    198  
    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. Currently we can't suggest any other solution, as we can't get rid of the socket get stuck problem. 
    200  
    201 '''Note about the socket stuck problem''' 
     206Note 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 gets stuck problem. 
     207 
     208'''More about the socket stuck problem''' 
    202209 
    203210This is a problem with the socket in general. Below are steps to reproduce with a plain UDP socket: