Verified Caller Flow

[DENGYONG18]

Verified Caller API Flow

What type of PR is this?

Add one of the following kinds:

• bug
• correction
• enhancement/feature
• cleanup
• documentation
• subproject management
• tests

What this PR does / why we need it:

Proposal of a Verified Caller API flow and an optional flow.

Which issue(s) this PR fixes:

Fixes #

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: DENGYONG18 (559e42b, 765b11e, 8e78dfb, 82cc880)

[olsi-korkuti]

Hi @DENGYONG18 I have just reviewed the call flow and trying to understand what is the "Strategy" parameter in the Verified Caller (pre-announce).

• Is that a display name field added dynamically directly to the Pre-Announce and is shown to the B-number device display?
• Is this to accommodate your implementation where the calls are branded via SMS that contains display name and a Brand card/logo?
• If that is the case, we can propose to add that as an optional field in order to allow for different implementations. If some Telcos will not use the Registration process via API, makes sense to need a dynamic display name on the fly. The content of that field might need some tight validation to not be misused but that is part of the network solution and out of the scope of the API.

cc: @alpaycetin74 @GillesInnov35 @stroncoso-quobis

[stroncoso-quobis]

Hi team, I left here my thoughs

--
Strategy field

IMHO, this looks great. As the verifyCallerAction brings flexibility and it includes some different ways to act for source (A-number) verification, a strategy field could do the same with the branding feature.

AFAIK, different consolidated ways to "brand" a call:

• Via verification and RCD, as drafted at IETF.
• Via SMS RCS as proposed by China Telecom and others (I seen this on several places).
• Via CNAM (Display name) as proposed by Vodafone and others due to network capability limitations.

From my point of view, a branding strategy field that will be replied on the response indicating the network capacity about this matter will be great.

For instance, if a network can include PASSporT, RCS or CNAM, it is up to the developer to use which one is preferred. On the other had, if a telco does not support PASSporT, or can not grant it for the route to B-number, it can reply back with a default action.

Finally, the telco can also include a "not supported" response, to reject announcements for some kind of branding strategy.

--
Display + subject fields

About the dynamic display name, I will consider using the registration display name as default and the pre-announce display name as an individual value. It is considered also at #46 by @alpaycetin74 , so we are all agree on that.

Also, if you consider it, a subject filed to indicate why are you calling (campaign name) will be also great .

Best regards,

[alpaycetin74]

Hello, due to release management rules we need to either close PRs or set them to draft state. I understand we can still discuss this PR but I need to set it as PR. Thank you for your understanding.