Communication Control Main Workflows

Here we provide a detailed explanation on the data flows between the different reTHINK framework entities involved in the decentralized control of reTHINK communications.

The classic “Alice calls Bob” example is used. However we have similar data flows for other use cases including chat and IoT.

In this example, Alice and Bob are subscribers of different Communication Service Providers (CSP) i.e. it is a cross domain communication. Identities of Alice and Bob are also managed by different Identity Providers selected by them, regardless of the CSPs they are subscribed to. All these four stakeholders - Alice CSP, Alice IdP, Bob CSP and Bob IdP - have had no previous contacts or relationships before the call is established between Alice and Bob. We assume Bob already has all required reTHINK functionalities running in his device - including the Application and Hyperties used to handle Audio and Video communications - while Alice has no reTHINK functionality running in her device, yet.

The main steps to setup a Communication between Alice and Bob are the following:

1- Alice deploys Some Application in her device runtime

2- The Application deploys Hyperty H1 from Alice’s CSP Catalog, that will be used to handle AV communications. To be noted that Hyperty H1 and Hyperty H2 already running in Bob’s device, are different.

1. Alice selects her identity to be associated with Hyperty H1. If no valid Identity token exists, the required Idp Proxy is deployed and used to generate it i.e. Alice is authenticated.
2. as soon as the CSP session is established, Hyperty H1 is registered in CSP’s Registry. At this point, H1 is discoverable and Alice’s device is ready to handle outgoing and incoming communication requests.
3. Let’s assume Alice wants to communicate with Bob. The first step, is the creation of the Connection Data object by Alice’s Hyperty that will be populated with data retrieved from WebRTC Local peerconnection API - including SDP and Ice Candidates \cite{webrtc}.
4. an Assertion token is generated by Alice’s Idp Proxy to the attached to message body invitation.
5. then Alice will look for Bob’s communication endpoint address by first deploying Bob’s CSP Protostub from its Catalogue. The Catalogue Protosub address is derived from Bob’s CSP domain by using the Well-known URIs standard \cite{well-known-uri}. The discovery of Bob’s CSP domain is handled by the Global Discovery (not visible in the picture) by using any Bob’s Identifier including Bob’s GUID. More details are provide in \cite{imads2017}.
6. as soon as Alice is connected to Bob’s CSP, she queries the Domain Registry about live Hyperty instances addresses that are compliant with Alice’s Connection Data Object Schema.
7. The retrieved Bob’s Hyperty instance addresses are used to invite Bob to connect with, by sending a “create” message containing a copy of Alice’s Connection Data Object and its address. But before the invitation reaches Bob’s H2 Hyperty, the IdP Proxy from Alice IdP is deployed in Bob’s runtime …
8. … that will be used to certify Alice’s identity by using the assertion attached to the invitation.
9. if Bob’s accepts Alice’s invitation, a copy of Alice’s Connection data object is created and Bob’s becomes an observer of it i.e. a Data Synchronisation Stream is established between Alice’s Connection Reporter and Bob’s Connection Data Objects.
10. Any change made by Alice on her Connection Data Object, e.g. new ICE Candidates added, will be immediately propagated to Bob’s Connection Data Object copy which can be used to set the changes to remote peer connection till the AV stream is successfully established with Alice’s endpoint.

The AV Stream connection from Alice to Bob’s endpoint is not illustrated but would follow the same model i.e.:

1. Bob’s Hyperty creates its own Connection Data Object
2. Bob’s Identity Assertion is generated by Bob’s IdP Proxy
3. Alice’s CSP Protostub is deployed in Bob’s Runtime and used to send a “create” message with a copy of Bob’s Connection Data Object in the message Body as well as Bob’ Identity Assertion.
4. Alice’s deploys Bob’s IdP Proxy and certifies Bob Identity assertion.
5. Alice becomes an Observer of Bob’s Connection Data Object and uses all the data received on this Object to set in the remote Web RTC Connection until the connection is established.

It should be noted that the same model applies to other types of communications, e.g. Group Chat, Machine to Machine. The difference is on the Data Object model used. Communication with peers in legacy domains that are not compliant with reTHINK (e.g. IMS) are also supported by using the same approach. The Interworking Protostubs and IdP Proxies for the legacy domain, are the only components required.