Changes between Version 7 and Version 8 of IPAddressChange

Timestamp:

Aug 26, 2011 7:37:39 AM (13 years ago)

Author:

bennylp

Comment:

--

IPAddressChange

@@ -113 +113 @@
 [[BR]]
 
-== Issues with iPhone/TCP == #iphone
+== Handling IP Change on iPhone == #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:
-
+[Update 2011/08/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. For a demonstration, please apply {{{iphone_ip_change_pjsip_1_12.patch}}} attached (see the bottom of this page). The patch is tested on version pjsip-1.12.
+
+ 0. You need to implement reachability API (sample is provided in the patch). With this API we can monitor the access point connection status and perform re-registration when necessary.
  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:
  {{{
@@ -157 +159 @@
  }}}
 
- 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:
+ 2. When IP address change is detected: a) close the TCP transport that we saved in step 1) above, and b) send unregistration. 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);
+static void ip_change()
+{
+    pj_status_t status;
+
+    PJ_LOG(3,(THIS_FILE, "xxx: IP change.."));
+
+    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;
+    }
+
+    status = pjsua_acc_set_registration(the_acc_id, PJ_FALSE);
     if (status != PJ_SUCCESS)
-        PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsip_transport_shutdown() error"));
-    pjsip_transport_dec_ref(the_transport);
-    the_transport = NULL;
+        PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsua_acc_set_registration(0) error"));
 }
-
 }}}
 
- 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).
+ 3. And finally, once unregistration in 2b) above is complete, re-register (with TCP). 
+
 
 == Symbian specific issues and solution == #sym