Re: [sr-dev] [SR-Users] how i should process replies on nathelper pings?

Hi guys! I can reproduce the problem - I think there is a bug: nathelper's (k) sipping_rpl_filter function - which should absorb the replies - is not executed on received replies. Maybe there is problem in general with the reply callback or maybe there is a bug from consolidating ser's and kamailio's module interface? regards klaus Andres Moya schrieb: > I am using git to pull 3.0 > > [root@v kamailio]# cat .git/config > [core] > repositoryformatversion = 0 > filemode = true > bare = false > logallrefupdates = true > [remote "origin"] > url = git://git.sip-router.org/sip-router > fetch = +refs/heads/*:refs/remotes/origin/* > [branch "master"] > remote = origin > merge = refs/heads/master > [branch "kamailio_3.0"] > remote = origin > merge = refs/heads/kamailio_3.0 > > > I can't do anything in request route? > [root@v kamailio]# cat /usr/local/etc/kamailio/kamailio.cfg | grep > nathelper > loadmodule "nathelper.so" > # ----- nathelper ----- > #modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7722") > modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock") > modparam("nathelper", "natping_interval", 30) > modparam("nathelper", "ping_nated_only", 1) > modparam("nathelper", "sipping_bflag", 7) > modparam("nathelper", "sipping_from", "sip:pinger@riki.ru") > modparam("registrar|nathelper", "received_avp", "$avp(i:80)") > > > Maybe wrong with sipping_from address. > > [root@v kamailio]# cat /usr/local/etc/kamailio/kamailio.cfg | grep > riki.ru > alias=sip.riki.ru:5060 > alias=sip.riki.ru:5070 > modparam("presence", "server_address", "sip:sip.riki.ru:5060") > modparam("nathelper", "sipping_from", "sip:pinger@riki.ru") > > well it is not a server name. but! it is local in database domains, > and aliased. Changing to pinger@server IP... > > U 195.167.152.55:5060 -> 77.37.164.119:32788 > OPTIONS sip:77.37.164.119:32788 SIP/2.0. > Via: SIP/2.0/UDP 195.167.152.55:5060;branch=0. > From: sip:pinger@195.167.152.55;tag=7b7af265. > To: sip:77.37.164.119:32788. > Call-ID: f2e08d27-ed2df483-8210ae1(a)195.167.152.55. > CSeq: 1 OPTIONS. > Content-Length: 0. > . > > # > U 77.37.164.119:32788 -> 195.167.152.55:5060 > SIP/2.0 200 OK. > Via: SIP/2.0/UDP 195.167.152.55:5060;branch=0. > Contact: <sip:192.168.0.102:32788>. > To: <sip:77.37.164.119:32788>;tag=864a9e4d. > From: <sip:pinger@195.167.152.55>;tag=7b7af265. > Call-ID: f2e08d27-ed2df483-8210ae1(a)195.167.152.55. > CSeq: 1 OPTIONS. > Accept: application/sdp. > Accept-Language: en. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO. > User-Agent: X-Lite release 1103k stamp 53621. > Content-Length: 0. > . > > Nov 26 15:42:19 v /usr/local/sbin/kamailio[29793]: ERROR: <core> > [forward.c:695]: ERROR: forward_reply: no 2nd via found in reply > > > > > Klaus Darilion wrote: >> Never saw this yet. IIRC correctly, the responses should be >> consumed by nathelper module before entering the script. >> >> which version are you using? >> >> klaus >> >> Andres Moya schrieb: >>> Hi. >>> >>> nathelper sending empty OPTIONS messages to clients. It have only >>> one VIA, server's IP address(195.167.152.55). Then it got reply i >>> have: >>> U 195.167.152.55:5060 -> 81.195.165.250:5060 >>> OPTIONS sip:81.195.165.250:5060 SIP/2.0..Via: SIP/2.0/UDP >>> 195.167.152.55:5060;branch=0..From: >>> sip:pinger@riki.ru;tag=e64c73d5..To: >>> sip:81.195.165.250:5060..Call-ID: >>> 680bed34-d2e5c741-0eff517(a)195.167.152 >>> .55..CSeq: 1 OPTIONS..Content-Length: 0.... >>> # >>> U 81.195.165.250:5060 -> 195.167.152.55:5060 >>> SIP/2.0 200 OK..Via: SIP/2.0/UDP >>> 195.167.152.55:5060;branch=0..Contact: <sip:10.0.52.103:5060>..To: >>> <sip:81.195.165.250:5060>;tag=021c6509..From: >>> <sip:pinger@riki.ru>;tag=e64c73d5..Call-ID: 680bed34-d2e >>> 5c741-0eff517@195.167.152.55..CSeq: 1 OPTIONS..Accept: >>> application/sdp, application/sdp..Accept-Language: en..Allow: >>> INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, >>> SUBSCRIBE..User-Agen >>> t: Zoiper rev.5324..Allow-Events: presence..Content-Length: 0.... >>> Nov 25 23:59:26 v /usr/local/sbin/kamailio[9697]: ERROR: <core> >>> [forward.c:695]: ERROR: forward_reply: no 2nd via found in reply >>> # >>> U 195.167.152.55:5070 -> 86.154.150.209:5060 >>> OPTIONS sip:86.154.150.209:5060 SIP/2.0..Via: SIP/2.0/UDP >>> 195.167.152.55:5070;branch=0..From: >>> sip:pinger@riki.ru;tag=f64c73d5..To: >>> sip:86.154.150.209:5060..Call-ID: >>> 680bed34-e2e5c741-7eff517(a)195.167.152 >>> .55..CSeq: 1 OPTIONS..Content-Length: 0.... >>> # >>> U 86.154.150.209:5060 -> 195.167.152.55:5070 >>> SIP/2.0 404 Not Found..Via: SIP/2.0/UDP >>> 195.167.152.55:5070;branch=0..To: >>> <sip:86.154.150.209>;tag=931uruqh0thc6crbneub..From: >>> <sip:pinger@riki.ru>;tag=f64c73d5..Call-ID: >>> 680bed34-e2e5c741-7eff517(a)195.1 >>> 67.152.55..CSeq: 1 OPTIONS..Content-Length: 0.... >>> Nov 25 23:59:33 v /usr/local/sbin/kamailio[9698]: ERROR: <core> >>> [forward.c:695]: ERROR: forward_reply: no 2nd via found in reply >>> >>> Reply should be consumed by nathelper? or i should eat it >>> somewhere? i can't do so in request route. and i can't use reply >>> route because i can't set t_on_reply, it is not my request. There >>> should be easy way... tired get ERROR: forward_reply: no 2nd via >>> found in reply >>> >>> thanks >>> >>> _______________________________________________ >>> sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users