search

reTHINK-project / specs

You'll find here the full detailed specification of reTHINK Framework
Apache License 2.0
3 stars 3 forks source link

Interworking with Legacy Services #4

Open pchainho opened 8 years ago

pchainho commented 8 years ago

https://github.com/reTHINK-project/dev-runtime-core/issues/107 folow up

These specs should be provided here

See also new created repo for slack interworking example here containing initial version for slack IW protostub.

jmcrom commented 7 years ago

Abot the architecture displayed in the dedicated page I have multiple questions.

I guess IWStub is some kind of ProtoStub (it should be precised in the text) ; then it has to be downloaded and the right place to get is the legacy domain itself so this soltion has some impact on a legacy domain. Indeed, in this view we may define the minimm set of functions a legacy domain has to implement to integrate reTHINK. (BTW that's the sense of the mentioned 3GPP spec).

We may also design some workaround solution so that interworking is achieved by another platform (the same way we implement idp-proxy in place of Google for instance) but for the same reasons it could not be the normal way.

Another undefined word is "IWHyperty". I gather it comes from an alternative solution described here. If still relevant, it should be also detailed: is it resident within runtime or downloaded ? and in the latter case from where ?

Another detail from the schema: the reference to "SIPoWS messages" seems to introduce some limitations regarding interworking scenarios to be addressed.

Eventually, IMS legacy interop task should attempt to map 3GPP functions (WIC, WWSF, WAF, eP-CSCF, eIMS-AGW) and associated seqences to reTHINK framework. Where do they fit in our architecture?

pchainho commented 7 years ago

I guess IWStub is some kind of ProtoStub (it should be precised in the text) ; then it has to be downloaded and the right place to get is the legacy domain itself so this soltion has some impact on a legacy domain. Indeed, in this view we may define the minimm set of functions a legacy domain has to implement to integrate reTHINK. (BTW that's the sense of the mentioned 3GPP spec).

Agree

We may also design some workaround solution so that interworking is achieved by another platform (the same way we implement idp-proxy in place of Google for instance) but for the same reasons it could not be the normal way.

Agree

Another undefined word is "IWHyperty". I gather it comes from an alternative solution described here. If still relevant, it should be also detailed: is it resident within runtime or downloaded ? and in the latter case from where ?

right, if you agree to follow the current proposal, the IWHyperty would not be used

Another detail from the schema: the reference to "SIPoWS messages" seems to introduce some limitations regarding interworking scenarios to be addressed.

Yes, it should be possible to use any legacy protocol but I guess SIPoWS is what 3GPP is standardising: @antonroman ?

Eventually, IMS legacy interop task should attempt to map 3GPP functions (WIC, WWSF, WAF, eP-CSCF, eIMS-AGW) and associated seqences to reTHINK framework. Where do they fit in our architecture?

I think this is under the scope of WP6 and can be reported in D6.2

jmcrom commented 7 years ago

@pchainho regarding SIPoWS it is in both in the 3GPP/IMS section (where it is relevant) and in the global schema (where it looks like a restriction)

antonroman commented 7 years ago

Sorry very much for my late reply.

I guess IWStub is some kind of ProtoStub (it should be precised in the text) ; then it has to be downloaded and the right place to get is the legacy domain itself so this soltion has some impact on a legacy domain. Indeed, in this view we may define the minimm set of functions a legacy domain has to implement to integrate reTHINK. (BTW that's the sense of the mentioned 3GPP spec).

Yes, the IWStub has to be provided by the Legacy Domain to make it interoperable with reTHINK. I added that to the text. I mentioned the example of IMS integration but this is not restricted to it, it is general for any third party service which an be interconnected.

Regarding the minimum set of functions, we should consider at least one compatible auth mechanism. Regarding the rest of commands which can be exchanged, I guess the idea is that is compatible with one or more of the existing datamodels.

We may also design some workaround solution so that interworking is achieved by another platform (the same way we implement idp-proxy in place of Google for instance) but for the same reasons it could not be the normal way.

In the specific case of IMS, as a workaround we could consider to have a gateway element within the architecture which translates the signaling protocol into SIP IMS-compliant so we can send SIP traffic directly to the P-CSCF of the operator but I guess that relaying the IWstub development in the operator makes more sense. We can define both options in the spec. The work to be done in T6.3 is an example of interconnection with IMS and can also be considered an interconnection "gateway" which could be used if the operator does not want to include any additional element in its IMS network to be interoperable with reTHINK.

Another undefined word is "IWHyperty". I gather it comes from an alternative solution described here. If still relevant, it should be also detailed: is it resident within runtime or downloaded ? and in the latter case from where ? right, if you agree to follow the current proposal, the IWHyperty would not be used I removed it from the doc.

Another detail from the schema: the reference to "SIPoWS messages" seems to introduce some limitations regarding interworking scenarios to be addressed. Yes, it should be possible to use any legacy protocol but I guess SIPoWS is what 3GPP is standardising: @antonroman ?

The protocol to be used in the web part is not standardized, SIPoWS is one option but there are vendors using propietary JSONoWS and REST API approaches. So we coulddefine two interop options:

  1. If the operator already has some kind of WebRTC gateway to make it interoperable from Web clients then it "only" needs to offer the IWstub which receives and send intructions from the Hyperty using the data object synchronization and then it would translate those commands into the signaling protocol supported by the WebRTC GW.
  2. If the operator does not have any WebRTC GW then we can propose a generic element which translates from object synchronization into IMS-compliant SIP. The work to be done in T6.3 could be connected directly to an IMS system using regular SIP.

Eventually, IMS legacy interop task should attempt to map 3GPP functions (WIC, WWSF, WAF, eP-CSCF, eIMS-AGW) and associated seqences to reTHINK framework. Where do they fit in our architecture? I think this is under the scope of WP6 and can be reported in D6.2

Ok, I will include the mapping in the two options mentioned above.

antonroman commented 7 years ago

I added an inital diagram at: https://github.com/reTHINK-project/specs/tree/master/dynamic-view/legacy-interworking.

I still need to comment all the steps in the readme.

The IdPproxy part is still missing, in the message send to the legacy domain to register I included a note to explain that in that initial registration message a token can be included, however I didn't include how we get that token.

@pchainho could you check the diagram? I'm going to create another diagram based on https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/inter-remote-comm.md describing an example of chat message and another for an IMS call

pchainho commented 7 years ago

Should be updated according to the outcome of https://github.com/reTHINK-project/specs/issues/11