Adding UML diagrams in API provider perspective Part2

[teikuran]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

Following Adding UML diagrams in API provider perspective #122, new flow examples are proposed to be added.

Changelog input

 release-note
- UML (for registration and call handling) uploaded to discuss and identify any future issue with baisc call flow understanding

[stroncoso]

Hi @teikuran

Thanks very much for the documentation work, it really shapes the API and it brings our eyes over the real implementations problems. I noticed that you include several "ISSUE (NotAddressed)" comments on the doc, do not hesitate to create them on the repo, in order to properly address them one-by-one.

Some initial comments:

• WebRTC registration lacks of the subscriber number in the body of the request. Currently is only covered on the 200OK reponse from the netowrk. Maybe it will be easier to implement on the application layer, if we include it on the request, but not really sure of the security implications... maybe none.
• POST SINK_URL looks a little confusing on the diagram, suggested the following formula: POST SINK_URL (session-event) to identify the type of event, or event more, include the content: `POST SINK_URL (session-event: 180 ringing)

We can comment it and agreed on results to merge and next steps at today's meeting.

Thanks for your contribution.
Regards,