Hello, we have been trying for 6 months now to find the cause of this problem and provide a solution.
The problem we are encountering is a sip disconnection from our trunk with a yeastar S100. The disconnections are random and last on average 120s although it is true that we sometimes have disconnections which last more than 3 minutes. On the side of the Yeastar PBX we did not find any problem because we configured another trunk to another equipment which is not asterisk and which never disconnected. After analyzing the logs we saw that In the offline period, S100 send Options to Astersik PBX but no response, so PBX regards it as offline. We have the following error in the logs: [2023-11-06 11:13:57] DEBUG[2648] res_pjsip.c: 0xd7b7664: Internal tsx timer expired after 3000 msec
[2023-11-06 11:13:57] DEBUG[2648] res_pjsip.c: 0xd7b7664: Callbacks executed
[2023-11-06 11:13:57] Contact trunk-Mcall_New-aor/sip:11287892@ip_asterisk:5160;transport=udp is now Unreachable. RTT: 0.000 msec
[2023-11-06 11:13:57] Endpoint trunk-Mcall_New-endpoint is now Unreachable
This post is confusing. Is Asterisk running on this Yeastar PBX? I don’t understand the relation between things or where the log output is from.
Hello @jcolp thanks for your answer. The problem we are having is that the pjsip trunk is inaccessible. They will always return after a period of time (random duration, which can range from a few seconds to a few minutes). here is the trunk configuration
[yeastar]
type=peer
qualify=yes
insecure=prompt,port
host=IP_yeastar
disallaw=all
context=from-trunk
allow=g729
The error I shared comes from the yeastar logs.
Our trunk is named Mcall_new in the yeastar S100.
[2023-11-06 11:13:57] DEBUG[2648] res_pjsip.c: 0xd7b7664: Internal tsx timer expired after 3000 msec
[2023-11-06 11:13:57] DEBUG[2648] res_pjsip.c: 0xd7b7664: Callbacks executed
[2023-11-06 11:13:57] Contact trunk-Mcall_New-aor/sip:11287892@ip_asterisk:5160;transport=udp is now Unreachable. RTT: 0.000 msec
[2023-11-06 11:13:57] Endpoint trunk-Mcall_New-endpoint is now Unreachable
When the trunk is disconnected, the ping between asterisk and yeastar goes well.
If by ping you mean a ping outside of Asterisk, then that would mean network connectivity issues outside of Asterisk.
the asterisk server and the yeast server are on the same network. When I disconnect the trunk, I ping between the two devices but the ping is fine. Do you think the problem will be a network problem?
Do a network capture and look at the traffic, to see what is happening, such as if it is being sent and response received. You can also check in Asterisk itself using “pjsip set logger on”.
Sorry, you’re using chan_sip seemingly so that would be “sip set debug on” for chan_sip. Note that for chan_sip if something is blocked in it, such as DNS, then that will block other things and cause it to stop processing for a period of time. The chan_sip module is no longer supported, has been removed as of Asterisk 21, and that’s the extent of help with it I’ll provide.
Ok I will try that. Thanks for your support
In the asterisk after enabling the pjsip logger, I don’t see any errors. I just have the notification that:
NOTICE[3676911] chan_sip.c: Peer ‘yeastar’ is now UNREACHABLE! Last qualifier: 2
NOTICE[3676911] chan_sip.c: Peer ‘yeastar’ is now Reachable. (2ms / 2000ms)
But on my full file I have this type of error which repeats itself almost every second or several times in the second :
chan_sip.c: Retransmission timeout reached on transmission 9912bd19-a1c2-4fbf-96e4-9e50fabaf02b for seqno 25260 (Critical Response) – See Home - Asterisk Documentation
Packet timed out after 12033ms with no response
do you have any suggestion please?
“sip set debug on” is used for chan_sip. As I stated before, this is the extent that I’ll help. Others may chime in and continue if they wish.
This is a configuration for the obsolete chan_sip, but I don’t believe “prompt” has ever been a valid value.
More importantly, it has nothing to do with res_pjsip.c
Looks like Yeaster does not respond the OPTION within set time. Do you have lot of calls running on Asterisk? Just sip set debug on and check the time when the OPTION was sent and when the 200 OK was received from Yeaster. see if it is taking a long time to respond?
Hello everyone, thank you for your suggestions. After debugging, I see that asterisk is sending sip options to yeastar on port 5060 and is not getting a response, even though I am using port 5160.Note that asterisk sends these sip options even when the trunk link is active.
Retransmitting #4 (NAT) to 10.106.8.153:5060:
OPTIONS sip:10.106.8.153 SIP/2.0
Via: SIP/2.0/UDP 10.106.8.181:5160;branch=z9hG4bK33e425a1;rport
Max-Forwards: 70
From: “Unknown” <sip:Unknown@10.106.8.181:5160>;tag=as65c1680a
To: <sip:10.106.8.153>
Contact: <sip:Unknown@10.106.8.181:5160>
Call-ID: 0f6dcdbf06603a266f680dd04acf606e@10.106.8.181:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-14.0.5.25(13.19.1)
Date: Wed, 08 Nov 2023 10:27:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
It’s sending TO port 5060. It is sending FROM port 5160.
yes that’s what I’m saying it should send TO 5160, the yeastar is configured on this port
Then you have to configure the port on the chan_sip peer entry
how can I do this please?
You would set the port option:
Such as:
port=5160
Within the corresponding peer entry.
It was already in 5160
That controls the port that chan_sip sends traffic FROM. It doesn’t control where it sends traffic TO.