You will need SIP debug output for this, as various different conditions get mapped onto busy and congestion. However the most likely reason is that the number you are calling is busy!
No, that number is not busy, because the phone is near me =)
Here is debug:
[code]<------------->
— (14 headers 15 lines) —
Sending to 194.44.237.ХХХ : 37889 (NAT)
Using INVITE request as basis request - e4ea2458ad7cf0ae@10.10.20.107
Found user ‘750’
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 4
Found RTP audio format 18
Found RTP audio format 2
Found RTP audio format 99
Peer audio RTP is at port 10.10.20.107:5006
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G723 for ID 4
Found audio description format G729 for ID 18
Found audio description format G726-32 for ID 2
Found audio description format iLBC for ID 99
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0xd0d (g723|ulaw|alaw|g726|g729|ilbc)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 10.10.20.107:5006
Looking for 1732 in from-internal (domain 192.168.0.102)
list_route: hop: sip:750@10.10.20.107
There is no final status on that trace. The decision as to what category to use will be based on the final status, typically a 4xx or 5xx status for a failed call. 1xx ones are interim results and the call will not terminate on receiving them.