Branded calling API uml diagrams

[stroncoso-quobis]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

Enhance and clarify comprehension of the API behavior and scope.

Which issue(s) this PR fixes:

Fixes #15

Special notes for reviewers:

UML description of the discussions in progress.
There are two versions:

• Complete: pre-announce + INVITE.
• Short: simple to embed into documentation.

The complete version, includes the relationship between the pre-announce and the voice session that happens afterward. It can be used as shared documents for discussions about parameters and other feature implications.

The short version is a

Changelog input

 release-note
doc: Included branded calling API uml diagrams

Additional documentation

Check extra comments at issues #6 (other UMLs) and #24 (parameters discussion)

[alpaycetin74]

Register responses in both figures contain parameters, hence the http code shouldn't be 204. We think of 201 Created.
Both responses also return the complete registration data provided in the request (as per @GillesInnov35 's comment), and a registrationId.
I am undecided about the validUntil/TTL type of parameter during registration. We can discuss this further. My concern is, if this time expires we also need to send a notification to a callback URL (as in QoD or Geofence APIs). This adds more complexity to the API.
Maybe we can consider the timer at a later phase, or add it without notification. Thank you.

[GillesInnov35]

@alpaycetin74 , as you say notification process is much complex. I think we should keep the TTL parameter without any notification when time will be exceeded.

[alpaycetin74]

@alpaycetin74 , as you say notification process is much complex. I think we should keep the TTL parameter without any notification when time will be exceeded.

If the timeToLive in registration phase is the validity of the service in general, it should be a long period, right ? It is actually the duration of a commercial contract between a business and operator. It would be in order of weeks, months ?
Then what unit should we use ?

[stroncoso-quobis]

If the timeToLive in registration phase is the validity of the service in general, it should be a long period, right ?

Ok, for me, this is the main concerning point. If we need to include branding information into the call, and it include the subject of the session, I can't picture a long TTL. Also, if we don't include a mandatory correlation field on the session itself, this could take a complete unverified approach.

But, to provide a clear solution, easy to help advance, we can use absolute timestamps, it is widely used on CAMARA APIs and it will serve for any use case, short or long TTL.

What do you think?

Regards,

[GillesInnov35]

@alpaycetin74 , TTL is the max time between the pre-announce call and the invite . So it might be very short, few seconds or minutes, no ?

[alpaycetin74]

@alpaycetin74 , TTL is the max time between the pre-announce call and the invite . So it might be very short, few seconds or minutes, no ?

Yes, but we thought this would be in the pre-announcement request, so that the customer can define a TTL for each call they are going to make separately.

[stroncoso-quobis]

Hi all,

Moving to DRAFT status as I want to review PRs #40 ✔️ , #43 and #46 to include all parameters and different use cases (sms, verification, block, etc).

I will push updates soon. Sorry for the inconvenience.

Best regards,

[stroncoso-quobis]

Included changes after #40 merge:

• Aligned parameters for registration
• Reviewed aggregator role on preannounce
• Updated params for pre-announce due Create wip version of call pre-announcement API #46 proposition
• General visual and response updated

I will keep it on draft until we merge #46 and then, we can include it as supporting documentation.

Best regards,