mautrix-telegram currently bridges Telegram call-related updates into Matrix as messages/notices, including at least:
tg.UpdatePhoneCall / PhoneCallRequested via onPhoneCall in pkg/connector/handletelegram.go (e.g. “Incoming … call” with BeeperActionMessageCall)
- Service actions such as
MessageActionPhoneCall, MessageActionGroupCall, MessageActionInviteToGroupCall, MessageActionGroupCallScheduled
Real Telegram voice/video calls are not bridged as MatrixRTC/Element Call (and are not expected to be).
For personal puppeting this is awkward:
- Matrix shows non-actionable call notices that cannot be answered as a real Matrix call.
- The user must open the official Telegram client to join/answer.
- Call-related noise in portals is undesirable if the bridge is used for messaging only.
mautrix-whatsapp already exposes an opt-out for the analogous case:
network:
call_start_notices: false
Request
Please add a config option, for example:
network:
# If false, do not bridge phone/group call events or call service messages to Matrix.
call_notices: true # default: true for current behaviour
When false:
- Ignore (or no-op)
UpdatePhoneCall / PhoneCallRequested for Matrix side effects.
- Skip converting call-related
MessageAction* variants into portal messages (at least for 1:1 phone calls; group-call actions optionally covered by the same flag or a separate one).
- Do not create portals solely due to a call offer.
- Leave normal message/media/sticker/etc. bridging unchanged.
If Telegram’s MTProto layer requires acknowledging call updates for session health, the bridge may still handle them internally—only Matrix emission should be optional.
Environment (example)
- mautrix-telegram (Go bridge, self-hosted)
- Homeserver: tuwunel
- Use case: personal puppeting; messaging only; calls in official Telegram app
Alternatives considered
- Client-side filtering in Element (incomplete, still noisy).
- Logging out of the bridge when expecting calls (impractical).
- Local patch (maintenance burden).
Related
- WhatsApp:
network.call_start_notices
- Same request prepared for mautrix-signal (
events.Call → “Incoming call” / “Call ended”)
Thanks!
Martin
mautrix-telegram currently bridges Telegram call-related updates into Matrix as messages/notices, including at least:
tg.UpdatePhoneCall/PhoneCallRequestedviaonPhoneCallinpkg/connector/handletelegram.go(e.g. “Incoming … call” withBeeperActionMessageCall)MessageActionPhoneCall,MessageActionGroupCall,MessageActionInviteToGroupCall,MessageActionGroupCallScheduledReal Telegram voice/video calls are not bridged as MatrixRTC/Element Call (and are not expected to be).
For personal puppeting this is awkward:
mautrix-whatsapp already exposes an opt-out for the analogous case:
Request
Please add a config option, for example:
When
false:UpdatePhoneCall/PhoneCallRequestedfor Matrix side effects.MessageAction*variants into portal messages (at least for 1:1 phone calls; group-call actions optionally covered by the same flag or a separate one).If Telegram’s MTProto layer requires acknowledging call updates for session health, the bridge may still handle them internally—only Matrix emission should be optional.
Environment (example)
Alternatives considered
Related
network.call_start_noticesevents.Call→ “Incoming call” / “Call ended”)Thanks!
Martin