Changes between Version 19 and Version 20 of Symbian_AP_Reconnection

Timestamp:

Jan 26, 2011 1:03:52 AM (14 years ago)

Author:

bennylp

Comment:

--

Symbian_AP_Reconnection

@@ -5 +5 @@
 }}}
 
-= IP Address change and Symbian Access Point Reconnection Issues =
+= IP Address change and Access Point Reconnection Issues =
 
 '''Table of Contents'''
@@ -16 +16 @@
 == Problem description ==
 
-Access point disconnection and reconnection are scenarios that need to be handled in mobile applications. Few issues or scenarios related to this for example are:
+IP address change and/or access point disconnection and reconnection are scenarios that need to be handled in mobile applications. Few issues or scenarios related to this for example are:
  - user moves outside the range of a Wi-Fi access point (AP) and lost the connection
  - user moves outside the range of one AP and reconnect to another
@@ -98 +98 @@
 
 [[BR]]
+
+== Issues with iPhone/TCP == #iphone
+
+[Update 2011/01/26]
+
+TCP is preferred on iPhone because of the background feature, but it has been reported that simply re-registering after an IP address change is detected may not work, presumably because the TCP socket itself is already in bad state and is unable to communicate anymore. The following steps can be used to perform re-registration with a new TCP transport:
+
+ 1. We need to keep track of which transport is being used by the registration, by implementing the {{{on_reg_state2()}}} callback. Add reference counter to it to prevent other from deleting the transport while we're referencing it (it shouldn't happen while the registration is active, but just in case). Sample code:
+ {{{
+static pjsua_acc_id the_acc_id;
+static pjsip_transport *the_transport;
+
+static void on_reg_state2(pjsua_acc_id acc_id, pjsua_reg_info *info)
+{
+   struct pjsip_regc_cbparam *rp = info->cbparam;
+
+ 
+    ...
+    if (acc_id != the_acc_id)
+        return;
+
+    if (rp->code/100 == 2 && rp->expiration > 0 && rp->contact_cnt > 0) {
+        /* Registration success */
+        if (the_transport) {
+            PJ_LOG(3,(THIS_FILE, "xxx: Releasing transport.."));
+            pjsip_transport_dec_ref(the_transport);
+            the_transport = NULL;
+        }
+        /* Save transport instance so that we can close it later when
+         * new IP address is detected.
+         */
+        PJ_LOG(3,(THIS_FILE, "xxx: Saving transport.."));
+        the_transport = rp->rdata->tp_info.transport;
+        pjsip_transport_add_ref(the_transport);
+    } else {
+        if (the_transport) {
+            PJ_LOG(3,(THIS_FILE, "xxx: Releasing transport.."));
+            pjsip_transport_dec_ref(the_transport);
+            the_transport = NULL;
+        }
+    }
+    ...
+}
+ }}}
+
+ 2. When IP address change is detected: a) send unregistration, and b) close the TCP transport that we saved in step 1) above. Sample code:
+ {{{
+pj_status_t status;
+
+PJ_LOG(3,(THIS_FILE, "xxx: IP change.."));
+
+status = pjsua_acc_set_registration(the_acc_id, PJ_FALSE);
+if (status != PJ_SUCCESS)
+    PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsua_acc_set_registration(0) error"));
+
+if (the_transport) {
+    status = pjsip_transport_shutdown(the_transport);
+    if (status != PJ_SUCCESS)
+        PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsip_transport_shutdown() error"));
+    pjsip_transport_dec_ref(the_transport);
+    the_transport = NULL;
+}
+
+}}}
+
+ 3. And finally, once unregistration in 2a) above is complete, re-register (with TCP). 
+
+Note that ideally the closing the TCP transport is done in step 3 and not in step 2b. The drawback with doing it in 2b is, when the unregistration request is challenged (i.e. step 2a resulted in 401 response being received), a new TCP transport will be created, and the request retry will be sent with this new TCP transport. Your server may not like this, since it will see the unregistration request is coming from different TCP connection than the original request.  But having said that, the existing TCP transport may not be in usable state anyway, so I suppose this is not a worse situation than that. But in general, you may need to tweak the timing of this closing the transport part (you may even want to put it before 2a).
 
 == Symbian specific issues and solution == #sym