Clarification on registrationExpireTime | webrtc-registration

[teikuran]

Problem description
The current specification for the webrtc-registration may need further clarification regarding how the GW handles the 'registrationExpireTime' when it is explicitly provided by the API consumer.

While the description for regSessionRequest states that if the client omits this field, the server sets the expiry according to its own TTL policy, there is no description about how the GW handles the registrationExpireTime when it is explicitly provided by the API consumer e.g., whehter the GW should strictly follow or ignore a client-provided value that exceeds operator limits.

Expected action
The "Server behaviour" should be mentioned e.g., regarding on the point if GW should respect the request or not and how.

[deepakjaiswal1]

@teikuran @stroncoso
The WebRTC gateway should manage registrationExpireTime using two server-side configuration values (not exposed in the API):

• Default registration duration – used when the client does not specify registrationExpireTime
• Max registration duration – the upper bound the GW will permit

Proposed server behaviour:

1. Client omits registrationExpireTime: The GW sets registrationExpireTime = currentTime + defaultRegistrationDuration.

2. Client provides registrationExpireTime: The GW calculates the requested duration as registrationExpireTime - currentTime.

   • If the requested duration is ≤ max registration duration, the GW honors the client-provided value.
   • If the requested duration exceeds max registration duration, the GW overrides it and sets registrationExpireTime = currentTime + maxRegistrationDuration.

3. Client provides an invalid registrationExpireTime (i.e., already in the past, zero, or negative duration): The GW rejects the request with a 4xx error.

The two duration values are purely operator-side configuration and are not surfaced in the API. The client is responsible for tracking the registrationExpireTime it submitted and managing its own refresh logic accordingly.

This behaviour mirrors established SIP Expires header negotiation (RFC 3261 §10.3), where a registrar may shorten but never extend the requested expiry, and should be documented under a "Server behaviour" section in the regSessionRequest specification.

[stroncoso]

Thanks @deepakjaiswal1 , your clarification makes complete sense to me. If @teikuran also agrees, we can include that info on the API somehow.

[stroncoso]

Confirmed at today's meeting: We will close this with a dedicated PR with clarifications on the API specs.

[teikuran]

@deepakjaiswal1
Further clarification if I may. What would be the expected behaviour that can be captured in the API spec, when the requested duration is shorter than operator's minimum TTL? Error response or etc.