On 03.07.20 at 19:57 Luca Bertoncello wrote:
[...]
>> 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.
>> I can't believe, the problem is here...
>
> So, now I know what was the problem and I solved it...
>
> The
Hi list!
Am 22.06.2020 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.
>
Am 24.06.20 um 08:10 schrieb Luca Bertoncello:
Am 24.06.2020 05:05, schrieb Michael Maier:
Hi
Your basic architecture looks good to me - now you have to start the
Nice to hear it...
analysis of the problem with pcapsipdump and wireshark as I wrote
before to get an idea what actually
Am 24.06.2020 05:05, schrieb Michael Maier:
Hi
Your basic architecture looks good to me - now you have to start the
Nice to hear it...
analysis of the problem with pcapsipdump and wireshark as I wrote
before to get an idea what actually happens at
all. You most probably won't come any
On 23.06.20 at 21:10 Luca Bertoncello wrote:
> Am 23.06.2020 um 21:08 schrieb Michael Maier:
>> On 23.06.20 at 08:05 Luca Bertoncello wrote:
>>> Am 23.06.2020 07:27, schrieb Luca Bertoncello:
>>>
>>> I again
>>>
> Do not change MTU. Probably there will be another problem. I expect
> packet
Am 23.06.2020 um 21:08 schrieb Michael Maier:
> On 23.06.20 at 08:05 Luca Bertoncello wrote:
>> Am 23.06.2020 07:27, schrieb Luca Bertoncello:
>>
>> I again
>>
Do not change MTU. Probably there will be another problem. I expect
packet size 1466 would pass and higher will have the same
On 23.06.20 at 08:05 Luca Bertoncello wrote:
> Am 23.06.2020 07:27, schrieb Luca Bertoncello:
>
> I again
>
>>> 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
RTP-VoIP-packets never reach this size.
Am 23.06.2020 um 17:04 schrieb Marek Greško:
> I interchanged LAN and LTE in the sentence.
OK...
> Do you have some kind of NAT in fron of asterisk? Or is your asterisk
No, Asterisk has a public IP. No NAT in front of Asterisk...
> having public IP? Could you share sip.conf (without
I interchanged LAN and LTE in the sentence.
Do you have some kind of NAT in fron of asterisk? Or is your asterisk
having public IP? Could you share sip.conf (without passwords)? One
LAN client, one LTE and general section.
Marek
2020-06-23 16:29 GMT+02:00, Luca Bertoncello :
> Am 23.06.2020
Am 23.06.2020 16:22, schrieb Marek Greško:
It seems your problems lie in something other. Most probably it is not
mtu problem. All my suspections are contradicted. If it is true you
have inter vlan voice quality problems, it is definitely something
different. Formerly I assumed you were trying
It seems your problems lie in something other. Most probably it is not
mtu problem. All my suspections are contradicted. If it is true you
have inter vlan voice quality problems, it is definitely something
different. Formerly I assumed you were trying only LTE vs LAN using
internet.
Marek
Am 23.06.2020 15:43, schrieb Marek Greško:
Hi
Do you mean "my Linux-Box ignores ICMP packet unreachable" or
"Deutsche
Telekom ignores them"?
I meant DT, but this was a speculation. I did not say they do. I
consider it highly improbable. Then I was asking whether you do. As
per configuration
2020-06-23 15:02 GMT+02:00, Luca Bertoncello :
> Am 23.06.2020 14:49, schrieb Marek Greško:
>
> Hi Marek,
>
>> this could be ip address of the different interface on the same box. I
>> think it works like expected. The only exception would be if the sip
>> peer ignores the icmp packet unreachable.
Am 23.06.2020 15:15, schrieb Jeff LaCoursiere:
Hi Jeff,
I have problem calling someone outside my networks and I have
problem if the peers are in different networks...
I may have missed this originally - are you saying you have trouble
when internal phones call each other, if they are on
Hi Luca,
On 6/23/20 8:02 AM, Luca Bertoncello wrote:
I have problem calling someone outside my networks and I have problem
if the peers are in different networks...
I may have missed this originally - are you saying you have trouble when
internal phones call each other, if they are on
Am 23.06.2020 14:49, schrieb Marek Greško:
Hi Marek,
this could be ip address of the different interface on the same box. I
think it works like expected. The only exception would be if the sip
peer ignores the icmp packet unreachable. But I doubt this is the
Do you mean "my Linux-Box ignores
Hello,
this could be ip address of the different interface on the same box. I
think it works like expected. The only exception would be if the sip
peer ignores the icmp packet unreachable. But I doubt this is the
case. Anyway you get problems also when calling to LTE phone without
using sip
Hello
Le 23/06/2020 à 09:06, Luca Bertoncello a écrit :
Am 23.06.2020 08:43, schrieb Luca Bertoncello:
And another thing, I discovered right now...
Could you suggest me something to restrict the problem?
Currently, I think the problem can be:
1) on Asterisk
2) on my Gateway/Firewall
A
Am 23.06.2020 10:07, schrieb Marek Greško:
Hi
this is a correct response:
From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set
(mtu = 1492)
So PMTU discovery is working. No problem here. You got correct message
to lower the packet size from 62.156.246.57. This is probably the
Hello,
this is a correct response:
From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set
(mtu = 1492)
So PMTU discovery is working. No problem here. You got correct message
to lower the packet size from 62.156.246.57. This is probably the last
hop before your site.
Marek
Am 23.06.2020 09:28, schrieb Marek Greško:
Hi
if you need clampmss then it is highly probable there is a PMTU
discovery problem. The clampmss does not work for UDP.
Is there a way to check if I have this problem?
I probably counted the size incorrectly. So you are able to ping with
size
Hello,
if you need clampmss then it is highly probable there is a PMTU
discovery problem. The clampmss does not work for UDP.
I probably counted the size incorrectly. So you are able to ping with
size 1464 and not with 1466. How about trying same ping sizes from the
internet towards your site? I
Am 23.06.2020 09:19, schrieb Administrator:
Hi Daniel
Audio has nothing to do with SIP signaling 5060 port. Look at your
rtp.conf
You're right...
I have to restrict to the ports I configured in rtp.conf...
So like:
iptables -A FORWARD -p tcp -m multiport --ports -ports 1:15100
Am 23.06.2020 08:43, schrieb Luca Bertoncello:
And another thing, I discovered right now...
Could you suggest me something to restrict the problem?
Currently, I think the problem can be:
1) on Asterisk
2) on my Gateway/Firewall
A couple of years ago I added this entry in my firewall:
Am 22.06.2020 20:09, schrieb Luca Bertoncello:
A couple of other ideas...
Conclusion (maybe!): it can *not* be a problem in the DSL connection
and
*maybe* it is not a problem in the communication with the Server of
Deutsche Telekom, since I have many problems to communicate between two
peers
Am 23.06.2020 07:27, schrieb Luca Bertoncello:
I again
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
I checked it, and I see, that the maximum I can use is a paket size of
1464 with all hosts via
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
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
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
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
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.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
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
problem?
-Original Message-
From: asterisk-users [mailto:asterisk-users-boun...@lists.digium.com] On Behalf
Of Luca Bertoncello
Sent: Monday, June 22, 2020 11:19 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Voice broken during calls (again
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
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
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
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
39 matches
Mail list logo
