We have recently (past few days) stopped being able to dial mobile numbers (07…) from one of our SIP servers. We haven’t made any changes (that I know of) recently. We also have another SIP server on a different connection, with a different IP which has an identical setup. This server is working fine.
I’ve included a log file from one attempt to dial an 07 number here http://pastebin.com/k33892iH. The issue affects multiple numbers and clients.
That was a whole lot of log…
-- Executing [[email protected]:3] NoOp("SIP/5145-000101a0", "TRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE: 20 - failing through to other trunks") in new stack
So there is your error.
20 subscriber absent 480 Temporarily unavailable
From the ietf:
21.4.18 480 Temporarily Unavailable
The callee’s end system was contacted successfully but the callee is
currently unavailable (for example, is not logged in, logged in but
in a state that precludes communication with the callee, or has
activated the “do not disturb” feature). The response MAY indicate a
better time to call in the Retry-After header field. The user could
also be available elsewhere (unbeknownst to this server). The reason
phrase SHOULD indicate a more precise cause as to why the callee is
unavailable. This value SHOULD be settable by the UA. Status 486
(Busy Here) MAY be used to more precisely indicate a particular
reason for the call failure.
This status is also returned by a redirect or proxy server that
recognizes the user identified by the Request-URI, but does not
currently have a valid forwarding location for that user.
Thanks for your reply.
It was my own mobile number I was calling, so I know DND or any similar features were active. I could also call the number fine from other (non-SIP) phones.
The final point about a redirect or proxy server is interesting, although why are landline number unaffected? Is there something special about the way that calls connect to mobile numbers?
It looks like the problem (or at least part of it) was the nameserver.
We recently stopped using one of our VoIP providers, but it turned out the only nameserver in /etc/resolv.conf was theirs.
Putting in some other nameservers seems to have sorted the problem.