Fractures in some calls

Asterisk Asterisk Support
#1

I use Asterisk 16.5. In some incoming calls exits fractures. This is also fels in the recorded files. How can i fix it?

Command ‘sip show cahnnelstats’ shows some send packets is lost.

Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.23.10.242     fe45f686eir  00:02:55 0000008756  0000000000 ( 0.00%) 0.0000 0000008751  0000001995 (22.80%) 0.0000
10.23.10.242     fe45f6acbl3  00:00:12 0000000635  0000000000 ( 0.00%) 0.0000 0000000633  0000000000 ( 0.00%) 0.0000
10.23.10.242     fe45f6adrcc  00:00:06 0000000314  0000000000 ( 0.00%) 0.0000 0000000312  0000000000 ( 0.00%) 0.0000
10.23.10.242     fe45f6a6mkq  00:00:44 0000002211  0000000000 ( 0.00%) 0.0000 0000002011  0000000000 ( 0.00%) 0.0000
10.23.10.242     fe45f690t5b  00:01:11 0000003598  0000000000 ( 0.00%) 0.0000 0000003594  0000001497 (41.65%) 0.0000
10.23.10.242     fe45f63arb9  00:11:24 0000034227  0000000000 ( 0.00%) 0.0000 0000034176  0000001997 ( 5.84%) 0.0001
10.23.10.242     fe45f687o1m  00:02:53 0000008668  0000000000 ( 0.00%) 0.0000 0000008629  0000001484 (17.20%) 0.0001
10.168.195.32    7544f80f138  00:02:06 0000006252  0000000000 ( 0.00%) 0.0000 0000006253  0000000000 ( 0.00%) 0.0011
10.168.195.62    7eb52968045  00:01:33 0000004628  0000000000 ( 0.00%) 0.0000 0000004629  0000000000 ( 0.00%) 0.0004
10.168.195.75    691d30b614e  00:12:50 0000029022  0000000000 ( 0.00%) 0.0000 0000028994  0000000000 ( 0.00%) 0.0004
10.168.195.67    36ab802439b  00:05:24 0000016115  0000000000 ( 0.00%) 0.0000 0000016122  0000000000 ( 0.00%) 0.0003
10.23.10.242     fe45f6ab84h  00:00:18 0000000945  0000000000 ( 0.00%) 0.0000 0000000944  0000000000 ( 0.00%) 0.0000
10.23.10.242     fe45f681vqh  00:03:37 0000010878  0000000000 ( 0.00%) 0.0000 0000010874  0000000997 ( 9.17%) 0.0000
10.168.195.79    2229dd-1600  00:00:23 0000000775  0000000000 ( 0.00%) 0.0000 0000000774  0000000000 ( 0.00%) 0.0006

This is my sip trunk

[trunk_1]
type=peer
username=trunk_1
host=10.23.10.242
context=incoming
dtmfmode=auto
nat=no
transport=udp
insecure=port,invite
fullname=trunk_1
disallow=all
allow=all
#2

What is a “fracture”? Should “exits” be “there exist”? What does “fels” mean?

Also, there is likely to be far too little informatiion to work out what is wrong, even when those points are clarified.

What channel technology are you using (e.g. DAHDI analogue, H.323 etc.)? If there is more than one implentation of the technology, which one? Please provide relevant configurations and logs.

#3

I mean voice is interrupted during on some calls. I use sip trunk. Which configuration files do you need?

#4

extensions.conf and either sip.conf or pjsip.conf, depending on which SIP driver you are using.

Note that, as you use the term “sip trunk”, which is not an Asterisk term, you may be using FreePBX, in which the relevant parts of these files is likely to included from the main file.

Note that interruption may just indicate that something is overloaded.

#5

I use Asterisk 16.5. Sip.conf part i attached.
extensions.conf part is simple, just adding incoming call into queue.
There is no overload on RAM, Network, CPU, etc.
Note: In interrupted calls lost send packets. I see it from these command ‘sip show cahnnelstats’ and also listening recorded file.

#6

What is the network layout? Is stuff local or remote?

#7

Network layout is local.

#8

Does the sound stop at a particular time into a particular part of the call. Does it restart on its own? If so has something changed in the call before it restarts.

Basically, though, the biggest part of answering this question is going to be working out what is going wrong, so we will need as much information as possible.

#9

Sometimes sound stop at particular time (1, 2 second) then continues sound. It is occure several times on one call.
And sometimes sound does not restarted, sound stoppped.

#10

Ok understand, it may special case, therefore answer to this question is difficult.
But what does it means “Lost ( %)” in Send part.

#11

It means the other side reported receiving that fewer a number of packets than were sent.

#12

…that subnet looks like your problem, if you are able to correlate the recording outages to the increase in Lost packet % for that call. It could be you have a bad switch, overloaded router, or something else specific to that portion of your network.

#13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.