Changes between Version 7 and Version 8 of IPAddressChange


Ignore:
Timestamp:
Aug 26, 2011 7:37:39 AM (8 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IPAddressChange

    v7 v8  
    113113[[BR]] 
    114114 
    115 == Issues with iPhone/TCP == #iphone 
     115== Handling IP Change on iPhone == #iphone 
    116116 
    117117[Update 2011/01/26] 
    118  
    119 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: 
    120  
     118[Update 2011/08/26] 
     119 
     120TCP 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. 
     121 
     122 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. 
    121123 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: 
    122124 {{{ 
     
    157159 }}} 
    158160 
    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: 
     161 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: 
    160162 {{{ 
    161 pj_status_t status; 
    162  
    163 PJ_LOG(3,(THIS_FILE, "xxx: IP change..")); 
    164  
    165 status = pjsua_acc_set_registration(the_acc_id, PJ_FALSE); 
    166 if (status != PJ_SUCCESS) 
    167     PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsua_acc_set_registration(0) error")); 
    168  
    169 if (the_transport) { 
    170     status = pjsip_transport_shutdown(the_transport); 
     163static void ip_change() 
     164{ 
     165    pj_status_t status; 
     166 
     167    PJ_LOG(3,(THIS_FILE, "xxx: IP change..")); 
     168 
     169    if (the_transport) { 
     170        status = pjsip_transport_shutdown(the_transport); 
     171        if (status != PJ_SUCCESS) 
     172            PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsip_transport_shutdown() error")); 
     173        pjsip_transport_dec_ref(the_transport); 
     174        the_transport = NULL; 
     175    } 
     176 
     177    status = pjsua_acc_set_registration(the_acc_id, PJ_FALSE); 
    171178    if (status != PJ_SUCCESS) 
    172         PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsip_transport_shutdown() error")); 
    173     pjsip_transport_dec_ref(the_transport); 
    174     the_transport = NULL; 
     179        PJ_PERROR(1,(THIS_FILE, status, "xxx: pjsua_acc_set_registration(0) error")); 
    175180} 
    176  
    177181}}} 
    178182 
    179  3. And finally, once unregistration in 2a) above is complete, re-register (with TCP).  
    180  
    181 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). 
     183 3. And finally, once unregistration in 2b) above is complete, re-register (with TCP).  
     184 
    182185 
    183186== Symbian specific issues and solution == #sym