SIP SHOW PEERS ASTERISK 1.8.21.0

[mosesintelix]

Dear Asterisk Team,

The first time i register my softphone to asterisk server and i run command sip show peers

The result like this
Name/username Host Dyn Forcerport ACL Port Status
1800/1800 111.95.195.45 D N 16118 OK (100 ms)

After a few minutes i run againt comamnd sip show peers

Name/username Host Dyn Forcerport ACL Port Status
1800/1800 111.95.195.45 D N 16118 OK (351 ms)

What causes the "Status" changed from 100 ms to 351 ms?

Thanks You

[david55]

Because the round trip time, being measured as a result of enabling the qualify option, was different on the last polls before the two show peers.

Both of these values are bad. 351ms is particularly bad. You need to reduce the load on the network interfaces, or prioritise SIP and RTP traffic.

(Prioritisation could result in an excessive SIP round trip time, but good RTP ones.)

[david55]

Excessive delays could also be the result of running on a gemeral purpose virtual machine. As well as introducing excessive scheduling delays, a VM not specifically tuned for real time applications will have a distorted sense of time.

[mosesintelix]

Dear Dadiv55

What ms the best values ​​for sip show peers?

Specification our server :
Intel(R) Xeon(R) CPU E5606 @ 2.13GHz
4 Core, Memory : 8 GB
Speed: 100Mb/s

Number of client that connects to the Asterisk server only 15 people using softphone.

Is this the main cause value "sip show peers" so bad?

Are there other parameters should I check to solve this problem?

Is there a possibility that the client connects to a server problem?

Our customer not using VM as server asterisk, they are physical Server.

Thanks
Mustafa T
Intelix Global Crossing

[david55]

If the server and client are real, the problem will lie in the network.

[mosesintelix]

Hi David55,

Can you tell me how to prove that this is a problem on the network? Because I have to provide proof to our customers that this problem is on their network

I usually use the tools wireshark, but I not so understand how to read a traffic results. Do you have other simple tools to trace this network problem?

Thanks

[mosesintelix]

Hi David55,


I experienced a strange thing today with an asterisk "1.8.21.0"

I've run the command "sip show peers" and the results are as follows:

#1812/1812 192.168.23.97 D A 35824 OK (105 ms)

I try ping IP 192.168.23.97 not replay.

I try to restart asterisk and run again "sip show peers" and the results remain the same

#1812/1812 192.168.23.97 D A 35824 OK (105 ms)

Why ext "1812" is still registered?

Thanks
Mustafa T

[david55]

Because the machine selectively ignores ping, or because it hasn't explicitly de-registered and neither the registration nor the qualify test has exceeded its timeout.

[david55]

You will need to interpose specialist packet logging hardware on the network. With coaxial ethernet, that would be easy. With twisted pair, there will be some disturbance to the network.

I don't know about suppliers of such equipment, as most people are satisfied with packet captures from routers or end systems.

[ianplain]

Hi

Are you sure there is a problem ? the rtt time will alter all the time in dependent on network status.

what is the problem they are having ?

see link in sig for detaisl of doing wireshark traces

[david55]

Let's try and summarise what I've said.

1) changing values of the qualify time are normal.

2) In my view, a 351ms round trip time is rather high. It will result in very noticeable delays in the speech, unless the RTP is prioritised to achieve a lower delay.

3) (not explicitly answered) The best value for this is 0ms, but you will never achieve this.

4) If you want absolute proof as to how much of the delay is due to Asterisk, you will need special instrumentation on the network. Most people don't want that level of proof.

Having said that, the question arises to what was the real world problem that caused you to look at these statistics. If it was anything other than long delays between finishing speaking and hearing an answer, you need to tell us what the real problem was.