Correct error responses and schema inconsistencies #234

Problem description

Error responses and schemas that the automated validation doesn't catch:

Error responses

• webrtc-call-handling: 501 is used with CALLTYPE_EMERGENCY_NOT_SUPPORTED for an unsupported callType value (L285-L309). 501 NOT_IMPLEMENTED is meant for functionality that isn't implemented. The code also lacks the API name prefix.
• webrtc-registration: EMERGENCY_ADDRESS_MISSING, MAX_REGISTRATION_PER_USER, MAX_REGISTRATION_PER_MSISDN and MAX_DEVICES_PER_USER lack the WEBRTC_REGISTRATION. prefix (L660-L704). No request field relates to EMERGENCY_ADDRESS_MISSING.
• Operations addressed by {mediaSessionId} or {registrationId} declare 404 IDENTIFIER_NOT_FOUND and 403 INVALID_TOKEN_CONTEXT, which relate to device or user identifiers these operations don't carry.

Schemas and examples

• webrtc-call-handling: MediaSessionCreate inherits status and answer from MediaSessionInformation, although the descriptions say they must not be sent on create (L534-L542).
• webrtc-call-handling: two PUT /sessions/{mediaSessionId}/status request examples ("Answer with location", "Location update") are full session bodies with properties that MediaSessionStatusChange doesn't have (L407-L410).
• webrtc-events-subscriptions: Subscription.types has maxItems: 1, but SubscriptionRequest.types allows 3 (L772).
• webrtc-events-subscriptions: the callback reuses operationId createNotificationChannelSubscription (L266), but operationIds must be unique.
• webrtc-events-subscriptions: subscriptionId is optional in MediaSession and missing from RegistrationEnds (L884-L890, L1037-L1051). The Event Subscription Guide says it MUST be valued for resource-based subscriptions.
• webrtc-events-subscriptions: the address pattern in MediaSession is narrower than Address in call-handling. It excludes urn:service:sos, phone-context and user=phone, so events for such sessions don't match the schema.
• webrtc-events-subscriptions: initialEvent and subscriptionMaxEvents are described as not used, but are still in Config.
• webrtc-call-handling and webrtc-registration: PUT defines both 200 and 204 without saying when each applies. The registration PUT description requires expiresAt in the response body, which a 204 can't carry.

PUT /subscriptions/{subscriptionId}

• The operation isn't part of the Commonalities subscription model. Up to r4.4 the model defines four operations and states that a consumer can't modify a subscription (Event Subscription Guide 2.2.1).
• SubscriptionUpdateRequest accepts {}.
• It reuses the create error sets (INVALID_PROTOCOL, MULTIEVENT_*), which don't apply to an update.

Expected behavior

• Declare only the error codes each operation can return, and prefix API-specific codes (Design Guide 3.2, 3.2.1). Use a 422 API-specific code for an unsupported callType.
• Fix the schemas and examples listed above.
• Decide in the WG whether to keep PUT /subscriptions/{subscriptionId}. If it stays, add minProperties: 1 and define update-specific errors; alternatively, propose the operation to Commonalities.

Alternative solution

Additional context

Found during the review of r3.1. The error code changes and the removal of unused Config fields are breaking and should be made before the next public release, preferably together with the Commonalities r4.4 update. Commonalities r4.4 deprecates the Generic<status> error responses.