Changes between Version 7 and Version 8 of 0.9/Media_Interface_Change


Ignore:
Timestamp:
Jun 19, 2008 2:03:28 PM (16 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • 0.9/Media_Interface_Change

    v7 v8  
    113113== Sample: ICE processing with the new media framework == 
    114114 
    115 === Generating initial offer === 
    116  
    117 This happens in {{{encode_sdp()}}}, when ICE is not running and {{{rem_sdp==NULL}}. The transport will include all ICE candidates in the offer. 
    118  
    119 === Generating initial answer === 
    120  
    121 First, the transport detects whether the remote offer contains ICE in {{{media_create()}}}. If yes, it marks {{{use_ice=True}}}. 
    122  
    123 Then in {{{encode_sdp()}}}, it checks if ICE is already running. Since this is an initial answer, ICE is not running yet. So it puts all candidates in the answer. In this function, the transport also checks for ICE-mismatch. 
    124  
    125 === Generating subsequent offer === 
    126  
    127 This happens in {{{encode_sdp()}}}, when ICE is already running and {{{rem_sdp==NULL}}}. The transport fills in the SDP with selected candidate only, one for each component. 
    128  
    129 === Generating subsequent answer === 
    130  
    131 This happens in {{{encode_sdp()}}}, when ICE is already running and {{{rem_sdp}}} is present. The transport detects for ICE '''restart''' condition or if the new offer no longer contains support for ICE. If ICE is restarted, then the internal ICE session will be destroyed and re-created. 
    132  
    133 The populated SDP depends on whether ICE is restarted or not. If ICE doesn't restart, then the answer contains only the selected candidate from the valid pairs, just like ''Generating subsequent offer'' above. If ICE is restarted, then it will contains all candidates. 
    134  
    135 === media_start() processing === 
    136  
    137 When we send offer, this is where we will see the remote answer for the first time. So we do the "heavy" negotiation here. 
    138  
    139 For ICE: 
    140  - Detect if answer contains ICE support ==> disable ICE 
    141  - Handle answer that contains ice-mismatch attribute ==> disable ICE 
    142  - Handle answer with transport address that doesn't match any candidates ==> disable ICE 
    143  - Handle when we set our role as Controlled, but answer contains ice-list ==> change role to Controlling 
    144  - If remote SDP contains the same ice-ufrag and ice-pwd as previous SDP, that means there's no change in the offer/answer, no need to do anything. 
    145  
    146 If things are okay, start ICE negotiation. 
    147  
    148  
    149 == Bug == 
    150  
    151 With the new framework, there's still a bug. The offer/answer RFC says that if UPDATE or re-INVITE fails, the media should remain unchanged, i.e. it falls back to use the previously successfully negotiated media. 
    152  
    153 That's not possible with the framework above, for the '''generating subsequent answer''' case above. Solving this is currently not possible with ICE, since that requires creating a new/fresh ''ice_strans'' everytime we receive updated offer, just in case the offer/answer fails so that we can revert back to old ''ice_strans''. 
    154