Does any one know why i get a busy tone when i call?
I have sip phone configure and registered and i also have my trunks steed up.
Nope, and with the information you’ve provided, it seems like a guessing game. 
What information do you need?
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Called SIP/vitel-inbound/
– SIP/vitel-inbound-00000045 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
– Executing [tdial@ext-trunk:8] Hangup(“SIP/vitel-inbound-00000044”, “”) in new stack
inbound
username=xxxxxx
type=friend
dtmfmode=auto
secret=xxxxxx
insecure=port,invite
host=inbound16.vitelity.net
allow=all
context=from-trunk
canreinvite=no
outbound
type=friend
dtmfmode=auto
host=outbound.vitelity.net
username=xxxxxx
fromuser=xxxxxx
secret=xxxxxxx
trustrpid=yes
sendrpid=yes
allow=all
canreinvite=no
Turn on your SIP debug and see what happens when Asterisk sends the INVITE to your provider.
<------------->
— (11 headers 0 lines) —
Responding to challenge, registration to domain/host name inbound16.vitelity.net
> doing dnsmgr_lookup for 'inbound16.vitelity.net’
REGISTER 11 headers, 0 lines
Reliably Transmitting (NAT) to 140.239.143.5:5060:
REGISTER sip:inbound16.vitelity.net SIP/2.0
Via: SIP/2.0/UDP 70.171.227.201:5060;branch=z9hG4bK1e852287;rport
Max-Forwards: 70
From: sip:dnlt_dani@inbound16.vitelity.net;tag=as0522b450
To: sip:dnlt_dani@inbound16.vitelity.net
Call-ID: 38dd6df45acf300f2559890a15fbf1ca@70.171.227.201
CSeq: 327 REGISTER
User-Agent: Asterisk PBX 1.8.8.1
Authorization: Digest username=“dnlt_dani”, realm=“asterisk”, algorithm=MD5, uri=“sip:inbound16.vitelity.net”, nonce=“458c2097”, response="3cbadd3a268490d69d1e8997ac65987f"
Expires: 120
Contact: sip:s@70.171.227.201:5060
Content-Length: 0
<— SIP read from UDP:140.239.143.5:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 70.171.227.201:5060;branch=z9hG4bK1e852287;received=70.171.227.201;rport=5060
From: sip:dnlt_dani@inbound16.vitelity.net;tag=as0522b450
To: sip:dnlt_dani@inbound16.vitelity.net
Call-ID: 38dd6df45acf300f2559890a15fbf1ca@70.171.227.201
CSeq: 327 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0
<------------->
— (10 headers 0 lines) —
<— SIP read from UDP:140.239.143.5:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 70.171.227.201:5060;branch=z9hG4bK1e852287;received=70.171.227.201;rport=5060
From: sip:dnlt_dani@inbound16.vitelity.net;tag=as0522b450
To: sip:dnlt_dani@inbound16.vitelity.net;tag=as5df9c0df
Call-ID: 38dd6df45acf300f2559890a15fbf1ca@70.171.227.201
CSeq: 327 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Expires: 60
Contact: sip:s@70.171.227.201:5060;expires=60
Date: Sat, 28 Jan 2012 02:25:30 GMT
Content-Length: 0
<------------->
— (13 headers 0 lines) —
Scheduling destruction of SIP dialog ‘38dd6df45acf300f2559890a15fbf1ca@70.171.227.201’ in 32000 ms (Method: REGISTER)
<— SIP read from UDP:172.16.1.96:5060 —>
NOTIFY sip:172.16.1.1 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.96:5060;branch=z9hG4bK-fd298ee2
From: “Dani” sip:100@172.16.1.1;tag=c226754226467e95o0
To: sip:172.16.1.1
Call-ID: fa22f38f-fde0ccad@172.16.1.96
CSeq: 1497 NOTIFY
Max-Forwards: 70
Contact: “Dani” sip:100@172.16.1.96:5060
Event: keep-alive
User-Agent: Cisco/SPA303-7.4.9a
Content-Length: 0
<------------->
— (11 headers 0 lines) —
<— Transmitting (NAT) to 172.16.1.96:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.1.96:5060;branch=z9hG4bK-fd298ee2;received=172.16.1.96;rport=5060
From: “Dani” sip:100@172.16.1.1;tag=c226754226467e95o0
To: sip:172.16.1.1;tag=as5c7970ab
Call-ID: fa22f38f-fde0ccad@172.16.1.96
CSeq: 1497 NOTIFY
Server: Asterisk PBX 1.8.8.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog ‘fa22f38f-fde0ccad@172.16.1.96’ in 32000 ms (Method: NOTIFY)
<— SIP read from UDP:172.16.1.96:5060 —>
REGISTER sip:172.16.1.1 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.96:5060;branch=z9hG4bK-10424934
From: “Dani” sip:100@172.16.1.1;tag=c226754226467e95o0
To: “Dani” sip:100@172.16.1.1
Call-ID: b8544dad-2eeaffcf@172.16.1.96
CSeq: 9254 REGISTER
Max-Forwards: 70
Authorization: Digest username=“100”,realm=“asterisk”,nonce=“210956f6”,uri=“sip:172.16.1.1”,algorithm=MD5,response="898960415e6579b9b13565de0c44f6aa"
Contact: “Dani” sip:100@172.16.1.96:5060;expires=3600
User-Agent: Cisco/SPA303-7.4.9a
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces
<------------->
— (13 headers 0 lines) —
Sending to 172.16.1.96:5060 (NAT)
<— Transmitting (NAT) to 172.16.1.96:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.16.1.96:5060;branch=z9hG4bK-10424934;received=172.16.1.96;rport=5060
From: “Dani” sip:100@172.16.1.1;tag=c226754226467e95o0
To: “Dani” sip:100@172.16.1.1;tag=as54c085c6
Call-ID: b8544dad-2eeaffcf@172.16.1.96
CSeq: 9254 REGISTER
Server: Asterisk PBX 1.8.8.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="562607d3"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog ‘b8544dad-2eeaffcf@172.16.1.96’ in 32000 ms (Method: REGISTER)
<— SIP read from UDP:172.16.1.96:5060 —>
REGISTER sip:172.16.1.1 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.96:5060;branch=z9hG4bK-49684374
From: “Dani” sip:100@172.16.1.1;tag=c226754226467e95o0
To: “Dani” sip:100@172.16.1.1
Call-ID: b8544dad-2eeaffcf@172.16.1.96
CSeq: 9255 REGISTER
Max-Forwards: 70
Authorization: Digest username=“100”,realm=“asterisk”,nonce=“562607d3”,uri=“sip:172.16.1.1”,algorithm=MD5,response="40334783eb8c14ca00621424fe11eaae"
Contact: “Dani” sip:100@172.16.1.96:5060;expires=3600
User-Agent: Cisco/SPA303-7.4.9a
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces
<------------->
— (13 headers 0 lines) —
Sending to 172.16.1.96:5060 (NAT)
Reliably Transmitting (NAT) to 172.16.1.96:5060:
OPTIONS sip:100@172.16.1.96:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.1:5060;branch=z9hG4bK0c779d4d;rport
Max-Forwards: 70
From: “Unknown” sip:Unknown@172.16.1.1;tag=as2bb08933
To: sip:100@172.16.1.96:5060
Contact: sip:Unknown@172.16.1.1:5060
Call-ID: 660ad8b926a110d25071cec05dfda064@172.16.1.1:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.8.8.1
Date: Fri, 27 Jan 2012 19:28:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
<— Transmitting (NAT) to 172.16.1.96:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.1.96:5060;branch=z9hG4bK-49684374;received=172.16.1.96;rport=5060
From: “Dani” sip:100@172.16.1.1;tag=c226754226467e95o0
To: “Dani” sip:100@172.16.1.1;tag=as54c085c6
Call-ID: b8544dad-2eeaffcf@172.16.1.96
CSeq: 9255 REGISTER
Server: Asterisk PBX 1.8.8.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Expires: 3600
Contact: sip:100@172.16.1.96:5060;expires=3600
Date: Fri, 27 Jan 2012 19:28:09 GMT
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog ‘b8544dad-2eeaffcf@172.16.1.96’ in 32000 ms (Method: REGISTER)
<— SIP read from UDP:172.16.1.96:5060 —>
SIP/2.0 200 OK
To: sip:100@172.16.1.96:5060;tag=38b63886b755f421i0
From: “Unknown” sip:Unknown@172.16.1.1;tag=as2bb08933
Call-ID: 660ad8b926a110d25071cec05dfda064@172.16.1.1:5060
CSeq: 102 OPTIONS
Via: SIP/2.0/UDP 172.16.1.1:5060;branch=z9hG4bK0c779d4d
Server: Cisco/SPA303-7.4.9a
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces
<------------->
Is this it?
If not how do you do it?
Sorry, I am new to this stuff!!
There are no SIP calls, either incoming or outgoing, in that log. You also need to use set verbose 3 (or higher), so that the dial plan can be followed.
I did set the verbose 3 but nothing changed.
When i called my voip provider they said that my server is not responding to incoming calls.
Do you guys ave a solution?
Thanks for the suggestion!!!
We are still waiting for sufficient information.
Until you can provide a trace including an incoming INVITE, we can’t be sure that the INVITEs are even reaching you, let alone diagnose why they are not producing a valid response.