1 | | Currently it is blocking, so call initialization would wait (blocking) until media is created and initialized. |
| 1 | In 2.0, media transport creation is now made on as-needed basis, i.e. when calls need them. Currently the creation is blocking, so call initialization would wait (blocking) until media is created and initialized. |
| 2 | |
| 3 | This ticket makes the creation asynchronous. The proposed solution is as follows: |
| 4 | |
| 5 | 1. modify media transport creation to asynchronous (e.g. for STUN resolution) |
| 6 | 1. add new callback, e.g. {{{on_call_media_transport_state(call_id, state_struct)}}} to report media transport status. We'll use this to report transport creation status, as well as other events. The events reported by existing on_ice_transport_error() callback may as well go to this callback too (and remove on_ice_transport_error() altogether? I'd say yes.) |
| 7 | 1. for outgoing calls, delay the INVITE transmission until media transport is ready. Be aware that app may hangup the call at any time, including when transport is being created, hence need to handle this case. |
| 8 | 1. for incoming calls, report the INVITE to on_incoming_call() immediately. As long as app doesn't reject the call in this callback, proceed with creating the transport (which will finish asynchronously later). If app answers the call while the transport is not ready, there are several cases: |
| 9 | a. if worker thread is enabled *and* current thread is not worker thread, block the execution waiting until transport is created. |
| 10 | b. for Symbian, do event polling |
| 11 | c. for other cases, return PJMEDIA_TP_EINSTATE (new errror: invalid transport state). |
| 12 | Also as in outgoing call case, app may hangup the call at any time. |
| 13 | |