go-sip/docs/evidence/20260918-ecs-sip-deployment.md

2026-09-18 ECS deployment and SIP endpoint verification

Scope and safety boundary

This is an owner-authorized first-version deployment/environment check on the existing Debian 13 ECS. No ECS, EIP, security group, Docker container, or unrelated instance was created, detached, stopped, or rebound. The fixed whitelist EIP 123.56.71.98 was confirmed by Alibaba Cloud as InUse on instance i-2zeb69p1fo75r92wplbz in cn-beijing.

This evidence is not P1 or production acceptance. It records deployment of the current dirty-tree candidate and a SIP OPTIONS reachability probe only. The probe sent no INVITE, did not select a telephone number, and did not place a telephone call or claim caller-ID/dial-prefix acceptance.

Candidate deployment

• Source tree: current working tree at source commit 758c0a2 with documented dirty state; local make build passed.
• Candidate SHA-256: 269a0d2ad350544597a71d3b0869ceb57d57f86defb3fe560e64e75bc052edb6.
• The candidate was copied as the non-destructive hash-named file /opt/sip-go-agent/sip-go-agent.269a0d2ad350544597a71d3b0869ceb57d57f86defb3fe560e64e75bc052edb6 and the remote hash matched.
• --help executed on the ECS and exposed the explicit agent and dispatcher subcommands.
• The pre-existing /opt/sip-go-agent/sip-go-agent was not overwritten. No Agent or Dispatcher systemd unit exists on this host, so the candidate was not silently activated as a production service.

The final make release artifact was also transferred to /opt/sip-go-agent/releases/local-development-14d61e617df1c00a9a0ab372f8baf0b8a67e40cff75fcfb36fb1f9cfb27a0725/. The release manifest and portable relative SHA256SUMS verified the binary/module hashes, Go 1.27.1, source_dirty=true, and credentials_embedded=false; the remote release --help exposed both agent and dispatcher. The manifest explicitly retains production_approval=false, so this is a deployment candidate, not a release approval.

Deployed process startup

• The candidate Agent was launched on the ECS in explicit --mode mock with an isolated temporary spool and returned successfully after startup.
• The candidate Dispatcher was launched in explicit --mode mock with an isolated temporary SQLite database and started successfully under a bounded timeout; the database was created at 122,880 bytes.
• dispatcher --once without RABBITMQ_URL failed closed with the expected missing-publisher configuration error. It did not silently run without the required MQ path.
• These are binary/startup checks only. No production Agent service was activated, and no real MQ command or business event was consumed.

Follow-up Dispatcher outbox validation

The candidate was rebuilt after the first ECS receipt smoke exposed that the long-running dispatcher --consume path did not flush its own outbox. Candidate SHA-256: 14d61e617df1c00a9a0ab372f8baf0b8a67e40cff75fcfb36fb1f9cfb27a0725. The current candidate was copied to the ECS and run with only --consume. Publishing the contract fixture to the isolated tenant queue resulted within one second in tasks=1, inbox=1, outbox=1, and outbox_status=published; no separate --once process was used. A temporary event queue bound to agent-call.events.v1 received one agent-call.command.result message. The regression test is in cmd/sip-go-agent/main_test.go.

Existing media environment

• Container: agent-call-asterisk-poc.
• Image: andrius/asterisk:22.10.1-pinned; container healthy.
• Asterisk: 22.10.1; UDP transport 0.0.0.0:5060 inside the container.
• Current endpoints are only anonymous and mock-callee; pjsip show registrations reports No objects found.
• Therefore this host currently has no configured provider trunk, provider registration, provider credentials, or production Agent/ARI execution path.

Provider signaling probe

Using the existing sipmock/sipp:0.1.0 SIPp image and a temporary OPTIONS-only scenario, one UDP OPTIONS was sent to each registered provider from the ECS private source 172.16.0.123. Each response carried received=123.56.71.98 and returned SIP/2.0 200 OK:

Provider entry	Endpoint	Result
数企	61.132.228.221:5060	200 OK
中鼎	60.171.24.90:5060	200 OK
百应	160.202.254.79:5060	200 OK

The temporary scenario and logs were removed after the probe. No INVITE, RTP media, registration, Digest exchange, caller-ID assertion, prefix rewrite, or telephone charge was generated.

Result and remaining gate

Passed: current candidate artifact was copied and executed for CLI verification on the authorized ECS; the fixed EIP was confirmed; all three registered SIP endpoints answered an OPTIONS probe through the fixed EIP.

Not proven: a 200 OK to OPTIONS is not provider authorization for an outbound call. The remote Asterisk still lacks provider trunk configuration. The provider-specific transport/registration/authentication mode and the mapping of the preserved caller IDs (BD93205882, mbkq, KQ91526) to From/PAI/Digest fields remain unconfirmed. The approved dial prefixes, number selection, real call duration/recording, AI/MQ/OSS path, and two-Cell P1 acceptance therefore remain open.