Also, this is how I am running the rtpproxy: 23414 ? Ss 0:00 /usr/local/bin/rtpproxy -s udp:184.106.168.144 22332 -u root root -p /var/run/rtpproxy/rtpproxy.pid -F -l 184.106.168.144
And here is the nathelper config for both opensips and b2b: modparam("nathelper", "rtpproxy_sock", "udp:184.106.168.144:22332") modparam("nathelper", "force_socket", "udp:184.106.168.144:22332") modparam("nathelper", "rtpproxy_retr", 2) modparam("nathelper", "received_avp", "$avp(i:42)") modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_autobridge", 1) modparam("nathelper", "sipping_bflag", 8) modparam("nathelper", "sipping_from", "sip:pin...@platform.worldtalkinc.com ") modparam("nathelper", "sipping_method", "INFO") Does anything of that seems suspicious to you ? On 11 February 2011 16:42, Kamen Petrov <kamen.pet...@gmail.com> wrote: > Anca: > > *> There was a problem with the db schema for the b2b_logic table - lots > of wrong NOT NULL constraints there. I have just fixed it. Please take the > new schema from svn and replace the table.* > -- Seems to be fine now, thank you. > > > *> Are you using the newest version of rtpproxy?* > -- I am running 1.2.0 right now. I have been running 1.2.1 before but with > the same success. I moved back to 1.2.0 mainly because the debug does not > work with 1.2.1 and I can't see what happens in the background. > > Ovidiu: > > *> Then please remove the old core file and make sure that you have the > latest source on both servers.* > -- I removed the old core file, tested a new call and got into the same > issue (as described before: segfault on the rtpproxy). A new core haven't > been generated. Both servers uses the same opensips setup with different > config files (loaded with: "*-f <file>*") > > > On theory, I should have rtpproxy_offer on the "route" and rtpproxy_answer > on the "onreply_route" right ? Since that is the case when I have segfault > on the rtpproxy. > If I remove the rtpproxy_answer form the onreply_route, there is no > segfault, but there is no audio as well. > > Please advise. > Your help guys is highly appreciated ! > -------------------------------------------- > Kamen Petrov > > > > On 11 February 2011 16:30, Ovidiu Sas <o...@voipembedded.com> wrote: > >> Then please remove the old core file and make sure that you have the >> latest source on both servers. >> >> On Fri, Feb 11, 2011 at 9:27 AM, Kamen Petrov <kamen.pet...@gmail.com> >> wrote: >> > The last core i have is: >> > -rw------- 1 root root 43188224 Feb 10 11:49 /core >> > >> > I did the attached tests 1 or 2 hours ago and the system time now is >> "Fri >> > Feb 11 14:29:14 UTC 2011". >> > >> > I guess there is no new core :( >> > >> > >> > On 11 February 2011 16:23, Ovidiu Sas <o...@voipembedded.com> wrote: >> >> >> >> Please get a gdb trace from the core file. >> >> >> >> Thanks, >> >> Ovidiu >> >> >> >> On Fri, Feb 11, 2011 at 8:31 AM, Kamen Petrov <kamen.pet...@gmail.com> >> >> wrote: >> >> >> Ok guys, >> >> >> >> >> >> Few issues still (after updating from trunk). >> >> >> >> >> >> As suggested, I removed the engage_rtp_proxy from the b2b opensips >> >> >> instance. >> >> >> >> >> >> I noticed the following debug from the opensips: >> >> >> Feb 11 12:49:06 sms /root/opensips-1.6.4-tls/opensips[21621]: >> >> >> ERROR:db_postgres:db_postgres_store_result: 0x7b9360 - invalid >> query, >> >> >> execution aborted >> >> >> Feb 11 12:49:06 sms /root/opensips-1.6.4-tls/opensips[21621]: >> >> >> ERROR:db_postgres:db_postgres_store_result: 0x7b9360: >> PGRES_FATAL_ERROR >> >> >> Feb 11 12:49:06 sms /root/opensips-1.6.4-tls/opensips[21621]: >> >> >> ERROR:db_postgres:db_postgres_store_result: 0x7b9360: ERROR: null >> >> >> value in >> >> >> column "e3_sid" violates not-null constraint#012 >> >> >> >> >> >> Looking on the postgres log, here is the failed SQL statement: >> >> >> 2011-02-11 12:49:06 UTC ERROR: null value in column "e3_sid" >> violates >> >> >> not-null constraint >> >> >> 2011-02-11 12:49:06 UTC STATEMENT: insert into b2b_logic >> >> >> >> >> >> >> (si_key,scenario,sparam0,sparam1,sparam2,sparam3,sparam4,sdp,sstate,next_sstate,e1_type,e1_sid,e1_to,e1_from,e1_key,e2_type,e2_sid,e2_to,e2_from,e2_key >> >> >> ) values >> >> >> >> >> >> ('545.0','','','','','','','',-3,0,0,'',' >> sip:17864776626@190.124.220.12:5060','sip:359883327749@69.25.128.234 >> ','B2B.608.661',1,'','sip:17864776626@190.124.220.12:5060',' >> sip:359883327749@69.25.128.234','B2B.545.4207959') >> >> >> >> >> >> I am using the default b2b postgres tables. >> >> >> >> >> >> So next, I have the following config on the rtpproxy opensips (not >> the >> >> >> b2b >> >> >> one): >> >> >> ##################################################### >> >> >> route[1] { >> >> >> fix_nated_contact(); >> >> >> >> >> >> if (is_method("INVITE")) { >> >> >> rewritehostport("184.106.168.144:5061"); >> >> >> if (rtpproxy_offer("eo","184.106.168.144")) >> >> >> t_on_reply("1"); >> >> >> } >> >> >> else if (method == "BYE" || method == "CANCEL") { >> >> >> unforce_rtp_proxy(); >> >> >> } >> >> >> .. >> >> >> } >> >> >> >> >> >> onreply_route[1] { >> >> >> if (!(status=~"183" || status=~"200")) { >> >> >> drop; >> >> >> } >> >> >> >> >> >> rtpproxy_answer("FA"); >> >> >> >> >> >> } >> >> >> ##################################################### >> >> >> >> >> >> As result, when I initiate a call, I get the following on the >> syslog: >> >> >> >> >> >> Feb 11 12:52:48 sms /root/opensips-1.6.4-tls/opensips[21754]: >> >> >> INFO:nathelper:rtpp_test: rtp proxy <udp:184.106.168.144:22332> >> found, >> >> >> support for it enabled >> >> >> Feb 11 12:52:48 sms /root/opensips-1.6.4-tls/opensips[21753]: >> >> >> INFO:nathelper:rtpp_test: rtp proxy <udp:184.106.168.144:22332> >> found, >> >> >> support for it enabled >> >> >> .... >> >> >> Feb 11 12:53:05 sms /root/opensips-1.6.4-tls/opensips[21746]: >> >> >> DBG:nathelper:force_rtp_proxy: Forcing body:#012[v=0#015#012o=- >> >> >> 229796569696953 1 IN IP4 190.124.220.12#015#012s=-#015#012c=IN IP4 >> >> >> 190.124.220.12 >> >> >> #015#012t=0 0#015#012m=audio 18338 RTP/AVP 0 101#015#012a=rtpmap:0 >> >> >> PCMU/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 >> >> >> 0-16] >> >> >> Feb 11 12:53:05 sms /root/opensips-1.6.4-tls/opensips[21746]: >> >> >> DBG:core:parse_to: display={011359883327749}, >> >> >> ruri={sip:359883327749@69.25.128.233} >> >> >> Feb 11 12:53:05 sms rtpproxy[21731]: DBUG:handle_command: received >> >> >> command >> >> >> "21746_6 LA 4512c49c3cd0db1b410744fe0ced15bf@69.25.128.233 >> >> >> 190.124.220.12 >> >> >> 18338 as612bc040;1 B2B.599.537;1" >> >> >> Feb 11 12:53:05 sms kernel: [7145167.526106] rtpproxy[21731]: >> segfault >> >> >> at >> >> >> 0 ip 00000000004053e9 sp 00007fff71948b00 error 4 in >> >> >> rtpproxy[400000+e000] >> >> >> .... >> >> >> .... >> >> >> Feb 11 12:53:05 sms /root/opensips-1.6.4-tls/opensips[21748]: >> >> >> DBG:tm:t_reply_matching: hash 23820 label 1987919557 branch 0 >> >> >> Feb 11 12:53:05 sms /root/opensips-1.6.4-tls/opensips[21748]: >> >> >> DBG:tm:t_reply_matching: REF_UNSAFE:[0x7fc0f89b4f10] after is 2 >> >> >> Feb 11 12:53:05 sms /root/opensips-1.6.4-tls/opensips[21748]: >> >> >> DBG:tm:t_reply_matching: reply matched (T=0x7fc0f89b4f10)! >> >> >> Feb 11 12:53:05 sms /root/opensips-1.6.4-tls/opensips[21748]: >> >> >> DBG:tm:t_check: end=0x7fc0f89b4f10 >> >> >> Feb 11 12:53:05 sms /root/opensips-1.6.4-tls/opensips[21748]: >> >> >> DBG:tm:reply_received: org. status uas=100, uac[0]=0 local=0 >> >> >> is_invite=1) >> >> >> Feb 11 12:53:06 sms /root/opensips-1.6.4-tls/opensips[21746]: >> >> >> ERROR:nathelper:send_rtpp_command: timeout waiting reply from a RTP >> >> >> proxy >> >> >> Feb 11 12:53:06 sms /root/opensips-1.6.4-tls/opensips[21746]: >> >> >> ERROR:nathelper:send_rtpp_command: proxy <udp:184.106.168.144:22332 >> > >> >> >> does >> >> >> not respond, disable it >> >> >> Feb 11 12:53:06 sms /root/opensips-1.6.4-tls/opensips[21746]: >> >> >> ERROR:nathelper:send_rtpp_command: can't send command to a RTP proxy >> >> >> Connection refused >> >> >> ........................ repeating over 100 >> >> >> times................................ >> >> >> >> >> >> Obviously the RTPproxy dies. >> >> >> What I noticed is, when i remove >> >> >> rtpproxy_answer("FA"); >> >> >> from the onreply_route, the RTPproxy does not dies. >> >> >> >> >> >> Any ideas what I am doing wrong ? >> >> >> >> >> >> Thank you. >> >> >> -- Kamen >> >> > >> >> > _______________________________________________ >> >> > Users mailing list >> >> > Users@lists.opensips.org >> >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> Users@lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users@lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users