Starting with changes on the Notification process following shared MoMs

Updated documentation, registration / notification diagram considered done.

Updated after today's meeting. Really appreciate feedback on salmon notes of the diagram.

Also considering splitting Registration(RACM) / Notification / CallHandling use cases. They are separate stages, working in parallel or dependant, but, to work with smaller images/documents will benefit all.

Blocked due lack of status definition:

• Include detailed status description #32

And blocked due JSON ACK definition. If we are talking about confirm status changes or to modify the SDP, an PUT/PATCH sould be the way. It must be valid for all notification channel mechanisms (websocket, PSN or webhook)
To discuss related with:

• BYON call handling (VVOIP) PUT lacks 200 OK JSON response body #24

• Updated to latest API version (headers and parameters)
• Improved terminating flow
• Uniform path on requests
• Included base documentation for status

Ready for merge after review commented today on the meeting.

Following #29 session ID variable names.
Also fixed compilation of the PlanUML image of call handling, a little big too long.

cc.: @deepakjaiswal1 @TEF-RicardoSerr

Regards,

@stroncoso-quobis @TEF-RicardoSerr
Please find my comments below:
-- Registration / De-registration--
Flow #4: We need to highlight that channelId is provided only when the channel is externally created, meaning not by the WebRTC Gateway. If the notification channel is an independent service (i.e., not part of the WebRTC Gateway), it should be set up before the RACM session.
-- Notification channel --
Flow # 6: There is no URL for PNS channel. There could be other params along with registrationToken.
-- Call handling (Originating / Terminating) --
Can we capture SIP UPDATE flow also?

@stroncoso-quobis Can we also capture call-flow call hold & resume?
@pradeepachar-mavenir @TEF-RicardoSerr For the PUT request to /vvoip/{apiVersion}/sessions/{vvoipSessionId}/status, there are two scenarios: (a) the session is updated with no response body, and (b) the session is updated with a response body. I suggest using status code 204 for updates with no response body, and status code 200 for updates that include a response body.

Hi @deepakjaiswal1 , reviewed flows after your revision

• Included more detailed and accourate (v0.1.2) info about notification channels
• Included more detail about UPDATE / PRACK on pre-ringing stages for IMS

Check updated UML renders on the PR description.

About the 204/200 in response to PUT actions, I suggest to keep the flow as it is to explain the base concept and get more in detail, maybe on the Markdown plain document or in the openApi description. Under that point of view, I consider that a "generic 204" is ok for this flow overview.

Regarding the call-flow call hold & resume I agree that it is a great resource to add. I can do it, but I suggest creating a new call flow file on a separate PR and try to touch base with this one.

Thanks for your comments! 🙇