g database for any of your call processing, an unreachable dns
> server can also be the cause of trouble. For some reason, even if you are
> using IP addressing, Mysql will try to resolve a connection and can hang
> (there is a mysql parameter to not resolve addresses).
>
> On Wed, No
, November 8th, 2023 at 1:21, John Harragin
wrote:
> Marek,
>
> See if calls hang in the system if you encounter another outage
> core show channels
>
> ...if so,
> core set verbose 3
> and see what instructions subsequent calls hang on.
>
>
>
> On Mon,
will see once the next massive internet
outage out of my control happens, whether it helped.
Thanks again
Marek
--- Original Message ---
On Tuesday, November 7th, 2023 at 16:28, Joshua C. Colp
wrote:
> On Tue, Nov 7, 2023 at 11:20 AM Marek Greško
> wrote:
>
>> Hello,
internet or at least outbound DNS, I will try
to make sure my findings are correct using tcpdump.
Thanks
Marek
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, November 7th, 2023 at 0:46, Greg Troxel wrote:
> Marek Greško marek.gre...@protonmail.com wri
t;
>
> On Mon, 6 Nov 2023 at 23:13, Marek Greško 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_r
really be resolvable.
Thanks
Marek
--- Original Message ---
On Monday, November 6th, 2023 at 19:52, Marek Greško
wrote:
> Hello,
>
> sure I have local DNS server and public resolving should not be needed for
> phone registrations. Running pjsip show endpojnt show t
.
In phone log I see:
CC_eventProc(event=63(CC_EV_SIG_REGISTER_FAILED),
lid=0, par=0, par2=(nil))
The phone is Cisco SPA525G2.
Thanks.
Marek
--- Original Message ---
On Monday, November 6th, 2023 at 15:45, Joshua C. Colp
wrote:
> On Mon, Nov 6, 2023 at 10:42 AM Marek Greško
>
:06 AM Marek Greško
> wrote:
>
>> 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 abl
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
Hello Jerry,
when you run asterisk using su, ownership of audio device files does not get
updated. When you login, you get the permissions. You can verify by ls -l and
getfacl on the device file.
Marek
--- Original Message ---
On Thursday, September 14th, 2023 at 14:33, Jerry Geis
Hello Michael,
I was also struggling with solicited MWI after moving to pjsip. My
problem was I was defining mailbox=111@extensioncontext. But the
correct context in the mailbox command is to be defined by context in
voicemail.conf. My voicemails were all defined in the context default
(see
the
section worked for registration.
Thanks for you effort.
Marek
ut 19. 10. 2021 o 20:22 Joshua C. Colp napísal(a):
> On Tue, Oct 19, 2021 at 3:18 PM Marek Greško wrote:
>
>> Hello,
>>
>> I am observing error:
>> res_pjsip/pjsip_configuration.c:2368 ast_sip_retriev
to load.
[Oct 19 19:55:20] ERROR[4385] loader.c: Failed to resolve dependencies for
res_pjsip_stir_shaken
[Oct 19 19:55:20] ERROR[4385] loader.c: res_pjsip_stir_shaken declined to
load.
Thanks
Marek
ut 19. 10. 2021 o 20:22 Joshua C. Colp napísal(a):
> On Tue, Oct 19, 2021 at 3:18 PM Marek Gre
Hello,
I am observing error:
res_pjsip/pjsip_configuration.c:2368 ast_sip_retrieve_auths: Couldn't find
auth 'provider'. Cannot authenticate.
res_pjsip_outbound_authenticator_digest.c:144
digest_create_request_with_auth: Endpoint: 'provider': Failed to set
authentication credentials
I use config
local to asterisk server could use. So many
backdoors can be open. Believe me. It is not secure. Maybe it is
acceptable on a dedicated asterisk box, but not on a multi purpose
server.
Marek
2021-09-10 23:28 GMT+02:00, Duncan Turnbull :
>
>
>> On 11/09/2021, at 2:54 AM, Marek G
not think opening the wide port
range is a solution. The nftables runs on the asterisk server itself.
Marek
2021-09-10 1:19 GMT+02:00, Duncan Turnbull :
>
>
>> On 10/09/2021, at 4:37 AM, Marek Greško wrote:
>>
>> There are other systems running on the same hardware. It
bugs could be present and I accept. I just wanted to be sure I am not
doing anything wrong. Now I am pretty sure it is a bug.
Thanks
Marek
2021-09-09 18:30 GMT+02:00, Administrator :
>
> Le 09/09/2021 à 18:15, Marek Greško a écrit :
>> There is always some risk. If there is a solution
There is always some risk. If there is a solution that should work, it
is best to use it. We just need the root cause, why it fails
sometimes.
Marek
2021-09-09 18:01 GMT+02:00, Antony Stone :
> On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
>
>> Hello,
>>
&
Hello,
I would not like to open whole range of udp ports for rtp. I use
nf_conntrack_sip module for dynamically opening relevant ports. And
there is probably some bug in it.
Marek
2021-09-08 23:12 GMT+02:00, Administrator :
> Hi. Our rules:
>
> Le 08/09/2021 à 22:43, Marek Grešk
Sorry did convert, not did converted :)
2021-09-08 22:43 GMT+02:00, Marek Greško :
> Hello,
>
> I did converted from iptables by automatical script and then rewritten
> myself, because not everything was rewritten successfully.
>
> Relevant parts:
>
> table ip fi
... pretty the same, but I have no ipv6 internet connectivity, so
this should not match ...
}
Is there something incorrect?
Thanks
Marek
2021-09-08 21:17 GMT+02:00, Duncan Turnbull :
>
>
>> On 9/09/2021, at 6:23 AM, Marek Greško wrote:
>>
>> Hello,
>>
>&g
GMT+02:00, Antony Stone :
> On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
>
>> > On 7/09/2021, at 8:30 AM, Marek Greško wrote:
>> >
>> > Hello,
>> >
>> > it is only local nftables with nf_conntrack_sip on the asterisk
>
and incoming stream is blocked. So the outgoing rtp
could not be learnt to send to nat addess.
Marek
2021-09-06 22:17 GMT+02:00, Duncan Turnbull :
>
>
>> On 7/09/2021, at 3:08 AM, Marek Greško wrote:
>>
>> Hello,
>>
>> so when debugging RTP in asterisk there was no r
into. It was working previously with the other provider because of
working SIP ALG on their gateways. But now with this provider and
disabled SIP ALG it is not allowed. As I remeber in the past these
setups did work. What are your experiences on this?
Thanks
Marek
2021-09-06 11:50 GMT+02:00, Marek Greško
Sorry rtp set debug on showed something. So let try for the problem to
arise again.
Marek
2021-09-06 11:48 GMT+02:00, Marek Greško :
> Hello,
>
>>> I would expect that when asterisk is aware of nat, it does not send
>>> the rtp until it receives rtp from other side to le
le? How should asterisk handle the situation?
> I can’t see anything to support that. Everything is looking normal except
> asterisk doesn’t appear to beseeing the rtp packet
>>
>> Thanks
>>
>> Marek
>>
>>
>>>
>>> Have fun, its all go
he debug should be conducted?
Is my suspection that the problem could be caused by nat ip addres
changing reasonable? How should asterisk handle the situation?
Thanks
Marek
>
> Have fun, its all good learning.
>
>
> On Sun, Sep 5, 2021 at 6:27 PM Marek Greško wrote:
>
>>
conversation to look at.
The phone private address is 192.168.100.235.
Thanks
Marek
2021-09-05 1:11 GMT+02:00, Duncan Turnbull :
>
>
>> On 5/09/2021, at 10:21 AM, Marek Greško wrote:
>>
>> Hello,
>>
>> could you please answer my previous question about anonymizing se
you see something inconsistent in it?
By algorithms I meant when the router actively translates the sip
payload to change the lan addresses to the natted one.
Thanks
Marek
2021-09-05 0:40 GMT+02:00, Antony Stone :
> On Thursday 08 July 2021 at 20:57:30, Marek Greško wrote:
>
>> He
021 at 22:13:32, Marek Greško wrote:
>
>> Hello,
>>
>> I agree my knowledge of SIP itself is poor, but I have quite well
>> general tcp/ip understanding. What sip parameters should be
>> anonymized? How about tag, branch, call-id, cseq values?
>
> Show us your
hat’s ip
> is what and where the conversations are captured
>
> It will become clear once you provide all the details
>
>
>>
>> Thanks
>>
>> Marek
>>
>> 2021-09-04 0:40 GMT+02:00, Antony Stone
>> :
>>> On Saturday 04 September
04 September 2021 at 00:34:49, Duncan Turnbull wrote:
>
>> > On 4/09/2021, at 7:53 AM, Marek Greško wrote:
>> >
>> > So you suspect something is messing up SIP protocol? Maybe the phone
>> > itself is not working properly. The phone itself is not aware of th
was asked to disable all the SIP ALG
on the provider's router in the previous discussion. And it made a big
improvement in the experience.
Marek
2021-09-03 12:19 GMT+02:00, Duncan Turnbull :
> On Fri, Sep 3, 2021 at 8:47 PM Marek Greško wrote:
>
>> Hello,
>>
>> I lo
ts either config or firewall. A firewall with ALGs is often
> problematic but your log suggests a lack of negotiation of agreed
> codecs.
>
> Good luck, you will learn some interesting things.
>
>
>
>>
>>Thanks
>>
>>Marek
>>
>>
>>2021-07-26 9:31
?
Thanks
Marek
2021-07-26 9:31 GMT+02:00, Marek Greško :
> I currently disabled also RTSP ALG and rebooted the router. Fixed for
> now. I do not know for how long.
>
> Marek
>
>
> 2021-07-26 8:54 GMT+02:00, Marek Greško :
>> Hmm, back to original problem. My happin
I currently disabled also RTSP ALG and rebooted the router. Fixed for
now. I do not know for how long.
Marek
2021-07-26 8:54 GMT+02:00, Marek Greško :
> Hmm, back to original problem. My happines was premature. Today one of
> the phones have no audio again. I see packets from lan segment
are neede to be disabled?
As of my observations these problems are triggered by reboots on
asterisk side. How could this be related? (I may be wrong.)
Thanks
Marek
2021-07-23 14:54 GMT+02:00, Marek Greško :
> I achieved a partial success adding --use-compact-form option.
>
> Marek
>
I achieved a partial success adding --use-compact-form option.
Marek
2021-07-23 13:47 GMT+02:00, Marek Greško :
> Hello,
>
> your suggestion to turn off SIP ALG on provider's router was probably
> correct. no problem until now. Thank you very much.
>
> I just found out an
ing Request msg INVITE/cseq=, will try
next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)
What could be the problem? How can I convince pjsue to work correctly
behind nat?
Thanks
Marek
2021-07-10 11:08 GMT+02:00, Marek Greško :
> Hello,
>
> I just disabled. Currently it i
t Regards,
>
> On Fri, Jul 9, 2021, 09:10 Antony Stone <
> antony.st...@asterisk.open.source.it> wrote:
>
>> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>>
>> > Hello,
>> >
>> > yes SIP ALG are anbled on the router. Should I disab
To be more specific I was on the
https://wiki.asterisk.org/wiki/display/AST/Getting+Started already,
but I assume all the additional transport parameters are relevant only
when asterisk itself is behind nat. Is not it true?
Marek
2021-07-09 8:47 GMT+02:00, Marek Greško :
> Hello,
>
>
de 2021 a la(s) 14:58, Marek Greško (mgres...@gmail.com)
> escribió:
>
>
>> The asterisk is connected to the internet with public static IP address.
>>
>> The pjsip config contains:
>>
>>
> What does your transport config look like?
>
> Take a look
Hello,
I have an asterisk setup using pjsip. Everything used to work
correctly until one remote site changed internet provider and thier
router does not support sip protocol algorithms.
It works for some time, but then suddenly audio stops working both
directions. When this happens I see RTP
Hello,
could somebody drive me how could I make run presence reporting by BLF
feature on the Cisco SPA525G2 with SPA500DS on asterisk with pjsip
stack?
I am not able to configure asterisk side. When I run pjsip show
subscriptions inbound I see all subscriptions as dialog. Which as of
my
cedure runs in its own context gosub-stdexten. If you
are aware of any better solution I would be glad to here about.
Marek
2021-01-05 18:32 GMT+01:00, Marek Greško :
> Hello,
>
> I am unable to figure out why I am not able to blind transfer when I
> am the caller and I call the
Hello,
I am unable to figure out why I am not able to blind transfer when I
am the caller and I call the extension defined by gosub.
When running asterisk -rvvv I can see:
-- Channel PJSIP/-0009: Dialed '@gosub-stdexten' does not exist.
It is evident there has been added some weird
+01:00, Joshua C. Colp :
> On Sat, Jan 2, 2021 at 5:36 AM Marek Greško wrote:
>
>> Hello,
>>
>> I configured MWI with pjsip.
>>
>> The aors section contains:
>>
>> mailboxes = 101@
>>
>> The endpoint section contains:
>>
&
Hello,
I configured MWI with pjsip.
The aors section contains:
mailboxes = 101@
The endpoint section contains:
context = internal
mailboxes = 101@
The dialplan leaves the voicemail by:
exten => s-NOANSWER,2,VoiceMail(${vmbox}@|u)
or:
exten => s-BUSY,2,VoiceMail(${vmbox}@|b)
When I configure
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 assum
-06-23 15:50 GMT+02:00, Luca Bertoncello :
> 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
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 ignor
ieb 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 siz
-06-23 9:40 GMT+02:00, Luca Bertoncello :
> 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 pr
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
with size 2 bytes larger the highest you are able to
ping.
Marek
2020-06-22 22:26 GMT+02:00, Luca Bertoncello :
> 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 phone
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
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,
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
Hi Luca,
I suspect the problem is either the line quality, aggregation or some
other factor. I can see you allow alaw and ulaw codecs for DT and
alaw, ulaw and gsm for the second provider. This could be the
difference why you observe problems mainly on DT. The alaw and ulaw
codec require 64 kbps
Hello,
provider responded the behavior is intentional from their side. So
this should be fixed in asterisk. The pjsip cleanly does not do any
unregistrations where it should.
Marek
2020-06-07 12:30 GMT+02:00, Marek Greško :
> Hello,
>
> I found the problem and also the workaround.
&g
and
unregister and reregister all of them during startup in case some of
them remain active after unclean shutdown.
Also probably provider side should be fixed?
Thanks for your insight.
Marek
2020-06-05 19:29 GMT+02:00, Doug Lytle :
> On 6/5/20 12:24 PM, Marek Greško wrote:
>> How can this
Hello,
after migration from chan_sip to res_pjsip I get strange behavior when
receiving call from the outside world. When call is received, it is
replicated multiple times. Two of that calls get to the phone. So the
phone is ringing on both lines. When having only Dial function in
dialplan I am
Hello,
great news. I did not find it because an underscore added compared to
chan_sip. Thank you very much. It is working.
Marek
2020-06-05 11:12 GMT+02:00, Joshua C. Colp :
> On Fri, Jun 5, 2020 at 6:02 AM Marek Greško wrote:
>
>> Hello,
>>
>> I would like to
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
64 matches
Mail list logo
