similar to: call replicating

Hello, I found the problem and also the workaround. Clearly, since it was working with chan_sip it should not be dialplan problem, but sip stack problem. I have line=yes set up. After asterisk restart the old registration is not unregistered and new one is registered with different line value. Then incoming invites and qualify requests are sent to all the registrations and there the problem

Hello, I would like to ask about current state of subscribecontext in pjsip. I found out some 6 years old discussion on that without any plans to implement it in the future. I have phones in different contexts. I suspect, when I use its context to subscribe, they will not see phones from the different contexts. Am I right? Marek

https://bugs.freedesktop.org/show_bug.cgi?id=93828 Bug ID: 93828 Summary: Xorg hangs randomly with nouveau driver Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Driver/nouveau Assignee:

Could you show the phone configurations - section "Proxy and Registration" On Mon, 6 Nov 2023 at 23:13, Marek Greško <marek.gresko at protonmail.com> wrote: > Hello, > > you are probably right. It should somehow be related to DNS. I just found > out this in the storm of previous messages: > > WARNING[13945] taskprocessor.c: The 'dns_system_resolver_tp'

Hello, it did not seem the call hung. It seemed it never started. There was no dialplan execution on the asterisk side. It looked like phones were unregistered. Same shows the log posted previously. Marek Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, November 8th, 2023 at 1:21, John Harragin <jharragin at mw.k12.ny.us> wrote: > Marek, >

Are the phones and the server in the same subnet? You might making note of the IPs and just simply try pinging everything with the uplink disconnected. Also, if you are using domain names for registration, it is possible a dns server must be reachable. If you are using database for any of your call processing, an unreachable dns server can also be the cause of trouble. For some reason, even if

On 6/5/20 12:24 PM, Marek Greško wrote: > How can this behavior been overriden? I do not expect this is problem > on provider side, since it was working normally using chan_sip. Console output and dial plan snippets are always useful when diagnosing, Doug -------------- next part -------------- An HTML attachment was scrubbed... URL:

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 last > hop before your site. No, the last hop is 62.156.246.65:

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 you sent you are not blocking icmp

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 QoS? That's a very good idea... Could you suggest me how can I check it? The Gateway is 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 1464 and not with 1466. How about trying same ping sizes from the > internet towards

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 only LTE vs LAN using > internet. I'm not sure what you mean with the last

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 size. The LTE phones could have lower MTU and thus overcome PMTU problem. Marek 2020-06-22 21:48

Marek Greško <marek.gresko at protonmail.com> writes: > But I am not sure why this is happening. I have sip providers hostname > in /etc/hosts file to prevent such situations. Should I reconfigure it > not to use hosts file but rather some RPZ on DNS server? Does asterisk > ignore hosts file? Or does it try to do some srv lookups? But in > either case, why does this influence

On Tue, Nov 7, 2023 at 11:20 AM Marek Greško <marek.gresko at protonmail.com> wrote: > Hello, > > well I do not ask those who only guess, but those who know what is > asterisk expected to do when internet connectivity goes down. I did not had > a chance to make internet not to work yet, since it is needed. But > inspecting dns logs I found out that there started to be

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 ICMP packet unreachable" or "Deutsche Telekom ignores them"? >

Hello, well I do not ask those who only guess, but those who know what is asterisk expected to do when internet connectivity goes down. I did not had a chance to make internet not to work yet, since it is needed. But inspecting dns logs I found out that there started to be resolving for _sip._tcp and _sip._udp records for the provider's server. So apparently making hosts record make asterisk

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 with size 2 bytes larger the highest you are able to ping. Marek 2020-06-22 22:26 GMT+02:00, Luca

Hello, I just realized that when my Internet connection goes down and I loose connectivity to VoIP SIP provider I loose ability to make local calls after some time. When I restart asterisk, I am able to make local calls for some time, but it then suddenly stops working again. I am using pjsip stack. What could be the cause of this? Thnaks Marek -------------- next part -------------- An HTML

hi, i'm testing asterisk 1.4/1.2 in the following scenario centos5/cpu quad xeon E5335 2.0Ghz - test clients behind nat - 1500+ testing instances - reregister option from 1min to 1hour - qualify set to 5000 top shows over 100% cpu. cpu cores sometimes go to 95% with htop i see ~16threads but only one child have ~95% cpu (how i can get info about that thread? what he is doing?) what is