Response forbidden sporadically on outgoing calls

Hello together,

we have the problem with two different providers on some freepbx-systems, that asterisk receives a Forbidden sporadically on outgoing calls, which fails then - after everything worked for some days wihtout any problems. when we do a sip reload in the CLI it is working again - what can be the cause for this issue and how can we solve this sustainable?

here is the entry of the LOG:
[2017-02-22 12:22:55] VERBOSE[34616][C-0001241d] app_dial.c: – Called SIP/arcor25602/01231456789
[2017-02-22 12:22:55] WARNING[22413][C-0001241d] chan_sip.c: Received response: “Forbidden” from '“ComfineTest”

You will have to ask the operators of the system that is rejecting the calls, however, my guess is that you are registering with it, a registration is getting lost, and it is not prepared to authenticate the INVITE directly.

thanks for your reply!
unfortunatelly it is impossible to get contact to an operator, because the rejecting partys are two big german providers (Deutsche Telekom, Arcor/Vodafone). They just say “we dont support this software/hardware - use our devices…” - and thats it.

but: after a sip-reload everything is fine. can i force a unregister and re-registration without sip reload? it would be really interesting, if just a re-registration would solve the issue aswell…

can nobody give me any help … i really don’t know what todo :frowning:

The chan_sip module has no mechanism to unregister/register without doing a sip reload.

okay, but maybe somebody else has experience with other provider (or the same) with the same problem and can help me how to fix it?

Did you check your registration process with those providers?
What is the expiry in response of your REGISTER request?
Did you see if your system re-register before the expiry?

–Satish Barot

sip show registry looks like this:
Host dnsmgr Username Refresh State Reg.Time
tel.t-online.de:5060 N xxx 465 Registered Mon, 13 Mar 2017 12:43:38
tel.t-online.de:5060 N xxx 465 Registered Mon, 13 Mar 2017 12:43:38
tel.t-online.de:5060 N xxx 465 Registered Mon, 13 Mar 2017 12:43:38
192.168.120.254:5060 N xxx 285 Registered Mon, 13 Mar 2017 12:41:48
192.168.120.254:5060 N xxx 285 Registered Mon, 13 Mar 2017 12:41:48
tel.t-online.de:5060 N xxx 465 Registered Mon, 13 Mar 2017 12:43:38
192.168.120.254:5060 N xxx 285 Registered Mon, 13 Mar 2017 12:41:48
tel.t-online.de:5060 N xxx 465 Registered Mon, 13 Mar 2017 12:43:38
192.168.120.254:5060 N xxx 285 Registered Mon, 13 Mar 2017 12:41:48

Error on outgoing call:
[2017-03-13 12:45:26] WARNING[23160]: chan_sip.c:20694 handle_response_invite: Received response: “Forbidden” from ‘“0123456” sip:0123456@tel.t-online.de;tag=as1e998b3d’

the trunk-settings for this line like this:
type=friend
username=0123456
fromuser=0123456
secret=0123456
host=tel.t-online.de
nat=yes
dtmfmode=rfc2833
canreinvite=update
fromdomain=tel.t-online.de
insecure=very
qualify=yes
srvlookup=no
session-timers=refuse

SIP-Settings looks like this:
Registrations: registertimeout: 20, registerattempts: 0
Registration Times: minexpiry: 60, maxexpiry: 3600, defaultexpiry: 120.

Do i need to make a tcpdump to check what the expiry is in the response from the register and if the re-register is placed before expiry or is there a more easy way to go?

after a sip-reload i got following output:
== Parsing ‘/etc/asterisk/sip_notify_additional.conf’: == Found
> doing dnsmgr_lookup for ‘tel.t-online.de
> ast_get_srv: SRV lookup for ‘_sip._udp.tel.t-online.de’ mapped to host h-epp-109.isp.t-ipnet.de, port 5060
> doing dnsmgr_lookup for ‘tel.t-online.de
> ast_get_srv: SRV lookup for ‘_sip._udp.tel.t-online.de’ mapped to host h-epp-109.isp.t-ipnet.de, port 5060
> doing dnsmgr_lookup for ‘tel.t-online.de
> ast_get_srv: SRV lookup for ‘_sip._udp.tel.t-online.de’ mapped to host h-epp-109.isp.t-ipnet.de, port 5060
> doing dnsmgr_lookup for ‘tel.t-online.de

maybe DNS inside asterisk does not work after a special ammount of time?

nobody any idea? we still have this frustrating problem. :frowning:

push… we still have this issue unsolved :frowning:

Did you find a solution to your problem?

Actually, I do see the same thing and German Telekom is not really helpful. They have some technical documentation (like 1TR114 and 1TR118), but their customer service gets freaked out when you start to ask about some missing details in these documents…

Anyway, the problem looks as if it is not really Asterisk related. Assuming that there are no problems with the registration (which involves a couple of other tricks), the problem is likely occur, if there have been no outgoing calls for a longer period of time. In my case, restarting Asterisk (a simple sip reload does not seem to work) always helped. The only noticable difference from the outside is that the restart goes through the mandatory challenge/response sequence for the initial registrations, but this does not directly affect the outgoing calls. I do not know what is actually happening on the Telekom servers.

Currently I have SRV lookups enabled and the current IP gets looked up this way before each outgoing call, which is easy to verify with pcap traces. The Asterisk docs say that only the first entry gets resolved, but the Telekom returns at least two. I wonder whether one should periodically evaluate all returned records and correlate that with successful and failed calls.

I’d say, if the problem is related to the CNAME cascades that are usually returned, then registering to all servers returned by the dig SRV command and modifying the dial plan to check the other ones in case 403 gets returned, should solve the problem. If it is a deeper problem, not related to address changes, then a restart seems to solve the problem for chan_sip, though Idon’t know why. PJSIP might be more clever as there are provisions to cope with address changes, but I haven’t tested that yet.

Of course, any hints are much appreciated.

our customer was (of course) angry and we knew that we dont have this problem with ohter machines within deutsche telekom, that are running newer asterisk/freepbx-versions, so we decided to reinstall the system of the customer from scratch with the newest version and now the problem does not occur anymore. this is not really nice to hear, because we still dont know what was wrong in that version, but finaly it solved the problem - that’s the most important thing.

I wonder what the differences are. Are you using the SIP stack or the new pjsip stack with the machines that work as expected?

The only difference I see, is that address handling could be better with pjsip.

i dont know if we used sip or pjsip on that machine - but i think we used pjsip in both cases…