Sometime in my sip accounts occurs network problem and generates "UnReachable" event.
[2020-04-27 16:57:56] NOTICE[2949] chan_sip.c: Peer '323' is now UNREACHABLE! Last qualify: 6
I also see it in log files. I have 2 question about this situation.
After how many second Asterisk generate this event when can not access to sip account?
Exist some parametr change this reachable timeout second?
You can look at:
qualifyfreq=60 = default value is 60 sec
qualifygap=100
this works if:
qualify=yes|4000 = 4000 ms
Related
I am using Kamailio 4.4 as the proxy with my Asterisk server. I am trying to develop a scenario where an extension gets registered on asterisk via Kamailio when it receives a push notification. This push notification is sent to the sip extension when a call towards this extension reaches to the Kamailio.
For example, suppose there is two SIP extension( extension 1 and extension 2) registered on Asterisk via Kamailio. When a call from extension 1 reaches the asterisk, it forwards the INVITE request towards extension 2 via Kamailio.Kamailio will try to forward it to extension 2. suppose the extension 2 is not able to receive the INVITE request from Kamailio. When extension two receive a push notification, it will register on asterisk.
So I need to get the call on extension 2 through the new registration.
We are trying to simulate registration of extension to the asterisk when receiving the push notification.
First, we registered extension 2 and disconnected the network. Then we tried to register the same extension when a call from extension 1 reaches to Kamailio. This is a simulation of push-based registration since an extension that receives the push will attempt to register when an incoming call is received.
When asterisk sends INVITE request to Kamailio, it immediately responded with 100 trying provisional response. This 100 response by Kamailio towards asterisk prevents asterisk from re-transmitting the INVITE.
Then Kamailio tried to send and retransmit the packet to extension 2, which does not have network access. This extension 2 was on port number 24071. Even after successful registration(in port 59995) of the extension 2, Kamailio continued to transmit the packets to the old port.
After that, we have configured Kamailio in a way that it won't send an immediate provisional reply(100 trying ) for INVITE request.
Here Kamailio is not immediately sending 100 trying message to Asterisk. This forces Asterisk to re-transmit. Asterisk was found to retransmit the same packets. However, even after the successful registration of extension 2, asterisk continued to send the old invite to Kamailio not the new one to the latest port.
This is the problem for me since push relies on the INVITE reaching the phone at the correct port number.
So, is there other good approaches to solve this issue?
One thing I would like to try is modifying the pending INVITE request towards old registered port with the new port details when new registration reaches to Kamailio. Can I get the ongoing requests from Kamailio?
Please suggest a viable solution.
Almost any kamailio config availible do similar thing.
You have save into location and consult it when do call.
However if you need really scalable platform you SHOULD NOT forward register requests to asterisk at all.
If kamailio send invite to wrong port, likly that mean you have TWO records in location.
I am working with IBM MQ. I managed to get a basic Handshake / Put Message(s) / Get Message(s) / Disconnect .net solution going on, a couple of days ago, but it only works on a local level, and I now need to update the solution so it works remotely as well.
After reading and experimenting for a while, I decided to follow IBM Knowledge Center's Point to Point scenario step by step. However, I can't start the Sender Channel as instructed by the guide's last step; the Sender Channel's status ping-pongs between Binding and Retrying, and the logs come up with the following error codes; AMQ9002, AMQ9202 and AMQ9999, meaning, as far as I can tell, there is some kind of trouble finding and/or connecting with the host, as explained by the error logs.
I have looked through a lot of questions regarding these errors in particular, but while I have followed most of the proposed solutions (I made sure the Receiver's listener is running, I tried turning off Firewalls, I tried with different ports, I have performed tests Telnet, I have stopped/restarted/resolved the Sender channel a few times, and I have tried setting this up from both, the command line and MQ Explorer), I have yet to get a successful communication going on between two different PCs.
I am aware the error could be either temporary, or the result of problems within the Network itself, but I have been trying to establish a successful connection for almost three days now, and before I pass this unto my bosses I would like to make sure I have exhausted every other possibility.
How can I complete IBM's Point To Point set up guide, or is there anything that could point me towards a different / better approach to get two PCs talking with each other via IBM MQ v9?
Although hastily translated from Japanese, you can find the detailed error logs below.
2017/09/19 17:34:09 - Process (234212.1) User (MUSR_MQADMIN) Program
(runmqchl.exe)
Host (DESKTOP - UP 4 D 363) Installation (Installation 1)
VRMF (9.0.3.0) QMgr (QM 1)
Time (2017-09-19T08: 34: 09.201 Z)
AMQ9002: Channel 'TO.QM2' is starting.
Description: Channel 'TO.QM2' is starting.
ACTION: None.
2017/09/19 17:34:30 - Process (234212.1) User (MUSR_MQADMIN) Program
(runmqchl.exe)
Host (DESKTOP - UP4D363) Installation (Installation 1)
VRMF (9.0.3.0) QMgr (QM 1)
Time (2017-09-19T08: 34: 30.824Z)
AMQ 9202: The remote host 'DESKTOP-1AV4LM3 (The correct ip address) (1415)' can not be used.Please try again later.
Description: Using TCP / IP to host 'DESKTOP-1AV4LM3 (The correct ip
address) of channel TO.QM2 (1415) 'trying to allocate a conversation,
but it did not succeed. However, It is temporary and there is also the
possibility that TCP / IP conversation can be allocated normally
later.
If the remote host can not be determined, '????' is displayed. .
ACTION: Please try the connection later. If the failure persists,
record the error value Please contact the stem administrator. The
return code from TCP / IP is 10060 (X'274C ').The cause of this
failure may be that the host can not reach the destination host.
Alternatively, There is a possibility that the host 'DESKTOP-1AV4LM3
(The correct ip address) (1415)' listener isn't running. If that is
the case, start the listener and try again.
2017/09/19 17:34:30 - Process (234212.1) User (MUSR_MQADMIN) Program (runmqchl.exe)
Host (DESKTOP - UP 4 D 363) Installation (Installation 1)
VRMF (9.0.3.0) QMgr (QM 1)
Time (2017-09-19T08: 34: 30.825Z)
AMQ9999: Channel 'TO.QM2' for host 'DESKTOP-1AV4LM3 (1415)' terminated abnormally
Description: The host 'DESKTOP-1AV4LM3 (1415)' cannot be determined.
ACTION: Check the error log for the preceding error message for
this channel program Please determine the cause of failure....
".
The 'interesting' bit of the error messages above is that the sender is attempting to start a channel to port 1415 on the destination and is getting a 10060 return code (WSAETIMEDOUT). This is different from an immediate rejection because the other end doesnt have a socket open, for example.
You will also note its timing out after about 21 seconds if your times are to be believed. The only time I've seen this kind of things is DNS resolution - There was an APAR for example showing that reverse DNS can cause delays in channel startup, and this could be for a successful or unsuccessful startup
http://www-01.ibm.com/support/docview.wss?uid=swg1IC96408
A new attribute was added to MQ to disable reverse DNS lookups if its the cause - See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.pro.doc/q113120_.htm#q113120___chlauth
If this is the case, on the receiving end (or both!) try runmqsc , 'ALTER QMGR REVDNS(DISABLED)'. You might have to restart the qmgr for it to be effective (I'm not sure, sorry)
I'd also echo the comment added to your question by JoshMc, to check the receiving end logs for messages (both global errors but more likely the qmgr specific AMQERR01.LOG files) when this occurs - I have a feeling that the timeout is only part of your problem.
Is there any way to stop duplicate INVITE in asterisk SIP message a?
We are using Asterisk 1.8.10
Inbound Call flow to VoIP/SIP is as follows:-
SIP trunk -> Asterisk 1.8 -> VOIP app
When we get call from SIP provide/trunk asterisk generate duplicate 2 SIP INVITE messages to VOIP app unable to handle it. Is there any way to stop it from asterisk side.
Any help will be appreciated!
Thanks
Asterisk send second invite only if
1) first invite was not confirmed. You app should answer OK(confirm).
2) reinvite requested.
You can try increase t1/t2 timer to increase delay in 1). For disable reinvite, see directmedia option.
I'm getting a weird behavior on my Asterisk.
Calls are dropped after 15mn.
I'm getting the following error on the log file:
NOTICE[6301] chan_sip.c: Failed to authenticate on INVITE to '<sip:41907736445#188.32.64.1>;tag=ef7143klc9'
I'm using Asterisk Realtime. Calls a received from an operator and forwarded to external numbers throught an outbound trunk provided by anther operator.
Thanks in advance
In your sip.conf, try setting qualify=yes or keepalive=yes globally or for the trunk. Make sure to reload or just restart the service.
What version of Asterisk are you running?
Some carriers may send "confirmation" invite every X minutes.
You can see more by enable sip debug
Also if exactly at 15 min calls get dropped, then i would check the firewall to see whether there is timer set there that closes the connection after 15 min. I am speaking from experience.
Default Asterisk configuration (only sip.conf changes).
I use call files for calling and I need to hangup after first ring while every dial.
WaitTime: 4 seconds doesn't work sometimes, since it's counting from the beginning (connect to SIP provider etc) and the client doesn't even receive the call.
00359894000001.call
Channel: SIP/flowroute/00359894000001
Extension: 00359894000001
WaitTime: 4
There are no way predict connection time and count how much ring was at called side. Ring create by endpoing equipment, you have no control/info about it.
If the connection time for the SIP provider etc is constant you should just check what it is and add it to your 4 seconds.