17 Sep
2016
17 Sep
'16
6:09 p.m.
Hi,
while playing with the script from http://kb.asipto.com/kamailio:presence:k43-blf
and "kamailio 4.4.3 (x86_64/freebsd) 5a2195" I could not see any NOTIFY packet
going out to the subscribed watcher.
"tcpdump -i lo0" shows self injected PUBLISH packets challenged with
"407 Proxy Authentication Required" and there they got stuck.
The PUBLISH packets are sent on lo0 from my network address to the same network
address (here 10.0.0.106 to 10.0.0.106). The proxy challenge is also sent from
10.0.0.106 to 10.0.0.106.
An xlog entry with the variable "$Ri" in route REQUEST shows 10.0.0.106 too.
Since these packets are only seen on lo0, should "$Ri" not show 127.0.0.1?
After disabling the WITH_AUTH variable, the watcher is getting its NOTIFY's.
Now I wonder under which circumstances this script is supposed to function
correctly without changes in the AUTH route?
By the way, I had the same problem with the provided script of the
msilo module (http://kamailio.org/docs/modules/4.4.x/modules/msilo.html#idp42867388)
which too only works if there is no "auth_challenge" in the way.
Could somebody with more insight in Kamailio internals give some hints
on this, please? How can it get solved in an elegant way?
Thanks,
Torsten
17 Sep
17 Sep
7:21 p.m.
Add #!define WITH_IPAUTH to your script and the server's IP address to the
address table and restart Kamailio.
Packets from your local address to your local address are routed through
your loopback interface. lo0 looks like some BSD, so you can verify that in
the routing table with netstat -rn
On Sat, Sep 17, 2016, 18:09 Torsten Hantzsche <thantzsche(a)petitenet.de>
wrote:
Hi,
while playing with the script from
http://kb.asipto.com/kamailio:presence:k43-blf
and "kamailio 4.4.3 (x86_64/freebsd) 5a2195" I could not see any NOTIFY
packet
going out to the subscribed watcher.
"tcpdump -i lo0" shows self injected PUBLISH packets challenged with
"407 Proxy Authentication Required" and there they got stuck.
The PUBLISH packets are sent on lo0 from my network address to the same
network
address (here 10.0.0.106 to 10.0.0.106). The proxy challenge is also sent
from
10.0.0.106 to 10.0.0.106.
An xlog entry with the variable "$Ri" in route REQUEST shows 10.0.0.106
too.
Since these packets are only seen on lo0, should "$Ri" not show 127.0.0.1?
After disabling the WITH_AUTH variable, the watcher is getting its
NOTIFY's.
Now I wonder under which circumstances this script is supposed to function
correctly without changes in the AUTH route?
By the way, I had the same problem with the provided script of the
msilo module (
http://kamailio.org/docs/modules/4.4.x/modules/msilo.html#idp42867388)
which too only works if there is no "auth_challenge" in the way.
Could somebody with more insight in Kamailio internals give some hints
on this, please? How can it get solved in an elegant way?
Thanks,
Torsten
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
18 Sep
18 Sep
11:51 a.m.
On Sat, 17 Sep 2016, Bastian Triller wrote:
Add #!define WITH_IPAUTH to your script and the server's IP address to the
address table and restart Kamailio.
Packets from your local address to your local address are routed through your
loopback interface. lo0 looks like some BSD, so you can verify that in the
routing table with netstat -rn
Bastian, thanks for the explanation. I have Kamailio running on FreeBSD
and never thought of a difference in the routing table compared to Linux.
The option WITH_IPAUTH did the trick.
Torsten
19 Sep
19 Sep
10:25 a.m.
On Sun, Sep 18, 2016 at 11:51:42AM +0200, Torsten Hantzsche wrote:
Bastian, thanks for the explanation. I have Kamailio
running on FreeBSD
and never thought of a difference in the routing table compared to Linux.
The option WITH_IPAUTH did the trick.
There is no difference in routing to the local adresses between Linux
and $BSD. To a local adress is alway routed via the loopback device,
the only difference may be the output of netstat/route.
2801
days inactive
2803
days old
3 comments
3 participants
participants (3)
-
Bastian Triller -
Daniel Tryba -
Torsten Hantzsche