I have a strange question.
When I have two conversations of the same length and once speak nothing and once speak a lot. Is the network traffic higher when you talk more?
Sometimes. If there is some kind of voice activity detection working, the traffic in one direction may be stopped in case silence is detected. AFAIK, Asterisk traditionally doesn’t do that, but I haven’t checked that lately.
thank you,
sometimes is bad for a measurement.
is it possible if you specify in the number plan (extension.conf) that the called person automatically takes off and, for example, the moh file should be played?
Comfort noise frames would do similar, as Asterisk doesn’t handle them well.
If the caller wants to have MoH played, they should put the call on hold; that is very different from simple silence suppression.
Why are you trying to measure in so much detail?
I would like to measure the difference in performance of an Asterisk server between encrypted and unencrypted calls.
So far I have only made several calls between two softphones and kept all calls at the same time.
However, I am not sure whether this is correct so far.
You could run 'tcpdump' and capture all packets (well, udp between x and y) and then count the packets in each direction.
I know the learning curve for 'sipp' is a bit steep, but I think it would make all this (based on your other tpoics on this task) a whole lot easier and credible.
I think this would better be approached from a white box point of view, given you are dealing with open source.
However, I’d also note that doing silence suppression on a secure channel is bad practice, because it leaks information about who is talking.
I know 
I tried weeks ago but failed miserably.
Maybe I’ll try again.
I’ve only used 'sipp' twice – once 7 years ago and once 4 years ago.
If you want to DM me an email address, I can reply with a tarball of my xml and shell scripts – but I’ll be of no use to answer any questions about it – too long ago 
1 Like
I have now measured the following.
have counted all RTP/SRTP packets for one second (several times)
unencrypted: no speak: 200-202
unencrypted: speak: 200
encrypted: no speak: 199-200
encrypted: speak: 200-202
average 200
But that has to be set somewhere, right?
sambling rate at the used G.711 audio codec is 64 kbps
711 µ-law (PCMU) and A-law (PCMA) coding algorithms, each sample is coded to be represented by 8 bits with an 8- kHz sampling rate which amounts to a bit rate of 64 kbps. These two algorithms are known as PCMU and PCMA, respectively. Most telephony products use either PCMU or PCMA for capturing or recording audio.
The standard RTP packet interval is 20ms, which suggests you are counting what is essentially the same packet in both in and out directions.
Encryption will affect the length, not the number of packets.
I understand that with the encryption.
But if I calculate 1 second / 100 packets =0,01
I don’t get the 20ms either
As I said, you must have counted both in and out directions on both legs of the call.
Does it? RFC 3711 says ’ None of the pre-defined encryption transforms uses any padding; for these, the RTP and SRTP payload sizes match exactly.’
Which, probably because I haven’t read or attempted to understand it, surprises me.
It does advise adding the a authentication tag, but it does seem that the IV is generated algorithmically, although incorporating the session key. I must admit I had assumed that a random IV would have been used.
I still don’t understand the calculation
A send packet to B and B sends packet to A: two packets.
Packet counted going from A and B to core: count two.
Packet counted going to B and A, from core: count another 2.
Four packets every timeslot. Time slot frequency 50Hz. Total 200 packets.
1 Like
Now it’s for dummies and I got it.
thank you for your patience.
One more question, where does this 50Hz come from? Are the 50 Hz fixed?
It is a compromise between latency and efficient use of bandwidth.
See the ptime attribute in https://tools.ietf.org/html/rfc4566#section-6