So basically what you need is to either resolve the fqdn for every received
packet, or keep the resolved up somehow to check against when a packet
arrives from downstream.
On Tue, 27 Aug 2019 at 19:18, Henning Westerholt wrote:
> Hello Sergiu,
>
> now its better understandable. Just looked brief
Nope, its broken again. I am probably too stupid for this.
wt., 27 sie 2019 o 23:12 przeqpiciel napisał(a):
> Right now it works.
> I added additional network card to my virtual kamailio, then put this NIC
> to asterisks network also i configured multiple listen and mhomed=1
>
> wt., 27 sie 2019
Right now it works.
I added additional network card to my virtual kamailio, then put this NIC
to asterisks network also i configured multiple listen and mhomed=1
wt., 27 sie 2019 o 20:54 Alex Balashov
napisał(a):
> I can see the temptation, but that’s actually looking at it backwards.
>
> If you
Hi,
I am running 4.3.5:1b0c0a, which I am aware is an EOL'd release train,
and have a problem with the dialog module I am baffled by.
On many calls - I can't find any correlation to particular kinds of
endpoints - I see spoofed BYEs come out of Kamailio after a minute and a
half, as if the call h
On Tue, 27 Aug 2019, 13:39 Daniel-Constantin Mierla,
wrote:
> I am not sure how much used are the event routes for tm:local-response
> and sl:local-response, I haven't seen any questions about them so far on
> mailing lists, that's why I am asking here if would make sense to rename
> them like tm
I can see the temptation, but that’s actually looking at it backwards.
If you have multiple listeners, e.g.
listen=udp:x.x.x.x:5060
listen=udp:y.y.y.y:5060
or multiple listeners on the same interface with multiple ports, if it’s NAT’d
AWS-style, e.g.
listen=udp:x.x.x.x:5060
listen=udp:x.x.x.x:
No, I hear about that first time. But I think i still need program that
will rewrite record route depends if it goes to asterisk or to Internet
wt., 27 sie 2019 o 15:44 Sergiu Pojoga napisał(a):
> Do you have: mhomed=1 ?
>
> On Tue, Aug 27, 2019 at 8:52 AM przeqpiciel wrote:
>
>> Thank you for
Hi Daniel,
sounds good to me, indeed more consistent.
Cheers,
Henning
Am 27.08.19 um 13:36 schrieb Daniel-Constantin Mierla:
> Hello,
>
> just discovered what I consider to be an inconsistency in naming and
> behaviour for event_route blocks for local-request and local-response
> and starting a
Hello Sergiu,
now its better understandable. Just looked briefly to the code, the function
works more or less like this:
- it will take the URI and resolve it to an IP address
- it will then compare this IP to the dispatcher nodes (depending on the mode
to all or one group)
So if there is a D
Finally, I uninstalled and reinstalled Kamailio and now SIP calls works
fine.
Thanks.
On Tue, Aug 27, 2019 at 4:26 PM Jack R wrote:
> Hi,
>
> I installed Kamailio SIP server:
> Following article:
> https://github.com/open5gs/nextepc/blob/master/docs/_docs/guide/04-setting-up-kamailio-IMS.md
>
>
Hello Gaurav,
can you check /lib/systemd/system/kamailio.service and see if it works if you
change it there?
Better would be then to change it with "sudo systemctl edit kamailio" - refer
e.g. to:
https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-a
Joel Serrano writes:
> Did you check to see if UDP packets (maybe?) are being queued at the
> network level before reaching K?
Thanks for the tip. Will check next time ($ ss -4 -n -l | grep 5060).
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-use
Hi Juha,
Did you check to see if UDP packets (maybe?) are being queued at the
network level before reaching K?
You should be able to see that with netstat, not that this fixes the
problem but might point in some direction...
On Tue, Aug 27, 2019 at 9:29 AM Juha Heinanen wrote:
> Juha Heinane
Juha Heinanen writes:
> Any ideas what could cause Kamailio (5.2 version) to stop processing
> requests over UDP? What additional info should I try to get?
Is there some means to find out if a UDP receiver process is currently
processing a request?
Forgot to mention that after about 10 minutes
I'm returning to an old issue, where Kamailio stops processing incoming
requests.
Now it turned out that only requests over UDP are not processed.
Requests over TCP work fine. Debug log doesn't show anything about the
requests over UDP, but wireshark sees them coming. core.ps shows that
main pro
Hello everyone,
I'm runing Kamailio 5.2.4 with enabled mysql, usrlocdb, presence, aliasdb, auth and NAT. I can register clients, establish calls and video calls, send IMs, etc. imc_rooms and imc_members tables were created when
kamailio was installed. I've also checked imc-create.sql script and tab
Hi Daniel,
yes, sorry I meant local-response!
Cheers,
Federico
On Tue, Aug 27, 2019 at 4:19 PM Daniel-Constantin Mierla
wrote:
> Hi Federico,
>
> local-request stays the same (that's rather used based on mailing list
> discussions).
>
> I proposed to change the local-response to local-respons
Hi Federico,
local-request stays the same (that's rather used based on mailing list
discussions).
I proposed to change the local-response to local-response-sent (I don't
remember any discussion about people using it, I checked the commit log
and was added by Peter Dunkley several years ago, I nev
Hi Daniel,
personally I have just one case of local-request, so it wouldn't hurt too
much this change that brings consistency.
Cheers,
Federico
On Tue, Aug 27, 2019 at 1:37 PM Daniel-Constantin Mierla
wrote:
> Hello,
>
> just discovered what I consider to be an inconsistency in naming and
> be
May be I didn't provide sufficient details, so I'll elaborate.
I'd like Kamailio to 'talk' to only known dispatcher gateways, so in the
REQINIT route I do:
route[REQINIT] {
# Silently drop requests from unknown gateways, very strict mode
if(!ds_is_from_list()) {
xlog("L_ALERT","blocking $rm re
Do you have: mhomed=1 ?
On Tue, Aug 27, 2019 at 8:52 AM przeqpiciel wrote:
> Thank you for the reply. It little help for me, Right now probably I have
> to make logic which change record route depends on it where Kamailio send
> packets internal / outside
>
> pon., 26 sie 2019 o 22:21 Alex Balas
hi
thank you for reply
i think it is the issue due to memory
it is using default values (-m 64 -M 8 )
can you plz hell me how to increase this
i m tring to run this (kamailio -m 512 -M 8) , but it is not working
still values same as default
plz help
thanks
On Tue, Aug 27, 2019 at 4:21 PM Davi
Thank you for the reply. It little help for me, Right now probably I have
to make logic which change record route depends on it where Kamailio send
packets internal / outside
pon., 26 sie 2019 o 22:21 Alex Balashov
napisał(a):
> Hi,
>
> You may wish to have a look at the ‘advertise’ directive to
Hello,
just discovered what I consider to be an inconsistency in naming and
behaviour for event_route blocks for local-request and local-response
and starting a discussion here to see how to move on.
The event_route[tm:local-request] is executed before sending there local
generated request out (a
Hi,
I installed Kamailio SIP server:
Following article:
https://github.com/open5gs/nextepc/blob/master/docs/_docs/guide/04-setting-up-kamailio-IMS.md
By following step # 12 (as per above article) when we initiate the call we
get - Too many hops 483
Created two user earlier:
$ kamctl add test tes
Can you provide with the log when users try to register and kamailio
doesn’t answer?
On Tue, 27 Aug 2019 at 12:40, Gaurav Bmotra
wrote:
> hi
> i m using kamailio 5.1,,, on ubuntu 18.4
> installed form source
>
> after few days it stop registering client to kamailio it resolved
> after r
hi
i m using kamailio 5.1,,, on ubuntu 18.4
installed form source
after few days it stop registering client to kamailio it resolved after
restart service ... same after few day
loges
-
kamailio.service - LSB: Start the Kamailio SIP proxy server
Loaded: loaded
Hello Daniel,
Thank you for getting back to me.
We will update with 5.2.4 and I'll let you know if it's solved.
Regards,
Igor.
De : Daniel-Constantin Mierla
Envoyé : mardi 27 août 2019 09:39
À : Kamailio (SER) - Users Mailing List ;
igor.potjevle...@gmail.com
Objet : Re: [SR-User
Hello,
On 27.08.19 09:27, igor.potjevle...@gmail.com wrote:
>
> Hello!
>
>
>
> Any help on that matter? Sounds like the domain parsing have been
> updated. Is it possible to back on the previous mode?
>
did you mean backporting to older branches? If yes, it was done to
branch 5.2, have you tried
Hello,
On 26.08.19 22:35, Henning Westerholt wrote:
>
> Hello Duarte,
>
> tm:local-request is (as the name says) a event route from tm. So this
> will be only executed for locally generated requests from tm, but not
> e.g. for requests generated with sl.
>
to avoid any misleading by the above stat
Hello!
Any help on that matter? Sounds like the domain parsing have been updated.
Is it possible to back on the previous mode?
Regards,
Igor.
De : igor.potjevle...@gmail.com
Envoyé : vendredi 23 août 2019 18:53
À : 'Kamailio (SER) - Users Mailing List'
Objet : lookup(aliases) iss
Hello,
On 26.08.19 18:26, Duarte Rocha wrote:
> Greetings,
>
> Does "event_route[tm:local-request]" works like onsend route ?
no, event_route[tm:local-request] is for requests initiated by Kamailio
via tm module (but other modules can be the source of the requests, as
they use internally tm modu
Thanks Federico for looking into this and finding that. I guess that the
issue is when sip_trace() is the last action in the reply_route, its
return code being propagated to the interpreter. Using 'exit' after it
or 'return 1' could be a variant, but as you said a proper fix should be
done so there
33 matches
Mail list logo
