Call Flow diagram

[GillesInnov35]

Problem description
Does a call flow diagram exist for this API

Expected action
if not it might be useful to propose one

[stroncoso-quobis]

Hi team,

I'm working on some UML to grant an editable easy to document and modify diagram.
I will try to create the PR as soon as possible.

Best regards,

[GillesInnov35]

I've tried to draw my understanding

[olsi-korkuti]

Hi @GillesInnov35, onboarding process and /register operation are different.
Onboarding (might be delegated to the aggregator of done by the operator themselves) consists on a process of vetting, where the company is verified they are legitimate, or have rights to act on behalf of a 3rd party company and they are owners of the phone numbers. Often this marks a successful start of a commercial agreement.
We can assess if OperateAPI is useful for this process, especially when the mobile operator does the onboarding itself.

The /register operation will come after the onboarding. It consists of registering, updating and deleting the phone numbers and associated brand name.

[GillesInnov35]

hi @olsi-korkuti , thanks for your comment. I was wondering when information for the Verify calling solution will be requested to the customer and pushed thanks to the API.
API subscription request might be a good opportunity ...
Gilles

[GillesInnov35]

Update

[stroncoso-quobis]

Hi team,

Sharing an extra point of view, done with UML code, that we can include as supporting doc and edit. I'm going to open a draft PR to have these editable for documentation and to discuss over it. I tried to include all info from #24 and we can update that PR based on the agreed parameters and endpoints

Feel free to comment and share feedback.
Best regards,

[GillesInnov35]

hi @stroncoso-quobis, many thanks for your proposal. I agree with the different flows and steps. It suits me well.
Concerning HTTP response code may I propose :

• for /register return a HTTP 200 with the identifier of registration (id) because information should be recorded with an identifier
• for /pre-announce return a HTTP 204 without any content because no id should be created

WDYT ?
BR
Gilles

[stroncoso-quobis]

Hi @GillesInnov35 ,

Thanks for your feedback. I have a typo: 200 is to include a body, 204 to no-content acknowledge. My bad with that. 🤦

So:

• /register -> 200OK with clientId
• /pre-announce -> 200OK with preAnnounceId + TTL

My suggestion, as stated at #24 is to include a 200 OK with a preAnnounceId (to allow correlating with following INVITEs) and a pre-announce time to live (to separate from registration). Of course, we can use the x-correlator header as ID as workaround, but then, no TTL will be informed about the pre-announcement valid period.

What do you think?
Best regards,

[alpaycetin74]

Hello, in case of registration creation, HTTP 201 Created with a registrationId would be a better fit.
We have also prepared a draft for the registration phase, which we will submit soon.
There are a few proposal around :) Maybe we can discuss all of them and then pick one to work on.

I find the idea of a token later to be used in SIP messaging very creative. But this is like combining two different planes of a telco and it may take some time for the network specs & vendors to get there. Anyway, it could be added as a "for future use" parameter.

[stroncoso-quobis]

Hi @alpaycetin74 ,

Thanks for your feedback, of course is a WIP to discuss live. As vendors participating in standardization processes, our target is to help provide these kinds of technology, and ideas. And this idea is based on conversations with telcos in Spain.

There are a few proposal around :) Maybe we can discuss all of them and then pick one to work on.

That's really great! We will be happy to contribute wherever decision is made. 👏 I will update the PR as we will agree on parameters and responses to be used.

Thanks!
Best regards

[olsi-korkuti]

@stroncoso-quobis Hi Santiago, I have just reviewed the UML. I also like the response with a pre-announce ID, we can include it as an optional value to serve as a token. From experience I have my doubts on the implementation into SIP headers given it is an important change from network vendors. But I am happy to add in the 200 OK response both as optional parameters the pre-announce ID and the timetolive (useful when not provided in the request).