; ============================================================
; PROPOSAL 2026-09-29 - chat messages between extensions with
; store-and-forward. NOT INSTALLED. Nothing reads this file.
; Goes together with src/msg-store.js.
; ============================================================
;
; TODAY (proven from the live config, read-only):
;   - extension endpoints have NO message_context, so a SIP MESSAGE from a
;     phone is handled by the endpoint's call context [from-internal]
;   - [from-internal] has _XXXX / _XXX, so the message is ACCEPTED (202) and
;     the CALL dialplan runs on a message channel: Dial() cannot work there
;     and there is no MessageSend() -> the text is silently dropped
;
; ------------------------------------------------------------
; VARIANT 1 (recommended): no dialplan logic at all
; ------------------------------------------------------------
; 1. extensions.conf: add this EMPTY context (no extensions on purpose).
;    Because nothing matches here, Asterisk gives the message to the bridge
;    (ARI event TextMessageReceived) instead of the dialplan.

[mphone-msg]
; intentionally empty - messages are handled by the bridge (src/msg-store.js)

; 2. every extension endpoint in the managed PJSIP file gets one extra line
;    (manage-extensions.sh add_extension, plus a one-time update of the
;    existing endpoints):
;
;        message_context=mphone-msg
;
;    Calls are not affected: "context=" (from-internal / receive-only) stays.
;
; ------------------------------------------------------------
; VARIANT 2 (fallback if the ARI event does not arrive in testing)
; ------------------------------------------------------------
; The dialplan passes the message to the bridge over loopback HTTP.
; CURL() and URIENCODE() exist on this box (checked). No System()/shell is
; used, so message text can never be run as a command.
; Limit: dialplan strings are cut at about 4000 characters, so long messages
; would be shortened - that is why variant 1 is preferred.
;
; [mphone-msg]
; exten => _XX.,1,NoOp(chat message to ${EXTEN})
;  same => n,Set(CURLOPT(conntimeout)=2)
;  same => n,Set(CURLOPT(httptimeout)=4)
;  same => n,Set(MSG_RESULT=${CURL(http://127.0.0.1:3000/api/internal/message,to=${EXTEN}&from=${URIENCODE(${MESSAGE(from)})}&body=${URIENCODE(${MESSAGE(body)})})})
;  same => n,Hangup()
;
; The bridge endpoint /api/internal/message would have to accept loopback
; requests only (127.0.0.1) and take the sender from the From user part.