The agent into queue is not able to pick or hang up the call

Hello everybody,
sip_log_part.txt (32.6 KB)

We are faced issue that I describe below.We use softphone 3CX and Network connexion is ok in the client side. In the server side it is right also.
The issue:
When there the call arrives into one agent, his softphone 3CX becomes frozen, I mean he does not able to pick or hang up the call, and the call’s still ringing. He has to wait more that one minutes to pick up the call.Normaly if the agent is not available to pick up the call it will be forwarding but it is not the case, the call does not forward to another agent in the queue and that our really problem. Consequence we lost more call in our production.
I join a part of the sip log, when this issue is happened for the agent 10503, may be that’s can help to understand the meaning of the issue.

In the log the state is ringing at 14:15:23 and the agent 10503 can’t do anything he has to wait and it’s at 14:16:35 that the is state is In use so he was waiting more 1minutes to pick up the call

Does someone have any ideas or suggestions, or Do we need to add more parameters in our configuration

Thank you so much

You only seem to have the DEBUG log channel. You need to enable and use the full log. In particular, sip set debug on puts the actual SIP protocol messages onto the VERBOSE channel in a way that is more easy to interpret.

In particular, the log you have provided doesn’t seem to include the first line of status messages.

However, if the phone is actually ringing, and you can’t pick it up, I would say that had to be a problem with the phone.

Note that the log does show Asterisk stopping the outbound call after 20 seconds.

Please see in join another full log agent 10110 with the issue today

sip_log_part2.txt (126.4 KB)

It would probably help to have a version with the just the VERBOSE channel, as the debug lines add a lot of noise.

However, I can see no response arriving from the phone. Also, not all the mandatory headers are being logged, which make me wonder if you still haven’t got the correct logging settings. In particular, there are no CSEQ header lines logged, and no SDP logged in the INVITE.

Thank you so much
Please would you like to give me the command that I can use to filter the log and getting the verbose channel as you want to check

Uncomment full in logger.conf
CLI: sip set debug on
CLI: core set debug 0
CLI: core set verbose 5
CLI: core reload logger

Provide the contents of /var/log/asterisk/full

You should get lines something like:

Transmitting… to xxx.xxx.xxx.xxx
INVITE…

followed by all the headers and SDP.

Then the responses should get logged with a “received from” line, and complete status message.

I think this will work with verbose set to 0, but having some verbose logging tends to help put things into context.

This is basically the same as in Collecting Debug Information - Asterisk Project - Asterisk Project Wiki except that I’m suggesting that you disable the DEBUG channel initially, as it will make it easier to confirm you have the correct logging settings, makes finding the actual SIP protocol messages easier to see, and may be sufficient, without having to enable debug level message.

Please see in join the full log with the channel: C-000258b7
Hope that can help you for checking the issue

Thank you so much
sip_log_part3.txt (195.8 KB)

Also note that the chan_sip that you are using is effectively unsupported. Sangoma don’t support it and there seems to be little open source community support for it.

Would you like to give me the link or something similar that I can contact them.
And Do you have any suggestions for us , because this issue is happened recently, we dont make any modifications and before it works well

Thank you so much

Who is “them”? This is open source software, so there is no guaranteed level of support. You can buy support through Sangoma, but you have to have a contract and use specific versions. Those versions do not include chan_sip, and if you re-enable it, they will not support that usage. Those versions are also not the latest, and features not supported through the contract may have bugs which are not in later versions.

The community generally means anyone prepared to provide updates on a voluntary basis, and they act as individuals in deciding what issues to address.

My best guess, is that something has changed in the routers in your network.

Ok thank you for your involvment.
“Who is “them”?..”
==> I didnt understand correctly what you meaned :slightly_smiling_face:

I’ll think about your suggestions about Sangoma
Is there any link to show more details about the products , price etc …

Please note that I don’t work for Sangoma, and I have no personal experience of their commercial support services.

1 Like