Am 22.06.2020 um 17:41 schrieb Marek Greško:
Hi
> try pinging your sip peer ip address following way:
>
> ping -n -M do -s 1300 -i 0.1 -c 100 ${ipaddress}
>
> Post several lines and the statistics.
root@bpi:/etc/asterisk# ping -n -M do -s 1300 -i 0.1 -c 100 tel.t-online.de
PING
Hello Luca,
We are still playing with visualization of your data, but I didn't want
you to wait any longer for some results. I think I blame both DT and
the Pi :)
First, a look at the phone side of your Banana Pi. The first thing we
noticed is there were a LOT more packets in one
Am 22.06.2020 um 22:12 schrieb Marek Greško:
Hi Marek
> Would you mind repeating the test with canreinvite=no set for all you
> phones and mobile phones?
All my peers have already canreinvite=no...
I only have canreinvite=yes on the SIP configuration on the Telekom part:
[pbxluca]
type=peer
Missing packet from DT could be caused by MTU issue.
Marek
2020-06-18 5:41 GMT+02:00, Jeff LaCoursiere :
> Hello Luca,
>
> We are still playing with visualization of your data, but I didn't want
> you to wait any longer for some results. I think I blame both DT and
> the Pi :)
>
> First, a
Am 22.06.20 um 16:48 schrieb Luca Bertoncello:
Hi list!
So, now I have a business contract and a technician was here to check
the DSL...
Nothing found, except that for 50Mbps I need now vectoring. Really
nice... A couple of years ago I could get 50Mbps without vectoring.
Of course, Deutsche
Would you mind repeating the test with canreinvite=no set for all you
phones and mobile phones?
What is your upload bitrate? Is it guaranteed?
I would try also to test the PMTU:
Try:
ping -M do -s 2000 ${ip address of the sip server}
You should receive icmp asking for lowering the packet
Hello,
there is no need to change canreinvite for provider configuration.
Do not change MTU. Probably there will be another problem. I expect
packet size 1466 would pass and higher will have the same result. It
would be interesting to make the same test from the outside towards
your asterisk
A thing I forgot to report...
My Asterisk listen on an high port (*not* 5060), since I had many
problems in the past with someone trying to use my Asterisk with brute
force attack...
I really don't think, this can be the problem, but better to report all...
Regards
Luca Bertoncello
Am 22.06.2020 um 21:30 schrieb Michael Maier:
> Did you check to prevent transcoding?
could you explain what do you mean and how to check it?
>> On the Gateway (Banana PI), where the Asterisk server also runs, the
>> load is about 0.50 during calls and it has a Gbps LAN.
>
> What's running on
Am 22.06.2020 um 22:42 schrieb Marek Greško:
Hi Marek,
> there is no need to change canreinvite for provider configuration.
OK, so I leave it...
> Do not change MTU. Probably there will be another problem. I expect
> packet size 1466 would pass and higher will have the same result. It
Am 22.06.2020 um 17:01 schrieb Telium Technical Support:
> I don't know if there was a prior email with more details, but
>
> Latency is as important as speed. Have you checked latency between your
> device and pop? What about QoS at your location, and does your ITSP
> support/respect
Hi list!
So, now I have a business contract and a technician was here to check
the DSL...
Nothing found, except that for 50Mbps I need now vectoring. Really
nice... A couple of years ago I could get 50Mbps without vectoring.
Of course, Deutsche Telekom said nothing about this change...
Well, I
I don't know if there was a prior email with more details, but
Latency is as important as speed. Have you checked latency between your device
and pop? What about QoS at your location, and does your ITSP support/respect
QoS?
Could problem be inside your network? Have you tested/optimized
Hello,
try pinging your sip peer ip address following way:
ping -n -M do -s 1300 -i 0.1 -c 100 ${ipaddress}
Post several lines and the statistics.
Were you also thinking about MTU problems? Not very probable, but one
never knows.
Marek
2020-06-22 17:18 GMT+02:00, Luca Bertoncello :
> Am
You could also use the 'mtr' command under Linux.
> Am 22.06.2020 um 17:41 schrieb Marek Greško :
>
> Hello,
>
> try pinging your sip peer ip address following way:
>
> ping -n -M do -s 1300 -i 0.1 -c 100 ${ipaddress}
>
> Post several lines and the statistics.
>
> Were you also thinking
Still lots of detail missing, butlikely causes include:
1. Egress latency (does your router/firewall support QoS, are you leaving
headroom )
2. Ingress latency - does your ITSP support it
3. Router/firewall latency - can it keep up with the traffic and packet size.
Do you have way too many
16 matches
Mail list logo
