The response to a provideRoamingNumber request came back as absentSubscriber. This has two different real causes that look identical in this one message: (1) the visited VLR/MSC genuinely checked and the subscriber wasn't reachable there (off, no coverage, not attached), or (2) the visited network never answered the request at all, and the querying side (GMSC/gateway) simply timed out waiting and reported absentSubscriber as the default outcome -- not because anyone actually confirmed the device's state.
Where you see it
In a returnError component of a MAP dialogue over TCAP/SCCP (roaming, SMS, call routing).
What to check
The measured request-to-response time below is real evidence, but there's no universal fast-vs-slow cutoff that tells these two cases apart -- the actual answer is whatever provideRoamingNumber response timer is configured on the querying/relaying node (GMSC or gateway), which isn't visible in the capture itself. Ask that node's operator for the configured timer value and compare it to the measured gap: a response landing right at (or just past) that timer value is the node's own timeout firing, not a real answer -- in that case the visited network's VLR/MSC isn't responding at all, a real infrastructure/interconnect issue to escalate there, not a device/coverage question.
Check which network element sent the returnError (calling GT) and the operation it answered.
Got a trace with MAP error 27 GMSC/gateway? Drop it in the analyzer: it finds the step that really failed first, which node sent the code and what to ask the other side. Captures, test-system PDFs and vendor exports. 5 free analyses a month, no sign-up.