you asked me for help, I asked you a question, if you don’t answer me how I help you?
I did not ask for any help. You started the post, I gave you suggestions.
I’m sorry, I must have dreamt it up.
Run Ethernet capture all time and check call that failed. You need to see WHO drop connection.
You can also check syslog with PJSIP and CHannel on all levels (capture is better).
If there is network fail you will see incoming packet to drop to zero before disconnect.
Also you will see who disconnected call.
@Marcin arrives a “bye” for no reason and falls the conversation (even on conversations that last several minutes).
I think I’ve solved it, I don’t publish the solution because the client has to confirm that the anomaly doesn’t happen anymore.
However, I think the problem is related to version 18 of the UCM (the 19 is too unstable so I avoid it), and I’m waiting for the next release fw.
I too think it arrived with 18.
I get a bye signal from the remote end even though they say they didn’t hang up the call.
This tells me it is a negotiation issue somewhere, but I can’t find it…
@damiano70 if you can PM me what you think the issue is I can test it on my end as well.
RTP timer i guess.
UCM can force it and call is abandon when there is no refresh.
But not sure without trace./
Exactly, except I can’t see what the provider receives.
All i get to know is that they sent the bye signal and I don’t get to know if it was because of packets we sent that they just didn’t receive.
…and getting relevant data from an already low grade SIP provider is next to impossible sometimes…
I have seen where only one client was having the exact same issues. I turned off the SIP session timer and that solved my problem.
be aware that since it is not a constant problem you will only be sure after a few days (in fact I am waiting for the customer to give me feedback).
What exactly did you do?
That is Lucas (lstutesman), but you are responding to lpneblett.
so I removed the NAT from the trunk, reading several forums of Asterisk seems that this is a problem of the latest version of Asterisk, and precisely solves by removing the Nat from the trunk.
As I said I’m waiting for feedback from my customer, I have not heard him complain yet, could indicate at least that if the problem has not been solved has at least improved.
I’ll update you. In the meantime, I’m waiting for your feedback.
I used to keep NAT on the trunk until firmware 1.0.10.x came out and they added the SDP check in PBX-SIP-NAT
So from 1.0.10.x to present i haven’t used nat on any trunk.
but if it was on, it would indeed cause an issue like this.
Thanks for sharing, I’ll keep at it.
I am testing this and will advise if my issues go away.
Thanks for sharing Phil.
Are you referring to PBX Settings/Sip Settings/Session timer -> timer (disabled) ?
Ya, that’s what I did.
I’d also be watching RTP timeout (ToS).
I thought about that to, but when I have RTP timer issues I only lose audio and the call stays open.
This goes from hearing everything to a complete call drop.
yes, but being an anomaly it is necessary to think also about the “non-normal”.