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 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 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 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
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 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
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 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
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
Hi.
I have an Asterisk 13.14.1 setup which uses ODBC to write CEL and CDR records.
The connection to my database server depends on a VPN tunnel being up, and if
Asterisk starts before that tunnel is functional, I get messages such as the
following in the Asterisk log file:
[2020-06-23
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
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
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 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
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
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
>>> Is there any way I can tell Asterisk that an ODBC connection problem is a
>>> fatal error
Your be best bet would be to do that check in the script that starts up
Asterisk and maybe a CRON job that periodically tests connectivity.
Doug
--
Hi.
Is there any better way of controlling Asterisk itself (by which I mean,
shutting it down, or telling it to restart) from within the dialplan, other
than using the System() command?
Regards,
Antony.
--
Software development can be quick, high quality, or low cost.
The customer gets to
Maybe using a fastAGI running as a sidecar. It may have access to systemd
and therefore be able reload or restart the asterisk. As well as take
further action in case something goes wrong. It can be triggered by a call
same way as App system.
BR
jöran
Doug Lytle schrieb am Di., 23. Juni 2020,
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
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
>>> other than using the System() command?
Not that I am aware of,
Doug
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
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
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 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 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
27 matches
Mail list logo
