It would still be interesting here to know whether there are any problems with PJSIP. If there is something like Kamailio on the other side, nothing is set in stone, regardless of whether it is optional or not, but it currently looks as if it is a chan_sip problem.
It MAY be a chan_sip problem. With the limited information provided, that’s the most that can be said.
Hai @jcolp issue was reoocured today and i have taken the requested logs and added in bug
https://issues.asterisk.org/jira/browse/ASTERISK-29667?filter=-2
The Asterisk logs show that the ZTE is very slow to respond, as seen from Asterisk, so there are multiple retransmissions in flight before it receives the 401. These will continue to arrive with the old CSeq an nonce until Asterisk has received on the 401 and any that were launched between when the 401 was sent and it was received have finally arrived at the ZTE. Whilst this indicates an overload somewhere, it is normal operation of the protocol.
I notice that you seem to have multiple registrations to the same physical device. That generally indicates using a consumer/one man and dog business account for a medium sized business, i.e. one designed for telephones, not for PABXes.
However, there also seems to be a case where the ZTE is sending the wrong From tag back (CSeq: 391), and being unable to stop retransmissions, as a result.
Also, please remove the filter parameter from the issue URI. It probably only applies to your account, and it forces a login request.
@david551 - Yes I have multiple DIDs’s around 35 DID’s getting registred.
And I said earlier this happen intermittently.
If you refer the the Wireshark traces shared filename Trace_27092021_1157.pcap
For some rare cases where asterisk sending the new Register request wth updated nonce but most of the cases the asterisk is not sending registration request with updated nonuse - it just keeps sending with an old nonce.
Refering the call-id - 3b02fa216d1e3f777ceba1d714480b35
Yes, I have also seen that that some of the registration requests are not received a response from the SIP provider also.
The first five send of CSeq 390 are due to severely excessive round trip delays, and it is normal that the nonce is the same. However, it does look like something went wrong on the Asterisk side after that as it logs, what I assume to be, a successful cancellation of the retransmissions:
[Sep 27 12:00:07] DEBUG[1634] chan_sip.c: Stopping retransmission on '3b02fa216d
1e3f777ceba1d714480b35@10.10.5.23' of Request 390: Match Found
but then seems to continue to retransmit, even though it cannot find the record of the retransmission when it gets a further response:
[Sep 27 12:00:41] DEBUG[1634] chan_sip.c: Stopping retransmission on '5eb29a5031f36a0623645db46397c805@10.10.5.23' of Request 390: Match Not Found
There also seem to be two retransmit number 3’s for 390, and two successful cancellations.
Given, though, that chan_sip is effectively unsupported, I think you are going to have to go through the logs yourself and provide an extract of just the key features on just one registration. People are unlikely to fix it unless it either directly affects them, or they can work out the underlying fault very quickly and trawling through log files is generally too labour intensive for the latter. The sorts of things that I was looking at were call IDs, from tags, CSeq numbers retransmit counts, request or response, and the results of trying to cancel a retransmission
In the mean time, you really need to address round trip times, and move to a true direct in dialling account, rather than multiple single line accounts.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.