calls: send session-terminate when the media path closes or fails

asxpi commented

2026-10-17 07:52:35 +00:00

Member

When the pc reports closed or failed, OnPcState tears the media down
and Finish sends only XEP-0353's . A peer that ends a Jingle
session only on session-terminate (another.im's Android app) keeps
such a call up, its video frozen, after the desktop has hung up.

Tell the peer in Jingle too, as the fatal media error path already
does: session-terminate with success when the path closed, and with
connectivity-error when it failed, once Jingle has started.

Two tests in test_calls_media.tcl check the terminate for both; they
fail without this change. Tested against the Android app: hanging up
on the desktop now ends the call on the phone.

Written and tested on v1.0.0-rc7 (b40975d6); rebased onto develop (7b31417d), where it applies cleanly.

🤖 Generated with Claude Code

When the pc reports closed or failed, OnPcState tears the media down and Finish sends only XEP-0353's <finish/>. A peer that ends a Jingle session only on session-terminate (another.im's Android app) keeps such a call up, its video frozen, after the desktop has hung up. Tell the peer in Jingle too, as the fatal media error path already does: session-terminate with success when the path closed, and with connectivity-error when it failed, once Jingle has started. Two tests in test_calls_media.tcl check the terminate for both; they fail without this change. Tested against the Android app: hanging up on the desktop now ends the call on the phone. Written and tested on v1.0.0-rc7 (b40975d6); rebased onto develop (7b31417d), where it applies cleanly. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

asxpi added 1 commit

2026-10-17 07:52:35 +00:00

calls: send session-terminate when the media path closes or fails 901b854f2a

When the pc reports closed or failed, OnPcState tears the media down
and Finish sends only XEP-0353's <finish/>. A peer that ends a Jingle
session only on session-terminate (another.im's Android app) keeps
such a call up, its video frozen, after the desktop has hung up.

Tell the peer in Jingle too, as the fatal media error path already
does: session-terminate with success when the path closed, and with
connectivity-error when it failed, once Jingle has started.

Two tests in test_calls_media.tcl check the terminate for both; they
fail without this change. Tested against the Android app: hanging up
on the desktop now ends the call on the phone.

Assisted-by: Claude:opus-5-5

ann referenced this pull request from a commit

2026-10-17 14:57:42 +00:00

Merge PR #9 (fix/calls-terminate-on-media-close): when the media path closes or fails on a call that has a Jingle session, the peer is told with session-terminate (success, or connectivity-error) beside the JMI finish, so a peer that ends sessions only on session-terminate does not keep a dead call up.

ann commented

2026-10-17 14:58:28 +00:00

Owner

Merged by hand into develop (merge commit in the 8411e18f line) and released in v1.0.0-rc10; thank you. PR #10 went in with a review follow-up (6996b1f9: the wire-answer parse under test, a deadline on the poll, the resolve() doc). Closing, since a hand merge is not marked merged here.

Merged by hand into develop (merge commit in the 8411e18f line) and released in v1.0.0-rc10; thank you. PR #10 went in with a review follow-up (6996b1f9: the wire-answer parse under test, a deadline on the poll, the resolve() doc). Closing, since a hand merge is not marked merged here.

ann closed this pull request

2026-10-17 14:58:29 +00:00

ann referenced this pull request from a commit

2026-10-25 23:27:10 +00:00

AUDIT-2026-10-25 #9 (Low): a Telegram secret chat message that decrypts but does not parse no longer stalls and aborts the chat: tacky/xmpp/mtproto.tcl gains tl::decodeLayer, which reads the decryptedMessageLayer envelope's header (random_bytes, layer, in_seq_no, out_seq_no) as decode does and its message on its own, a message that does not decode (an unknown constructor not at the tail, such as a newer layer's entity, or bytes left over) becoming {_ unknown id raw why parse}; receive uses it, so Process consumes the message's seq number and reports it dropped (reason parse) instead of dropping the envelope before its seq was read, which made the next message a hole, sent a Resend that brought the same bytes back and aborted the chat with gap after 120 s. Only an envelope that is not a decryptedMessageLayer is still dropped whole. Test: test_mtproto_protocol.tcl mtproto-protocol-a-message-that-does-not-parse-still-takes-its-seq (fails before: the next message held, a Resend, and the tick ended the chat).

ann referenced this pull request from a commit

2026-10-25 23:27:10 +00:00

AUDIT-2026-10-25 #12 (Low, the rest): an envelope with fewer than 15 random bytes is dropped, as Telegram's apps drop it: tacky/xmpp/mtproto.tcl receive makes its message {_ unknown why random_bytes}, so it still uses its seq number (now safe, #9) and is reported dropped with reason random_bytes. Test: test_mtproto_protocol.tcl mtproto-protocol-an-envelope-with-short-random-bytes-is-dropped-but-counted (fails before: the message was taken).

ann referenced this pull request from a commit

2026-10-25 23:27:10 +00:00

AUDIT-2026-10-25 #9 #10 #12: the protocol engine's header states the rules as they now are: each hole asked for with its own Resend, a 65th held message or a hole open for 120 s aborts, an unparsable message or one with under 15 random bytes uses its seq number and is dropped. Docs only.

ann referenced this pull request from a commit