A requisite for working calls is a good network, may I ask what are the best tools to be sure that network is good (before calling the sys admin)?
I’ve tried:
I.e. It happened to me that there was a bad queue management on the router, but no package lost were reported in the asterisk channels.
May I ask if there’s a check list for this kind of troubles?
Thanks, BR
Wireshark does UDP, and has specific support for RTP.
Thank you, so wireshark is the one and only swiss army knife.
I should study it deepen, thanks
This is from a call where and endpoint show lost packets and the other is fine, I’ve noticed many of those red rows :
In this case what would you do, who is triggering the wrong sequence number?
My initial reaction is that this is valid within the contract for UDP services. Networks do not guarantee that UDP packets will not be duplicated. The typical reason for duplication would a be a reconfiguration of a network after a link appeared to have failed.
Significant numbers of duplicates would indicate a network that had problems.
Thank you @david55 for your reply, except transport is TCP.
Only a specific device show the packets lost (if I replace with a different hardware no packet are lost), maker says that his device is fine and won’t replace it.
So is there any way to understand objectively if it is this device that trigger the troubles?
The signaling transport may be using TCP, but the RTP traffic is UDP.
I see duplication, not loss.
Thank you, I’ve found this old topic, no way to turn all to TCP?
Lost is reported on client side diagnostic and console:
pjsip show channelstats
...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec. Count Lost Pct Jitter Count Lost Pct Jitter RTT....
===========================================================================================================
c0d91c35 105-00001559 00:03:18 slin 8460 5373K 63520 0.000 9667 1 0 0.003 0.006
c0d91c35 PBX_SL-00001557 00:03:18 slin 9667 0 0 0.000 8376 0 0 0.004 0.023
No, there is no such functionality to have it go over TCP inside of Asterisk.
There are also good reason why UDP is used. It is generally better to interpolate missing packets than to have an extended silence during which the sender waits for a missing ACK and resends the packet.
I’m looking at this docs:
https://www.wireshark.org/docs///wsug_html_chunked/_rtp.html
I can see there’s an “out of sequence” problem, but cannot understand how to fix it.
It’s duplicated rather than fully out of sequence.
What problem is it actually causing? The recipient should simply ignore it.
Whilst it does suggest faulty network hardware, it is failing safe.
(The sending hardware probably believes the first attempt failed, when it actually succeeded.)
(Asterisk should drop it here, if it is the receiver:
)
This cause an audio silence on one side and a video freeze.
Tried to run audio only and still happens.
Anything that can be setup on the freepbx to fix it?
I’m not sure which end is which, but I would say your problem is much more likely due to the payload type 127 that wireshark is failing to match against the SDP.
I think, at this point, I would want the full SDP exchange from the “pjsip set logger on” output (or for legacy systems, “sip set debug on”).
I don’t believe that you have really lost more than 5 million packets. That’s more than a day’s worth. If you have, the wrong denominator is being used for the percentage calculation.
It’s possible that the failure to match type 127 is because the captured SDP is truncated, but one reason it may be truncated is that you are allowing far too many codecs. You should only allow the codecs you intend to use.
Will make another try with debug turned on, anyway on the endpoint only G729 and PCMA are enabled.
I cannot find anything about the type 127, can you please explain what is this?
Thank you
You mentioned video freeze, do you mean the handset screen locks up? Obviously Video isn’t using G729?
Also, any reason you are using G729, I would suggest using something else as you may run into issues if the box is trying to transcode that using software rather than a transcoding card.
It’s all over your wireshark message sequence chart, e.g. 00:10:37,162116.
Also, if you are using video, there is no advantage in using G.729, as the video will dominate the traffic.