feat: send 100 Trying + 180 Ringing inbound#51
Merged
Conversation
An inbound INVITE drew no provisional response: the server INVITE transaction only delivered the request to the TU, and the consumer had no way to alert. Per RFC 3261 §9.1 a caller may not send CANCEL until it has received a provisional, so a peer that hung up before pickup sent nothing at all — the call rang forever — and callers heard no ringback. - Auto-send `100 Trying` from the inbound router the moment a fresh INVITE lands (§17.2.1): quenches INVITE retransmits and unblocks the caller's CANCEL. - Add `IncomingCall::ring()` to send `180 Ringing`. It shares a per-call UAS `To` tag with the eventual `200`/reject final (§12.1.1), so the early and confirmed dialogs are the same dialog; `accept`/`reject` now reuse that stored tag instead of minting a fresh one each. Integration tests cover the automatic 100 and the 180/200 tag match; the RFC-COVERAGE table now reflects the real behavior (it previously claimed an automatic 100 that was never actually sent). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
An inbound INVITE drew no provisional response: the server INVITE transaction only delivered the request to the TU, and the consumer had no way to alert the caller. Per RFC 3261 §9.1 a caller may not send
CANCELuntil it has received a provisional — so a peer that hung up before pickup sent nothing at all (the call rang forever on both ends), and callers heard no ringback.What
100 Tryingfrom the inbound router the moment a fresh INVITE lands (§17.2.1): quenches INVITE retransmits and unblocks the caller'sCANCEL.IncomingCall::ring()sends180 Ringing. It shares a per-call UASTotag with the eventual200/reject final (§12.1.1), so the early and confirmed dialogs are the same dialog;accept/rejectnow reuse that stored tag instead of minting a fresh one each.RFC-COVERAGE.mdupdated — it previously claimed an automatic100that was never actually sent.Tests
New integration tests in
tests/end_to_end_call.rs: the automatic100, and the180/200tag match. Full suite green (229 lib + 10 e2e + doc).Consumer
wavekat-voicecallsring()on the inbound path (wavekat/wavekat-voice draft PR). Publish a new minor so that consumer can drop its local[patch.crates-io]and pin the release.🤖 Generated with Claude Code