enhance: Possibly breaking down MediaSessionInformation into distinct schema

[teikuran]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

To address following issues:

The current API definition re-uses the MediaSessionInformation schema, using it as the message body for almost all operations, including POST requests/responses, GET responses, and PUT requests/responses.

This leads to ambiguity e.g., currently, receiverAddress is not marked as required in the MediaSessionInformation schema. This allows a client to technically submit a call initiation request without a destination, which is functionally invalid.

Which issue(s) this PR fixes:

Fixes #147

Changelog input

 release-note - webrtc-call-handling
- enhance: Possibly breaking down MediaSessionInformation into distinct schema 

[deepakjaiswal1]

@teikuran The schema decomposition approach is well-structured and correctly addresses Issue #147 (in the right direction).

One request before merge: please rebase this PR on top of PR #142 once it is checked in. The MediaSessionStatusChange schema currently does not include locationDetails, which is being introduced in PR #142 for the PUT path (answering party location at setup and post-establishment location updates). A rebase will surface that conflict and the fix will be straightforward.

[stroncoso]

Ok, #142 was already merged, please, @teikuran review conflict resolution and we can approve and merge.
👍

[stroncoso]

LGTM
There are commonalities warnings, but they can be reviewed later

[deepakjaiswal1]

Issue: offer required in MediaSessionResponse breaks the receiver pick-up flow

MediaSessionResponse marks offer as required, and this schema is used for all GET responses. However, in the receiver pick-up flow, the callee retrieves the session immediately upon receiving a session-invitation event — before any SDP exchange has occurred. If the originator used the deferred-offer path, the session at GET time will have no offer, causing the response to fail schema validation.

This is further contradicted by the WrtcSDPDescriptor description, which explicitly states the answer element may be absent when no answer exists yet — acknowledging that partial-state sessions are valid.

Suggestion: Remove offer from the required list in MediaSessionResponse.

[deepakjaiswal1]

Issue: mediaSessionId should not be inherited by request schemas

mediaSessionId is defined in MediaSessionInformation (the base schema), which means it is inherited by MediaSessionCreate via allOf — making it a valid field in the POST request body. The only guard against a client sending it is a prose note in the field description. Schema validation and auto-generated clients would see it as permitted.

This is a leftover from before the refactor. The intent of breaking up MediaSessionInformation was precisely to give each operation the correct shape — mediaSessionId should have been part of that work.

Suggestion: Remove mediaSessionId from MediaSessionInformation and declare it only in MediaSessionResponse, where it is required. This enforces the constraint at the schema level rather than relying on a documentation note.

[teikuran]

Issue: offer required in MediaSessionResponse breaks the receiver pick-up flow

Thank you for your comment.
This raises a more fundamental question: is deferred offer intended to be supported by this API?

Based on the current specification, it appears that the callee is expected to have an SDP offer available when retrieving the session after receiving a session-invitation event because MediaSessionCreate explicitly requires offer.

Regarding the reference to WrtcSDPDescriptor, we agree that the specification explicitly allows answer to be absent in intermediate states (e.g. after session creation and before the call is accepted). However, this only demonstrates that the API supports states where an answer has not yet been generated. It does not necessarily imply that offer may also be absent.

Furthermore, with telco network, it is defined in 3GPP that the UE shall contain a SDP offer.

Issue: mediaSessionId should not be inherited by request schemas

Thank you. We will incorporate the comment as indicated.

[deepakjaiswal1]

Issue: offer required in MediaSessionResponse breaks the receiver pick-up flow

@teikuran I agree with your feedback. We, currently do not support deferred offer.

[stroncoso]

Conflict probably generated by the Commonalities/ICM v4.2 merge #174 , sorry 🙇

Anyway, the fix is easily covered from the web editor accepting the current change, not the incomming. Couple of clicks ahead.

An screenshot here:

[stroncoso]

LGTM

[stroncoso]

@teikuran , @deepakjaiswal1 up to you to merge when you consider. Thank you! 🙇