Media/WebRTC/Architecture: Difference between revisions

Line 172: Line 172:
http://www.websequencediagrams.com/?lz=dGl0bGUgU2lnbmFsaW5nIFRocmVhZHMgKENyZWF0ZU9mZmVyKQpwYXJ0aWNpcGFudCAiRE9NACAHIiBhcyBET00AEw1QQyBhcyBQQwAnDkNDQVBQVGFzawAvBQAJBQBJDUdTTVRhc2sgYXMgR1MAQw5TVFMKCkRPTSAtPiBQQzogRGlzcGF0Y2gAgRUOUEMgLT4AUwY6IElQQyhDQ19DYWxsRmVhdHVyZV8AgUMNAIEJBSAtPiBHU00AJQlNU0dfQ1JFQVRFT0ZGRVIpCkdTAG8FAB8FZnNtZGVmX2V2X2MAghQFb2ZmZXIAFQ1nc21zZHAAGAdfbG9jYWxfc2RwABAUZW5jb2RlX3NkcF9hbmRfdXBkYXRlX3ZlcnNpb24Aag0AZwYgd2VicnRjLm9yZyBmbG93cwAQFG10cmFuc3BvcnQAFg5TVFMAgikLABwKW0lDRV0tPkNvbm5lY3QoKSkKU1RTAIIHDQCBPwUgSUNFIGNhbmRpZGF0ZXMAgg0JAIJfCwCCKgUgU0RQAIJOCwCDHA1vbkNhbGxFdmVudAAiCwCDLAhET00Ag0oLAIRtBQBHBgpub3RlIGxlZnQgb2YAgyUGU3Vic2VxdWVudACBEwV0cmlja2xpbmcAHQ4ATQVKUyBjYWxsYmFja1xud2l0aCAAgy4GAIFDJACBUhRDABMKAIFOGElDRQCBXwYAIgoAgU8WAF4PAIEZJACCegkKCg&s=default
http://www.websequencediagrams.com/?lz=dGl0bGUgU2lnbmFsaW5nIFRocmVhZHMgKENyZWF0ZU9mZmVyKQpwYXJ0aWNpcGFudCAiRE9NACAHIiBhcyBET00AEw1QQyBhcyBQQwAnDkNDQVBQVGFzawAvBQAJBQBJDUdTTVRhc2sgYXMgR1MAQw5TVFMKCkRPTSAtPiBQQzogRGlzcGF0Y2gAgRUOUEMgLT4AUwY6IElQQyhDQ19DYWxsRmVhdHVyZV8AgUMNAIEJBSAtPiBHU00AJQlNU0dfQ1JFQVRFT0ZGRVIpCkdTAG8FAB8FZnNtZGVmX2V2X2MAghQFb2ZmZXIAFQ1nc21zZHAAGAdfbG9jYWxfc2RwABAUZW5jb2RlX3NkcF9hbmRfdXBkYXRlX3ZlcnNpb24Aag0AZwYgd2VicnRjLm9yZyBmbG93cwAQFG10cmFuc3BvcnQAFg5TVFMAgikLABwKW0lDRV0tPkNvbm5lY3QoKSkKU1RTAIIHDQCBPwUgSUNFIGNhbmRpZGF0ZXMAgg0JAIJfCwCCKgUgU0RQAIJOCwCDHA1vbkNhbGxFdmVudAAiCwCDLAhET00Ag0oLAIRtBQBHBgpub3RlIGxlZnQgb2YAgyUGU3Vic2VxdWVudACBEwV0cmlja2xpbmcAHQ4ATQVKUyBjYWxsYmFja1xud2l0aCAAgy4GAIFDJACBUhRDABMKAIFOGElDRQCBXwYAIgoAgU8WAF4PAIEZJACCegkKCg&s=default


[TODO: EKR. (1) Should we do the ICE allocation in PC and just have SIPCC ask it. (2) first offer creation is asynchronous internally because ICE may be asynchronous.]
[TODO: EKR. Parallel forking and cloning.]
[TODO: EKR. Parallel forking and cloning.]


The sequence for CreateOffer is shown in the link above.
The sequence for CreateOffer is shown in the link above.


As described above, most of the heavy lifting for the API happens off the DOM thread. Thus, when the JS invokes CreateOffer(), this turns into a Dispatch to the PeerConnection thread which (after some activity of its own) invokes SIPCC's FEATURE_CREATE_OFFER via a SIPCC IPC message to CCAPP_Task, which using the GSMTask thread constructs the SDP based on local streams added using AddStream. The appropriate transport flows (mtransport) are then constructed. The SDP offer is then Dispatched back all the way to the DOM thread which eventually calls the JS CreateOffer callback. [Question: is this actually not Dispatch but some fancier call.]
As described above, most of the heavy lifting for the API happens off the DOM thread. Thus, when the JS invokes CreateOffer(), this turns into a Dispatch to the PeerConnection thread which (after some activity of its own) invokes SIPCC's FEATURE_CREATE_OFFER via a SIPCC IPC message to CCAPP_Task, which using the GSMTask thread constructs the SDP based on local streams added using AddStream. The appropriate transport flows (mtransport) are then constructed. (Note thast they may already exist if some have been pre-created). The SDP offer is then Dispatched back all the way to the DOM thread which eventually calls the JS CreateOffer callback. [Question: is this actually not Dispatch but some fancier call.]


In the meantime, the ICE gathering process has been running on the STS thread. As each candidate is gathered, the STS thread does an IPC call to the GSMTask thread to return the ICE candidate. These candidates are then Dispatched back to the CCAPP_Task thread and then to the PC thread and then eventually to the DOM thread where the ICE candidate events fire.
In the meantime, the ICE gathering process has been running on the STS thread. As each candidate is gathered, the STS thread does an IPC call to the GSMTask thread to return the ICE candidate. These candidates are then Dispatched back to the CCAPP_Task thread and then to the PC thread and then eventually to the DOM thread where the ICE candidate events fire.


[Question: Enda. (1) During function gsmsdp_create_local_sdp the media streams that were added by AddStream are interrogated, how can I represent that in this diagram or is it implied that GSMTask ownes these streams and there is no outside interaction?   (2) I am not sure we do 'create webrtc flows' here, I thought this was the responsibility of setLocalDescription or setRemoteDescription.  I am happy that we create SIPCC internal representation of media streams but not sure we call out to webrtc at this point.]
At this point it may be necessary to create some WebRTC.org streams in order to determine what the acceptable media parameters are for the SDP. For instance, if
that is required to determine whether a given codec is supported. [TODO: Enda?] However, they would not be hooked up to anything at this point.


=== Signaling System: SetLocal(Caller) ===
=== Signaling System: SetLocal(Caller) ===
Confirmed users
214

edits