Skip to content

feat: complete SipConfiguration attributes for API 2026-04-16#51

Merged
Fivell merged 5 commits into
mainfrom
feat/incoming-auth-credentials
May 5, 2026
Merged

feat: complete SipConfiguration attributes for API 2026-04-16#51
Fivell merged 5 commits into
mainfrom
feat/incoming-auth-credentials

Conversation

@Fivell
Copy link
Copy Markdown
Member

@Fivell Fivell commented Apr 30, 2026

Summary

Completes the API 2026-04-16 SipConfiguration attribute set. Mirrors the Ruby reference PR #80.

5 writable attributes (missed during the original 2026-04-16 rollout)

These attributes the server accepts under API 2026-04-16 and are listed in the public 2026-04-16 changelog, but were absent from both this SDK and the public Postman collection. Server is authoritative — added all five:

Java field Wire Type
enabledSipRegistration enabled_sip_registration Boolean
useDidInRuri use_did_in_ruri Boolean
networkProtocolPriority network_protocol_priority NetworkProtocolPriority enum
diversionInjectMode diversion_inject_mode DiversionInjectMode enum
cnamLookup cnam_lookup Boolean

Two new enums added:

  • DiversionInjectModenone, did_number
  • NetworkProtocolPriorityforce_ipv4, force_ipv6, any, prefer_ipv4, prefer_ipv6

2 read-only attributes

Server-generated, returned only when enabledSipRegistration: true:

  • incomingAuthUsername
  • incomingAuthPassword

The API rejects writes (400 Param not allowed). Both fields are annotated with @JsonProperty(access = JsonProperty.Access.WRITE_ONLY), which in Jackson's terminology means "deserialize from JSON, never serialize back to JSON" — exactly the read-only-on-write semantics required.

Misc

  • Bumped to 4.0.1 in build.gradle.kts.

Test plan

  • ./gradlew test — passes
  • New tests:
    • Deserialize a SIP configuration response with all 5 writable + 2 read-only fields populated; assert getters return correct values.
    • Serialize a SipConfiguration that has the 2 read-only fields populated (simulating round-trip after a GET); assert the resulting JSON does NOT include incoming_auth_username / incoming_auth_password. This is the regression-prevention test for the read-only contract.
  • CI green
  • After merge: tag 4.0.1, JitPack auto-builds, publish GitHub Release

@Fivell Fivell changed the title feat: complete V3.5 SipConfiguration attributes for API 2026-04-16 feat: complete SipConfiguration attributes for API 2026-04-16 May 4, 2026
@Fivell Fivell force-pushed the feat/incoming-auth-credentials branch from 6cbf047 to fb71432 Compare May 4, 2026 15:01
Fivell added 2 commits May 4, 2026 17:36
Adds the 5 writable + 2 read-only SIP registration attributes
introduced in API 2026-04-16: enabled_sip_registration,
use_did_in_ruri, cnam_lookup, network_protocol_priority,
diversion_inject_mode plus server-generated incoming_auth_username
and incoming_auth_password (returned only when sip_registration is
enabled, stripped from POST/PATCH bodies because the API rejects
writes with 400 Param not allowed).

Includes wire-format coverage of the create / read / disable PATCH
flows, fixture alignment with real sandbox responses, and the
SDK-specific changes needed to land the feature cleanly (typing /
nullability fixes, read-only enforcement at the type level,
constructor / builder ergonomics).
Override the SDK's idiomatic debug/log surface to replace credential
field values with [FILTERED] before they reach default print(),
logger output, debugger inspection, or unhandled exception traces.
The wire payload is unaffected — serializers continue to emit the
real values (or strip read-only ones via the existing read-only
mechanism).

Marks SIP auth_password and the server-generated incoming_auth_*
on SipConfiguration, plus username and password on the
credentials_and_ip authentication method, as sensitive.
@Fivell Fivell force-pushed the feat/incoming-auth-credentials branch 2 times, most recently from 4e62915 to 1aefc01 Compare May 4, 2026 16:39
Fivell added 2 commits May 5, 2026 00:24
The server enforces multi-field invariants on the sip_registration
toggle (host / port must be absent when enabled, use_did_in_ruri
must be false when disabled). The SDK now applies those cascades
automatically so caller code never has to enumerate the rule set:

  - enabled_sip_registration = true  -> host = null, port = null
                                         (always emitted on the wire,
                                         even on a fresh config)
  - enabled_sip_registration = false -> use_did_in_ruri = false
  - host = <non-blank>               -> enabled_sip_registration = false,
                                         use_did_in_ruri = false

The host/port nullification fires unconditionally so a PATCH against
an existing trunk that already has them persisted server-side is
told to clear them — a conditional cascade would silently drop the
fields and the server would reject the merged request with 422.

The cascade fires only on application-driven assignments;
deserialization of server responses (which are already internally
consistent) bypasses it so existing combinations are not
clobbered.
Add a SIP registration usage section to the README that explains
the cascade rules and shows the enable / disable examples. The
disable example is a single setHost() / config.host = '...' call —
the cascade flips the dependent fields automatically.
@Fivell Fivell force-pushed the feat/incoming-auth-credentials branch from 1aefc01 to f0c6fea Compare May 4, 2026 22:24
The same one-line credential-mask ternary that returns [FILTERED] for
non-null credential strings was inlined in two unrelated toString()
overrides: SipConfiguration and CredentialsAndIpAuthenticationMethod.
Extract it into a new com.didww.sdk.internal.Redact utility class.
Both call sites now route through Redact.mask, removing the duplicate.

Behaviour is unchanged — the helper body is character-for-character
identical to the previous inline expressions, and the existing
redaction tests on both types continue to pass.
@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud Bot commented May 4, 2026

@Fivell Fivell merged commit 38d1ce0 into main May 5, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant