my Asterisk system cannot receive incoming calls. outbound calls work fine.
in the CLI, I receive this error:
[Jun 16 16:09:43] NOTICE[14001]: chan_sip.c:7430 sip_reg_timeout: – Registration for 'gnoso@inbound7.vitelity.net’ timed out, trying again (Attempt #1)
What is the meaning of this? Inbound calls used to work fine, and outbound calls still do.
Below is the pertinent part of sip.conf
[general]
register => gnoso:*******@inbound7.vitelity.net:5060
[vitel-inbound] ;(exact format/casing required)
type=friend
host=inbound7.vitelity.net
context=incoming ;(ext-did or from-trunk for A@H)
username=gnoso
secret=********
allow=all
insecure=very
canreinvite=no
[vitel-outbound] ;(exact format/casing required)
type=friend
host=outbound.vitelity.net
context=outbound ;(ext-did or from-trunk for A@H)
username=gnoso
fromuser=gnoso
trustrpid=yes
sendrpid=yes
secret=*******
allow=all
canreinvite=no
I have *'ed the private/password information.
Can anyone help?
Cannot reproduce. I have exactly what I should see (without the right password):
<--- SIP read from 64.2.142.13:5060 --->
SIP/2.0 403 Forbidden (Bad auth)
Please post your sip debug with registration attempt.
we are in the process of moving Asterisk to a new server. If this does not solve the problem, I will post the information.
we completed the move, but an issue still remained, though it was a different problem.
all issues have now been fixed, however.
for the reference of those in a similar situation, we logged the packets coming into Smoothwall (our firewall) and found that, for some crazy reason, Vitelity was sending packets to 10.4.4.87, instead of 10.4.4.138. 10.4.4.87 is the new address of the old asterisk server. the old server was originally 10.4.4.138 and all the phones were configured to talk to it. to minimize fuss when we switched the server, we carried the IP over the new server and the old one which would still be active for a reference, not for use. the old server had never been supposed to talk to Vitelity after it was retired, but somehow things had gone haywire. there was no rule in Smoothwall to cause this, in fact, every rule was to the contrary. we restarted Smoothwall and all things returned to normal.
i hope this is help to anyone else in a similar situation. thank you for your help.
we completed the move, but an issue still remained, though it was a different problem.
all issues have now been fixed, however.
for the reference of those in a similar situation, we logged the packets coming into Smoothwall (our firewall) and found that, for some crazy reason, Vitelity was sending packets to 10.4.4.87, instead of 10.4.4.138. 10.4.4.87 is the new address of the old asterisk server. the old server was originally 10.4.4.138 and all the phones were configured to talk to it. to minimize fuss when we switched the server, we carried the IP over the new server and the old one which would still be active for a reference, not for use. the old server had never been supposed to talk to Vitelity after it was retired, but somehow things had gone haywire. there was no rule in Smoothwall to cause this, in fact, every rule was to the contrary. we restarted Smoothwall and all things returned to normal.
i hope this is help to anyone else in a similar situation. thank you for your help.
sorry for the repeat post, I cant figure out how to delete these!
Note: This would have been a 2nd repeat post, I did not make another post to apologize! 