Hello Henning,
Thanks for precious indications!
I've tried to disable dns caching but nothing changed
Also captured everything on the network interface, but nothing discovered!
I've changed also dns server (from kube DNs to core dns) without success.
I'll try to reproduce in vm environment with
Am Donnerstag, 2. August 2018, 20:33:28 CEST schrieb Paolo Visintin -
evosip.cloud:
> I am able to see
> 0(710) DEBUG: dmq [notification_peer.c:240]: get_dmq_host_list(): adding
> DMQ node A host dmq-router-service=sip:42.100.109.113:5062
>
> but in tcpdump no DNS query
>
> Also doing a loop of
Hi Charles,
when I say kamailio "resolves" but does not query DNS I mean that in DEBUG
I am able to see
0(710) DEBUG: dmq [notification_peer.c:240]: get_dmq_host_list(): adding
DMQ node A host dmq-router-service=sip:42.100.109.113:5062
but in tcpdump no DNS query
Also doing a loop of "kamcmd
Hi Paolo,
kamailio "resolves" A host but does not query the DNS
What do you mean by this?
I am not overly familiar with Kamailio's DNS internals, but what do you see
if you run the following commands?
kamcmd dns.lookup SRV _sip._udp.dmq-router-service.paolo.svc.cluster.local
kamcmd
Hello again!
Another interesting thing found running in debug=3
0(710) DEBUG: dmq [notification_peer.c:240]: get_dmq_host_list(): adding
DMQ node A host dmq-router-service=sip:42.100.109.113:5062
so , kamailio "resolves" A host but does not query the DNS
this is dump of dns request inside
Hello Charles,
sorry for late reply, we've had some issues rebuilding docker images with
kamailo nightly build!
We are running on our local, private on premise kubernetes cluster so
connections from outside is simply impossible (in dev we are using a
"closed" network system)
I've just tried to :
Hi Aleksandar,
The initial depopulation of the nodes (following a period of 'pending'
state) is due to no response being received from them. Are you able to
trace the messages to/from one of them to confirm what is happening there?
As for the unrecognised IP, I'm afraid I can't answer that one.
Hi Charles,
We're so glad about the improvements you just committed! Thanks!
Now I'm using the latest nightly: 5.2.0~dev6+0~20180726010431.1165+xenial
Kamailio starts even if the DNS record does not exist at first, that's
great. I'm having this nodes up and running:
```
proxy-66f79498cc-8ws6d
Hi,
I have just pushed some changes to master - one of these allows startup to
continue even if initial node resolution fails.
There are some other improvements, too, which I have been planning to push
for some time and which should also help in your situation.
Can you try again with these
Similar thing with a different type of nodes:
```
proxy-94b6ccf46-6n49v 3/3 Running 0
1m172.22.5.99 master.alex.cloud.evox.it
proxy-94b6ccf46-7jrgj 3/3 Running 0
1m172.22.5.98 master.alex.cloud.evox.it
proxy-94b6ccf46-rbskb
Here's another example:
```
router-0 3/3 Running 0
13m 172.22.5.94 master.alex.cloud.evox.it
router-1 3/3 Running 0
13m 172.22.5.3 master.alex.cloud.evox.it
router-2 3/3
Hi,
I'm now creating a dns record inside kubernetes with a headless service.
Unfortunately I must use a busybox that will start before the kamailio
nodes so the dns record will be created before kamailio starts because
otherwise it will crash as I told you before. IMHO it will be useful
to have a
On Thu, Jul 5, 2018 at 12:35 PM Charles Chance
wrote:
> I'll take a look - which version are you using?
5.2.0~dev6+0~20180616010152.1138+xenial
Thank you!
--
Aleksandar Sosic
mail: alex.sosic@evosip.cloud
___
Kamailio (SER) - Users Mailing List
I'll take a look - which version are you using?
Cheers,
Charles
On 5 July 2018 at 11:17, Aleksandar Sosic wrote:
> On Mon, Jul 2, 2018 at 2:55 PM Charles Chance
> wrote:
> > Hi Aleksandar,
> > [...]
> > You do not, in fact, need to maintain a dedicated node who's only role
> is "DMQ server"
On Mon, Jul 2, 2018 at 2:55 PM Charles Chance
wrote:
> Hi Aleksandar,
> [...]
> You do not, in fact, need to maintain a dedicated node who's only role is
> "DMQ server" as you have described it. I would recommend removing it
> completely and allowing your other nodes to discover/communicate
Hi Aleksandar,
On 1 July 2018 at 07:08, Aleksandar Sosic wrote:
> Hi everyone,
>
> so adding some xlogs We've managed to find out what's happening.
> The request route was using:
> ```
> if(is_method("KDMQ")){
> ```
> but this if was never triggered(!?)
> We changed that to
> ```
> if($rm
Hi everyone,
so adding some xlogs We've managed to find out what's happening.
The request route was using:
```
if(is_method("KDMQ")){
```
but this if was never triggered(!?)
We changed that to
```
if($rm == "KDMQ"){
```
And now it's working.
So why is that? In the documentation there's an
With a more verbose kamailio (not sure if it helps):
```3(32) DEBUG: [core/udp_server.c:491]: udp_rcv_loop():
received on udp socket: (106/100/520) [[KDMQ
sip:notification_peer@10.0.0.102:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP
10.0.0.49;branch=z9hG4bK361]]
3(32) DEBUG:
Hi Charles,
The notification address is set to localhost only for the server node
because I have a mutual architecture and don't know which nodes are up
and with which IPs. There could be a possibility that there are no
other kamailio nodes beside the dmq-server.
I'm pretty sure this
Hello,
Is there anything preventing the messages from reaching Kamailio? If you
have a pcap from one of the servers we may be able to see what’s happening.
Also, you have the notification address set to localhost - this should
instead point to one of the other nodes.
Cheers,
Charles
On Fri,
20 matches
Mail list logo
