I've run into a particular issue in several scenarios that I just can't overlook anymore. It seams that whenever an extension in a route is either not registered or unreachable the route breaks and callers receive a "this number has been disconnected or is no longer in service" error message.
This has happened...
...on Incoming calls when the route is just a single extension.
...on Incoming calls when the route is a huntlist and just a single extension cannot be reached.
...in a Find Me Follow Me set up when just a single extension cannot be reached. In this scenario when an extension with Find me Follow me set up receives a call from another internal extension, the call does go to voicemail but still does not call the remaining extensions.
Shouldn't the call route ignore the extension that can't be reached and move to the next step in the route?
The message is being
The message is being generated by the originating telephone carrier. When I make a test call from my mobile it comes from AT&T. When my upstream provider tests from his mobile it comes from Verizon Wireless.
Prior installs of other Asterisk configuration interfaces reacted the same way you described: if an extension could not be reached the call went straight to VM or to the next step in the route. This is what I expected from MTE also.
I have changed nothing in the underlying configuration. This is a standard MTE ISO install.
its not MTE, its either
its not MTE, its either something youve done or not done in terms of interop with your carrier... I have hundreds of tenants and if one of their T1's goes offline, voicemail picks up immediately. If you dont believe me look through tl-userexten-base yourself.
it doesnt matter if joe blow at extension 100 calls extension 101 or if an outside caller calls 8005551212 and that maps using 'go to user extension' 101.. its the same tl-userexten-base.
If you are saying that joe blow at 100 can call 101 and get the behavior you want.. then outside callers will get the same thing unless:
a) you set something up horribly wrong
b) you have an interop issue you havent worked through with the carrier in terms of how sip.conf is supposed to be setup.
I do believe you and that's
I do believe you and that's why I'm here looking for assistance. If I did not think that it would act this way I would just pull the plug and go back to one of the other platforms I've used previously that did not suit my needs.
Joe Blow at ext 100 can call 101 and get the results I need unless find me follow me is set up for ext 101. If that is the case and one of the phones in find me follow me is unplugged the call goes directly to VM without ringing the other phones.
a) I'm fine admitting if I've screwed something up (I'm not above that), but I need some direction on where to look.
b) I'm not sure what the problem could be in the interop between myself and the carrier since the calls are making it to the Asterisk box. Any direction you can point me in would be helpful.
lets start with the
lets start with the basics..
make sure your box is on a pubic ip and no nat is interfering with your connection with your provider
make sure your not accepting anonymous calls (set allowguest=no in the [general] section of sip.conf)
make sure you arent enabling re-invites
find out what type of switch your itsp is using to send calls.. there could be interop issues. Perhaps he is expecting 503 messages instead of 488 messages etc etc. its a whole sorted detail of things but knowing what type of device you are connected to is a starting point. How does he negotiate SIP/SDP? Is it using proxy-authentication (username/secret) or is it configured to trust an IP implicitly?
The server is in a data
The server is in a data center on a public IP.
canreinvite is set to 'no' everywhere I can find.
We're configured to trust an IP implicitly. So when I set allowguest to 'no' it breaks all inbound calling, correct?
Our SIP trunks are coming from a Cisco device that we manage to connect back to the PSTN. I'm waiting on a call back from my upstream to discuss further with them. I'll update when I know more, though I'm still confused how an interop problem with them would cause this problem when the calls are making it to the server.
I attempted to do some testing last night but was unable to force the problem to reoccur. Luckily (I guess) I have some users who are without Internet this morning so I've been able to duplicate it though I am unable to see anything in the logs to point me in the right direction.
We're configured to trust an
We're configured to trust an IP implicitly. So when I set allowguest to 'no' it breaks all inbound calling, correct?
not if you set it up correctly.. if you set this and inbound fails.. its clear indication you didnt set up your trunk right.
paste the sip.conf setting for that trunk
That wouldn't surprise me
That wouldn't surprise me either...
[VS-01]
qualify=no
nat=no
host=a.b.c.d
dtmfmode=rfc2833
context=from-outside
type=friend
rfc2833compensate=yes
canreinvite=no
disallow=all
allow=ulaw
change it to
change it to this..
[VS-01]
qualify=no
nat=no
username=VS-01
host=a.b.c.d
dtmfmode=rfc2833
context=from-outside
type=peer
rfc2833compensate=yes <--- unless cisco said you need this i would remove
canreinvite=no
disallow=all
allow=ulaw
insecure=port,invite
set allowguest=no
the rfc compensate command was created for asterisk 1.2 <-> 1.4 trunks
Perfect. I'm able to set
Perfect. I'm able to set allowguest to no and still receive calls now.
The RFC Compensate was in there because of an older piece of equipment we had prior to the Cisco. This was the only way I could get DTMF passed. I just haven't made the time to remove it and test it yet.
Back to the routes breaking, all of my client's seem to have had their Internet restored, so I'll have to try and force a break again.
good to hear.. at least this
good to hear.. at least this way we will know, for certain, that the call is arriving based on the attributes of this trunk instead of processing under the generic [general] attributes.
I'm currently running MTE
I'm currently running MTE 6.0.1.72. This is on my very short list to get upgraded as I need to get app_valetparking installed and working too.
A client lost Internet for an hour or so yesterday evening with the same results. I am going to upgrade to current before we do any further troubleshooting.
the only recording in asterisk that plays a message with that information is discon-or-out-of-service and that isnt used by thirdlane.
[root@eeman asterisk]# pwd
/etc/asterisk
[root@eeman asterisk]# grep discon-or-out-of-service *
[root@eeman asterisk]#
apparently your provider is playing that message? Or you altered something?
if it were thirdlane then you should be able to unplug a phone.. go to another phone and call that phone's 3 or 4 digit extension.. and get that same message. If you arrive in voicemail then you have some other issue going on, perhaps even an interop issue.