1.7 KiB
2026-09-19 repeated authorized SIP outbound verification
Scope
The owner kept the ECS online and authorized another bounded outbound
verification window. Alibaba Cloud state was rechecked immediately before the
test: instance i-2zeb69p1fo75r92wplbz was Running, EIP
123.56.71.98 was InUse and still attached to that instance, and the
Asterisk mock container was healthy. The target remained the approved
15003164745.
The existing sipmock/sipp:0.1.0 image sent one direct INVITE per registered
line using the listed prefix and candidate preserved caller ID. Each attempt
had a 35-second bound, advertised PCMA/8000 SDP, sent no RTP audio, and was
cancelled/aborted by SIPp when no final answer arrived.
Results
| Line | Candidate Request-URI user / caller | Responses | Result |
|---|---|---|---|
数企 61.132.228.221:5060 |
708915003164745 / BD93205882 |
100 Trying, 183 Session Progress |
No final 200 OK within bound |
中鼎 60.171.24.90:5060 |
15003164745 / mbkq |
100 Trying |
No final response/200 OK within bound |
百应 160.202.254.79:5060 |
mka75515003164745 / KQ91526 |
100 Trying, 183 Session Progress, 180 Ringing |
No final 200 OK within bound |
No line formed an answered INVITE dialog. No RTP/audio, recording, AI, OSS,
or billing result was claimed. The earlier attempt remains recorded in
docs/evidence/20260918-real-sip-provider-calls.md; this retry confirms the
same non-connected boundary in a later allowed window.
Cleanup
After the retry, no SIPp process or /tmp/real-* scenario/log remained on the
ECS and the Asterisk container remained healthy. This is provider-line
signaling evidence only, not successful SIP media or P1 acceptance.