Hi sorry,
I forget to give my openser.cfg, there is one more point if i am using STUN server in our linksys device the call goes normal for long time till user finish the call. It seems something wrong in NAT configuration.
# # sample config file to be used with nathelper/rtpproxy #
#
# ----------- global configuration parameters ------------------------
debug=7 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E)
/* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) listen=212.XXX.XXX.XXX:5064 #port=5064 children=4
disable_dns_blacklist = yes
# --- module loading
mpath="/usr/local/lib/openser/modules/"
loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "nathelper.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
modparam("usrloc", "db_mode", 2) modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("usrloc|auth_db","db_url","mysql://proxy:MoHaKa21@192.168.1.50/emafone")
# -- usrloc params --
modparam("usrloc", "nat_bflag", 6)
# -- registrar params -- modparam("registrar|nathelper", "received_avp", "$avp(i:42)")
# -- auth params --
# -- rr params -- modparam("rr", "enable_full_lr", 1)
# -- nathelper
modparam("nathelper", "natping_interval", 0) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("nathelper", "rtpproxy_disable", 0) modparam("nathelper", "rtpproxy_disable_tout", 60) modparam("nathelper", "rtpproxy_tout", 1) modparam("nathelper", "rtpproxy_retr", 5) modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "received_avp", "$avp(i:801)")
#modparam("nathelper", "rtpproxy_sock", "udp:212.100.235.229:22222") #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@openser.org")
# --- main routing logic route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; };
# NAT detection route(2);
if (!method=="REGISTER") record_route();
if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); route(1); };
if (!uri==myself) { #append_hf("P-hint: outbound\r\n"); route(1); };
if (uri==myself) { if (method=="REGISTER") { if (!www_authorize("212.XXX.XXX.XXX", "subscriber")) { www_challenge("212.XXX.XXX.XXX", "0"); exit; };
if (isflagset(5)) { setbflag(6); # if you want OPTIONS natpings uncomment next # setbflag(7); }; save("location"); exit; };
#########PSTTN CALL #############################################
if (uri=~"sip:00[1-9][0-9]+@.*") { strip(2); rewritehostport("212.XXX.XXX.XXX:5060"); route(1); exit;
};
###################################################################
if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); };
route(1); }
route[1] { if (subst_uri('/(sip:.*);nat=yes/\1/')){ setbflag(6); };
if (isflagset(5)||isbflagset(6)) { route(3); }
if (!t_relay()) { sl_reply_error(); }; exit; }
route[2]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(6); }; }
route[3] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy(); t_on_failure("1");
};
if (isflagset(5)) search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); t_on_reply("1"); }
failure_route[1] { if (isbflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } }
onreply_route[1] { if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
if (isbflagset(6)) { fix_nated_contact(); } exit; }
Regards, www.Go4Calls.Com VoIP Forums
From: go4calls@hotmail.com To: users@lists.openser.org; users@openser.org Subject: Calls disconnect automatically Date: Sun, 20 Jan 2008 18:01:48 +0800
Hi Friends,
I start getting one problem, the calls disconnect automatically in 30 and 32 sec. I am using openser + rtpproxy before with the same openser.cfg it was running smoothly and once traffic increased this problem appeared.
Could you please help me to solve this issue because i put openser in production and now no one can make long call.
Regards, www.Go4Calls.Com VoIP Forums Express yourself instantly with MSN Messenger! MSN Messenger
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
El Domingo, 20 de Enero de 2008, VoIP Forums www.Go4Calls.com escribió:
modparam("nathelper", "natping_interval", 0) modparam("nathelper", "ping_nated_only", 1)
Does do nothing. If you set "ping_nated_only" but dissable "natping_interval" then your NATted contacts will not receive a keepalive ping.
And 30-32 seconds is typically the UDP conexion time a common router mantains open the UDP port for incoming replies.
So firt, try setting correctly parameters: modparam("nathelper", "natping_interval", 20) modparam("nathelper", "ping_nated_only", 1)
Hi,
i tired with the following configuration but still result is same. calls disconnect in 30 - 32 sec
modparam("nathelper", "natping_interval", 20) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("nathelper", "rtpproxy_disable", 0) modparam("nathelper", "rtpproxy_disable_tout", 60) modparam("nathelper", "rtpproxy_tout", 1) modparam("nathelper", "rtpproxy_retr", 5) modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "received_avp", "$avp(i:801)")
Please advise me if i need more modification?
Regards, www.Go4Calls.Com VoIP Forums
From: ibc@aliax.net To: users@lists.openser.org Date: Sun, 20 Jan 2008 17:39:39 +0100 Subject: Re: [OpenSER-Users] Calls disconnect automatically
El Domingo, 20 de Enero de 2008, VoIP Forums www.Go4Calls.com escribió:
modparam("nathelper", "natping_interval", 0) modparam("nathelper", "ping_nated_only", 1)
Does do nothing. If you set "ping_nated_only" but dissable "natping_interval" then your NATted contacts will not receive a keepalive ping.
And 30-32 seconds is typically the UDP conexion time a common router mantains open the UDP port for incoming replies.
So firt, try setting correctly parameters: modparam("nathelper", "natping_interval", 20) modparam("nathelper", "ping_nated_only", 1)
-- Iñaki Baz Castillo
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
El Lunes, 21 de Enero de 2008, VoIP Forums www.Go4Calls.com escribió:
i tired with the following configuration but still result is same. calls disconnect in 30 - 32 sec
modparam("nathelper", "natping_interval", 20) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("nathelper", "rtpproxy_disable", 0) modparam("nathelper", "rtpproxy_disable_tout", 60) modparam("nathelper", "rtpproxy_tout", 1) modparam("nathelper", "rtpproxy_retr", 5) modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "received_avp", "$avp(i:801)")
Please advise me if i need more modification?
Which kind of calls are disconnected after 30 seconds? PSTN calls or user to user call?
In any case, you could do a "tcpdump -n port UAC_RTP_PORT" in a PC using a softphone that uses UAC_RTP_PORT for audio. Call to PSTN (or other user) from this softphone and monitorize with tcpdump when the audio is disconnected.
Some gateways (as Asterisk) disconnect a call by default if they don't receive RTP during 30 seconds.
Since I don't know which kind of gateway you use I don't know if it uses Session Timers as call monitorization way, so if your router blocks the port after 30 seconds, then the periodic ire-INVITE or UPDATE from gateway to UAC will not arrive so they won't be replied with "200 OK", and gateway will discconect the call. To test this, do a "ngrep" in a computer using a softphone registered behind NAT (no STUN). After REGISTER you should receive a OPTIONS from proxy as keep alive.
Another possible problem is the existence of painful ALG routers, have you tested if your router implements SIP ALG?
The problem is only with PSTN call.
I tried to send call to the three gateway Teles, SIP-HIT and Asterisk but all disconnect calls in that priticular seconds. The thinng is i cannot understand if i am using STUN in Linksyspap2 the call goes normal and without STUN it disconnect. So the problem is gateway side or Openser?
our router is not implimented with SIP, and there is one more strange thing, In some callshop the same rtptproxy working well and going cal for long duration but i have 3 callshop which facing this problem. the configuration and others are same as other working devices.
Regards, www.Go4Calls.Com VoIP Forums > From: ibc@aliax.net> To: users@lists.openser.org> Date: Mon, 21 Jan 2008 00:19:12 +0100> Subject: Re: [OpenSER-Users] Calls disconnect automatically> > El Lunes, 21 de Enero de 2008, VoIP Forums www.Go4Calls.com escribió:> > i tired with the following configuration but still result is same. calls> > disconnect in 30 - 32 sec> >> > modparam("nathelper", "natping_interval", 20)> > modparam("nathelper", "ping_nated_only", 1)> > modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock")> > modparam("nathelper", "rtpproxy_disable", 0)> > modparam("nathelper", "rtpproxy_disable_tout", 60)> > modparam("nathelper", "rtpproxy_tout", 1)> > modparam("nathelper", "rtpproxy_retr", 5)> > modparam("nathelper", "sipping_method", "OPTIONS")> > modparam("nathelper", "received_avp", "$avp(i:801)")> >> > Please advise me if i need more modification?> > > Which kind of calls are disconnected after 30 seconds? PSTN calls or user to > user call?> > In any case, you could do a "tcpdump -n port UAC_RTP_PORT" in a PC using a > softphone that uses UAC_RTP_PORT for audio. Call to PSTN (or other user) from > this softphone and monitorize with tcpdump when the audio is disconnected.> > Some gateways (as Asterisk) disconnect a call by default if they don't receive > RTP during 30 seconds.> > Since I don't know which kind of gateway you use I don't know if it uses > Session Timers as call monitorization way, so if your router blocks the port > after 30 seconds, then the periodic ire-INVITE or UPDATE from gateway to UAC > will not arrive so they won't be replied with "200 OK", and gateway will > discconect the call.> To test this, do a "ngrep" in a computer using a softphone registered behind > NAT (no STUN). After REGISTER you should receive a OPTIONS from proxy as keep > alive.> > Another possible problem is the existence of painful ALG routers, have you > tested if your router implements SIP ALG?> > > > > -- > Iñaki Baz Castillo> > _______________________________________________> Users mailing list> Users@lists.openser.org> http://lists.openser.org/cgi-bin/mailman/listinfo/users _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
On Monday 21 January 2008 00:52:24 VoIP Forums www.Go4Calls.com wrote:
The problem is only with PSTN call.
I tried to send call to the three gateway Teles, SIP-HIT and Asterisk but all disconnect calls in that priticular seconds. The thinng is i cannot understand if i am using STUN in Linksyspap2 the call goes normal and without STUN it disconnect. So the problem is gateway side or Openser?
our router is not implimented with SIP, and there is one more strange thing, In some callshop the same rtptproxy working well and going cal for long duration but i have 3 callshop which facing this problem. the configuration and others are same as other working devices.
Try the "tcpdump" I suggested in client side, you will discover when audio is cut.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I suppose you have a trouble with ACK paquets, I think that's why you've been disconnected after 30s... There are some clients that shutdown the call after not receiving ACK paquet after their 200OK.
As Iñaki said use tcpdump / or ngrep -W byline port 5060
to see what's wrong
Have a nice day!
Iñaki Baz Castillo a écrit :
On Monday 21 January 2008 00:52:24 VoIP Forums www.Go4Calls.com wrote:
The problem is only with PSTN call.
I tried to send call to the three gateway Teles, SIP-HIT and Asterisk but all disconnect calls in that priticular seconds. The thinng is i cannot understand if i am using STUN in Linksyspap2 the call goes normal and without STUN it disconnect. So the problem is gateway side or Openser?
our router is not implimented with SIP, and there is one more strange thing, In some callshop the same rtptproxy working well and going cal for long duration but i have 3 callshop which facing this problem. the configuration and others are same as other working devices.
Try the "tcpdump" I suggested in client side, you will discover when
audio is
cut.
Hi All,
I have captured the packet when the device sent ICMP to the media gateway and the reply comming "DESTINATION PORT UNREACHABE" that time device send BYE message to Openser. I am not so expert to analysis the packet if you could have a look to the following URL i put already the shot of packet.
http://www.emafone.net/packet.JPG
Regards, www.Go4Calls.Com VoIP Forums
Date: Mon, 21 Jan 2008 10:05:13 +0100 From: lftsy@free.fr To: ibc@in.ilimit.es CC: users@lists.openser.org Subject: Re: [OpenSER-Users] Calls disconnect automatically
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I suppose you have a trouble with ACK paquets, I think that's why you've been disconnected after 30s... There are some clients that shutdown the call after not receiving ACK paquet after their 200OK.
As Iñaki said use tcpdump / or ngrep -W byline port 5060
to see what's wrong
Have a nice day!
Iñaki Baz Castillo a écrit :
On Monday 21 January 2008 00:52:24 VoIP Forums www.Go4Calls.com wrote:
The problem is only with PSTN call.
I tried to send call to the three gateway Teles, SIP-HIT and Asterisk but all disconnect calls in that priticular seconds. The thinng is i cannot understand if i am using STUN in Linksyspap2 the call goes normal and without STUN it disconnect. So the problem is gateway side or Openser?
our router is not implimented with SIP, and there is one more strange thing, In some callshop the same rtptproxy working well and going cal for long duration but i have 3 callshop which facing this problem. the configuration and others are same as other working devices.
Try the "tcpdump" I suggested in client side, you will discover when
audio is
cut.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHlGBIN4+o+2LtdFwRAq4rAJ4l6N2JVEuPQB6FYkfyOsqcQlPbXwCeIuO3 9pbYaQyUTLh6M+6TSjM5kH0= =haPm -----END PGP SIGNATURE-----
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
On Monday 21 January 2008 12:27:07 VoIP Forums www.Go4Calls.com wrote:
Hi All,
I have captured the packet when the device sent ICMP to the media gateway and the reply comming "DESTINATION PORT UNREACHABE" that time device send BYE message to Openser. I am not so expert to analysis the packet if you could have a look to the following URL i put already the shot of packet.
Sorry, but that trace says nothing to me.
In a PC with Linux install "ngrep", open a softphone with no STUN configured and make a call to PSTN. But first run this:
ngrep -d any -P ' ' -W byline -T -t "" udp port 5060
And paste it.
VoIP Forums www.Go4Calls.com wrote:
Hi,
i tired with the following configuration but still result is same. calls disconnect in 30 - 32 sec
30 seconds is default timeout for ISDN signaling. If ISDN gateway sends SETUP but not receive CONNECT during this timeout it disconnect call.
So I think that problem in signaling path: -- GW don't receive ISDN message from POTS -- or SIP ACK routed incorrectly and GW don't receive it