Changes between Version 5 and Version 6 of Symbian_AP_Reconnection

Feb 25, 2009 5:36:38 PM (15 years ago)



  • Symbian_AP_Reconnection

    v5 v6  
    27 == Issues == 
     27== Issues and solution related to IP address change == 
    2929When the connection is reconnected, the handset may get different IP address than what it previously got. There are few ramifications of this, for example if PJSUA-LIB is used: 
    5757 The account URI needs to be updated with the new address, and re-registration is necessary to inform the registrar about the new URI. 
    59  '''Solution:''' :: 
     59 '''Description:''' :: 
    6060 PJSUA-LIB has the capability to detect the (SIP) IP address change based on the response of REGISTER request and automatically update the registration with the correct IP if it detects that the IP/port seen by the server is different than the address specified in the Contact URI. This feature is enabled by default, via the {{{pjsua_acc_config.allow_contact_rewrite}}} setting. 
    6767 The media (RTP/RTCP) addresses in PJSUA-LIB are normally determined during PJSUA-LIB startup, hence they need to be updated with the new address. 
    69  '''Solution:''' :: 
     69 '''Description:''' :: 
    7070 If ICE media transport is used, and STUN is enabled on the media transport, then the media transport will automatically update its publicly mapped IP address from the STUN Binding response. The transport should send STUN Binding request periodically (approximately every 15 seconds) as NAT keep-alive mechanism, so the address change will be detected by the transport automatically during this operation. 
    8080 Dialog's Contact URI needs to be updated. 
    82  '''Solution:''' :: 
     82 '''Description:''' :: 
    8383 The dialog's Contact URI is set initially when the dialog is created, from the account's Contact URI. While at the PJSIP level the {{{pjsip_inv_reinvite()}}} allows changing of Contact URI via the {{{new_contact}}} argument, currently this feature is not used by PJSUA-LIB, i.e. the {{{pjsua_call_reinvite()}}} does not allow the application to change the Contact URI. 
    8888 Changing of RTP/RTCP media addresses of ongoing call 
    90  '''Solution:''' :: 
     90 '''Description:''' :: 
    9191 If ICE is used, then new STUN srflx address will be signaled in updated SDP offer, as long as: 
    92    - ICE media transport has detected that the IP address has changed (via the keep-alive above) 
     92   - ICE media transport has detected that the IP address has changed (via the keep-alive above), and 
    9393   - the media was previously inactive, since if media has been active (hence ICE session is active), the SDP will contain only the used candidates and not all the list of candidates. 
    9595 Alternatively, '''we may not need to inform the new RTP/RTCP address at all'''. If the remote media endpoint has the capability to switch its RTP/RTCP transmission to the source address of the RTP/RTCP packets (note: PJMEDIA has this capability), then it should automatically switch its destination address to our new address. 
     100== Symbian specific issues == #sym 
     102=== Socket call get stucked after reconnecting to different access point (AP) === 
     103Steps to reproduce: 
     104 1. Create RConnection, call Start() to connect to AP 
     105 1. Create UDP socket, call !SendTo() to send a packet 
     106 1. Disconnect the AP (Menu -> Connectivity -> Conn. mgr. -> Active data connections -> (highlight the AP) -> Options (menu) -> Disconnect). 
     107 1. Call udp.!SendTo() again 
     108 1. AP selection dialog appears, select different AP 
     109 1. !WaitForRequest() to the udp.!SendTo() operation now '''will get stuck for 1-2 minutes'''. 
     110 1. Now if you call udp.!SendTo() again, now !WaitForRequest() will get stuck indefinitely 
     112The problem above does not occur if: 
     113 - the user selects the same AP. In this case the udp.!SendTo() should complete successfully 
     114 - the user cancels the AP selection dialog. In this case the udp.!SendTo() will fail immediately with KErrCancel without blocking the application. 
     115 - the socket is closed and re-opened. In this case the udp.!SendTo() should complete successfully 
     117The implication of above symptom is the library may get stucked in {{{pjsua_destroy()}}} when the application tries to destroy the stack when it detects that the AP connection is down.  
     119Currently we don't have a solution for this, except to only use one AP (perhaps to select the AP when PJSIP is started and lock the RConnection that is assigned to PJLIB to this AP).