Fix ClickToDial documentation compliance issues

[YadingFang]

What type of PR is this?

• documentation

What this PR does / why we need it:

Aligns the supplementary ClickToDial documentation with the CAMARA Security & Interoperability Profile and the OpenAPI definition.

The changes:

• replace the client_secret authentication example with private_key_jwt guidance;
• remove stale version and release-note content;
• add recordingEnabled to the request attribute table;
• clarify that datacontenttype is optional;
• use reserved phone numbers consistently in examples and tests.

Which issue(s) this PR fixes:

Fixes #113

[camara-validation]

CAMARA Validation — PASS

0 errors, 0 warnings, 0 hints | Profile: standard

View full results

[YadingFang]

@hdamker The documentation issues identified in #113 have been addressed. Could you please review this PR when convenient?

[hdamker]

@hdamker The documentation issues identified in #113 have been addressed. Could you please review this PR when convenient?

@YadingFang PR looks good to me, addresses #113 fully.

Another issue you might want to consider: +12345678 (US has always 1+9 digits) and +87654321 (+876 reserved for satellite) aren't numbers an agent would recognize as valid phone numbers.

For the examples, it's worth using numbers from a range that's reserved so it can never be assigned to a real subscriber, while still being well-formed E.164 that a validator/agent will accept:

• UK — Ofcom "drama" range (reserved precisely so fiction and examples never dial a real line): mobiles +447700900000–+447700900999. E.g. caller +447700900000, callee +447700900123.
• US/Canada — NANP fictional numbers: 555-0100–555-0199 under any valid area code. E.g. caller +12025550100, callee +12025550199.

Either is fine — I'd suggest picking one pair and using it consistently across both the documentation and the OpenAPI (CALL_STATUS_CHANGED_EXAMPLE plus the other request/response examples), so the docs and spec don't drift apart again.

[YadingFang]

@hdamker The documentation issues identified in #113 have been addressed. Could you please review this PR when convenient?

@YadingFang PR looks good to me, addresses #113 fully.

Another issue you might want to consider: +12345678 (US has always 1+9 digits) and +87654321 (+876 reserved for satellite) aren't numbers an agent would recognize as valid phone numbers.

For the examples, it's worth using numbers from a range that's reserved so it can never be assigned to a real subscriber, while still being well-formed E.164 that a validator/agent will accept:

• UK — Ofcom "drama" range (reserved precisely so fiction and examples never dial a real line): mobiles +447700900000–+447700900999. E.g. caller +447700900000, callee +447700900123.
• US/Canada — NANP fictional numbers: 555-0100–555-0199 under any valid area code. E.g. caller +12025550100, callee +12025550199.

Either is fine — I'd suggest picking one pair and using it consistently across both the documentation and the OpenAPI (CALL_STATUS_CHANGED_EXAMPLE plus the other request/response examples), so the docs and spec don't drift apart again.

Thanks @hdamker. I have updated the examples to consistently use the UK Ofcom reserved numbers in the API documentation, User Story, OpenAPI definition, and the hard-coded test case. CAMARA Validation remains green with 0 errors, 0 warnings, and 0 hints.

[hdamker]

@YadingFang approvals for this PR are need to be done by your fellow @camaraproject/click-to-dial_codeowners

[YadingFang]

@YadingFang approvals for this PR are need to be done by your fellow @camaraproject/click-to-dial_codeowners

Understood, thanks @hdamker for the review and clarification.

[XunliYang]

LGTM