[OpenSIPS-Users] Topology hiding - B2B_LOGIC
Kamen Petrov
kamen.petrov at gmail.com
Fri Feb 11 15:44:14 CET 2011
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:pinger at 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.petrov at 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 <osas at 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.petrov at 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 <osas at 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.petrov at 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 at 190.124.220.12:5060','sip:359883327749 at 69.25.128.234
>> ','B2B.608.661',1,'','sip:17864776626 at 190.124.220.12:5060','
>> sip:359883327749 at 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 at 69.25.128.233}
>> >> >> Feb 11 12:53:05 sms rtpproxy[21731]: DBUG:handle_command: received
>> >> >> command
>> >> >> "21746_6 LA 4512c49c3cd0db1b410744fe0ced15bf at 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 at lists.opensips.org
>> >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> Users mailing list
>> >> Users at lists.opensips.org
>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>> >
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110211/fb07f1be/attachment.htm>
More information about the Users
mailing list