From bogdan at opensips.org Tue Nov 1 12:10:45 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 1 Nov 2016 13:10:45 +0200 Subject: [OpenSIPS-Users] Routing in opensips In-Reply-To: References: <64ca0729-1829-3ad8-9548-8b815f6d01b8@opensips.org> <316e9a04-7742-ab9e-329d-e0615cc64179@opensips.org> <5bf7c4cc-285a-2a7a-f5fe-62cbc4601e1d@opensips.org> Message-ID: <9a3d5834-6396-ca9e-898b-21e31cd8b661@opensips.org> Hi Eric, The outgoing INVITE request looks ok - the RR and VIA headers carry the public IP of your OpenSIPS. You should get back some reply. Not sure how valid is that test server, but you can try sending to sip:opensips.org:5060 ( or 78.46.64.50:5060 ) - this sip server is definitely up . BTW, the SDP you send out is bogus as it contain only private IPs, so the other end point will not be able to send you ant RTP back. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 31.10.2016 14:21, Eric Freeman wrote: > > Please attached pcap file. Is this what you need? > > > Eric Freeman > > Technical Director/NA for TBWA\Chiat\Day > > TBWA\Chiat\Day New York > 488 Madison Ave. > New York NY 10022 > United States of America > Tel: +12128041324 > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *Sent:* Monday, October 31, 2016 6:36:18 AM > *To:* Eric Freeman; OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] Routing in opensips > Hi Eric, > > What I'm asking here is to post the full INVITE packet from your > opensips server to the external host - I Want to to check the SIP > headers and the SDP. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 25.10.2016 16:38, Eric Freeman wrote: >> >> The opensips server is 10.88.23.13 the video conference server is >> 10.89.71.12. The IP I am trying to connect to 199.48.152.152, I >> believe is a valid host. I found it on a test SIP site on the Internet >> >> >> 10:02:59.346842 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: INVITE >> sip:111 at 199.48.152.152 SIP/2.0 >> >> 10:02:59.351769 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 >> 100 Giving a try >> >> 10:02:59.352232 IP 10.88.23.13.sip > >> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >> sip:111 at 199.48.152.152 SIP/2.0 >> >> 10:02:59.352238 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >> >> 10:02:59.871480 IP 10.88.23.13.sip > >> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >> sip:111 at 199.48.152.152 SIP/2.0 >> >> 10:02:59.871489 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >> >> 10:03:00.874461 IP 10.88.23.13.sip > >> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >> sip:111 at 199.48.152.152 SIP/2.0 >> >> 10:03:00.874483 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >> >> 10:03:02.877430 IP 10.88.23.13.sip > >> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >> sip:111 at 199.48.152.152 SIP/2.0 >> >> 10:03:02.877440 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >> >> 10:03:03.930697 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 >> 408 Request Timeout >> >> 10:03:03.958682 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: ACK >> sip:111 at 199.48.152.152 SIP/2.0 >> >> >> Eric Freeman >> >> Technical Director/NA for TBWA\Chiat\Day >> >> TBWA\Chiat\Day New York >> 488 Madison Ave. >> New York NY 10022 >> United States of America >> Tel: +12128041324 >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* Tuesday, October 25, 2016 7:04:15 AM >> *To:* Eric Freeman; OpenSIPS users mailling list >> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >> Hi Eric, >> >> By traffic (coming back), you understand RTP or SIP traffic ? >> >> Could you post the INVITE message getting out of your server ? I >> suspect the INVITE has in SDP a private IP that is not reachable for >> the end device (where the call is sent). >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 21.10.2016 18:46, Eric Freeman wrote: >>> >>> Yes, I see Request INVITE going to the device I am calling. I do not >>> see any traffic coming back. I am following up with my Firewall team. >>> >>> My Firewall team suggested I might need to change the RTP ports to >>> use UDP 2326-2485. Where do I change/check these settings on the >>> OpenSIPs server to see if I have the traffic going out those ports. >>> >>> >>> Thanks, >>> >>> >>> Eric Freeman >>> >>> Technical Director/NA for TBWA\Chiat\Day >>> >>> TBWA\Chiat\Day New York >>> 488 Madison Ave. >>> New York NY 10022 >>> United States of America >>> Tel: +12128041324 >>> ------------------------------------------------------------------------ >>> *From:* Bogdan-Andrei Iancu >>> *Sent:* Monday, October 3, 2016 4:44:26 AM >>> *To:* Eric Freeman; OpenSIPS users mailling list >>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>> Hi Eric, >>> >>> Not the OpenSIPs logs I'm looking for, but the actual SIP packet at >>> network level (use ngrep or tcpdump) for the INVITE leaving your >>> OpenSIPS. >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 30.09.2016 16:52, Eric Freeman wrote: >>>> >>>> Hopefully this is the relevant information you need from the log. I >>>> am trying to call 111 at 199.48.152.152. The IP of the opensips server >>>> si 10.88.23.10 and has a public IP of 204.17.231.3. The IP address >>>> of the video conference server is 10.89.71.12. >>>> >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_msg: SIP Request: >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_msg: method: >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_msg: uri: >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_msg: version: >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_headers: flags=2 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_to: end of header reached, state=10 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_to: display={}, ruri={sip:111 at 199.48.152.152} >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:get_hdr_field: [26]; uri=[sip:111 at 199.48.152.152] >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:get_hdr_field: to body [#015#012] >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:get_hdr_field: cseq : <1> >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_via_param: found param type 235, = ; >>>> state=6 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_via_param: found param type 232, = >>>> ; state=16 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_via: end of header reached, state=5 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_headers: via found, flags=2 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_headers: this is the first via >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:receive_msg: After parse_msg... >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:receive_msg: preparing to run routing scripts... >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_headers: flags=100 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:maxfwd:is_maxfwd_present: value = 70 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:uri:has_totag: no totag >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_headers: flags=78 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:tm:t_lookup_request: start searching: hash=25578, isACK=0 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:tm:matching_3261: RFC3261 transaction matching failed >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:tm:t_lookup_request: no transaction found >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_to_param: >>>> tag=2c770a98-c47590a-13c4-45026-57ed3cdd-1bac9941-57ed3cdd >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_to: end of header reached, state=29 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_to: display={"Conference Room"}, >>>> ruri={sip:LifeSize at 10.88.23.13;transport=UDP} >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:grep_sock_info: checking if host==us: 11==11 && >>>> [10.88.23.13] == [10.88.23.13] >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:grep_sock_info: checking if port 5060 matches port 5060 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_headers: flags=200 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:get_hdr_field: content_length=1759 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:get_hdr_field: found end of header >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:rr:find_first_route: No Route headers found >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:grep_sock_info: checking if host==us: 14==11 && >>>> [199.48.152.152] == [10.88.23.13] >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:grep_sock_info: checking if port 5060 matches port 5060 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:grep_sock_info: checking if host==us: 14==11 && >>>> [199.48.152.152] == [10.88.23.13] >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:grep_sock_info: checking if port 5060 matches port 5060 >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:check_self: host != me >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:parse_headers: flags=ffffffffffffffff >>>> >>>> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: >>>> DBG:core:do_action_set_adv_address: setting adv address = >>>> [204.17.231.3] >>>> >>>> >>>> Eric Freeman >>>> >>>> Technical Director/NA for TBWA\Chiat\Day >>>> >>>> TBWA\Chiat\Day New York >>>> 488 Madison Ave. >>>> New York NY 10022 >>>> United States of America >>>> Tel: +12128041324 >>>> ------------------------------------------------------------------------ >>>> *From:* Bogdan-Andrei Iancu >>>> *Sent:* Friday, September 30, 2016 4:32:01 AM >>>> *To:* Eric Freeman; OpenSIPS users mailling list >>>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>>> Hi Eric, >>>> >>>> As a first step, can you confirm that the INVITE (sent out by your >>>> OPenSIPS to the internet) has in VIA hdr the public IP of your NAT ? >>>> >>>> Best regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 29.09.2016 19:14, Eric Freeman wrote: >>>>> >>>>> It is still not working, I added my public IP as requested. I do >>>>> not have any gateways or anything set up. Do I need to add anything? >>>>> >>>>> I added this to the route statement: >>>>> >>>>> >>>>> if (!uri==myself) { >>>>> >>>>> append_hf("P-hint: outbound\r\n"); >>>>> >>>>> set_advertised_address("XXX.XX.XXX.X"); >>>>> >>>>> route(relay); >>>>> >>>>> >>>>> I am still receiving these errors: >>>>> >>>>> Sep 29 12:10:22 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:rr:find_first_route: No Route >>>>> headers found >>>>> >>>>> Sep 29 12:10:22 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:rr:loose_route: There is no >>>>> Route HF >>>>> >>>>> Sep 29 12:10:22 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=78 >>>>> >>>>> >>>>> >>>>> Eric Freeman >>>>> >>>>> Technical Director/NA for TBWA\Chiat\Day >>>>> >>>>> TBWA\Chiat\Day New York >>>>> 488 Madison Ave. >>>>> New York NY 10022 >>>>> United States of America >>>>> Tel: +12128041324 >>>>> ------------------------------------------------------------------------ >>>>> *From:* Bogdan-Andrei Iancu >>>>> *Sent:* Tuesday, September 20, 2016 8:38:31 AM >>>>> *To:* Eric Freeman; OpenSIPS users mailling list >>>>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>>>> He Eric, >>>>> >>>>> In the script (generated by menuconfig), you have an IF block with : >>>>> append_hf("P-hint: outbound\r\n"); >>>>> >>>>> That block is executed if one of your users is dialing an external >>>>> SIP domain. So, that is the place where the calls will break out >>>>> to public internet. >>>>> >>>>> As your OpenSIPS has a private IP (not routable in internet), you >>>>> need to configure it to advertise the public IP of your NAT via >>>>> the set_advertise_address() - see: >>>>> http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc46 >>>>> >>>>> Put there the public IP of your NAT. Also, be sure you create in >>>>> your router (running the NAT) a port forwarding from the public IP >>>>> port 5060 UDP to the private IP of your OpenSIPS port 5060 UDP. >>>>> >>>>> Best regards, >>> >>> >>> >>> ------------------------------------------------------------------------------- >>> This e-mail is intended only for the named person or entity to which >>> it is addressed and contains valuable business >>> information that is privileged, confidential and/or otherwise >>> protected from disclosure. If you received this e-mail >>> in error, any review, use, dissemination, distribution or copying of >>> this e-mail is strictly prohibited. Please notify us >>> immediately of the error via e-mail to disclaimer at email-abuse.com >>> and please delete the e-mail from your system, >>> retaining no copies in any media. We appreciate your cooperation. >>> -------------------------------------------------------------------disc99999999 >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dani.popa at gmail.com Tue Nov 1 13:36:39 2016 From: dani.popa at gmail.com (Dani Popa) Date: Tue, 1 Nov 2016 14:36:39 +0200 Subject: [OpenSIPS-Users] opensips git revision: 76e9809 crash Message-ID: Hi, I got a crash. Thanks, version: opensips 2.1.1 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. git revision: 76e9809 main.c compiled on 21:32:22 Jul 5 2016 with gcc 4.9.2 #0 0x00007fcf270f5779 in db_mysql_val2bind (v=v at entry=0x7fcf25d30ce0 , binds=binds at entry=0x7fcf28668d08, i=i at entry=15) at val.c:295 #1 0x00007fcf270fbe1a in db_mysql_do_prepared_query (conn=conn at entry=0x7fcf28664e90, v=v at entry=0x7fcf25d30b00 , n=n at entry=17, uv=uv at entry=0x0, un=un at entry=0, query=0x7fcf27315980 ) at dbase.c:676 #2 0x00007fcf27101508 in db_mysql_insert (_h=0x7fcf28664e90, _k=0x7fcf25d32180 , _v=0x7fcf25d30b00 , _n=17) at dbase.c:1265 #3 0x00007fcf25af85fa in acc_db_request (rq=rq at entry=0x7fcf28219f40 , rpl=rpl at entry=0x7fcf286677e0, ins_list=ins_list at entry=0x7fcf25d334d8 , cdr_flag=2) at acc.c:638 #4 0x00007fcf25b0713d in on_missed (code=, reply=0x7fcf286677e0, req=0x7fcf28219f40 , t=) at acc_logic.c:456 #5 tmcb_func (t=, type=, ps=) at acc_logic.c:685 #6 0x00007fcf27ff4326 in run_trans_callbacks (type=type at entry=32, trans=trans at entry=0x7fcf22c7c1b0, req=req at entry=0x7fcf28219f40 , rpl=, code=) at t_hooks.c:209 #7 0x00007fcf27faea86 in run_failure_handlers (t=0x7fcf22c7c1b0) at t_reply.c:569 #8 t_should_relay_response (reply=, cancel_bitmap=, should_relay=, should_store=, branch=, new_code=500, Trans=0x7fcf22c7c1b0) at t_reply.c:911 #9 relay_reply (t=0x7fcf22c7c1b0, p_msg=, branch=, msg_status=500, cancel_bitmap=) at t_reply.c:1125 #10 0x00007fcf27fb2325 in reply_received (p_msg=0x7fcf286677e0) at t_reply.c:1505 #11 0x000000000047b585 in forward_reply (msg=msg at entry=0x7fcf286677e0) at forward.c:517 #12 0x000000000045d9bd in receive_msg ( buf=0x85f540 "SIP/2.0 500 Internal server error\r\nVia: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK7615.63e34a06.0\r\nFrom: \"XXXXXXXXXX\" ;tag=g8t85U635m04N\r\nTo: , rcv_info=rcv_info at entry=0x7ffc8eadc4e0) at receive.c:243 #13 0x00000000005a04c5 in udp_read_req (si=, bytes_read=) at net/proto_udp/proto_udp.c:190 #14 0x000000000058bfbe in handle_io (fm=, fm=, fm=, idx=, event_type=2) at net/net_udp.c:260 #15 io_wait_loop_epoll (h=, t=, repeat=) at net/../io_wait_loop.h:190 #16 udp_rcv_loop (si=si at entry=0x7fcf28641f68) at net/net_udp.c:308 #17 0x000000000058db9c in udp_start_processes (chd_rank=chd_rank at entry=0x84c26c , startup_done=startup_done at entry=0x0) at net/net_udp.c:448 #18 0x000000000041a9d3 in main_loop () at main.c:722 #19 main (argc=, argv=) at main.c:1259 -- Dani Popa -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionutionita at opensips.org Tue Nov 1 16:05:08 2016 From: ionutionita at opensips.org (Ionut Ionita) Date: Tue, 1 Nov 2016 17:05:08 +0200 Subject: [OpenSIPS-Users] opensips git revision: 76e9809 crash In-Reply-To: References: Message-ID: <7a9c0e01-d905-06b2-5ca3-a9def4fd1ca0@opensips.org> Hi, Can you try upgrading to 2.1.4? Commit e49e2e8 could fix this problem. Regards, Ionut Ionita OpenSIPS Developer On 11/01/2016 02:36 PM, Dani Popa wrote: > Hi, > > I got a crash. > > Thanks, > > version: opensips 2.1.1 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > git revision: 76e9809 > main.c compiled on 21:32:22 Jul 5 2016 with gcc 4.9.2 > > #0 0x00007fcf270f5779 in db_mysql_val2bind (v=v at entry=0x7fcf25d30ce0 > , binds=binds at entry=0x7fcf28668d08, i=i at entry=15) at > val.c:295 > #1 0x00007fcf270fbe1a in db_mysql_do_prepared_query > (conn=conn at entry=0x7fcf28664e90, v=v at entry=0x7fcf25d30b00 , > n=n at entry=17, uv=uv at entry=0x0, un=un at entry=0, query=0x7fcf27315980 > ) > at dbase.c:676 > #2 0x00007fcf27101508 in db_mysql_insert (_h=0x7fcf28664e90, > _k=0x7fcf25d32180 , _v=0x7fcf25d30b00 , _n=17) at > dbase.c:1265 > #3 0x00007fcf25af85fa in acc_db_request (rq=rq at entry=0x7fcf28219f40 > , rpl=rpl at entry=0x7fcf286677e0, > ins_list=ins_list at entry=0x7fcf25d334d8 , cdr_flag=2) at > acc.c:638 > #4 0x00007fcf25b0713d in on_missed (code=, > reply=0x7fcf286677e0, req=0x7fcf28219f40 , t= out>) at acc_logic.c:456 > #5 tmcb_func (t=, type=, ps= out>) at acc_logic.c:685 > #6 0x00007fcf27ff4326 in run_trans_callbacks (type=type at entry=32, > trans=trans at entry=0x7fcf22c7c1b0, req=req at entry=0x7fcf28219f40 > , rpl=, code=) at t_hooks.c:209 > #7 0x00007fcf27faea86 in run_failure_handlers (t=0x7fcf22c7c1b0) at > t_reply.c:569 > #8 t_should_relay_response (reply=, > cancel_bitmap=, should_relay=, > should_store=, branch=, new_code=500, > Trans=0x7fcf22c7c1b0) at t_reply.c:911 > #9 relay_reply (t=0x7fcf22c7c1b0, p_msg=, > branch=, msg_status=500, cancel_bitmap=) > at t_reply.c:1125 > #10 0x00007fcf27fb2325 in reply_received (p_msg=0x7fcf286677e0) at > t_reply.c:1505 > #11 0x000000000047b585 in forward_reply (msg=msg at entry=0x7fcf286677e0) > at forward.c:517 > #12 0x000000000045d9bd in receive_msg ( > buf=0x85f540 "SIP/2.0 500 Internal server error\r\nVia: > SIP/2.0/UDP > XXX.XXX.XXX.XXX:5060;branch=z9hG4bK7615.63e34a06.0\r\nFrom: > \"XXXXXXXXXX\" > ;tag=g8t85U635m04N\r\nTo: > , > rcv_info=rcv_info at entry=0x7ffc8eadc4e0) at receive.c:243 > #13 0x00000000005a04c5 in udp_read_req (si=, > bytes_read=) at net/proto_udp/proto_udp.c:190 > #14 0x000000000058bfbe in handle_io (fm=, fm= out>, fm=, idx=, event_type=2) at > net/net_udp.c:260 > #15 io_wait_loop_epoll (h=, t=, > repeat=) at net/../io_wait_loop.h:190 > #16 udp_rcv_loop (si=si at entry=0x7fcf28641f68) at net/net_udp.c:308 > #17 0x000000000058db9c in udp_start_processes > (chd_rank=chd_rank at entry=0x84c26c , > startup_done=startup_done at entry=0x0) at net/net_udp.c:448 > #18 0x000000000041a9d3 in main_loop () at main.c:722 > #19 main (argc=, argv=) at main.c:1259 > > > -- > Dani Popa > > > _______________________________________________ > 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: From bogdan at opensips.org Tue Nov 1 22:44:26 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 1 Nov 2016 23:44:26 +0200 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> Message-ID: Hi Jonathan, Please give it a try to this patch - it is not really tested, but when the call is sent the Queue announcement, it should have a ";cc_pos=xxx" parameter giving the position is the queue (0 being the first to be dispatched to agents). Let me know if it works. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 28.10.2016 15:59, Jonathan Hunter wrote: > > Hi Bogdan, > > > Great news, really do appreciate that. > > > Many thanks > > > Jon > > > > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *Sent:* 28 October 2016 12:48 > *To:* Jonathan Hunter; OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position > Hi Jonathan, > > No, it is no yet available. Give me couple of days and I will make a > patch for it. > > Best regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > Home ? OpenSIPS Solutions > www.opensips-solutions.com > OpenSIPS is a mature Open Source implementation of a SIP server. > OpenSIPS is more than a SIP proxy/router as it includes > application-level functionalities. > > > On 25.10.2016 19:22, Jonathan Hunter wrote: >> >> Hi Bogdan, >> >> >> Sorry cant recall If I replied to this. >> >> >> Is cc_pos available now to extract from the module? >> >> >> Thats the only thing I need then I can implement call center which I >> think will be much more scale-able than the other approach I am using >> with FreeSWITCH, I would use that just for announcements. >> >> >> Any response/help appreciated. >> >> >> Jon >> >> >> >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* 13 October 2016 10:59 >> *To:* Jonathan Hunter; OpenSIPS users mailling list >> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >> Hi Jonathan, >> >> No, currently this is not possible. I was trying to envision a >> solution for your need. >> >> But, checking the code, it is really difficult to add the headers to >> the INVITEs originated by OpenSIPS (via the B2BUA), as we need some >> flexibility (different headers to different INVITEs belonging to the >> same B2B scenario , and even more, we need to traverse couple of >> internal APIs - to propagate the hdrs from Call center module all the >> way to TM). >> >> So, a simpler approach may be to add such extra info as URI params to >> the RURI. Like if you have the RURI "sip:queue at 192.168.1.10:5060" for >> the queue/waiting playback, the RURI in the INVITE to the media >> server will look like : >> sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the >> estimated time to wait in seconds and cc_pos the position in the queue. >> >> What do you think of this ? >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 12.10.2016 17:21, Jonathan Hunter wrote: >>> Hi Bogdan, >>> >>> Yes being able to grab the queue position would be perfect. >>> >>> Is that possible? >>> >>> Thanks >>> >>> Jon >>> >>> ------------------------------------------------------------------------ >>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>> To: hunterj91 at hotmail.com; users at lists.opensips.org >>> From: bogdan at opensips.org >>> Date: Wed, 12 Oct 2016 15:42:43 +0300 >>> >>> Hi Jonathan, >>> >>> When a call is mapped to a flow / queue (before playing the welcome >>> message), we know the ETA (estimated time to wait) and when is >>> placed in the queue (before playing the queuing) we internally know >>> the position in the queue. >>> >>> Would it help to have the position in the queue placed into a >>> custome SIP header, when sending the INVITE to the message_queue URL >>> ? or to the welcome message ? >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 12.10.2016 12:06, Jonathan Hunter wrote: >>> >>> Hello Bogdan, >>> >>> Thanks for the response. >>> >>> In terms of my question, with a number of queuing platforms, >>> they have the capability to tell the caller, what position they >>> are in , and when they are likely to be answered. >>> >>> I just wondered if this logic was already within the module, or >>> if I would need to use an external code/script to facilitate >>> this function? >>> >>> As I presume call_center tracks the number of calls currently in >>> a queue ? I would then want to be able to extract that >>> information, and if a caller was for example in 3rd place in a >>> queue, I could inject the relevant audio from freeswitch to tell >>> them their current position? >>> >>> Does that make sense? :) Just wanted to know if its something >>> this module can do? >>> >>> Thanks >>> >>> Jon >>> >>> ------------------------------------------------------------------------ >>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>> position >>> To: users at lists.opensips.org ; >>> hunterj91 at hotmail.com >>> From: bogdan at opensips.org >>> Date: Wed, 12 Oct 2016 11:23:45 +0300 >>> >>> Hello Jon, >>> >>> The message_queue is a SIP URI pointing to an audio announcement >>> to play to roll of the waiting/in-queue playback. This needs to >>> be an announcements that never ends (from the perspective of the >>> media server); only the the OpenSIPS Queue may terminate the >>> playback, when it decides to take out the call from waiting and >>> to deliver it to an agent. >>> >>> As for your question, I'm not sure I understand what you mean by >>> "inject a message with queue position for the caller in >>> question" - could you detail please ? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> On 11.10.2016 13:36, Jonathan Hunter wrote: >>> >>> Hi guys, >>> >>> I have implemented an opensips/freeswitch environment, and I >>> wish to add call queues to it, and I like the look of >>> call_center, so just checking this out in comparison to >>> mod_callcenter in FS world. >>> >>> My main question is if using the call_center module if you >>> can inject a message with queue position for the caller in >>> question, as I cant see that in documentation, I only see >>> message_queue which I assume could be used to report the >>> callers position, but just wondered if anyone has done this >>> and if they could give me some tips as to if possible? >>> >>> Many thanks >>> >>> Jon >>> >>> >>> _______________________________________________ >>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: call_center_pos.patch Type: text/x-patch Size: 2575 bytes Desc: not available URL: From hunterj91 at hotmail.com Wed Nov 2 08:56:43 2016 From: hunterj91 at hotmail.com (Jonathan Hunter) Date: Wed, 2 Nov 2016 07:56:43 +0000 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> , Message-ID: Hi Bogdan, Thanks very much for this. I have just applied patch (installed from sources so when to call_center module directory and ran patch < call_center_pos.patch) then did a recompile. However when I now route to the call center (cc_handle_call) it generates a core and kills opensips; !!!!user 2000 has Callqueue set so send to Call Queue Route Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set event EPOLLHUP - connection closed by the remote peer! Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: CRITICAL:core:receive_fd: EOF on 19 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: child process 21119 exited by a signal 11 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: core was generated Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: terminating due to SIGCHLD Do you need me to backtrace/debug through to get the issue? Or is problem how I applied patch? Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 01 November 2016 21:44 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Please give it a try to this patch - it is not really tested, but when the call is sent the Queue announcement, it should have a ";cc_pos=xxx" parameter giving the position is the queue (0 being the first to be dispatched to agents). Let me know if it works. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 28.10.2016 15:59, Jonathan Hunter wrote: Hi Bogdan, Great news, really do appreciate that. Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 28 October 2016 12:48 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, it is no yet available. Give me couple of days and I will make a patch for it. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 25.10.2016 19:22, Jonathan Hunter wrote: Hi Bogdan, Sorry cant recall If I replied to this. Is cc_pos available now to extract from the module? Thats the only thing I need then I can implement call center which I think will be much more scale-able than the other approach I am using with FreeSWITCH, I would use that just for announcements. Any response/help appreciated. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 13 October 2016 10:59 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, currently this is not possible. I was trying to envision a solution for your need. But, checking the code, it is really difficult to add the headers to the INVITEs originated by OpenSIPS (via the B2BUA), as we need some flexibility (different headers to different INVITEs belonging to the same B2B scenario , and even more, we need to traverse couple of internal APIs - to propagate the hdrs from Call center module all the way to TM). So, a simpler approach may be to add such extra info as URI params to the RURI. Like if you have the RURI "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the RURI in the INVITE to the media server will look like : sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the estimated time to wait in seconds and cc_pos the position in the queue. What do you think of this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 17:21, Jonathan Hunter wrote: Hi Bogdan, Yes being able to grab the queue position would be perfect. Is that possible? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: hunterj91 at hotmail.com; users at lists.opensips.org From: bogdan at opensips.org Date: Wed, 12 Oct 2016 15:42:43 +0300 Hi Jonathan, When a call is mapped to a flow / queue (before playing the welcome message), we know the ETA (estimated time to wait) and when is placed in the queue (before playing the queuing) we internally know the position in the queue. Would it help to have the position in the queue placed into a custome SIP header, when sending the INVITE to the message_queue URL ? or to the welcome message ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 12:06, Jonathan Hunter wrote: Hello Bogdan, Thanks for the response. In terms of my question, with a number of queuing platforms, they have the capability to tell the caller, what position they are in , and when they are likely to be answered. I just wondered if this logic was already within the module, or if I would need to use an external code/script to facilitate this function? As I presume call_center tracks the number of calls currently in a queue ? I would then want to be able to extract that information, and if a caller was for example in 3rd place in a queue, I could inject the relevant audio from freeswitch to tell them their current position? Does that make sense? :) Just wanted to know if its something this module can do? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: users at lists.opensips.org; hunterj91 at hotmail.com From: bogdan at opensips.org Date: Wed, 12 Oct 2016 11:23:45 +0300 Hello Jon, The message_queue is a SIP URI pointing to an audio announcement to play to roll of the waiting/in-queue playback. This needs to be an announcements that never ends (from the perspective of the media server); only the the OpenSIPS Queue may terminate the playback, when it decides to take out the call from waiting and to deliver it to an agent. As for your question, I'm not sure I understand what you mean by "inject a message with queue position for the caller in question" - could you detail please ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11.10.2016 13:36, Jonathan Hunter wrote: Hi guys, I have implemented an opensips/freeswitch environment, and I wish to add call queues to it, and I like the look of call_center, so just checking this out in comparison to mod_callcenter in FS world. My main question is if using the call_center module if you can inject a message with queue position for the caller in question, as I cant see that in documentation, I only see message_queue which I assume could be used to report the callers position, but just wondered if anyone has done this and if they could give me some tips as to if possible? Many thanks Jon _______________________________________________ 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: From rrobson at greenlightcrm.com Tue Nov 1 12:40:01 2016 From: rrobson at greenlightcrm.com (Richard Robson) Date: Tue, 1 Nov 2016 11:40:01 +0000 Subject: [OpenSIPS-Users] multiple retransmissions on 4XX after ACK [Solved] In-Reply-To: References: <68394410-DC78-4DB0-A414-73ECBCD5E8E9@inin.com> Message-ID: <62280644-9ccb-d568-ebd8-84ee19ce723b@greenlightcrm.com> An HTML attachment was scrubbed... URL: From eric.freeman at tbwachiat.com Tue Nov 1 13:24:58 2016 From: eric.freeman at tbwachiat.com (Eric Freeman) Date: Tue, 1 Nov 2016 12:24:58 +0000 Subject: [OpenSIPS-Users] Routing in opensips In-Reply-To: <9a3d5834-6396-ca9e-898b-21e31cd8b661@opensips.org> References: <64ca0729-1829-3ad8-9548-8b815f6d01b8@opensips.org> <316e9a04-7742-ab9e-329d-e0615cc64179@opensips.org> <5bf7c4cc-285a-2a7a-f5fe-62cbc4601e1d@opensips.org> , <9a3d5834-6396-ca9e-898b-21e31cd8b661@opensips.org> Message-ID: Thank you. I will test with that IP. How do I change the SDP to my public IP address so I can get RTP information back? Thank you, Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Tuesday, November 1, 2016 7:10:45 AM To: Eric Freeman; users at lists.opensips.org Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, The outgoing INVITE request looks ok - the RR and VIA headers carry the public IP of your OpenSIPS. You should get back some reply. Not sure how valid is that test server, but you can try sending to sip:opensips.org:5060 ( or 78.46.64.50:5060 ) - this sip server is definitely up . BTW, the SDP you send out is bogus as it contain only private IPs, so the other end point will not be able to send you ant RTP back. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 31.10.2016 14:21, Eric Freeman wrote: Please attached pcap file. Is this what you need? Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Monday, October 31, 2016 6:36:18 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, What I'm asking here is to post the full INVITE packet from your opensips server to the external host - I Want to to check the SIP headers and the SDP. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.10.2016 16:38, Eric Freeman wrote: The opensips server is 10.88.23.13 the video conference server is 10.89.71.12. The IP I am trying to connect to 199.48.152.152, I believe is a valid host. I found it on a test SIP site on the Internet 10:02:59.346842 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:02:59.351769 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 100 Giving a try 10:02:59.352232 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:02:59.352238 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:02:59.871480 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:02:59.871489 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:03:00.874461 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:03:00.874483 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:03:02.877430 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:03:02.877440 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:03:03.930697 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 408 Request Timeout 10:03:03.958682 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: ACK sip:111 at 199.48.152.152 SIP/2.0 Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Tuesday, October 25, 2016 7:04:15 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, By traffic (coming back), you understand RTP or SIP traffic ? Could you post the INVITE message getting out of your server ? I suspect the INVITE has in SDP a private IP that is not reachable for the end device (where the call is sent). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.10.2016 18:46, Eric Freeman wrote: Yes, I see Request INVITE going to the device I am calling. I do not see any traffic coming back. I am following up with my Firewall team. My Firewall team suggested I might need to change the RTP ports to use UDP 2326-2485. Where do I change/check these settings on the OpenSIPs server to see if I have the traffic going out those ports. Thanks, Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Monday, October 3, 2016 4:44:26 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, Not the OpenSIPs logs I'm looking for, but the actual SIP packet at network level (use ngrep or tcpdump) for the INVITE leaving your OpenSIPS. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 30.09.2016 16:52, Eric Freeman wrote: Hopefully this is the relevant information you need from the log. I am trying to call 111 at 199.48.152.152. The IP of the opensips server si 10.88.23.10 and has a public IP of 204.17.231.3. The IP address of the video conference server is 10.89.71.12. Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: SIP Request: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: method: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: uri: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: version: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=2 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: end of header reached, state=10 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: display={}, ruri={sip:111 at 199.48.152.152} Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: [26]; uri=[sip:111 at 199.48.152.152] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: to body [#015#012] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: cseq : <1> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_via_param: found param type 235, = ; state=6 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_via_param: found param type 232, = ; state=16 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_via: end of header reached, state=5 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: via found, flags=2 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: this is the first via Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:receive_msg: After parse_msg... Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:receive_msg: preparing to run routing scripts... Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=100 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:maxfwd:is_maxfwd_present: value = 70 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:uri:has_totag: no totag Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=78 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:tm:t_lookup_request: start searching: hash=25578, isACK=0 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:tm:matching_3261: RFC3261 transaction matching failed Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:tm:t_lookup_request: no transaction found Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to_param: tag=2c770a98-c47590a-13c4-45026-57ed3cdd-1bac9941-57ed3cdd Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: end of header reached, state=29 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: display={"Conference Room"}, ruri={sip:LifeSize at 10.88.23.13;transport=UDP} Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if host==us: 11==11 && [10.88.23.13] == [10.88.23.13] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=200 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: content_length=1759 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: found end of header Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:rr:find_first_route: No Route headers found Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if host==us: 14==11 && [199.48.152.152] == [10.88.23.13] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if host==us: 14==11 && [199.48.152.152] == [10.88.23.13] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:check_self: host != me Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:do_action_set_adv_address: setting adv address = [204.17.231.3] Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Friday, September 30, 2016 4:32:01 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, As a first step, can you confirm that the INVITE (sent out by your OPenSIPS to the internet) has in VIA hdr the public IP of your NAT ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 29.09.2016 19:14, Eric Freeman wrote: It is still not working, I added my public IP as requested. I do not have any gateways or anything set up. Do I need to add anything? I added this to the route statement: if (!uri==myself) { append_hf("P-hint: outbound\r\n"); set_advertised_address("XXX.XX.XXX.X"); route(relay); I am still receiving these errors: Sep 29 12:10:22 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:rr:find_first_route: No Route headers found Sep 29 12:10:22 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:rr:loose_route: There is no Route HF Sep 29 12:10:22 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=78 Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Tuesday, September 20, 2016 8:38:31 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips He Eric, In the script (generated by menuconfig), you have an IF block with : append_hf("P-hint: outbound\r\n"); That block is executed if one of your users is dialing an external SIP domain. So, that is the place where the calls will break out to public internet. As your OpenSIPS has a private IP (not routable in internet), you need to configure it to advertise the public IP of your NAT via the set_advertise_address() - see: http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc46 Put there the public IP of your NAT. Also, be sure you create in your router (running the NAT) a port forwarding from the public IP port 5060 UDP to the private IP of your OpenSIPS port 5060 UDP. Best regards, ------------------------------------------------------------------------------- This e-mail is intended only for the named person or entity to which it is addressed and contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure. If you received this e-mail in error, any review, use, dissemination, distribution or copying of this e-mail is strictly prohibited. Please notify us immediately of the error via e-mail to disclaimer at email-abuse.com and please delete the e-mail from your system, retaining no copies in any media. We appreciate your cooperation. -------------------------------------------------------------------disc99999999 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Nov 1 13:34:05 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 1 Nov 2016 14:34:05 +0200 Subject: [OpenSIPS-Users] Routing in opensips In-Reply-To: References: <316e9a04-7742-ab9e-329d-e0615cc64179@opensips.org> <5bf7c4cc-285a-2a7a-f5fe-62cbc4601e1d@opensips.org> <9a3d5834-6396-ca9e-898b-21e31cd8b661@opensips.org> Message-ID: Eric, You can simply change it with the fix_nated_sdp() function: http://www.opensips.org/html/docs/modules/2.2.x/nathelper.html#id294042 But you have to be careful that the IP:port you force in SDP is also valid from IP perspective - like any RTP traffic landing on that IP is actually getting to the right application. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 01.11.2016 14:24, Eric Freeman wrote: > > Thank you. I will test with that IP. How do I change the SDP to my > public IP address so I can get RTP information back? > > > Thank you, > > > Eric Freeman > > Technical Director/NA for TBWA\Chiat\Day > > TBWA\Chiat\Day New York > 488 Madison Ave. > New York NY 10022 > United States of America > Tel: +12128041324 > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *Sent:* Tuesday, November 1, 2016 7:10:45 AM > *To:* Eric Freeman; users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] Routing in opensips > Hi Eric, > > The outgoing INVITE request looks ok - the RR and VIA headers carry > the public IP of your OpenSIPS. You should get back some reply. Not > sure how valid is that test server, but you can try sending to > sip:opensips.org:5060 ( or 78.46.64.50:5060 ) - this sip server is > definitely up . > > BTW, the SDP you send out is bogus as it contain only private IPs, so > the other end point will not be able to send you ant RTP back. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 31.10.2016 14:21, Eric Freeman wrote: >> >> Please attached pcap file. Is this what you need? >> >> >> Eric Freeman >> >> Technical Director/NA for TBWA\Chiat\Day >> >> TBWA\Chiat\Day New York >> 488 Madison Ave. >> New York NY 10022 >> United States of America >> Tel: +12128041324 >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* Monday, October 31, 2016 6:36:18 AM >> *To:* Eric Freeman; OpenSIPS users mailling list >> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >> Hi Eric, >> >> What I'm asking here is to post the full INVITE packet from your >> opensips server to the external host - I Want to to check the SIP >> headers and the SDP. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 25.10.2016 16:38, Eric Freeman wrote: >>> >>> The opensips server is 10.88.23.13 the video conference server is >>> 10.89.71.12. The IP I am trying to connect to 199.48.152.152, I >>> believe is a valid host. I found it on a test SIP site on the Internet >>> >>> >>> 10:02:59.346842 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: INVITE >>> sip:111 at 199.48.152.152 SIP/2.0 >>> >>> 10:02:59.351769 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 >>> 100 Giving a try >>> >>> 10:02:59.352232 IP 10.88.23.13.sip > >>> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >>> sip:111 at 199.48.152.152 SIP/2.0 >>> >>> 10:02:59.352238 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >>> >>> 10:02:59.871480 IP 10.88.23.13.sip > >>> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >>> sip:111 at 199.48.152.152 SIP/2.0 >>> >>> 10:02:59.871489 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >>> >>> 10:03:00.874461 IP 10.88.23.13.sip > >>> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >>> sip:111 at 199.48.152.152 SIP/2.0 >>> >>> 10:03:00.874483 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >>> >>> 10:03:02.877430 IP 10.88.23.13.sip > >>> sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE >>> sip:111 at 199.48.152.152 SIP/2.0 >>> >>> 10:03:02.877440 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp >>> >>> 10:03:03.930697 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 >>> 408 Request Timeout >>> >>> 10:03:03.958682 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: ACK >>> sip:111 at 199.48.152.152 SIP/2.0 >>> >>> >>> Eric Freeman >>> >>> Technical Director/NA for TBWA\Chiat\Day >>> >>> TBWA\Chiat\Day New York >>> 488 Madison Ave. >>> New York NY 10022 >>> United States of America >>> Tel: +12128041324 >>> ------------------------------------------------------------------------ >>> *From:* Bogdan-Andrei Iancu >>> *Sent:* Tuesday, October 25, 2016 7:04:15 AM >>> *To:* Eric Freeman; OpenSIPS users mailling list >>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>> Hi Eric, >>> >>> By traffic (coming back), you understand RTP or SIP traffic ? >>> >>> Could you post the INVITE message getting out of your server ? I >>> suspect the INVITE has in SDP a private IP that is not reachable for >>> the end device (where the call is sent). >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 21.10.2016 18:46, Eric Freeman wrote: >>>> >>>> Yes, I see Request INVITE going to the device I am calling. I do >>>> not see any traffic coming back. I am following up with my Firewall >>>> team. >>>> >>>> My Firewall team suggested I might need to change the RTP ports to >>>> use UDP 2326-2485. Where do I change/check these settings on the >>>> OpenSIPs server to see if I have the traffic going out those ports. >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Eric Freeman >>>> >>>> Technical Director/NA for TBWA\Chiat\Day >>>> >>>> TBWA\Chiat\Day New York >>>> 488 Madison Ave. >>>> New York NY 10022 >>>> United States of America >>>> Tel: +12128041324 >>>> ------------------------------------------------------------------------ >>>> *From:* Bogdan-Andrei Iancu >>>> *Sent:* Monday, October 3, 2016 4:44:26 AM >>>> *To:* Eric Freeman; OpenSIPS users mailling list >>>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>>> Hi Eric, >>>> >>>> Not the OpenSIPs logs I'm looking for, but the actual SIP packet at >>>> network level (use ngrep or tcpdump) for the INVITE leaving your >>>> OpenSIPS. >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 30.09.2016 16:52, Eric Freeman wrote: >>>>> >>>>> Hopefully this is the relevant information you need from the log. >>>>> I am trying to call 111 at 199.48.152.152. The IP of the opensips >>>>> server si 10.88.23.10 and has a public IP of 204.17.231.3. The IP >>>>> address of the video conference server is 10.89.71.12. >>>>> >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: SIP Request: >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: method: >>>>> >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: uri: >>>>> >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: version: >>>>> >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=2 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_to: end of header >>>>> reached, state=10 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_to: display={}, >>>>> ruri={sip:111 at 199.48.152.152} >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: >>>>> [26]; uri=[sip:111 at 199.48.152.152] >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: to body >>>>> [#015#012] >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: cseq >>>>> : <1> >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_via_param: found >>>>> param type 235, = ; state=6 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_via_param: found >>>>> param type 232, = ; >>>>> state=16 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_via: end of header >>>>> reached, state=5 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: via >>>>> found, flags=2 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: this is >>>>> the first via >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:receive_msg: After >>>>> parse_msg... >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:receive_msg: preparing >>>>> to run routing scripts... >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=100 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:maxfwd:is_maxfwd_present: >>>>> value = 70 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:uri:has_totag: no totag >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=78 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:tm:t_lookup_request: start >>>>> searching: hash=25578, isACK=0 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:tm:matching_3261: RFC3261 >>>>> transaction matching failed >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:tm:t_lookup_request: no >>>>> transaction found >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_to_param: >>>>> tag=2c770a98-c47590a-13c4-45026-57ed3cdd-1bac9941-57ed3cdd >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_to: end of header >>>>> reached, state=29 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_to: >>>>> display={"Conference Room"}, >>>>> ruri={sip:LifeSize at 10.88.23.13;transport=UDP} >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking >>>>> if host==us: 11==11 && [10.88.23.13] == [10.88.23.13] >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking >>>>> if port 5060 matches port 5060 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=200 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: >>>>> content_length=1759 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: found end >>>>> of header >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:rr:find_first_route: No Route >>>>> headers found >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking >>>>> if host==us: 14==11 && [199.48.152.152] == [10.88.23.13] >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking >>>>> if port 5060 matches port 5060 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking >>>>> if host==us: 14==11 && [199.48.152.152] == [10.88.23.13] >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking >>>>> if port 5060 matches port 5060 >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:check_self: host != me >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: >>>>> flags=ffffffffffffffff >>>>> >>>>> Sep 29 12:10:17 cd-ubuntu-opensips >>>>> /usr/local/sbin/opensips[12878]: >>>>> DBG:core:do_action_set_adv_address: setting adv address = >>>>> [204.17.231.3] >>>>> >>>>> >>>>> Eric Freeman >>>>> >>>>> Technical Director/NA for TBWA\Chiat\Day >>>>> >>>>> TBWA\Chiat\Day New York >>>>> 488 Madison Ave. >>>>> New York NY 10022 >>>>> United States of America >>>>> Tel: +12128041324 >>>>> ------------------------------------------------------------------------ >>>>> *From:* Bogdan-Andrei Iancu >>>>> *Sent:* Friday, September 30, 2016 4:32:01 AM >>>>> *To:* Eric Freeman; OpenSIPS users mailling list >>>>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>>>> Hi Eric, >>>>> >>>>> As a first step, can you confirm that the INVITE (sent out by your >>>>> OPenSIPS to the internet) has in VIA hdr the public IP of your NAT ? >>>>> >>>>> Best regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 29.09.2016 19:14, Eric Freeman wrote: >>>>>> >>>>>> It is still not working, I added my public IP as requested. I do >>>>>> not have any gateways or anything set up. Do I need to add anything? >>>>>> >>>>>> I added this to the route statement: >>>>>> >>>>>> >>>>>> if (!uri==myself) { >>>>>> >>>>>> append_hf("P-hint: outbound\r\n"); >>>>>> >>>>>> set_advertised_address("XXX.XX.XXX.X"); >>>>>> >>>>>> route(relay); >>>>>> >>>>>> >>>>>> I am still receiving these errors: >>>>>> >>>>>> Sep 29 12:10:22 cd-ubuntu-opensips >>>>>> /usr/local/sbin/opensips[12878]: DBG:rr:find_first_route: No >>>>>> Route headers found >>>>>> >>>>>> Sep 29 12:10:22 cd-ubuntu-opensips >>>>>> /usr/local/sbin/opensips[12878]: DBG:rr:loose_route: There is no >>>>>> Route HF >>>>>> >>>>>> Sep 29 12:10:22 cd-ubuntu-opensips >>>>>> /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=78 >>>>>> >>>>>> >>>>>> >>>>>> Eric Freeman >>>>>> >>>>>> Technical Director/NA for TBWA\Chiat\Day >>>>>> >>>>>> TBWA\Chiat\Day New York >>>>>> 488 Madison Ave. >>>>>> New York NY 10022 >>>>>> United States of America >>>>>> Tel: +12128041324 >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* Bogdan-Andrei Iancu >>>>>> *Sent:* Tuesday, September 20, 2016 8:38:31 AM >>>>>> *To:* Eric Freeman; OpenSIPS users mailling list >>>>>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>>>>> He Eric, >>>>>> >>>>>> In the script (generated by menuconfig), you have an IF block with : >>>>>> append_hf("P-hint: outbound\r\n"); >>>>>> >>>>>> That block is executed if one of your users is dialing an >>>>>> external SIP domain. So, that is the place where the calls will >>>>>> break out to public internet. >>>>>> >>>>>> As your OpenSIPS has a private IP (not routable in internet), you >>>>>> need to configure it to advertise the public IP of your NAT via >>>>>> the set_advertise_address() - see: >>>>>> http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc46 >>>>>> >>>>>> Put there the public IP of your NAT. Also, be sure you create in >>>>>> your router (running the NAT) a port forwarding from the public >>>>>> IP port 5060 UDP to the private IP of your OpenSIPS port 5060 UDP. >>>>>> >>>>>> Best regards, >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------- >>>> This e-mail is intended only for the named person or entity to >>>> which it is addressed and contains valuable business >>>> information that is privileged, confidential and/or otherwise >>>> protected from disclosure. If you received this e-mail >>>> in error, any review, use, dissemination, distribution or copying >>>> of this e-mail is strictly prohibited. Please notify us >>>> immediately of the error via e-mail to disclaimer at email-abuse.com >>>> and please delete the e-mail from your system, >>>> retaining no copies in any media. We appreciate your cooperation. >>>> -------------------------------------------------------------------disc99999999 >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Nov 2 09:09:45 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 2 Nov 2016 10:09:45 +0200 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> Message-ID: For sure it is a patch issue. if you have a backtrace, it will useful. Thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 02.11.2016 09:56, Jonathan Hunter wrote: > > Hi Bogdan, > > > Thanks very much for this. > > > I have just applied patch (installed from sources so when to > call_center module directory and ran patch < call_center_pos.patch) > then did a recompile. > > > However when I now route to the call center (cc_handle_call) it > generates a core and kills opensips; > > > !!!!user 2000 has Callqueue set so send to Call Queue Route > Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: > NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set > event EPOLLHUP - connection closed by the remote peer! > Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: > CRITICAL:core:receive_fd: EOF on 19 > Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: > INFO:core:handle_sigs: child process 21119 exited by a signal 11 > Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: > INFO:core:handle_sigs: core was generated > Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: > INFO:core:handle_sigs: terminating due to SIGCHLD > > > > Do you need me to backtrace/debug through to get the issue? Or is > problem how I applied patch? > > > Many thanks > > > Jon > > > > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *Sent:* 01 November 2016 21:44 > *To:* Jonathan Hunter; OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position > Hi Jonathan, > > Please give it a try to this patch - it is not really tested, but when > the call is sent the Queue announcement, it should have a > ";cc_pos=xxx" parameter giving the position is the queue (0 being the > first to be dispatched to agents). > > Let me know if it works. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > Home ? OpenSIPS Solutions > www.opensips-solutions.com > OpenSIPS is a mature Open Source implementation of a SIP server. > OpenSIPS is more than a SIP proxy/router as it includes > application-level functionalities. > > > On 28.10.2016 15:59, Jonathan Hunter wrote: >> >> Hi Bogdan, >> >> >> Great news, really do appreciate that. >> >> >> Many thanks >> >> >> Jon >> >> >> >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* 28 October 2016 12:48 >> *To:* Jonathan Hunter; OpenSIPS users mailling list >> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >> Hi Jonathan, >> >> No, it is no yet available. Give me couple of days and I will make a >> patch for it. >> >> Best regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> Home ? OpenSIPS Solutions >> www.opensips-solutions.com >> OpenSIPS is a mature Open Source implementation of a SIP server. >> OpenSIPS is more than a SIP proxy/router as it includes >> application-level functionalities. >> >> >> On 25.10.2016 19:22, Jonathan Hunter wrote: >>> >>> Hi Bogdan, >>> >>> >>> Sorry cant recall If I replied to this. >>> >>> >>> Is cc_pos available now to extract from the module? >>> >>> >>> Thats the only thing I need then I can implement call center which I >>> think will be much more scale-able than the other approach I am >>> using with FreeSWITCH, I would use that just for announcements. >>> >>> >>> Any response/help appreciated. >>> >>> >>> Jon >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Bogdan-Andrei Iancu >>> *Sent:* 13 October 2016 10:59 >>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>> Hi Jonathan, >>> >>> No, currently this is not possible. I was trying to envision a >>> solution for your need. >>> >>> But, checking the code, it is really difficult to add the headers to >>> the INVITEs originated by OpenSIPS (via the B2BUA), as we need some >>> flexibility (different headers to different INVITEs belonging to the >>> same B2B scenario , and even more, we need to traverse couple of >>> internal APIs - to propagate the hdrs from Call center module all >>> the way to TM). >>> >>> So, a simpler approach may be to add such extra info as URI params >>> to the RURI. Like if you have the RURI "sip:queue at 192.168.1.10:5060" >>> for the queue/waiting playback, the RURI in the INVITE to the media >>> server will look like : >>> sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the >>> estimated time to wait in seconds and cc_pos the position in the queue. >>> >>> What do you think of this ? >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 12.10.2016 17:21, Jonathan Hunter wrote: >>>> Hi Bogdan, >>>> >>>> Yes being able to grab the queue position would be perfect. >>>> >>>> Is that possible? >>>> >>>> Thanks >>>> >>>> Jon >>>> >>>> ------------------------------------------------------------------------ >>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>>> To: hunterj91 at hotmail.com; users at lists.opensips.org >>>> From: bogdan at opensips.org >>>> Date: Wed, 12 Oct 2016 15:42:43 +0300 >>>> >>>> Hi Jonathan, >>>> >>>> When a call is mapped to a flow / queue (before playing the welcome >>>> message), we know the ETA (estimated time to wait) and when is >>>> placed in the queue (before playing the queuing) we internally know >>>> the position in the queue. >>>> >>>> Would it help to have the position in the queue placed into a >>>> custome SIP header, when sending the INVITE to the message_queue >>>> URL ? or to the welcome message ? >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 12.10.2016 12:06, Jonathan Hunter wrote: >>>> >>>> Hello Bogdan, >>>> >>>> Thanks for the response. >>>> >>>> In terms of my question, with a number of queuing platforms, >>>> they have the capability to tell the caller, what position they >>>> are in , and when they are likely to be answered. >>>> >>>> I just wondered if this logic was already within the module, or >>>> if I would need to use an external code/script to facilitate >>>> this function? >>>> >>>> As I presume call_center tracks the number of calls currently >>>> in a queue ? I would then want to be able to extract that >>>> information, and if a caller was for example in 3rd place in a >>>> queue, I could inject the relevant audio from freeswitch to >>>> tell them their current position? >>>> >>>> Does that make sense? :) Just wanted to know if its something >>>> this module can do? >>>> >>>> Thanks >>>> >>>> Jon >>>> >>>> ------------------------------------------------------------------------ >>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>> position >>>> To: users at lists.opensips.org ; >>>> hunterj91 at hotmail.com >>>> From: bogdan at opensips.org >>>> Date: Wed, 12 Oct 2016 11:23:45 +0300 >>>> >>>> Hello Jon, >>>> >>>> The message_queue is a SIP URI pointing to an audio >>>> announcement to play to roll of the waiting/in-queue playback. >>>> This needs to be an announcements that never ends (from the >>>> perspective of the media server); only the the OpenSIPS Queue >>>> may terminate the playback, when it decides to take out the >>>> call from waiting and to deliver it to an agent. >>>> >>>> As for your question, I'm not sure I understand what you mean >>>> by "inject a message with queue position for the caller in >>>> question" - could you detail please ? >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> >>>> On 11.10.2016 13:36, Jonathan Hunter wrote: >>>> >>>> Hi guys, >>>> >>>> I have implemented an opensips/freeswitch environment, and >>>> I wish to add call queues to it, and I like the look of >>>> call_center, so just checking this out in comparison to >>>> mod_callcenter in FS world. >>>> >>>> My main question is if using the call_center module if you >>>> can inject a message with queue position for the caller in >>>> question, as I cant see that in documentation, I only see >>>> message_queue which I assume could be used to report the >>>> callers position, but just wondered if anyone has done this >>>> and if they could give me some tips as to if possible? >>>> >>>> Many thanks >>>> >>>> Jon >>>> >>>> >>>> _______________________________________________ >>>> 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: From hunterj91 at hotmail.com Wed Nov 2 10:33:09 2016 From: hunterj91 at hotmail.com (Jonathan Hunter) Date: Wed, 2 Nov 2016 09:33:09 +0000 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> , Message-ID: Hi Bogdan, I am getting the core dumps, but containing no symbol tables, so I presume I need to recompile with debug flags enabled? Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004ed7fb in ?? () "/core.24882" is a core file. Please specify an executable to debug. (gdb) bt full #0 0x00000000004ed7fb in ?? () No symbol table info available. #1 0x00007f6af7604468 in ?? () No symbol table info available. #2 0x000000000000001a in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. I installed 2.1 from sources, so whats the best way to do this? thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 02 November 2016 08:09 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position For sure it is a patch issue. if you have a backtrace, it will useful. Thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 02.11.2016 09:56, Jonathan Hunter wrote: Hi Bogdan, Thanks very much for this. I have just applied patch (installed from sources so when to call_center module directory and ran patch < call_center_pos.patch) then did a recompile. However when I now route to the call center (cc_handle_call) it generates a core and kills opensips; !!!!user 2000 has Callqueue set so send to Call Queue Route Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set event EPOLLHUP - connection closed by the remote peer! Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: CRITICAL:core:receive_fd: EOF on 19 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: child process 21119 exited by a signal 11 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: core was generated Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: terminating due to SIGCHLD Do you need me to backtrace/debug through to get the issue? Or is problem how I applied patch? Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 01 November 2016 21:44 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Please give it a try to this patch - it is not really tested, but when the call is sent the Queue announcement, it should have a ";cc_pos=xxx" parameter giving the position is the queue (0 being the first to be dispatched to agents). Let me know if it works. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 28.10.2016 15:59, Jonathan Hunter wrote: Hi Bogdan, Great news, really do appreciate that. Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 28 October 2016 12:48 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, it is no yet available. Give me couple of days and I will make a patch for it. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 25.10.2016 19:22, Jonathan Hunter wrote: Hi Bogdan, Sorry cant recall If I replied to this. Is cc_pos available now to extract from the module? Thats the only thing I need then I can implement call center which I think will be much more scale-able than the other approach I am using with FreeSWITCH, I would use that just for announcements. Any response/help appreciated. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 13 October 2016 10:59 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, currently this is not possible. I was trying to envision a solution for your need. But, checking the code, it is really difficult to add the headers to the INVITEs originated by OpenSIPS (via the B2BUA), as we need some flexibility (different headers to different INVITEs belonging to the same B2B scenario , and even more, we need to traverse couple of internal APIs - to propagate the hdrs from Call center module all the way to TM). So, a simpler approach may be to add such extra info as URI params to the RURI. Like if you have the RURI "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the RURI in the INVITE to the media server will look like : sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the estimated time to wait in seconds and cc_pos the position in the queue. What do you think of this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 17:21, Jonathan Hunter wrote: Hi Bogdan, Yes being able to grab the queue position would be perfect. Is that possible? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: hunterj91 at hotmail.com; users at lists.opensips.org From: bogdan at opensips.org Date: Wed, 12 Oct 2016 15:42:43 +0300 Hi Jonathan, When a call is mapped to a flow / queue (before playing the welcome message), we know the ETA (estimated time to wait) and when is placed in the queue (before playing the queuing) we internally know the position in the queue. Would it help to have the position in the queue placed into a custome SIP header, when sending the INVITE to the message_queue URL ? or to the welcome message ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 12:06, Jonathan Hunter wrote: Hello Bogdan, Thanks for the response. In terms of my question, with a number of queuing platforms, they have the capability to tell the caller, what position they are in , and when they are likely to be answered. I just wondered if this logic was already within the module, or if I would need to use an external code/script to facilitate this function? As I presume call_center tracks the number of calls currently in a queue ? I would then want to be able to extract that information, and if a caller was for example in 3rd place in a queue, I could inject the relevant audio from freeswitch to tell them their current position? Does that make sense? :) Just wanted to know if its something this module can do? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: users at lists.opensips.org; hunterj91 at hotmail.com From: bogdan at opensips.org Date: Wed, 12 Oct 2016 11:23:45 +0300 Hello Jon, The message_queue is a SIP URI pointing to an audio announcement to play to roll of the waiting/in-queue playback. This needs to be an announcements that never ends (from the perspective of the media server); only the the OpenSIPS Queue may terminate the playback, when it decides to take out the call from waiting and to deliver it to an agent. As for your question, I'm not sure I understand what you mean by "inject a message with queue position for the caller in question" - could you detail please ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11.10.2016 13:36, Jonathan Hunter wrote: Hi guys, I have implemented an opensips/freeswitch environment, and I wish to add call queues to it, and I like the look of call_center, so just checking this out in comparison to mod_callcenter in FS world. My main question is if using the call_center module if you can inject a message with queue position for the caller in question, as I cant see that in documentation, I only see message_queue which I assume could be used to report the callers position, but just wondered if anyone has done this and if they could give me some tips as to if possible? Many thanks Jon _______________________________________________ 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: From koce at mentalchallenge.tk Wed Nov 2 11:14:09 2016 From: koce at mentalchallenge.tk (koce) Date: Wed, 2 Nov 2016 11:14:09 +0100 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position (Jonathan Hunter) In-Reply-To: References: Message-ID: Hello I recently started to explore call_center module and I think that it might not be patch related. here is my experience. I downloaded opensips branch 2.2 commit c8a605b. when agent is registered and there are no clients in line/queue the caller gets connected to the agent almost instantly and everything works fine. If the agent is in wrapup_time and I call again the same flow/queue I get send to the media server and moh starts streaming. Now when the wrapup_time finishes and the caller needs to be connected to the agent or somewhere earlier before that opensips crashes and caller is stuck in moh stream. but if there is no call during wrapup_time period and I call again everything works fine. tested with 1 agent in 2 flows, 1 user and asterisk as media server to stream moh sorry if I high jacket this thread but I think it's relevant to the crash Jonathan Hunter is experiencing. ====================================================== last few log lines from the crash Nov 2 08:01:12 opensips /sbin/opensips[12152]: b2b_reply BYE : [F=sip:user01 at opensips.test R= D=UA= IP=(192.168.116.125:5060 192.168.116.125:5060) ID=B2B.323.7879765.1478070026] Nov 2 08:01:20 opensips /sbin/opensips[12151]: CALLCENTER MODULE: [F=sip:user01 at opensips.test R=sip:english at opensips.test D= M=INVITE IP=(192.168.69.114:39336 192.168.116.125:5060) ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] Nov 2 08:01:20 opensips /sbin/opensips[12151]: INFO:b2b_logic:b2bl_add_client: adding entity [0xb33c9c4c]->[B2B.464.2920496.1478070079] to tuple [0xb33c9d40]->[13.0] Nov 2 08:01:20 opensips /sbin/opensips[12152]: INFO:b2b_logic:b2b_add_dlginfo: Dialog pair: [zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] - [B2B.464.2920496.1478070079] Nov 2 08:01:20 opensips /sbin/opensips[12152]: b2b_reply INVITE : [F=sip:user01 at opensips.test R= D= UA= IP=(192.168.117.100:5065 192.168.116.125:5060) ID=B2B.464.2920496.1478070079] Nov 2 08:01:21 opensips /sbin/opensips[12152]: b2b_request ACK : [F=sip:user01 at opensips.test R=sip:192.168.116.125:5060 D= UA= IP=(192.168.69.114:39336 192.168.116.125:5060) ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] Nov 2 08:01:25 opensips /sbin/opensips[12152]: b2b_request INVITE : [F=sip:user01 at opensips.test R=sip:192.168.116.125:5060 D= UA= IP=(192.168.69.114:39336 192.168.116.125:5060) ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] Nov 2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: child process 12152 exited by a signal 11 Nov 2 08:01:26 opensips /sbin/opensips[12181]: CRITICAL:core:receive_fd: EOF on 34 Nov 2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: core was generated Nov 2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: terminating due to SIGCHLD Nov 2 08:01:26 opensips /sbin/opensips[12181]: INFO:core:sig_usr: signal 15 received Nov 2 08:01:26 opensips /sbin/opensips[12173]: INFO:core:sig_usr: signal 15 received On 11/02/2016 10:33 AM, users-request at lists.opensips.org wrote: > Re: opensips 2.1 call_center queue position (Jonathan Hunter) From dawid.mielnik at gmail.com Wed Nov 2 22:16:36 2016 From: dawid.mielnik at gmail.com (Dawid Mielnik) Date: Wed, 2 Nov 2016 22:16:36 +0100 Subject: [OpenSIPS-Users] tcp io logs, loop Message-ID: Hi, I have a reduntant OpenSIPS 2.2.1 setup with clusterer and binary interface replication. TCP is not used for SIP. A few times I have observed debug log being flooded with messages like these below. What is causing them ? Should I be worried ? How to get rid of this issue ? Oct 17 11:25:56.281436 DEB 4315 DBG:maxfwd:is_maxfwd_present: value = 70 Oct 17 11:25:56.281481 DEB 4315 DBG:uri:has_totag: no totag Oct 17 11:25:56.281492 DEB 4315 DBG:siptrace:sip_trace_w: can't trace dialog! Will try to trace transaction Oct 17 11:25:56.281498 DEB 4315 DBG:siptrace:sip_trace_w: tracing transaction! Oct 17 11:25:56.281502 DEB 4315 DBG:core:parse_to_param: tag=as09518802 Oct 17 11:25:56.281507 DEB 4315 DBG:core:parse_to: end of header reached, state=29 Oct 17 11:25:56.281511 DEB 4315 DBG:core:parse_to: display={"asterisk"}, ruri={sip:asterisk at XX.XX.XXX.253} Oct 17 11:25:56.281516 DEB 4315 DBG:core:parse_headers: flags=40 Oct 17 11:25:56.281521 DEB 4315 DBG:siptrace:sip_trace: sip_trace called Oct 17 11:25:56.281525 DEB 4315 DBG:siptrace:pipport2su: proto 17, host XX.XX.XXX.253 , port 5060 Oct 17 11:25:56.281530 DEB 4315 DBG:siptrace:pipport2su: proto 17, host XX.XX.XXX.250 , port 5060 Oct 17 11:25:56.281535 DEB 4315 DBG:core:mk_proxy: doing DNS lookup... Oct 17 11:25:56.281539 DEB 4315 DBG:core:comp_scriptvar: int 20 : 5060 / 5060 Oct 17 11:25:56.281543 DEB 4315 DBG:core:parse_headers: flags=ffffffffffffffff Oct 17 11:25:56.281548 DEB 4315 DBG:core:check_ip_address: params XX.XX.XXX.253, XX.XX.XXX.253, 0 Oct 17 11:25:56.281552 DEB 4315 DBG:core:parse_headers: flags=40 Oct 17 11:25:56.281570 DEB 4315 DBG:siptrace:pipport2su: proto 17, host XX.XX.XXX.250 , port 5060 Oct 17 11:25:56.281576 DEB 4315 DBG:siptrace:pipport2su: proto 17, host XX.XX.XXX.253 , port 5060 Oct 17 11:25:56.281581 DEB 4315 DBG:core:mk_proxy: doing DNS lookup... Oct 17 11:25:56.281664 DEB 4315 DBG:core:destroy_avp_list: destroying list (nil) Oct 17 11:25:56.281673 DEB 4315 DBG:core:receive_msg: cleaning up Oct 17 11:25:58.515305 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.515378 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.515387 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.515792 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.515814 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.515820 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:58.515825 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:58.515830 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:58.515835 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:58.515840 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:58.515844 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:58.515856 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.515861 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.516050 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.516163 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.516187 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.516193 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:58.516198 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:58.516203 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:58.516208 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:58.516332 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:58.516343 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:58.516349 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.516353 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.516358 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.516431 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.516439 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.516445 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:58.516449 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:58.516454 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:58.516459 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:58.516644 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:58.516660 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:58.516666 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.516671 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.516676 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.516739 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.516751 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.516756 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:58.516760 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:58.516765 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:58.516769 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:58.516826 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:58.516843 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:58.516849 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.516854 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.516859 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.516880 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.516886 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.516891 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:58.516896 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:58.516918 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:58.516925 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:58.516976 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:58.516984 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:58.517026 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.517043 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.517049 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.517072 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.517079 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.517084 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:58.517089 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:58.517094 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:58.517098 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:58.517186 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:58.517203 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:58.517209 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.517214 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.517218 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.517354 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.517375 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.517381 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:58.517386 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:58.517405 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:58.517411 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:58.517528 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:58.517545 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:58.517551 DEB 4335 DBG:core:handle_tcpconn_ev: data available on 0x7f2da0d453c8 48 Oct 17 11:25:58.517556 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called Oct 17 11:25:58.517560 DEB 4335 DBG:core:send2child: to tcp child 0 0(4327), 0x7f2da0d453c8 rw 1 Oct 17 11:25:58.517705 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:58.517726 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:58.517732 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 ... Oct 17 11:25:59.398295 DEB 4327 DBG:core:handle_io: We have received conn 0x7f2da0d453c8 with rw 1 on fd 8 Oct 17 11:25:59.398335 DEB 4327 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 Oct 17 11:25:59.398344 DEB 4327 DBG:core:tcp_receive_timeout: 0x7f2da0d453c8 expired - (221, 222) lt=221 Oct 17 11:25:59.398352 DEB 4327 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called Oct 17 11:25:59.398361 DEB 4327 DBG:core:tcpconn_release: releasing con 0x7f2da0d453c8, state 0, fd=-1, id=1 Oct 17 11:25:59.398369 DEB 4327 DBG:core:tcpconn_release: extra_data (nil) Oct 17 11:25:59.398380 DEB 4335 DBG:core:handle_tcp_worker: reader response= 7f2da0d453c8, 0 from 0 Oct 17 11:25:59.398406 DEB 4335 DBG:core:io_watch_add: [TCP_main] io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), fd_no=35/1024 Oct 17 11:25:59.398423 DEB 4335 DBG:core:__tcpconn_lifetime: timeout for hash=1 - 0x7f2da0d453c8 (223 > 221) Oct 17 11:25:59.398429 DEB 4335 DBG:core:io_watch_del: [TCP_main] io_watch_del op on index -1 48 (0x83b1c0, 48, -1, 0x10,0x3) fd_no=36 called Best regards, Dawid -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Nov 3 09:11:09 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 3 Nov 2016 10:11:09 +0200 Subject: [OpenSIPS-Users] tcp io logs, loop In-Reply-To: References: Message-ID: <01ac7f5b-7e4b-3c5c-fb78-29cd17a7b1b4@opensips.org> Hi, Dawid! Those are simply debug messages from the process's internal reactor. There is nothing wrong with them, it simply proves the TCP interface (for bin replication) is working properly. Unless there is no ERROR, WARNING, CRITICAL logs, there is nothing to worry about. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/02/2016 11:16 PM, Dawid Mielnik wrote: > Hi, > > I have a reduntant OpenSIPS 2.2.1 setup with clusterer and binary > interface replication. TCP is not used for SIP. A few times I have > observed debug log being flooded with messages like these below. > What is causing them ? Should I be worried ? How to get rid of this > issue ? > > Oct 17 11:25:56.281436 DEB 4315 DBG:maxfwd:is_maxfwd_present: value = 70 > Oct 17 11:25:56.281481 DEB 4315 DBG:uri:has_totag: no totag > Oct 17 11:25:56.281492 DEB 4315 DBG:siptrace:sip_trace_w: can't trace > dialog! Will try to trace transaction > Oct 17 11:25:56.281498 DEB 4315 DBG:siptrace:sip_trace_w: tracing > transaction! > Oct 17 11:25:56.281502 DEB 4315 DBG:core:parse_to_param: tag=as09518802 > Oct 17 11:25:56.281507 DEB 4315 DBG:core:parse_to: end of header > reached, state=29 > Oct 17 11:25:56.281511 DEB 4315 DBG:core:parse_to: > display={"asterisk"}, ruri={sip:asterisk at XX.XX.XXX.253} > Oct 17 11:25:56.281516 DEB 4315 DBG:core:parse_headers: flags=40 > Oct 17 11:25:56.281521 DEB 4315 DBG:siptrace:sip_trace: sip_trace called > Oct 17 11:25:56.281525 DEB 4315 DBG:siptrace:pipport2su: proto 17, > host XX.XX.XXX.253 , port 5060 > Oct 17 11:25:56.281530 DEB 4315 DBG:siptrace:pipport2su: proto 17, > host XX.XX.XXX.250 , port 5060 > Oct 17 11:25:56.281535 DEB 4315 DBG:core:mk_proxy: doing DNS lookup... > Oct 17 11:25:56.281539 DEB 4315 DBG:core:comp_scriptvar: int 20 : > 5060 / 5060 > Oct 17 11:25:56.281543 DEB 4315 DBG:core:parse_headers: > flags=ffffffffffffffff > Oct 17 11:25:56.281548 DEB 4315 DBG:core:check_ip_address: params > XX.XX.XXX.253, XX.XX.XXX.253, 0 > Oct 17 11:25:56.281552 DEB 4315 DBG:core:parse_headers: flags=40 > Oct 17 11:25:56.281570 DEB 4315 DBG:siptrace:pipport2su: proto 17, > host XX.XX.XXX.250 , port 5060 > Oct 17 11:25:56.281576 DEB 4315 DBG:siptrace:pipport2su: proto 17, > host XX.XX.XXX.253 , port 5060 > Oct 17 11:25:56.281581 DEB 4315 DBG:core:mk_proxy: doing DNS lookup... > Oct 17 11:25:56.281664 DEB 4315 DBG:core:destroy_avp_list: destroying > list (nil) > Oct 17 11:25:56.281673 DEB 4315 DBG:core:receive_msg: cleaning up > Oct 17 11:25:58.515305 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.515378 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.515387 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.515792 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.515814 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.515820 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.515825 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.515830 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.515835 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.515840 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.515844 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.515856 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.515861 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516050 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516163 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516187 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516193 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516198 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516203 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516208 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516332 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516343 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.516349 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.516353 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516358 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516431 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516439 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516445 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516449 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516454 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516459 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516644 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516660 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.516666 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.516671 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516676 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516739 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516751 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516756 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516760 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516765 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516769 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516826 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516843 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.516849 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.516854 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516859 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516880 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516886 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516891 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516896 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516918 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516925 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516976 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516984 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.517026 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.517043 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.517049 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.517072 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.517079 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.517084 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.517089 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.517094 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.517098 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.517186 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.517203 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.517209 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.517214 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.517218 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.517354 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.517375 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.517381 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.517386 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.517405 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.517411 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.517528 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.517545 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.517551 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.517556 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.517560 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.517705 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.517726 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.517732 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > > > ... > > > Oct 17 11:25:59.398295 DEB 4327 DBG:core:handle_io: We have received > conn 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:59.398335 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:59.398344 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:59.398352 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:59.398361 DEB 4327 DBG:core:tcpconn_release: releasing > con 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:59.398369 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:59.398380 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:59.398406 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:59.398423 DEB 4335 DBG:core:__tcpconn_lifetime: timeout > for hash=1 - 0x7f2da0d453c8 (223 > 221) > Oct 17 11:25:59.398429 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index -1 48 (0x83b1c0, 48, -1, 0x10,0x3) fd_no=36 > called > > Best regards, > Dawid > > > _______________________________________________ > 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: From dawid.mielnik at gmail.com Thu Nov 3 09:24:20 2016 From: dawid.mielnik at gmail.com (Dawid Mielnik) Date: Thu, 3 Nov 2016 09:24:20 +0100 Subject: [OpenSIPS-Users] tcp io logs, loop In-Reply-To: <01ac7f5b-7e4b-3c5c-fb78-29cd17a7b1b4@opensips.org> References: <01ac7f5b-7e4b-3c5c-fb78-29cd17a7b1b4@opensips.org> Message-ID: Hi Razvan, I know they are debug level but because they only happen from time to time and they really flood the log I was worried this might be some loop error. Ok then, thank you for the info! BR, Dawid On Thu, Nov 3, 2016 at 9:11 AM, R?zvan Crainea wrote: > Hi, Dawid! > > Those are simply debug messages from the process's internal reactor. There > is nothing wrong with them, it simply proves the TCP interface (for bin > replication) is working properly. Unless there is no ERROR, WARNING, > CRITICAL logs, there is nothing to worry about. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 11/02/2016 11:16 PM, Dawid Mielnik wrote: > > Hi, > > I have a reduntant OpenSIPS 2.2.1 setup with clusterer and binary > interface replication. TCP is not used for SIP. A few times I have observed > debug log being flooded with messages like these below. > What is causing them ? Should I be worried ? How to get rid of this issue ? > > Oct 17 11:25:56.281436 DEB 4315 DBG:maxfwd:is_maxfwd_present: value = 70 > Oct 17 11:25:56.281481 DEB 4315 DBG:uri:has_totag: no totag > Oct 17 11:25:56.281492 DEB 4315 DBG:siptrace:sip_trace_w: can't trace > dialog! Will try to trace transaction > Oct 17 11:25:56.281498 DEB 4315 DBG:siptrace:sip_trace_w: tracing > transaction! > Oct 17 11:25:56.281502 DEB 4315 DBG:core:parse_to_param: tag=as09518802 > Oct 17 11:25:56.281507 DEB 4315 DBG:core:parse_to: end of header reached, > state=29 > Oct 17 11:25:56.281511 DEB 4315 DBG:core:parse_to: display={"asterisk"}, > ruri={sip:asterisk at XX.XX.XXX.253} > Oct 17 11:25:56.281516 DEB 4315 DBG:core:parse_headers: flags=40 > Oct 17 11:25:56.281521 DEB 4315 DBG:siptrace:sip_trace: sip_trace called > Oct 17 11:25:56.281525 DEB 4315 DBG:siptrace:pipport2su: proto 17, host > XX.XX.XXX.253 , port 5060 > Oct 17 11:25:56.281530 DEB 4315 DBG:siptrace:pipport2su: proto 17, host > XX.XX.XXX.250 , port 5060 > Oct 17 11:25:56.281535 DEB 4315 DBG:core:mk_proxy: doing DNS lookup... > Oct 17 11:25:56.281539 DEB 4315 DBG:core:comp_scriptvar: int 20 : 5060 / > 5060 > Oct 17 11:25:56.281543 DEB 4315 DBG:core:parse_headers: > flags=ffffffffffffffff > Oct 17 11:25:56.281548 DEB 4315 DBG:core:check_ip_address: params > XX.XX.XXX.253, XX.XX.XXX.253, 0 > Oct 17 11:25:56.281552 DEB 4315 DBG:core:parse_headers: flags=40 > Oct 17 11:25:56.281570 DEB 4315 DBG:siptrace:pipport2su: proto 17, host > XX.XX.XXX.250 , port 5060 > Oct 17 11:25:56.281576 DEB 4315 DBG:siptrace:pipport2su: proto 17, host > XX.XX.XXX.253 , port 5060 > Oct 17 11:25:56.281581 DEB 4315 DBG:core:mk_proxy: doing DNS lookup... > Oct 17 11:25:56.281664 DEB 4315 DBG:core:destroy_avp_list: destroying > list (nil) > Oct 17 11:25:56.281673 DEB 4315 DBG:core:receive_msg: cleaning up > Oct 17 11:25:58.515305 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.515378 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.515387 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.515792 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.515814 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.515820 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.515825 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.515830 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.515835 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.515840 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.515844 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.515856 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.515861 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516050 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516163 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516187 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516193 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516198 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516203 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516208 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516332 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516343 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.516349 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.516353 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516358 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516431 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516439 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516445 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516449 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516454 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516459 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516644 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516660 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.516666 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.516671 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516676 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516739 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516751 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516756 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516760 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516765 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516769 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516826 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516843 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.516849 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.516854 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.516859 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.516880 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.516886 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.516891 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.516896 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.516918 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.516925 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.516976 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.516984 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.517026 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.517043 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.517049 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.517072 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.517079 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.517084 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.517089 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.517094 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.517098 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.517186 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.517203 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.517209 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.517214 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.517218 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.517354 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.517375 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.517381 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:58.517386 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:58.517405 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:58.517411 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:58.517528 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:58.517545 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:58.517551 DEB 4335 DBG:core:handle_tcpconn_ev: data > available on 0x7f2da0d453c8 48 > Oct 17 11:25:58.517556 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index 1 48 (0x83b1c0, 48, 1, 0x0,0x1) fd_no=36 called > Oct 17 11:25:58.517560 DEB 4335 DBG:core:send2child: to tcp child 0 > 0(4327), 0x7f2da0d453c8 rw 1 > Oct 17 11:25:58.517705 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:58.517726 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:58.517732 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > > > ... > > > Oct 17 11:25:59.398295 DEB 4327 DBG:core:handle_io: We have received conn > 0x7f2da0d453c8 with rw 1 on fd 8 > Oct 17 11:25:59.398335 DEB 4327 DBG:core:io_watch_add: [TCP_worker] > io_watch_add op (8 on 6) (0x83b1c0, 8, 19, 0x7f2da0d453c8,1), fd_no=2/1024 > Oct 17 11:25:59.398344 DEB 4327 DBG:core:tcp_receive_timeout: > 0x7f2da0d453c8 expired - (221, 222) lt=221 > Oct 17 11:25:59.398352 DEB 4327 DBG:core:io_watch_del: [TCP_worker] > io_watch_del op on index -1 8 (0x83b1c0, 8, -1, 0x10,0x1) fd_no=3 called > Oct 17 11:25:59.398361 DEB 4327 DBG:core:tcpconn_release: releasing con > 0x7f2da0d453c8, state 0, fd=-1, id=1 > Oct 17 11:25:59.398369 DEB 4327 DBG:core:tcpconn_release: extra_data > (nil) > Oct 17 11:25:59.398380 DEB 4335 DBG:core:handle_tcp_worker: reader > response= 7f2da0d453c8, 0 from 0 > Oct 17 11:25:59.398406 DEB 4335 DBG:core:io_watch_add: [TCP_main] > io_watch_add op (48 on 6) (0x83b1c0, 48, 19, 0x7f2da0d453c8,1), > fd_no=35/1024 > Oct 17 11:25:59.398423 DEB 4335 DBG:core:__tcpconn_lifetime: timeout for > hash=1 - 0x7f2da0d453c8 (223 > 221) > Oct 17 11:25:59.398429 DEB 4335 DBG:core:io_watch_del: [TCP_main] > io_watch_del op on index -1 48 (0x83b1c0, 48, -1, 0x10,0x3) fd_no=36 called > > Best regards, > Dawid > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://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: From razvan at opensips.org Thu Nov 3 09:35:49 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 3 Nov 2016 10:35:49 +0200 Subject: [OpenSIPS-Users] tcp io logs, loop In-Reply-To: References: <01ac7f5b-7e4b-3c5c-fb78-29cd17a7b1b4@opensips.org> Message-ID: Hi, Dawid! That log appears when you have traffic. If you stop the traffic and you're still seeing those debug messages, then that might be a problem. BR R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/03/2016 10:24 AM, Dawid Mielnik wrote: > Hi Razvan, > > I know they are debug level but because they only happen from time to > time and they really flood the log I was worried this might be some > loop error. > Ok then, thank you for the info! > > BR, > Dawid > > > On Thu, Nov 3, 2016 at 9:11 AM, R?zvan Crainea > wrote: > > Hi, Dawid! > > Those are simply debug messages from the process's internal > reactor. There is nothing wrong with them, it simply proves the > TCP interface (for bin replication) is working properly. Unless > there is no ERROR, WARNING, CRITICAL logs, there is nothing to > worry about. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/02/2016 11:16 PM, Dawid Mielnik wrote: >> Hi, >> >> I have a reduntant OpenSIPS 2.2.1 setup with clusterer and binary >> interface replication. TCP is not used for SIP. A few times I >> have observed debug log being flooded with messages like these below. >> What is causing them ? Should I be worried ? How to get rid of >> this issue ? >> >> Oct 17 11:25:56.281436 DEB 4315 DBG:maxfwd:is_maxfwd_present: >> value = 70 >> Oct 17 11:25:56.281481 DEB 4315 DBG:uri:has_totag: no totag >> Oct 17 11:25:56.281492 DEB 4315 DBG:siptrace:sip_trace_w: can't >> trace dialog! Will try to trace transaction >> Oct 17 11:25:56.281498 DEB 4315 DBG:siptrace:sip_trace_w: >> tracing transaction! >> Oct 17 11:25:56.281502 DEB 4315 DBG:core:parse_to_param: >> tag=as09518802 >> Oct 17 11:25:56.281507 DEB 4315 DBG:core:parse_to: end of header >> reached, state=29 >> Oct 17 11:25:56.281511 DEB 4315 DBG:core:parse_to: >> display={"asterisk"}, ruri={sip:asterisk at XX.XX.XXX >> .253} >> Oct 17 11:25:56.281516 DEB 4315 DBG:core:parse_headers: flags=40 >> Oct 17 11:25:56.281521 DEB 4315 DBG:siptrace:sip_trace: >> sip_trace called >> Oct 17 11:25:56.281525 DEB 4315 DBG:siptrace:pipport2su: proto >> 17, host XX.XX.XXX.253 , port 5060 >> Oct 17 11:25:56.281530 DEB 4315 DBG:siptrace:pipport2su: proto >> 17, host XX.XX.XXX.250 , port 5060 >> Oct 17 11:25:56.281535 DEB 4315 DBG:core:mk_proxy: doing DNS >> lookup... >> Oct 17 11:25:56.281539 DEB 4315 DBG:core:comp_scriptvar: int 20 >> : 5060 / 5060 >> Oct 17 11:25:56.281543 DEB 4315 DBG:core:parse_headers: >> flags=ffffffffffffffff >> Oct 17 11:25:56.281548 DEB 4315 DBG:core:check_ip_address: >> params XX.XX.XXX.253, XX.XX.XXX.253, 0 >> Oct 17 11:25:56.281552 DEB 4315 DBG:core:parse_headers: flags=40 >> Oct 17 11:25:56.281570 DEB 4315 DBG:siptrace:pipport2su: proto >> 17, host XX.XX.XXX.250 , port 5060 >> Oct 17 11:25:56.281576 DEB 4315 DBG:siptrace:pipport2su: proto >> 17, host XX.XX.XXX.253 , port 5060 >> Oct 17 11:25:56.281581 DEB 4315 DBG:core:mk_proxy: doing DNS >> lookup... >> Oct 17 11:25:56.281664 DEB 4315 DBG:core:destroy_avp_list: >> destroying list (nil) >> Oct 17 11:25:56.281673 DEB 4315 DBG:core:receive_msg: cleaning up >> Oct 17 11:25:58.515305 DEB 4335 DBG:core:handle_tcpconn_ev: data >> available on 0x7f2da0d453c8 48 >> Oct 17 11:25:58.515378 DEB 4335 DBG:core:io_watch_del: >> [TCP_main] io_watch_del op on index 1 48 (0x83b1c0, 48, 1, >> 0x0,0x1) fd_no=36 called >> Oct 17 11:25:58.515387 DEB 4335 DBG:core:send2child: to tcp >> child 0 0(4327), 0x7f2da0d453c8 rw 1 >> Oct 17 11:25:58.515792 DEB 4327 DBG:core:handle_io: We have >> received conn 0x7f2da0d453c8 with rw 1 on fd 8 >> Oct 17 11:25:58.515814 DEB 4327 DBG:core:io_watch_add: >> [TCP_worker] io_watch_add op (8 on 6) (0x83b1c0, 8, 19, >> 0x7f2da0d453c8,1), fd_no=2/1024 >> Oct 17 11:25:58.515820 DEB 4327 DBG:core:tcp_receive_timeout: >> 0x7f2da0d453c8 expired - (221, 222) lt=221 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dawid.mielnik at gmail.com Thu Nov 3 10:09:55 2016 From: dawid.mielnik at gmail.com (Dawid Mielnik) Date: Thu, 3 Nov 2016 10:09:55 +0100 Subject: [OpenSIPS-Users] Dialog replication problems In-Reply-To: References: Message-ID: Anyone ? I have just upgraded to the latest 2.2 version form GIT and am still experiencing this. active server: dialog:: hash=*2297:947327686* dialog_id=9866487206598 state:: 4 user_flags:: 0 timestart:: 1478162278 datestart:: 2016-11-03 09:37:58 timeout:: 1478183878 dateout:: 2016-11-03 15:37:58 callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY from_uri:: sip:+48226522655 at XXX.XXX.XXX.250 to_uri:: sip:+48501657887 at XXX.XXX.XXX.250 caller_tag:: 86343576 caller_contact:: sip:+48226522655 at ZZZ.ZZZ.ZZZ.34 :60603;rinstance=eab8d8723e64bbad callee_cseq:: 0 caller_route_set:: caller_bind_addr:: udp:XXX.XXX.XXX.250:5061 caller_sdp:: CALLEES:: callee:: callee_tag:: 192571 callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP caller_cseq:: 1 callee_route_set:: callee_bind_addr:: udp:XXX.XXX.XXX.250:5060 callee_sdp:: ... standby server: dialog:: hash=*2297:1952115624* dialog_id=9867491994536 state:: 4 user_flags:: 0 timestart:: 1478162278 datestart:: 2016-11-03 09:37:58 timeout:: 1478183877 dateout:: 2016-11-03 15:37:57 callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY from_uri:: sip:+48226522655 at XXX.XXX.XXX.250 to_uri:: sip:+48501657887 at XXX.XXX.XXX.250 caller_tag:: 86343576 caller_contact:: sip:+48226522655 at ZZZ.ZZZ.ZZZ.34 :60603;rinstance=eab8d8723e64bbad callee_cseq:: 0 caller_route_set:: caller_bind_addr:: udp:XXX.XXX.XXX.250:5061 caller_sdp:: CALLEES:: callee:: callee_tag:: 192571 callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP caller_cseq:: 1 callee_route_set:: callee_bind_addr:: udp:XXX.XXX.XXX.250:5060 callee_sdp:: ... After switch-over BYE is received on the standby server: Nov 3 09:44:38.571442 DEB 10180 DBG:core:parse_msg: SIP Request: Nov 3 09:44:38.571471 DEB 10180 DBG:core:parse_msg: method: Nov 3 09:44:38.571475 DEB 10180 DBG:core:parse_msg: uri: Nov 3 09:44:38.571479 DEB 10180 DBG:core:parse_msg: version: ... Nov 3 09:44:38.571809 DEB 10180 DBG:dialog:w_match_dialog: We found DID param in R-URI with value of 9f8.6c217783 Nov 3 09:44:38.571812 DEB 10180 DBG:dialog:dlg_onroute: route param is '9f8.6c217783' (len=12) Nov 3 09:44:38.571814 DEB 10180 DBG:dialog:lookup_dlg: *no dialog id=947327686 found on entry 2297* Nov 3 09:44:38.571816 DEB 10180 DBG:dialog:dlg_onroute: unable to find dialog for BYE with route param '9f8.6c217783' ... Is this normal behaviour that dialog hash (and recently added dialog id) are different on the replicated server ? BR, Dawid On Wed, Oct 26, 2016 at 4:43 PM, Dawid Mielnik wrote: > Hi All, > > I have a reduntant OpenSIPS 2.2.1 setup with clusterer, binary interface > replication and a floating IP. I am encountering a few niuances and am > wondering if I am doing something wrong or if there is a bug. > > 1) Replicated dialog hash id is different on the standby server from the > active server > > active: > > dialog:: hash=637:902131071 > state:: 4 > user_flags:: 0 > timestart:: 1477413837 > datestart:: 2016-10-25 18:43:57 > timeout:: 1477435437 > dateout:: 2016-10-26 00:43:57 > callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg > ... > > standby: > > dialog:: hash=637:902131072 > state:: 4 > user_flags:: 0 > timestart:: 1477413837 > datestart:: 2016-10-25 18:43:57 > timeout:: 1477435438 > dateout:: 2016-10-26 00:43:58 > callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg > ... > > When a switch overoccurs during a dialog, and a request is received on the > second server the dialog can not be matched by the DID param and has to > fall back to looking for other SIP elements. > > DBG:dialog:lookup_dlg: no dialog id=902131071 found on entry 637 > DBG:dialog:dlg_onroute: unable to find dialog for BYE with route param > 'd72.f7d65c53' > > 2) No CDR on the standby server after switch over > > When a switch over occurs during a dialog CDR is not generated at the end > of the call (I have to do it manually). I to not see any run_dlg_callbacks > info in debug logs although the replicated dialog seems to have all the acc > flags. > > active: > > dialog:: hash=637:902131071 > ... > values:: > accX_table:: acc > accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00 > accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655 > \x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024 > accX_leg:: \x00\x00\x00\x00 > accX_core:: \x06\x00INVITE\b\x0004027a21\x01\x0030\ > x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\ > x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\ > x07\x00\x00\x00\x00\x00 > ... > accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00 > ... > standby: > > dialog:: hash=637:902131072 > ... > values:: > accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00 > ... > accX_core:: \x06\x00INVITE\b\x0004027a21\x01\x0030\ > x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\ > x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\ > x07\x00\x00\x00\x00\x00 > accX_leg:: \x00\x00\x00\x00 > accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655 > \x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024 > accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00 > accX_table:: acc > ... > > My relevant config: > #### DIALOG module > loadmodule "dialog.so" > > modparam("dialog", "dlg_match_mode", 1) > modparam("dialog", "default_timeout", 21600) # 6 hours timeout > modparam("dialog", "db_mode", 0) > modparam("dialog", "accept_replicated_dialogs", 1) > modparam("dialog", "replicate_dialogs_to", 1) > #modparam("dialog", "accept_replicated_profiles", 1) > #modparam("dialog", "replicate_profiles_to", 1) > modparam("dialog", "profiles_with_value", "trunkCalls") > modparam("dialog", "options_ping_interval", 60) > > #### CLUSTERER module > loadmodule "clusterer.so" > modparam("clusterer", "db_url", "text:///usr/local/etc/opensips") > modparam("clusterer", "server_id", 2) #2 or 1 depending on node > > > # for initial requests > do_accounting("db", "cdr|missed", "acc"); > > > Has anyone experienced similar problems ? Is there something that I am > missing ? > > Best regards, > Dawid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Nov 3 11:27:23 2016 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 3 Nov 2016 12:27:23 +0200 Subject: [OpenSIPS-Users] Dialog replication problems In-Reply-To: References: Message-ID: Hi, Dawid! I have looked into the problem and also managed to come up with a fix! Could you please go to your OpenSIPS 2.2 source code directory, apply the below patch, recompile the dialog module and see if it fixes the problem? git apply <(base64 -d < Anyone ? > > I have just upgraded to the latest 2.2 version form GIT and am still > experiencing this. > > active server: > > dialog:: hash=*2297:947327686* dialog_id=9866487206598 > state:: 4 > user_flags:: 0 > timestart:: 1478162278 > datestart:: 2016-11-03 09:37:58 > timeout:: 1478183878 > dateout:: 2016-11-03 15:37:58 > callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY > from_uri:: sip:+48226522655 at XXX.XXX.XXX.250 > to_uri:: sip:+48501657887 at XXX.XXX.XXX.250 > caller_tag:: 86343576 > caller_contact:: > sip:+48226522655 at ZZZ.ZZZ.ZZZ.34:60603;rinstance=eab8d8723e64bbad > callee_cseq:: 0 > caller_route_set:: > caller_bind_addr:: udp:XXX.XXX.XXX.250:5061 > caller_sdp:: > CALLEES:: > callee:: > callee_tag:: 192571 > callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP > caller_cseq:: 1 > callee_route_set:: > callee_bind_addr:: udp:XXX.XXX.XXX.250:5060 > callee_sdp:: > ... > > standby server: > > dialog:: hash=*2297:1952115624* dialog_id=9867491994536 > state:: 4 > user_flags:: 0 > timestart:: 1478162278 > datestart:: 2016-11-03 09:37:58 > timeout:: 1478183877 > dateout:: 2016-11-03 15:37:57 > callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY > from_uri:: sip:+48226522655 at XXX.XXX.XXX.250 > to_uri:: sip:+48501657887 at XXX.XXX.XXX.250 > caller_tag:: 86343576 > caller_contact:: > sip:+48226522655 at ZZZ.ZZZ.ZZZ.34:60603;rinstance=eab8d8723e64bbad > callee_cseq:: 0 > caller_route_set:: > caller_bind_addr:: udp:XXX.XXX.XXX.250:5061 > caller_sdp:: > CALLEES:: > callee:: > callee_tag:: 192571 > callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP > caller_cseq:: 1 > callee_route_set:: > callee_bind_addr:: udp:XXX.XXX.XXX.250:5060 > callee_sdp:: > ... > > After switch-over BYE is received on the standby server: > > Nov 3 09:44:38.571442 DEB 10180 DBG:core:parse_msg: SIP Request: > Nov 3 09:44:38.571471 DEB 10180 DBG:core:parse_msg: method: > Nov 3 09:44:38.571475 DEB 10180 DBG:core:parse_msg: uri: > > Nov 3 09:44:38.571479 DEB 10180 DBG:core:parse_msg: version: > ... > Nov 3 09:44:38.571809 DEB 10180 DBG:dialog:w_match_dialog: We found > DID param in R-URI with value of 9f8.6c217783 > Nov 3 09:44:38.571812 DEB 10180 DBG:dialog:dlg_onroute: route param > is '9f8.6c217783' (len=12) > Nov 3 09:44:38.571814 DEB 10180 DBG:dialog:lookup_dlg: *no dialog > id=947327686 found on entry 2297* > Nov 3 09:44:38.571816 DEB 10180 DBG:dialog:dlg_onroute: unable to > find dialog for BYE with route param '9f8.6c217783' > ... > > > Is this normal behaviour that dialog hash (and recently added dialog > id) are different on the replicated server ? > > BR, > Dawid > > On Wed, Oct 26, 2016 at 4:43 PM, Dawid Mielnik > > wrote: > > Hi All, > > I have a reduntant OpenSIPS 2.2.1 setup with clusterer, binary > interface replication and a floating IP. I am encountering a few > niuances and am wondering if I am doing something wrong or if > there is a bug. > > 1) Replicated dialog hash id is different on the standby server > from the active server > > active: > > dialog:: hash=637:902131071 > state:: 4 > user_flags:: 0 > timestart:: 1477413837 > datestart:: 2016-10-25 18:43:57 > timeout:: 1477435437 > dateout:: 2016-10-26 00:43:57 > callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg > ... > > standby: > > dialog:: hash=637:902131072 > state:: 4 > user_flags:: 0 > timestart:: 1477413837 > datestart:: 2016-10-25 18:43:57 > timeout:: 1477435438 > dateout:: 2016-10-26 00:43:58 > callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg > ... > > When a switch overoccurs during a dialog, and a request is > received on the second server the dialog can not be matched by the > DID param and has to fall back to looking for other SIP elements. > > DBG:dialog:lookup_dlg: no dialog id=902131071 found on entry 637 > DBG:dialog:dlg_onroute: unable to find dialog for BYE with route > param 'd72.f7d65c53' > > 2) No CDR on the standby server after switch over > > When a switch over occurs during a dialog CDR is not generated at > the end of the call (I have to do it manually). I to not see any > run_dlg_callbacks info in debug logs although the replicated > dialog seems to have all the acc flags. > > active: > > dialog:: hash=637:902131071 > ... > values:: > accX_table:: acc > accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00 > accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655 > \f\x00+48226522655 > \x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024 > accX_leg:: \x00\x00\x00\x00 > accX_core:: > \x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00 > ... > accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00 > ... > standby: > > dialog:: hash=637:902131072 > ... > values:: > accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00 > ... > accX_core:: > \x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00 > accX_leg:: \x00\x00\x00\x00 > accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655 > \f\x00+48226522655 > \x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024 > accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00 > accX_table:: acc > ... > > My relevant config: > #### DIALOG module > loadmodule "dialog.so" > > modparam("dialog", "dlg_match_mode", 1) > modparam("dialog", "default_timeout", 21600) # 6 hours timeout > modparam("dialog", "db_mode", 0) > modparam("dialog", "accept_replicated_dialogs", 1) > modparam("dialog", "replicate_dialogs_to", 1) > #modparam("dialog", "accept_replicated_profiles", 1) > #modparam("dialog", "replicate_profiles_to", 1) > modparam("dialog", "profiles_with_value", "trunkCalls") > modparam("dialog", "options_ping_interval", 60) > > #### CLUSTERER module > loadmodule "clusterer.so" > modparam("clusterer", "db_url", "text:///usr/local/etc/opensips") > modparam("clusterer", "server_id", 2) #2 or 1 depending on node > > > # for initial requests > do_accounting("db", "cdr|missed", "acc"); > > > Has anyone experienced similar problems ? Is there something that > I am missing ? > > Best regards, > Dawid > > > > > _______________________________________________ > 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: From bogdan at opensips.org Thu Nov 3 11:34:06 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 3 Nov 2016 12:34:06 +0200 Subject: [OpenSIPS-Users] Routing in opensips In-Reply-To: References: <5bf7c4cc-285a-2a7a-f5fe-62cbc4601e1d@opensips.org> <9a3d5834-6396-ca9e-898b-21e31cd8b661@opensips.org> Message-ID: Hi Eric, First of all, have you managed to get the SIP reply back ? I guess this was the original issue. If this works, we can move on to solving the RTP part too. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 02.11.2016 22:40, Eric Freeman wrote: > > I am not clear of what I am doing. I did some googling. > > > I added the if nat_uac line to the fix_nated line. It did not fix my > issue. > > In the Invite Request Packet I see the Owner Address as the 10 address > next to the Owner Address section of the packet. The same for the > Connection information.Does that mean I didn't set up the > fix_nates_sdp correctly? Let me know if you want to see my entire > opensips.cfg file. > > > route[relay] { > > # for INVITEs enable some additional helper routes > > if (is_method("INVITE")) { > > if(nat_uac_test("8")) { > > xlog("We have incoming SDP, let's fix if it's behind NAT\n"); > > fix_nated_sdp("2"); > > } > > > t_on_branch("per_branch_ops"); > > t_on_reply("handle_nat"); > > t_on_failure("missed_call"); > > > Thank you for all of your help, > > > Eric Freeman > > Technical Director/NA for TBWA\Chiat\Day > > TBWA\Chiat\Day New York > 488 Madison Ave. > New York NY 10022 > United States of America > Tel: +12128041324 > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *Sent:* Tuesday, November 1, 2016 8:34:05 AM > *To:* Eric Freeman; users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] Routing in opensips > Eric, > > You can simply change it with the fix_nated_sdp() function: > http://www.opensips.org/html/docs/modules/2.2.x/nathelper.html#id294042 > > But you have to be careful that the IP:port you force in SDP is also > valid from IP perspective - like any RTP traffic landing on that IP is > actually getting to the right application. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 01.11.2016 14:24, Eric Freeman wrote: >> >> Thank you. I will test with that IP. How do I change the SDP to my >> public IP address so I can get RTP information back? >> >> >> Thank you, >> >> >> Eric Freeman >> >> Technical Director/NA for TBWA\Chiat\Day >> >> TBWA\Chiat\Day New York >> 488 Madison Ave. >> New York NY 10022 >> United States of America >> Tel: +12128041324 >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* Tuesday, November 1, 2016 7:10:45 AM >> *To:* Eric Freeman; users at lists.opensips.org >> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >> Hi Eric, >> >> The outgoing INVITE request looks ok - the RR and VIA headers carry >> the public IP of your OpenSIPS. You should get back some reply. Not >> sure how valid is that test server, but you can try sending to >> sip:opensips.org:5060 ( or 78.46.64.50:5060 ) - this sip server is >> definitely up . >> >> BTW, the SDP you send out is bogus as it contain only private IPs, so >> the other end point will not be able to send you ant RTP back. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 31.10.2016 14:21, Eric Freeman wrote: >>> >>> Please attached pcap file. Is this what you need? >>> >>> >>> Eric Freeman >>> >>> Technical Director/NA for TBWA\Chiat\Day >>> >>> TBWA\Chiat\Day New York >>> 488 Madison Ave. >>> New York NY 10022 >>> United States of America >>> Tel: +12128041324 >>> ------------------------------------------------------------------------ >>> *From:* Bogdan-Andrei Iancu >>> *Sent:* Monday, October 31, 2016 6:36:18 AM >>> *To:* Eric Freeman; OpenSIPS users mailling list >>> *Subject:* Re: [OpenSIPS-Users] Routing in opensips >>> Hi Eric, >>> >>> What I'm asking here is to post the full INVITE packet from your >>> opensips server to the external host - I Want to to check the SIP >>> headers and the SDP. >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 25.10.2016 16:38, Eric Freeman wrote: >>>> >>>> The opensips server is 10.88.23.13 the video conference server is >>>> 10.89.71.12. The IP I am trying to connect to 199.48.152.152, I >>>> believe is a valid host. I found it on a test SIP site on the Internet >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dawid.mielnik at gmail.com Thu Nov 3 12:02:20 2016 From: dawid.mielnik at gmail.com (Dawid Mielnik) Date: Thu, 3 Nov 2016 12:02:20 +0100 Subject: [OpenSIPS-Users] Dialog replication problems In-Reply-To: References: Message-ID: Hi Liviu, Yes - big difference with the patch : active server: dialog:: hash=3426:1456403041 dialog_id=14716014359137 state:: 4 user_flags:: 0 timestart:: 1478170024 datestart:: 2016-11-03 11:47:04 timeout:: 1478191625 dateout:: 2016-11-03 17:47:05 callid:: 81140NWQxYTg1ZWRkZDNiYzE2OGExYzI1NmE1N2Y4MjM2MTE ... standby server: dialog:: hash=3426:1456403041 dialog_id=14716014359137 state:: 4 user_flags:: 0 timestart:: 1478170024 datestart:: 2016-11-03 11:47:04 timeout:: 1478191625 dateout:: 2016-11-03 17:47:05 callid:: 81140NWQxYTg1ZWRkZDNiYzE2OGExYzI1NmE1N2Y4MjM2MTE ... BYE after switch-over: Nov 3 11:48:55.964155 DEB 29249 DBG:core:parse_msg: SIP Request: Nov 3 11:48:55.964185 DEB 29249 DBG:core:parse_msg: method: Nov 3 11:48:55.964191 DEB 29249 DBG:core:parse_msg: uri: Nov 3 11:48:55.964197 DEB 29249 DBG:core:parse_msg: version: ... Nov 3 11:48:55.964395 DEB 29249 DBG:dialog:w_match_dialog: We found DID param in R-URI with value of 26d.162fec65 Nov 3 11:48:55.964399 DEB 29249 DBG:dialog:dlg_onroute: route param is '26d.162fec65' (len=12) Nov 3 11:48:55.964437 DEB 29249 DBG:dialog:lookup_dlg: ref dlg 0x7f70c12a7b30 with 1 -> 3 Nov 3 11:48:55.964451 DEB 29249 DBG:dialog:lookup_dlg: dialog id=1456403041 found on entry 3426 ... Thank you. Also, should CDR be generated on the standby server after the switch-over ? I am still not getting those (have to keep my own variables in dialog and insert in db manually). I am using topology hiding module if that makes any difference (manual CDR generation is triggered when ( $DLG_status!=NULL && !validate_dialog() ) condition fails after which I call fix_route_dialog()).. BR, Dawd On Thu, Nov 3, 2016 at 11:27 AM, Liviu Chircu wrote: > Hi, Dawid! > > I have looked into the problem and also managed to come up with a fix! > Could you please go to your OpenSIPS 2.2 source code directory, apply the > below patch, recompile the dialog module and see if it fixes the problem? > > git apply <(base64 -d < ZGlmZiAtLWdpdCBhL21vZHVsZXMvZGlhbG9nL2RsZ19yZXBsaWNhdGlvbi5j > IGIvbW9kdWxlcy9k > aWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKaW5kZXggYTg0NTVhZi4uZGE2MmRi > NiAxMDA2NDQKLS0t > IGEvbW9kdWxlcy9kaWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKKysrIGIvbW9k > dWxlcy9kaWFsb2cv > ZGxnX3JlcGxpY2F0aW9uLmMKQEAgLTE4Miw3ICsxODIsNiBAQCBpbnQgZGxn > X3JlcGxpY2F0ZWRf > Y3JlYXRlKHN0cnVjdCBkbGdfY2VsbCAqY2VsbCwgc3RyICpmdGFnLCBzdHIg > KnR0YWcsIGludCBz > YWZlKQogCWRsZy0+bGVnc19ub1tETEdfTEVHXzIwME9LXS > A9IERMR19GSVJTVF9DQUxMRUVfTEVH > OwogCiAJLyogbGluayB0aGUgZGlhbG9nIGludG8gdGhlIGhhc2ggKi8KLQlk > bGctPmhfaWQgPSBk > X2VudHJ5LT5uZXh0X2lkKys7CiAJaWYgKCFkX2VudHJ5LT5maXJzdCkKIAkJ > ZF9lbnRyeS0+Zmly > c3QgPSBkX2VudHJ5LT5sYXN0ID0gZGxnOwogCWVsc2Ugewo= > EOF > ) > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 03.11.2016 11:09, Dawid Mielnik wrote: > > Anyone ? > > I have just upgraded to the latest 2.2 version form GIT and am still > experiencing this. > > active server: > > dialog:: hash=*2297:947327686* dialog_id=9866487206598 > state:: 4 > user_flags:: 0 > timestart:: 1478162278 > datestart:: 2016-11-03 09:37:58 > timeout:: 1478183878 > dateout:: 2016-11-03 15:37:58 > callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY > from_uri:: sip:+48226522655 at XXX.XXX.XXX.250 > to_uri:: sip:+48501657887 at XXX.XXX.XXX.250 > caller_tag:: 86343576 > caller_contact:: sip:+48226522655 at ZZZ.ZZZ.ZZZ.34:60603;rinstance= > eab8d8723e64bbad > callee_cseq:: 0 > caller_route_set:: > caller_bind_addr:: udp:XXX.XXX.XXX.250:5061 > caller_sdp:: > CALLEES:: > callee:: > callee_tag:: 192571 > callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP > caller_cseq:: 1 > callee_route_set:: > callee_bind_addr:: udp:XXX.XXX.XXX.250:5060 > callee_sdp:: > ... > > standby server: > > dialog:: hash=*2297:1952115624* dialog_id=9867491994536 > state:: 4 > user_flags:: 0 > timestart:: 1478162278 > datestart:: 2016-11-03 09:37:58 > timeout:: 1478183877 > dateout:: 2016-11-03 15:37:57 > callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY > from_uri:: sip:+48226522655 at XXX.XXX.XXX.250 > to_uri:: sip:+48501657887 at XXX.XXX.XXX.250 > caller_tag:: 86343576 > caller_contact:: sip:+48226522655 at ZZZ.ZZZ.ZZZ.34:60603;rinstance= > eab8d8723e64bbad > callee_cseq:: 0 > caller_route_set:: > caller_bind_addr:: udp:XXX.XXX.XXX.250:5061 > caller_sdp:: > CALLEES:: > callee:: > callee_tag:: 192571 > callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP > caller_cseq:: 1 > callee_route_set:: > callee_bind_addr:: udp:XXX.XXX.XXX.250:5060 > callee_sdp:: > ... > > After switch-over BYE is received on the standby server: > > Nov 3 09:44:38.571442 DEB 10180 DBG:core:parse_msg: SIP Request: > Nov 3 09:44:38.571471 DEB 10180 DBG:core:parse_msg: method: > Nov 3 09:44:38.571475 DEB 10180 DBG:core:parse_msg: uri: > > Nov 3 09:44:38.571479 DEB 10180 DBG:core:parse_msg: version: > ... > Nov 3 09:44:38.571809 DEB 10180 DBG:dialog:w_match_dialog: We found DID > param in R-URI with value of 9f8.6c217783 > Nov 3 09:44:38.571812 DEB 10180 DBG:dialog:dlg_onroute: route param is > '9f8.6c217783' (len=12) > Nov 3 09:44:38.571814 DEB 10180 DBG:dialog:lookup_dlg: *no dialog > id=947327686 found on entry 2297* > Nov 3 09:44:38.571816 DEB 10180 DBG:dialog:dlg_onroute: unable to find > dialog for BYE with route param '9f8.6c217783' > ... > > > Is this normal behaviour that dialog hash (and recently added dialog id) > are different on the replicated server ? > > BR, > Dawid > > On Wed, Oct 26, 2016 at 4:43 PM, Dawid Mielnik > wrote: > >> Hi All, >> >> I have a reduntant OpenSIPS 2.2.1 setup with clusterer, binary interface >> replication and a floating IP. I am encountering a few niuances and am >> wondering if I am doing something wrong or if there is a bug. >> >> 1) Replicated dialog hash id is different on the standby server from the >> active server >> >> active: >> >> dialog:: hash=637:902131071 >> state:: 4 >> user_flags:: 0 >> timestart:: 1477413837 >> datestart:: 2016-10-25 18:43:57 >> timeout:: 1477435437 >> dateout:: 2016-10-26 00:43:57 >> callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg >> ... >> >> standby: >> >> dialog:: hash=637:902131072 >> state:: 4 >> user_flags:: 0 >> timestart:: 1477413837 >> datestart:: 2016-10-25 18:43:57 >> timeout:: 1477435438 >> dateout:: 2016-10-26 00:43:58 >> callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg >> ... >> >> When a switch overoccurs during a dialog, and a request is received on >> the second server the dialog can not be matched by the DID param and has to >> fall back to looking for other SIP elements. >> >> DBG:dialog:lookup_dlg: no dialog id=902131071 found on entry 637 >> DBG:dialog:dlg_onroute: unable to find dialog for BYE with route param >> 'd72.f7d65c53' >> >> 2) No CDR on the standby server after switch over >> >> When a switch over occurs during a dialog CDR is not generated at the end >> of the call (I have to do it manually). I to not see any run_dlg_callbacks >> info in debug logs although the replicated dialog seems to have all the acc >> flags. >> >> active: >> >> dialog:: hash=637:902131071 >> ... >> values:: >> accX_table:: acc >> accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00 >> accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655 >> \x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024 >> accX_leg:: \x00\x00\x00\x00 >> accX_core:: \x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5Y >> zI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\ >> xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00 >> ... >> accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00 >> ... >> standby: >> >> dialog:: hash=637:902131072 >> ... >> values:: >> accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00 >> ... >> accX_core:: \x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5Y >> zI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\ >> xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00 >> accX_leg:: \x00\x00\x00\x00 >> accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655 >> \x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024 >> accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00 >> accX_table:: acc >> ... >> >> My relevant config: >> #### DIALOG module >> loadmodule "dialog.so" >> >> modparam("dialog", "dlg_match_mode", 1) >> modparam("dialog", "default_timeout", 21600) # 6 hours timeout >> modparam("dialog", "db_mode", 0) >> modparam("dialog", "accept_replicated_dialogs", 1) >> modparam("dialog", "replicate_dialogs_to", 1) >> #modparam("dialog", "accept_replicated_profiles", 1) >> #modparam("dialog", "replicate_profiles_to", 1) >> modparam("dialog", "profiles_with_value", "trunkCalls") >> modparam("dialog", "options_ping_interval", 60) >> >> #### CLUSTERER module >> loadmodule "clusterer.so" >> modparam("clusterer", "db_url", "text:///usr/local/etc/opensips") >> modparam("clusterer", "server_id", 2) #2 or 1 depending on node >> >> >> # for initial requests >> do_accounting("db", "cdr|missed", "acc"); >> >> >> Has anyone experienced similar problems ? Is there something that I am >> missing ? >> >> Best regards, >> Dawid >> >> > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://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: From bogdan at opensips.org Thu Nov 3 12:27:07 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 3 Nov 2016 13:27:07 +0200 Subject: [OpenSIPS-Users] [Tutorial] OpenSIPS Accounting in the limelight Message-ID: <39da7698-618f-84d5-3695-8286120225a4@opensips.org> Are you a beginner looking to use SIP Accounting ? or an expert looking to create improve and create complex accounting records ? The new OpenSIPS Accounting tutorial unveils how SIP accounting works in OpenSIPS, from basic to complex scenarios with custom CDR format and multi-leg accounting for call forwarding. Everything is backed up by detailed explanations and working scripts examples. http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting The accounting was never so simple to do as now, thanks to all the heavy work of our colleague Ionut Ionita. Enjoy, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com From liviu at opensips.org Thu Nov 3 13:03:46 2016 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 3 Nov 2016 14:03:46 +0200 Subject: [OpenSIPS-Users] Dialog replication problems In-Reply-To: References: Message-ID: <4cf1c0a3-95e5-c6c9-5d9c-5c81f45fa135@opensips.org> Thanks for the quick test! Will have it pushed upstream today. Transparent CDR generation for the replicated dialogs is currently not working. For that to work, the two nodes would need to _accurately_ share state (i.e. "who is the primary?"), otherwise double CDR/billing situations could occur. Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 03.11.2016 13:02, Dawid Mielnik wrote: > Hi Liviu, > > Yes - big difference with the patch : > > Also, should CDR be generated on the standby server after the > switch-over ? I am still not getting those (have to keep my own > variables in dialog and insert in db manually). I am using topology > hiding module if that makes any difference (manual CDR generation is > triggered when ( $DLG_status!=NULL && !validate_dialog() ) condition > fails after which I call fix_route_dialog()).. > > BR, > Dawd From jim at devito.cc Fri Nov 4 15:15:20 2016 From: jim at devito.cc (Jim DeVito) Date: Fri, 04 Nov 2016 07:15:20 -0700 Subject: [OpenSIPS-Users] =?utf-8?q?Strange_segfault_when_calling_check=5F?= =?utf-8?q?fraud?= Message-ID: Hi All, Wondering if you have seen something like this. It happens when calling check_fraud() like this... check_fraud("$fU", "$rU", "1"); I can reproduce it on 2 of my 3 servers. Let me know if there is other debugging info that may be needed. Thanks!! Nov 4 13:55:17 sip-proxy02 kernel: opensips[5257]: segfault at 0 ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in drouting.so[7f619d947000+38000] Nov 4 13:55:17 sip-proxy02 kernel: opensips[5256]: segfault at 0 ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in drouting.so[7f619d947000+38000] Nov 4 13:55:18 sip-proxy02 kernel: opensips[5260]: segfault at 0 ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in drouting.so[7f619d947000+38000] Nov 4 13:55:18 sip-proxy02 kernel: opensips[5254]: segfault at 0 ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in drouting.so[7f619d947000+38000] Nov 4 13:55:18 sip-proxy02 kernel: opensips[5259]: segfault at 0 ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in drouting.so[7f619d947000+38000] [root at sip-proxy02 ~]# gdb /var/tmp/core.5257 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 This GDB was configured as "x86_64-redhat-linux-gnu". BFD: Warning: /var/tmp/core.5257 is truncated: expected core file size >= 3226677248, found: 1183989760. BFD: Warning: /var/tmp/core.5257 is truncated: expected core file size >= 3226677248, found: 1183989760. [New LWP 5257] Reading symbols from /usr/sbin/opensips...Reading symbols from /usr/lib/debug/usr/sbin/opensips.debug...done. done. Cannot access memory at address 0x7f62635a71e8 Cannot access memory at address 0x7f62635a71e0 (gdb) bt full Python Exception Cannot access memory at address 0x7ffee6ccd718: [root at sip-proxy02 ~]# yum list installed | grep opensips opensips.x86_64 2.2.2-1.el7 @opensips opensips-db_mysql.x86_64 2.2.2-1.el7 @opensips opensips-debuginfo.x86_64 2.2.2-1.el7 @opensips opensips-event_route.x86_64 2.2.2-1.el7 @opensips opensips-fraud_detection.x86_64 2.2.2-1.el7 @opensips opensips-rest_client.x86_64 2.2.2-1.el7 @opensips opensips-yum-releases.noarch 2.2-3.el7 @/opensips-yum-releases-2.2-3.el7.noarch -- Jim DeVito From liviu at opensips.org Fri Nov 4 16:08:19 2016 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 4 Nov 2016 17:08:19 +0200 Subject: [OpenSIPS-Users] Strange segfault when calling check_fraud In-Reply-To: References: Message-ID: <814b558c-7315-3a57-03ce-704538698c23@opensips.org> Hi, Jim! It appears that OpenSIPS is either getting restarted too quickly or runs out of disk space before it is able to fully write the 3 GB corefile. If the size of your drouting data allows it, you could reduce the corefile size by shrinking the shared memory pool OpenSIPS starts with. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 04.11.2016 16:15, Jim DeVito wrote: > Hi All, > > Wondering if you have seen something like this. It happens when > calling check_fraud() like this... > > check_fraud("$fU", "$rU", "1"); > > I can reproduce it on 2 of my 3 servers. Let me know if there is other > debugging info that may be needed. > > Thanks!! > > Nov 4 13:55:17 sip-proxy02 kernel: opensips[5257]: segfault at 0 ip > 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in > drouting.so[7f619d947000+38000] > Nov 4 13:55:17 sip-proxy02 kernel: opensips[5256]: segfault at 0 ip > 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in > drouting.so[7f619d947000+38000] > Nov 4 13:55:18 sip-proxy02 kernel: opensips[5260]: segfault at 0 ip > 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in > drouting.so[7f619d947000+38000] > Nov 4 13:55:18 sip-proxy02 kernel: opensips[5254]: segfault at 0 ip > 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in > drouting.so[7f619d947000+38000] > Nov 4 13:55:18 sip-proxy02 kernel: opensips[5259]: segfault at 0 ip > 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in > drouting.so[7f619d947000+38000] > > [root at sip-proxy02 ~]# gdb /var/tmp/core.5257 > GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 > > This GDB was configured as "x86_64-redhat-linux-gnu". > > BFD: Warning: /var/tmp/core.5257 is truncated: expected core file size > >= 3226677248, found: 1183989760. > BFD: Warning: /var/tmp/core.5257 is truncated: expected core file size > >= 3226677248, found: 1183989760. > [New LWP 5257] > Reading symbols from /usr/sbin/opensips...Reading symbols from > /usr/lib/debug/usr/sbin/opensips.debug...done. > done. > Cannot access memory at address 0x7f62635a71e8 > Cannot access memory at address 0x7f62635a71e0 > (gdb) bt full > Python Exception Cannot access memory at > address 0x7ffee6ccd718: > > [root at sip-proxy02 ~]# yum list installed | grep opensips > opensips.x86_64 2.2.2-1.el7 @opensips > opensips-db_mysql.x86_64 2.2.2-1.el7 @opensips > opensips-debuginfo.x86_64 2.2.2-1.el7 @opensips > opensips-event_route.x86_64 2.2.2-1.el7 @opensips > opensips-fraud_detection.x86_64 2.2.2-1.el7 @opensips > opensips-rest_client.x86_64 2.2.2-1.el7 @opensips > opensips-yum-releases.noarch 2.2-3.el7 > @/opensips-yum-releases-2.2-3.el7.noarch > From jim at devito.cc Fri Nov 4 16:34:25 2016 From: jim at devito.cc (Jim DeVito) Date: Fri, 04 Nov 2016 08:34:25 -0700 Subject: [OpenSIPS-Users] =?utf-8?q?Strange_segfault_when_calling_check=5F?= =?utf-8?q?fraud?= In-Reply-To: <814b558c-7315-3a57-03ce-704538698c23@opensips.org> References: <814b558c-7315-3a57-03ce-704538698c23@opensips.org> Message-ID: Thanks for the tip Liviu! I was able to get the full core file and paseted below is the back trace. Let me know if this can help track down what is going on. http://pastebin.com/m7LfVHqJ Thanks!! --- Jim DeVito On 2016-11-04 08:08, Liviu Chircu wrote: > Hi, Jim! > > It appears that OpenSIPS is either getting restarted too quickly or > runs out of disk space before it is able to fully write the 3 GB > corefile. If the size of your drouting data allows it, you could > reduce the corefile size by shrinking the shared memory pool OpenSIPS > starts with. > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 04.11.2016 16:15, Jim DeVito wrote: >> Hi All, >> >> Wondering if you have seen something like this. It happens when >> calling check_fraud() like this... >> >> check_fraud("$fU", "$rU", "1"); >> >> I can reproduce it on 2 of my 3 servers. Let me know if there is other >> debugging info that may be needed. >> >> Thanks!! >> >> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5257]: segfault at 0 ip >> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >> drouting.so[7f619d947000+38000] >> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5256]: segfault at 0 ip >> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >> drouting.so[7f619d947000+38000] >> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5260]: segfault at 0 ip >> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >> drouting.so[7f619d947000+38000] >> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5254]: segfault at 0 ip >> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >> drouting.so[7f619d947000+38000] >> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5259]: segfault at 0 ip >> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >> drouting.so[7f619d947000+38000] >> >> [root at sip-proxy02 ~]# gdb /var/tmp/core.5257 >> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 >> >> This GDB was configured as "x86_64-redhat-linux-gnu". >> >> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file size >> >= 3226677248, found: 1183989760. >> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file size >> >= 3226677248, found: 1183989760. >> [New LWP 5257] >> Reading symbols from /usr/sbin/opensips...Reading symbols from >> /usr/lib/debug/usr/sbin/opensips.debug...done. >> done. >> Cannot access memory at address 0x7f62635a71e8 >> Cannot access memory at address 0x7f62635a71e0 >> (gdb) bt full >> Python Exception Cannot access memory at >> address 0x7ffee6ccd718: >> >> [root at sip-proxy02 ~]# yum list installed | grep opensips >> opensips.x86_64 2.2.2-1.el7 @opensips >> opensips-db_mysql.x86_64 2.2.2-1.el7 @opensips >> opensips-debuginfo.x86_64 2.2.2-1.el7 @opensips >> opensips-event_route.x86_64 2.2.2-1.el7 @opensips >> opensips-fraud_detection.x86_64 2.2.2-1.el7 >> @opensips >> opensips-rest_client.x86_64 2.2.2-1.el7 @opensips >> opensips-yum-releases.noarch 2.2-3.el7 >> @/opensips-yum-releases-2.2-3.el7.noarch >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From liviu at opensips.org Fri Nov 4 17:30:51 2016 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 4 Nov 2016 18:30:51 +0200 Subject: [OpenSIPS-Users] Strange segfault when calling check_fraud In-Reply-To: References: <814b558c-7315-3a57-03ce-704538698c23@opensips.org> Message-ID: Thank you, Jim! The backtrace is very helpful. Could you give a bit more details about how you are triggering this bug? Could it be right after you are starting OpenSIPS? Also, pasting the output of `opensips -V` could help as well. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 04.11.2016 17:34, Jim DeVito wrote: > Thanks for the tip Liviu! > > I was able to get the full core file and paseted below is the back > trace. Let me know if this can help track down what is going on. > > http://pastebin.com/m7LfVHqJ > > Thanks!! > > --- > Jim DeVito > > On 2016-11-04 08:08, Liviu Chircu wrote: >> Hi, Jim! >> >> It appears that OpenSIPS is either getting restarted too quickly or >> runs out of disk space before it is able to fully write the 3 GB >> corefile. If the size of your drouting data allows it, you could >> reduce the corefile size by shrinking the shared memory pool OpenSIPS >> starts with. >> >> Regards, >> >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> >> On 04.11.2016 16:15, Jim DeVito wrote: >>> Hi All, >>> >>> Wondering if you have seen something like this. It happens when >>> calling check_fraud() like this... >>> >>> check_fraud("$fU", "$rU", "1"); >>> >>> I can reproduce it on 2 of my 3 servers. Let me know if there is >>> other debugging info that may be needed. >>> >>> Thanks!! >>> >>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5257]: segfault at 0 ip >>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>> drouting.so[7f619d947000+38000] >>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5256]: segfault at 0 ip >>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>> drouting.so[7f619d947000+38000] >>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5260]: segfault at 0 ip >>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>> drouting.so[7f619d947000+38000] >>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5254]: segfault at 0 ip >>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>> drouting.so[7f619d947000+38000] >>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5259]: segfault at 0 ip >>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>> drouting.so[7f619d947000+38000] >>> >>> [root at sip-proxy02 ~]# gdb /var/tmp/core.5257 >>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 >>> >>> This GDB was configured as "x86_64-redhat-linux-gnu". >>> >>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>> size >= 3226677248, found: 1183989760. >>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>> size >= 3226677248, found: 1183989760. >>> [New LWP 5257] >>> Reading symbols from /usr/sbin/opensips...Reading symbols from >>> /usr/lib/debug/usr/sbin/opensips.debug...done. >>> done. >>> Cannot access memory at address 0x7f62635a71e8 >>> Cannot access memory at address 0x7f62635a71e0 >>> (gdb) bt full >>> Python Exception Cannot access memory at >>> address 0x7ffee6ccd718: >>> >>> [root at sip-proxy02 ~]# yum list installed | grep opensips >>> opensips.x86_64 2.2.2-1.el7 @opensips >>> opensips-db_mysql.x86_64 2.2.2-1.el7 @opensips >>> opensips-debuginfo.x86_64 2.2.2-1.el7 @opensips >>> opensips-event_route.x86_64 2.2.2-1.el7 @opensips >>> opensips-fraud_detection.x86_64 2.2.2-1.el7 @opensips >>> opensips-rest_client.x86_64 2.2.2-1.el7 @opensips >>> opensips-yum-releases.noarch 2.2-3.el7 >>> @/opensips-yum-releases-2.2-3.el7.noarch >>> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From jim at devito.cc Fri Nov 4 17:46:26 2016 From: jim at devito.cc (Jim DeVito) Date: Fri, 04 Nov 2016 09:46:26 -0700 Subject: [OpenSIPS-Users] =?utf-8?q?Strange_segfault_when_calling_check=5F?= =?utf-8?q?fraud?= In-Reply-To: References: <814b558c-7315-3a57-03ce-704538698c23@opensips.org> Message-ID: <43065bb66b0cbdea5612ab9b86ea082d@mail.devito.cc> Seems like it happen while opensips is still starting (loading the dr_ tables into memory) when the first INVITE comes across the check_fraud() function. I can comment out the check_fraud() and it is just fine. version: opensips 2.2.2 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. main.c compiled on 00:00:54 Oct 20 2016 with gcc 4.8.5 Thanks!! --- Jim DeVito On 2016-11-04 09:30, Liviu Chircu wrote: > Thank you, Jim! The backtrace is very helpful. > > Could you give a bit more details about how you are triggering this > bug? Could it be right after you are starting OpenSIPS? > > Also, pasting the output of `opensips -V` could help as well. > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 04.11.2016 17:34, Jim DeVito wrote: >> Thanks for the tip Liviu! >> >> I was able to get the full core file and paseted below is the back >> trace. Let me know if this can help track down what is going on. >> >> http://pastebin.com/m7LfVHqJ >> >> Thanks!! >> >> --- >> Jim DeVito >> >> On 2016-11-04 08:08, Liviu Chircu wrote: >>> Hi, Jim! >>> >>> It appears that OpenSIPS is either getting restarted too quickly or >>> runs out of disk space before it is able to fully write the 3 GB >>> corefile. If the size of your drouting data allows it, you could >>> reduce the corefile size by shrinking the shared memory pool OpenSIPS >>> starts with. >>> >>> Regards, >>> >>> Liviu Chircu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> >>> On 04.11.2016 16:15, Jim DeVito wrote: >>>> Hi All, >>>> >>>> Wondering if you have seen something like this. It happens when >>>> calling check_fraud() like this... >>>> >>>> check_fraud("$fU", "$rU", "1"); >>>> >>>> I can reproduce it on 2 of my 3 servers. Let me know if there is >>>> other debugging info that may be needed. >>>> >>>> Thanks!! >>>> >>>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5257]: segfault at 0 ip >>>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>> drouting.so[7f619d947000+38000] >>>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5256]: segfault at 0 ip >>>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>> drouting.so[7f619d947000+38000] >>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5260]: segfault at 0 ip >>>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>> drouting.so[7f619d947000+38000] >>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5254]: segfault at 0 ip >>>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>> drouting.so[7f619d947000+38000] >>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5259]: segfault at 0 ip >>>> 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>> drouting.so[7f619d947000+38000] >>>> >>>> [root at sip-proxy02 ~]# gdb /var/tmp/core.5257 >>>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 >>>> >>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>> >>>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>>> size >= 3226677248, found: 1183989760. >>>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>>> size >= 3226677248, found: 1183989760. >>>> [New LWP 5257] >>>> Reading symbols from /usr/sbin/opensips...Reading symbols from >>>> /usr/lib/debug/usr/sbin/opensips.debug...done. >>>> done. >>>> Cannot access memory at address 0x7f62635a71e8 >>>> Cannot access memory at address 0x7f62635a71e0 >>>> (gdb) bt full >>>> Python Exception Cannot access memory at >>>> address 0x7ffee6ccd718: >>>> >>>> [root at sip-proxy02 ~]# yum list installed | grep opensips >>>> opensips.x86_64 2.2.2-1.el7 @opensips >>>> opensips-db_mysql.x86_64 2.2.2-1.el7 @opensips >>>> opensips-debuginfo.x86_64 2.2.2-1.el7 @opensips >>>> opensips-event_route.x86_64 2.2.2-1.el7 @opensips >>>> opensips-fraud_detection.x86_64 2.2.2-1.el7 @opensips >>>> opensips-rest_client.x86_64 2.2.2-1.el7 @opensips >>>> opensips-yum-releases.noarch 2.2-3.el7 >>>> @/opensips-yum-releases-2.2-3.el7.noarch >>>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From liviu at opensips.org Fri Nov 4 18:15:10 2016 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 4 Nov 2016 19:15:10 +0200 Subject: [OpenSIPS-Users] Strange segfault when calling check_fraud In-Reply-To: <43065bb66b0cbdea5612ab9b86ea082d@mail.devito.cc> References: <814b558c-7315-3a57-03ce-704538698c23@opensips.org> <43065bb66b0cbdea5612ab9b86ea082d@mail.devito.cc> Message-ID: <9a0598ee-28fe-1580-9913-922a2f121e26@opensips.org> Thank you for all the help, Jim! A fix for this issue has been pushed to all 2.X versions of the git repository [1] If you prefer to use packages [2], you may want to use your distro's nighly build repos [1]: http://www.opensips.org/Downloads/Downloads#toc3 [2]: http://www.opensips.org/Downloads/Downloads#toc2 Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 04.11.2016 18:46, Jim DeVito wrote: > Seems like it happen while opensips is still starting (loading the dr_ > tables into memory) when the first INVITE comes across the > check_fraud() function. I can comment out the check_fraud() and it is > just fine. > > version: opensips 2.2.2 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > main.c compiled on 00:00:54 Oct 20 2016 with gcc 4.8.5 > > Thanks!! > > --- > Jim DeVito > > > On 2016-11-04 09:30, Liviu Chircu wrote: >> Thank you, Jim! The backtrace is very helpful. >> >> Could you give a bit more details about how you are triggering this >> bug? Could it be right after you are starting OpenSIPS? >> >> Also, pasting the output of `opensips -V` could help as well. >> >> Regards, >> >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> >> On 04.11.2016 17:34, Jim DeVito wrote: >>> Thanks for the tip Liviu! >>> >>> I was able to get the full core file and paseted below is the back >>> trace. Let me know if this can help track down what is going on. >>> >>> http://pastebin.com/m7LfVHqJ >>> >>> Thanks!! >>> >>> --- >>> Jim DeVito >>> >>> On 2016-11-04 08:08, Liviu Chircu wrote: >>>> Hi, Jim! >>>> >>>> It appears that OpenSIPS is either getting restarted too quickly or >>>> runs out of disk space before it is able to fully write the 3 GB >>>> corefile. If the size of your drouting data allows it, you could >>>> reduce the corefile size by shrinking the shared memory pool OpenSIPS >>>> starts with. >>>> >>>> Regards, >>>> >>>> Liviu Chircu >>>> OpenSIPS Developer >>>> http://www.opensips-solutions.com >>>> >>>> On 04.11.2016 16:15, Jim DeVito wrote: >>>>> Hi All, >>>>> >>>>> Wondering if you have seen something like this. It happens when >>>>> calling check_fraud() like this... >>>>> >>>>> check_fraud("$fU", "$rU", "1"); >>>>> >>>>> I can reproduce it on 2 of my 3 servers. Let me know if there is >>>>> other debugging info that may be needed. >>>>> >>>>> Thanks!! >>>>> >>>>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5257]: segfault at 0 >>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>> drouting.so[7f619d947000+38000] >>>>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5256]: segfault at 0 >>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>> drouting.so[7f619d947000+38000] >>>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5260]: segfault at 0 >>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>> drouting.so[7f619d947000+38000] >>>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5254]: segfault at 0 >>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>> drouting.so[7f619d947000+38000] >>>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5259]: segfault at 0 >>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>> drouting.so[7f619d947000+38000] >>>>> >>>>> [root at sip-proxy02 ~]# gdb /var/tmp/core.5257 >>>>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 >>>>> >>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>> >>>>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>>>> size >= 3226677248, found: 1183989760. >>>>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>>>> size >= 3226677248, found: 1183989760. >>>>> [New LWP 5257] >>>>> Reading symbols from /usr/sbin/opensips...Reading symbols from >>>>> /usr/lib/debug/usr/sbin/opensips.debug...done. >>>>> done. >>>>> Cannot access memory at address 0x7f62635a71e8 >>>>> Cannot access memory at address 0x7f62635a71e0 >>>>> (gdb) bt full >>>>> Python Exception Cannot access memory at >>>>> address 0x7ffee6ccd718: >>>>> >>>>> [root at sip-proxy02 ~]# yum list installed | grep opensips >>>>> opensips.x86_64 2.2.2-1.el7 @opensips >>>>> opensips-db_mysql.x86_64 2.2.2-1.el7 @opensips >>>>> opensips-debuginfo.x86_64 2.2.2-1.el7 @opensips >>>>> opensips-event_route.x86_64 2.2.2-1.el7 @opensips >>>>> opensips-fraud_detection.x86_64 2.2.2-1.el7 @opensips >>>>> opensips-rest_client.x86_64 2.2.2-1.el7 @opensips >>>>> opensips-yum-releases.noarch 2.2-3.el7 >>>>> @/opensips-yum-releases-2.2-3.el7.noarch >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From jim at devito.cc Fri Nov 4 18:32:04 2016 From: jim at devito.cc (Jim DeVito) Date: Fri, 04 Nov 2016 10:32:04 -0700 Subject: [OpenSIPS-Users] =?utf-8?q?Strange_segfault_when_calling_check=5F?= =?utf-8?q?fraud?= In-Reply-To: <9a0598ee-28fe-1580-9913-922a2f121e26@opensips.org> References: <814b558c-7315-3a57-03ce-704538698c23@opensips.org> <43065bb66b0cbdea5612ab9b86ea082d@mail.devito.cc> <9a0598ee-28fe-1580-9913-922a2f121e26@opensips.org> Message-ID: <9906786c53570cda377bea73628a1072@mail.devito.cc> I See it Thanks! Will run nighties later this weekend and let you know if I have any trouble. Thanks for fixing it!! --- Jim DeVito On 2016-11-04 10:15, Liviu Chircu wrote: > Thank you for all the help, Jim! A fix for this issue has been pushed > to all 2.X versions of the git repository [1] > > If you prefer to use packages [2], you may want to use your distro's > nighly build repos > > [1]: http://www.opensips.org/Downloads/Downloads#toc3 > [2]: http://www.opensips.org/Downloads/Downloads#toc2 > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 04.11.2016 18:46, Jim DeVito wrote: >> Seems like it happen while opensips is still starting (loading the dr_ >> tables into memory) when the first INVITE comes across the >> check_fraud() function. I can comment out the check_fraud() and it is >> just fine. >> >> version: opensips 2.2.2 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >> MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >> main.c compiled on 00:00:54 Oct 20 2016 with gcc 4.8.5 >> >> Thanks!! >> >> --- >> Jim DeVito >> >> >> On 2016-11-04 09:30, Liviu Chircu wrote: >>> Thank you, Jim! The backtrace is very helpful. >>> >>> Could you give a bit more details about how you are triggering this >>> bug? Could it be right after you are starting OpenSIPS? >>> >>> Also, pasting the output of `opensips -V` could help as well. >>> >>> Regards, >>> >>> Liviu Chircu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> >>> On 04.11.2016 17:34, Jim DeVito wrote: >>>> Thanks for the tip Liviu! >>>> >>>> I was able to get the full core file and paseted below is the back >>>> trace. Let me know if this can help track down what is going on. >>>> >>>> http://pastebin.com/m7LfVHqJ >>>> >>>> Thanks!! >>>> >>>> --- >>>> Jim DeVito >>>> >>>> On 2016-11-04 08:08, Liviu Chircu wrote: >>>>> Hi, Jim! >>>>> >>>>> It appears that OpenSIPS is either getting restarted too quickly or >>>>> runs out of disk space before it is able to fully write the 3 GB >>>>> corefile. If the size of your drouting data allows it, you could >>>>> reduce the corefile size by shrinking the shared memory pool >>>>> OpenSIPS >>>>> starts with. >>>>> >>>>> Regards, >>>>> >>>>> Liviu Chircu >>>>> OpenSIPS Developer >>>>> http://www.opensips-solutions.com >>>>> >>>>> On 04.11.2016 16:15, Jim DeVito wrote: >>>>>> Hi All, >>>>>> >>>>>> Wondering if you have seen something like this. It happens when >>>>>> calling check_fraud() like this... >>>>>> >>>>>> check_fraud("$fU", "$rU", "1"); >>>>>> >>>>>> I can reproduce it on 2 of my 3 servers. Let me know if there is >>>>>> other debugging info that may be needed. >>>>>> >>>>>> Thanks!! >>>>>> >>>>>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5257]: segfault at 0 >>>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>>> drouting.so[7f619d947000+38000] >>>>>> Nov 4 13:55:17 sip-proxy02 kernel: opensips[5256]: segfault at 0 >>>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>>> drouting.so[7f619d947000+38000] >>>>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5260]: segfault at 0 >>>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>>> drouting.so[7f619d947000+38000] >>>>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5254]: segfault at 0 >>>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>>> drouting.so[7f619d947000+38000] >>>>>> Nov 4 13:55:18 sip-proxy02 kernel: opensips[5259]: segfault at 0 >>>>>> ip 00007f619d94ff2e sp 00007ffee6ccd718 error 4 in >>>>>> drouting.so[7f619d947000+38000] >>>>>> >>>>>> [root at sip-proxy02 ~]# gdb /var/tmp/core.5257 >>>>>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 >>>>>> >>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>> >>>>>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>>>>> size >= 3226677248, found: 1183989760. >>>>>> BFD: Warning: /var/tmp/core.5257 is truncated: expected core file >>>>>> size >= 3226677248, found: 1183989760. >>>>>> [New LWP 5257] >>>>>> Reading symbols from /usr/sbin/opensips...Reading symbols from >>>>>> /usr/lib/debug/usr/sbin/opensips.debug...done. >>>>>> done. >>>>>> Cannot access memory at address 0x7f62635a71e8 >>>>>> Cannot access memory at address 0x7f62635a71e0 >>>>>> (gdb) bt full >>>>>> Python Exception Cannot access memory at >>>>>> address 0x7ffee6ccd718: >>>>>> >>>>>> [root at sip-proxy02 ~]# yum list installed | grep opensips >>>>>> opensips.x86_64 2.2.2-1.el7 @opensips >>>>>> opensips-db_mysql.x86_64 2.2.2-1.el7 @opensips >>>>>> opensips-debuginfo.x86_64 2.2.2-1.el7 @opensips >>>>>> opensips-event_route.x86_64 2.2.2-1.el7 @opensips >>>>>> opensips-fraud_detection.x86_64 2.2.2-1.el7 @opensips >>>>>> opensips-rest_client.x86_64 2.2.2-1.el7 @opensips >>>>>> opensips-yum-releases.noarch 2.2-3.el7 >>>>>> @/opensips-yum-releases-2.2-3.el7.noarch >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From hunterj91 at hotmail.com Sun Nov 6 17:50:08 2016 From: hunterj91 at hotmail.com (Jonathan Hunter) Date: Sun, 6 Nov 2016 16:50:08 +0000 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: <5d601c3e-ac5b-b6d1-fc0a-7959f1f0e4a0@opensips.org> References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> , <5d601c3e-ac5b-b6d1-fc0a-7959f1f0e4a0@opensips.org> Message-ID: Hi Bogdan, Sorry for the delay. I installed directly via make install, not via packages. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 03 November 2016 10:39 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Have you installed OpenSIPS via packages ? or directly via "make install" ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 02.11.2016 11:33, Jonathan Hunter wrote: Hi Bogdan, I am getting the core dumps, but containing no symbol tables, so I presume I need to recompile with debug flags enabled? Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004ed7fb in ?? () "/core.24882" is a core file. Please specify an executable to debug. (gdb) bt full #0 0x00000000004ed7fb in ?? () No symbol table info available. #1 0x00007f6af7604468 in ?? () No symbol table info available. #2 0x000000000000001a in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. I installed 2.1 from sources, so whats the best way to do this? thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 02 November 2016 08:09 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position For sure it is a patch issue. if you have a backtrace, it will useful. Thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 02.11.2016 09:56, Jonathan Hunter wrote: Hi Bogdan, Thanks very much for this. I have just applied patch (installed from sources so when to call_center module directory and ran patch < call_center_pos.patch) then did a recompile. However when I now route to the call center (cc_handle_call) it generates a core and kills opensips; !!!!user 2000 has Callqueue set so send to Call Queue Route Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set event EPOLLHUP - connection closed by the remote peer! Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: CRITICAL:core:receive_fd: EOF on 19 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: child process 21119 exited by a signal 11 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: core was generated Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: terminating due to SIGCHLD Do you need me to backtrace/debug through to get the issue? Or is problem how I applied patch? Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 01 November 2016 21:44 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Please give it a try to this patch - it is not really tested, but when the call is sent the Queue announcement, it should have a ";cc_pos=xxx" parameter giving the position is the queue (0 being the first to be dispatched to agents). Let me know if it works. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 28.10.2016 15:59, Jonathan Hunter wrote: Hi Bogdan, Great news, really do appreciate that. Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 28 October 2016 12:48 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, it is no yet available. Give me couple of days and I will make a patch for it. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 25.10.2016 19:22, Jonathan Hunter wrote: Hi Bogdan, Sorry cant recall If I replied to this. Is cc_pos available now to extract from the module? Thats the only thing I need then I can implement call center which I think will be much more scale-able than the other approach I am using with FreeSWITCH, I would use that just for announcements. Any response/help appreciated. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 13 October 2016 10:59 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, currently this is not possible. I was trying to envision a solution for your need. But, checking the code, it is really difficult to add the headers to the INVITEs originated by OpenSIPS (via the B2BUA), as we need some flexibility (different headers to different INVITEs belonging to the same B2B scenario , and even more, we need to traverse couple of internal APIs - to propagate the hdrs from Call center module all the way to TM). So, a simpler approach may be to add such extra info as URI params to the RURI. Like if you have the RURI "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the RURI in the INVITE to the media server will look like : sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the estimated time to wait in seconds and cc_pos the position in the queue. What do you think of this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 17:21, Jonathan Hunter wrote: Hi Bogdan, Yes being able to grab the queue position would be perfect. Is that possible? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: hunterj91 at hotmail.com; users at lists.opensips.org From: bogdan at opensips.org Date: Wed, 12 Oct 2016 15:42:43 +0300 Hi Jonathan, When a call is mapped to a flow / queue (before playing the welcome message), we know the ETA (estimated time to wait) and when is placed in the queue (before playing the queuing) we internally know the position in the queue. Would it help to have the position in the queue placed into a custome SIP header, when sending the INVITE to the message_queue URL ? or to the welcome message ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 12:06, Jonathan Hunter wrote: Hello Bogdan, Thanks for the response. In terms of my question, with a number of queuing platforms, they have the capability to tell the caller, what position they are in , and when they are likely to be answered. I just wondered if this logic was already within the module, or if I would need to use an external code/script to facilitate this function? As I presume call_center tracks the number of calls currently in a queue ? I would then want to be able to extract that information, and if a caller was for example in 3rd place in a queue, I could inject the relevant audio from freeswitch to tell them their current position? Does that make sense? :) Just wanted to know if its something this module can do? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: users at lists.opensips.org; hunterj91 at hotmail.com From: bogdan at opensips.org Date: Wed, 12 Oct 2016 11:23:45 +0300 Hello Jon, The message_queue is a SIP URI pointing to an audio announcement to play to roll of the waiting/in-queue playback. This needs to be an announcements that never ends (from the perspective of the media server); only the the OpenSIPS Queue may terminate the playback, when it decides to take out the call from waiting and to deliver it to an agent. As for your question, I'm not sure I understand what you mean by "inject a message with queue position for the caller in question" - could you detail please ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11.10.2016 13:36, Jonathan Hunter wrote: Hi guys, I have implemented an opensips/freeswitch environment, and I wish to add call queues to it, and I like the look of call_center, so just checking this out in comparison to mod_callcenter in FS world. My main question is if using the call_center module if you can inject a message with queue position for the caller in question, as I cant see that in documentation, I only see message_queue which I assume could be used to report the callers position, but just wondered if anyone has done this and if they could give me some tips as to if possible? Many thanks Jon _______________________________________________ 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: From acmicrox at gmail.com Mon Nov 7 10:04:16 2016 From: acmicrox at gmail.com (Chen-Che Huang) Date: Mon, 7 Nov 2016 02:04:16 -0700 (MST) Subject: [OpenSIPS-Users] No TLS-related files in OpenSIPS 1.11.9 src.tar.gz Message-ID: <1478509456538-7604883.post@n2.nabble.com> Dear all, It seems that the http://opensips.org/pub/opensips/1.11.9/opensips-1.11.9.tar.gz does not contain tls-related files. Can anyone let me know where to download the 1.11.9 src with TLS-related files? Thanks. Best regards, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/No-TLS-related-files-in-OpenSIPS-1-11-9-src-tar-gz-tp7604883.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Mon Nov 7 10:11:06 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 7 Nov 2016 11:11:06 +0200 Subject: [OpenSIPS-Users] No TLS-related files in OpenSIPS 1.11.9 src.tar.gz In-Reply-To: <1478509456538-7604883.post@n2.nabble.com> References: <1478509456538-7604883.post@n2.nabble.com> Message-ID: <0760d5ba-565d-b46c-06c9-6bb9572bbb1f@opensips.org> Hi, Chen-Che! You can download directly the sources from github[1]. [1] https://github.com/OpenSIPS/opensips/archive/1.11.9.zip Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/07/2016 11:04 AM, Chen-Che Huang wrote: > Dear all, > > It seems that the > http://opensips.org/pub/opensips/1.11.9/opensips-1.11.9.tar.gz does not > contain tls-related files. Can anyone let me know where to download the > 1.11.9 src with TLS-related files? Thanks. > > Best regards, > Chen-Che > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/No-TLS-related-files-in-OpenSIPS-1-11-9-src-tar-gz-tp7604883.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From razvan at opensips.org Mon Nov 7 10:21:17 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 7 Nov 2016 11:21:17 +0200 Subject: [OpenSIPS-Users] No TLS-related files in OpenSIPS 1.11.9 src.tar.gz In-Reply-To: <0760d5ba-565d-b46c-06c9-6bb9572bbb1f@opensips.org> References: <1478509456538-7604883.post@n2.nabble.com> <0760d5ba-565d-b46c-06c9-6bb9572bbb1f@opensips.org> Message-ID: <99df1d60-5c6e-68f6-163d-5f1f7de3960b@opensips.org> I've also published the archive in the official download server[2]. Thanks for pointing this out. [2] http://opensips.org/pub/opensips/1.11.9/opensips-1.11.9-tls.tar.gz Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/07/2016 11:11 AM, R?zvan Crainea wrote: > Hi, Chen-Che! > > You can download directly the sources from github[1]. > > [1] https://github.com/OpenSIPS/opensips/archive/1.11.9.zip > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/07/2016 11:04 AM, Chen-Che Huang wrote: >> Dear all, >> >> It seems that the >> http://opensips.org/pub/opensips/1.11.9/opensips-1.11.9.tar.gz does not >> contain tls-related files. Can anyone let me know where to download the >> 1.11.9 src with TLS-related files? Thanks. >> >> Best regards, >> Chen-Che >> >> >> >> -- >> View this message in context: >> http://opensips-open-sip-server.1449251.n2.nabble.com/No-TLS-related-files-in-OpenSIPS-1-11-9-src-tar-gz-tp7604883.html >> Sent from the OpenSIPS - Users mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 From sahadevupadhyay20aug at gmail.com Mon Nov 7 11:50:36 2016 From: sahadevupadhyay20aug at gmail.com (Sahadev Upadhyay) Date: Mon, 7 Nov 2016 16:20:36 +0530 Subject: [OpenSIPS-Users] ExpressConnector -- unable to connect OpenSer Message-ID: Dear All, I have a problem while running startup.sh file of wesip server. It gives an error-- root at sahadev-MS-7518:/usr/local/wesip/bin# HttpConnector [main] - The HttpConnector [all:8081] has been created ExpressConnector [main] - Unable to connect to OpenSER. ExpressConnector [main] - Unable to connect to OpenSER. ExpressConnector [main] - Unable to connect to OpenSER. Please help me to resolve the issue. I am doing configuration of OpenSips-2.2 and wesip server Thanks Sahadev Upadhyay -------------- next part -------------- An HTML attachment was scrubbed... URL: From sahadevupadhyay20aug at gmail.com Mon Nov 7 11:51:41 2016 From: sahadevupadhyay20aug at gmail.com (Sahadev Upadhyay) Date: Mon, 7 Nov 2016 16:21:41 +0530 Subject: [OpenSIPS-Users] ExpressConnector -- unable to connect OpenSer Message-ID: Dear All, I have a problem while running startup.sh file of wesip server. It gives an error-- root at sahadev-MS-7518:/usr/local/wesip/bin# HttpConnector [main] - The HttpConnector [all:8081] has been created ExpressConnector [main] - Unable to connect to OpenSER. ExpressConnector [main] - Unable to connect to OpenSER. ExpressConnector [main] - Unable to connect to OpenSER. Please help me to resolve the issue. I am doing configuration of OpenSips-2.2 and wesip server Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Mon Nov 7 13:20:05 2016 From: denis7979 at mail.ru (Denis) Date: Mon, 7 Nov 2016 15:20:05 +0300 Subject: [OpenSIPS-Users] B2B top hiding Message-ID: <595252113.20161107152005@ptl.ru> Hello! Opensips 2.2.2. I want to make an installation of Opensips which will include auth and top hiding functionality. First of all, in the main route, i catch INVITE "if (is_method("INVITE") && !has_totag()) { route(1); exit; }" then, in route [1], i make some auth procedure using "pv_proxy_authorize" and "proxy_authorize" functions if auth procedure is successful i make "xlog("L_INFO", "Route1:$rm was received with auth (IP=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) AND B2B prepared"); b2b_init_request("top hiding"); exit;" In the local route i try to edit port of the destination, using "xlog("L_INFO", "Local:$rm was received with auth (IP=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au)"); rewritehostport("1.1.1.1:5065");" where 1.1.1.1 - ip address of Opensips. In attachment you can see debug of unsuccessful call, where 1.1.1.1 - ip address of Opensips. 2.2.2.2 - caller SIP UA I can see in syslog both messages, in local route and in route [1]. As you can see from the debug Opensips doesn`t try to send INVITE to 1.1.1.1:5065. Thank you for any help. mailto:denis7979 at mail.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: b2b_problem.txt URL: From daniel.zanutti at gmail.com Mon Nov 7 13:36:31 2016 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Mon, 7 Nov 2016 10:36:31 -0200 Subject: [OpenSIPS-Users] Github x gzip version Message-ID: Hi Just a question about which version to use: Is it safe to use the latest Github version of 1.11.x or is safe to use the .tar.gz version? My point is: Can I trust github version to use in production? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Nov 7 13:45:19 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 7 Nov 2016 14:45:19 +0200 Subject: [OpenSIPS-Users] B2B top hiding In-Reply-To: <595252113.20161107152005@ptl.ru> References: <595252113.20161107152005@ptl.ru> Message-ID: <03255b67-44f7-a9bd-3729-060a04e37c45@opensips.org> Hi, Denis! Can you please detail a bit what you are trying to achieve? In the trace attached, all I can see is that OpenSIPS doesn't authenticate the UA - I don't see why it should even try to send the INVITE anywhere. However, if you are saying that you see both lines in the log, it means at a certain point the INVITE was authenticated and the topo-hiding was engaged. Did you try setting the port before calling b2b_init_request(), in route(1)? BR R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/07/2016 02:20 PM, Denis wrote: > B2B top hiding Hello! > > Opensips 2.2.2. > > I want to make an installation of Opensips which will include auth > and top hiding functionality. > > First of all, in the main route, i catch INVITE > "if (is_method("INVITE") && !has_totag()) { > route(1); > exit; > }" > > then, in route [1], i make some auth procedure using > "pv_proxy_authorize" and "proxy_authorize" functions > if auth procedure is successful i make > "xlog("L_INFO", "Route1:$rm was received with auth (IP=$si, IPD=$rd, > CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) AND B2B prepared"); > b2b_init_request("top hiding"); > exit;" > > In the local route i try to edit port of the destination, using > "xlog("L_INFO", "Local:$rm was received with auth (IP=$si, IPD=$rd, > CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au)"); > rewritehostport("1.1.1.1:5065");" > > where 1.1.1.1 - ip address of Opensips. > > In attachment you can see debug of unsuccessful call, where > 1.1.1.1 - ip address of Opensips. > 2.2.2.2 - caller SIP UA > > I can see in syslog both messages, in local route and in route [1]. > > As you can see from the debug Opensips doesn`t try to send INVITE to > 1.1.1.1:5065. > > Thank you for any help. > > > mailto:denis7979 at mail.ru > > > _______________________________________________ > 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: From denis7979 at mail.ru Mon Nov 7 14:20:13 2016 From: denis7979 at mail.ru (Denis) Date: Mon, 7 Nov 2016 16:20:13 +0300 Subject: [OpenSIPS-Users] B2B top hiding In-Reply-To: <03255b67-44f7-a9bd-3729-060a04e37c45@opensips.org> References: <595252113.20161107152005@ptl.ru> <03255b67-44f7-a9bd-3729-060a04e37c45@opensips.org> Message-ID: <1129145584.20161107162013@ptl.ru> Hello, Razvan! I want to make some input point to my SIP network which will make authentication and topology hiding. Authentication works (i checked it by inserting in client SIP UA wrong password), but b2b doesn`t. When i try to setting port before b2b_init_request i see in log " ERROR:b2b_logic:create_top_hiding_entities: failed to create new b2b server instance" mailto:denis7979 at mail.ru Hi, Denis! Can you please detail a bit what you are trying to achieve? In the trace attached, all I can see is that OpenSIPS doesn't authenticate the UA - I don't see why it should even try to send the INVITE anywhere. However, if you are saying that you see both lines in the log, it means at a certain point the INVITE was authenticated and the topo-hiding was engaged. Did you try setting the port before calling b2b_init_request(), in route(1)? BR R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/07/2016 02:20 PM, Denis wrote: B2B top hiding Hello! Opensips 2.2.2. I want to make an installation of Opensips which will include auth and top hiding functionality. First of all, in the main route, i catch INVITE "if (is_method("INVITE") && !has_totag()) { route(1); exit; }" then, in route [1], i make some auth procedure using "pv_proxy_authorize" and "proxy_authorize" functions if auth procedure is successful i make "xlog("L_INFO", "Route1:$rm was received with auth (IP=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) AND B2B prepared"); b2b_init_request("top hiding"); exit;" In the local route i try to edit port of the destination, using "xlog("L_INFO", "Local:$rm was received with auth (IP=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au)"); rewritehostport("1.1.1.1:5065");" where 1.1.1.1 - ip address of Opensips. In attachment you can see debug of unsuccessful call, where 1.1.1.1 - ip address of Opensips. 2.2.2.2 - caller SIP UA I can see in syslog both messages, in local route and in route [1]. As you can see from the debug Opensips doesn`t try to send INVITE to 1.1.1.1:5065. Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From razvan at opensips.org Mon Nov 7 14:42:01 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 7 Nov 2016 15:42:01 +0200 Subject: [OpenSIPS-Users] B2B top hiding In-Reply-To: <1129145584.20161107162013@ptl.ru> References: <595252113.20161107152005@ptl.ru> <03255b67-44f7-a9bd-3729-060a04e37c45@opensips.org> <1129145584.20161107162013@ptl.ru> Message-ID: <88207606-7394-b3ce-97d2-cd94d6946ac4@opensips.org> Hi, Denis! Are you seeing any other ERROR messages in the logs? When you see those errors in the log, does OpenSIPS send any message out (even to himself)? Can you provide a full trace? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/07/2016 03:20 PM, Denis wrote: > Re: [OpenSIPS-Users] B2B top hiding Hello, Razvan! > > I want to make some input point to my SIP network which will make > authentication and topology hiding. > Authentication works (i checked it by inserting in client SIP UA wrong > password), but b2b doesn`t. > When i try to setting port before b2b_init_request i see in log " > ERROR:b2b_logic:create_top_hiding_entities: failed to create new b2b > server instance" > > mailto:denis7979 at mail.ru > > > Hi, Denis! > > Can you please detail a bit what you are trying to achieve? In the > trace attached, all I can see is that OpenSIPS doesn't authenticate > the UA - I don't see why it should even try to send the INVITE anywhere. > However, if you are saying that you see both lines in the log, it > means at a certain point the INVITE was authenticated and the > topo-hiding was engaged. Did you try setting the port before calling > b2b_init_request(), in route(1)? > > BR > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/07/2016 02:20 PM, Denis wrote: > > B2B top hiding Hello! > > Opensips 2.2.2. > > I want to make an installation of Opensips which will include auth > and top hiding functionality. > > First of all, in the main route, i catch INVITE > "if (is_method("INVITE") && !has_totag()) { > route(1); > exit; > }" > > then, in route [1], i make some auth procedure using > "pv_proxy_authorize" and "proxy_authorize" functions > if auth procedure is successful i make > "xlog("L_INFO", "Route1:$rm was received with auth (IP=$si, IPD=$rd, > CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) AND B2B prepared"); > b2b_init_request("top hiding"); > exit;" > > In the local route i try to edit port of the destination, using > "xlog("L_INFO", "Local:$rm was received with auth (IP=$si, IPD=$rd, > CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au)"); > rewritehostport("1.1.1.1:5065");" > > where 1.1.1.1 - ip address of Opensips. > > In attachment you can see debug of unsuccessful call, where > 1.1.1.1 - ip address of Opensips. > 2.2.2.2 - caller SIP UA > > I can see in syslog both messages, in local route and in route [1]. > > As you can see from the debug Opensips doesn`t try to send INVITE to > 1.1.1.1:5065. > > Thank you for any help. > > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: From jim at devito.cc Mon Nov 7 20:20:07 2016 From: jim at devito.cc (Jim DeVito) Date: Mon, 07 Nov 2016 11:20:07 -0800 Subject: [OpenSIPS-Users] =?utf-8?q?Possible_Memory_Leak_in_rest=5Fclient_?= =?utf-8?q?module=2E?= Message-ID: <10fe005ba618cd93d4b9d4abc31f968b@mail.devito.cc> Hi All, This happened prior to 2.2.2 and I thought I saw a bug report that was fixed in 2.2.2. However it still seems to be a thing with using the res_curl module. After about a week I get this... Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] ERROR:core:fm_malloc: not enough free pkg memory (4296 bytes left), please increase the "-M" command line parameter! Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] INFO:core:fm_malloc: attempting defragmentation... (need 1808 bytes) Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] INFO:core:fm_malloc: unable to alloc a big enough fragment! Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] ERROR:rest_client:rest_get_method: curl_easy_perform: Out of memory I reboot and all is well for another week. Like res_client is not releasing the memory it is using. shmem:used_size:: seems to always be going up until it runs out of the memory I allotted with the -M switch. What else can I do to see where this is coming from? Thanks!! -- Jim DeVito From bogdan at opensips.org Mon Nov 7 20:51:46 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 7 Nov 2016 21:51:46 +0200 Subject: [OpenSIPS-Users] Github x gzip version In-Reply-To: References: Message-ID: <9db41a71-4ec0-405d-db5b-60fbd62f313b@opensips.org> Hi Daniel, yes, it is, as time as you are using it from a stable branch. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.11.2016 14:36, Daniel Zanutti wrote: > Hi > > Just a question about which version to use: > > Is it safe to use the latest Github version of 1.11.x or is safe to > use the .tar.gz version? > My point is: Can I trust github version to use in production? > > Thanks > > > > _______________________________________________ > 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: From bogdan at opensips.org Mon Nov 7 20:54:51 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 7 Nov 2016 21:54:51 +0200 Subject: [OpenSIPS-Users] ExpressConnector -- unable to connect OpenSer In-Reply-To: References: Message-ID: <57379338-482e-9f51-eda6-261a23b77de0@opensips.org> Hi, I do not want to disappoint you, but I don't think the wesip project is not active for a long time. I'm not familiar with how wesip connects to OpenSIPS, but I do you have any idea if this is over xmlrpc ? or ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.11.2016 12:51, Sahadev Upadhyay wrote: > Dear All, > > I have a problem while running startup.sh file of wesip server. > It gives an error-- > root at sahadev-MS-7518:/usr/local/wesip/bin# HttpConnector [main] - > The HttpConnector [all:8081] has been created > ExpressConnector [main] - Unable to connect to OpenSER. > ExpressConnector [main] - Unable to connect to OpenSER. > ExpressConnector [main] - Unable to connect to OpenSER. > > Please help me to resolve the issue. > I am doing configuration of OpenSips-2.2 and wesip server > > Thanks > > > _______________________________________________ > 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: From bogdan at opensips.org Mon Nov 7 21:04:35 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 7 Nov 2016 22:04:35 +0200 Subject: [OpenSIPS-Users] Possible Memory Leak in rest_client module. In-Reply-To: <10fe005ba618cd93d4b9d4abc31f968b@mail.devito.cc> References: <10fe005ba618cd93d4b9d4abc31f968b@mail.devito.cc> Message-ID: <95a5b0e2-5c81-184d-9fd9-3f0e72886284@opensips.org> Hi Jim, Please see http://www.opensips.org/Documentation/TroubleShooting-OutOfMem - let me know if you managed to get the mem dump. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.11.2016 21:20, Jim DeVito wrote: > Hi All, > > This happened prior to 2.2.2 and I thought I saw a bug report that was > fixed in 2.2.2. However it still seems to be a thing with using the > res_curl module. After about a week I get this... > > Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] > ERROR:core:fm_malloc: not enough free pkg memory (4296 bytes left), > please increase the "-M" command line parameter! > Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] > INFO:core:fm_malloc: attempting defragmentation... (need 1808 bytes) > Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] > INFO:core:fm_malloc: unable to alloc a big enough fragment! > Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] > ERROR:rest_client:rest_get_method: curl_easy_perform: Out of memory > > I reboot and all is well for another week. Like res_client is not > releasing the memory it is using. shmem:used_size:: seems to always be > going up until it runs out of the memory I allotted with the -M > switch. What else can I do to see where this is coming from? > > Thanks!! > From hunterj91 at hotmail.com Mon Nov 7 21:35:36 2016 From: hunterj91 at hotmail.com (Jonathan Hunter) Date: Mon, 7 Nov 2016 20:35:36 +0000 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: <698e1be4-ce83-9782-5286-e8154bccd0b8@opensips.org> References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> <5d601c3e-ac5b-b6d1-fc0a-7959f1f0e4a0@opensips.org> , <698e1be4-ce83-9782-5286-e8154bccd0b8@opensips.org> Message-ID: Hi Bogdan, Hope you are well. Yes that patch works, it stops the crash, and adds the parameter; Request-Line: INVITE sip:7777 at 1.2.3.4:5080;cc_pos=0 SIP/2.0 Which is great! I will now get to work on the solution, thanks again. Jon From: Bogdan-Andrei Iancu Sent: 07 November 2016 15:15 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Please revert the prev patch and try this new one - hopefully it will fix the crash. Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 06.11.2016 18:50, Jonathan Hunter wrote: Hi Bogdan, Sorry for the delay. I installed directly via make install, not via packages. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 03 November 2016 10:39 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Have you installed OpenSIPS via packages ? or directly via "make install" ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 02.11.2016 11:33, Jonathan Hunter wrote: Hi Bogdan, I am getting the core dumps, but containing no symbol tables, so I presume I need to recompile with debug flags enabled? Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004ed7fb in ?? () "/core.24882" is a core file. Please specify an executable to debug. (gdb) bt full #0 0x00000000004ed7fb in ?? () No symbol table info available. #1 0x00007f6af7604468 in ?? () No symbol table info available. #2 0x000000000000001a in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. I installed 2.1 from sources, so whats the best way to do this? thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 02 November 2016 08:09 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position For sure it is a patch issue. if you have a backtrace, it will useful. Thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 02.11.2016 09:56, Jonathan Hunter wrote: Hi Bogdan, Thanks very much for this. I have just applied patch (installed from sources so when to call_center module directory and ran patch < call_center_pos.patch) then did a recompile. However when I now route to the call center (cc_handle_call) it generates a core and kills opensips; !!!!user 2000 has Callqueue set so send to Call Queue Route Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set event EPOLLHUP - connection closed by the remote peer! Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: CRITICAL:core:receive_fd: EOF on 19 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: child process 21119 exited by a signal 11 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: core was generated Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: terminating due to SIGCHLD Do you need me to backtrace/debug through to get the issue? Or is problem how I applied patch? Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 01 November 2016 21:44 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Please give it a try to this patch - it is not really tested, but when the call is sent the Queue announcement, it should have a ";cc_pos=xxx" parameter giving the position is the queue (0 being the first to be dispatched to agents). Let me know if it works. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 28.10.2016 15:59, Jonathan Hunter wrote: Hi Bogdan, Great news, really do appreciate that. Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 28 October 2016 12:48 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, it is no yet available. Give me couple of days and I will make a patch for it. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 25.10.2016 19:22, Jonathan Hunter wrote: Hi Bogdan, Sorry cant recall If I replied to this. Is cc_pos available now to extract from the module? Thats the only thing I need then I can implement call center which I think will be much more scale-able than the other approach I am using with FreeSWITCH, I would use that just for announcements. Any response/help appreciated. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 13 October 2016 10:59 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, currently this is not possible. I was trying to envision a solution for your need. But, checking the code, it is really difficult to add the headers to the INVITEs originated by OpenSIPS (via the B2BUA), as we need some flexibility (different headers to different INVITEs belonging to the same B2B scenario , and even more, we need to traverse couple of internal APIs - to propagate the hdrs from Call center module all the way to TM). So, a simpler approach may be to add such extra info as URI params to the RURI. Like if you have the RURI "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the RURI in the INVITE to the media server will look like : sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the estimated time to wait in seconds and cc_pos the position in the queue. What do you think of this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 17:21, Jonathan Hunter wrote: Hi Bogdan, Yes being able to grab the queue position would be perfect. Is that possible? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: hunterj91 at hotmail.com; users at lists.opensips.org From: bogdan at opensips.org Date: Wed, 12 Oct 2016 15:42:43 +0300 Hi Jonathan, When a call is mapped to a flow / queue (before playing the welcome message), we know the ETA (estimated time to wait) and when is placed in the queue (before playing the queuing) we internally know the position in the queue. Would it help to have the position in the queue placed into a custome SIP header, when sending the INVITE to the message_queue URL ? or to the welcome message ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 12:06, Jonathan Hunter wrote: Hello Bogdan, Thanks for the response. In terms of my question, with a number of queuing platforms, they have the capability to tell the caller, what position they are in , and when they are likely to be answered. I just wondered if this logic was already within the module, or if I would need to use an external code/script to facilitate this function? As I presume call_center tracks the number of calls currently in a queue ? I would then want to be able to extract that information, and if a caller was for example in 3rd place in a queue, I could inject the relevant audio from freeswitch to tell them their current position? Does that make sense? :) Just wanted to know if its something this module can do? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: users at lists.opensips.org; hunterj91 at hotmail.com From: bogdan at opensips.org Date: Wed, 12 Oct 2016 11:23:45 +0300 Hello Jon, The message_queue is a SIP URI pointing to an audio announcement to play to roll of the waiting/in-queue playback. This needs to be an announcements that never ends (from the perspective of the media server); only the the OpenSIPS Queue may terminate the playback, when it decides to take out the call from waiting and to deliver it to an agent. As for your question, I'm not sure I understand what you mean by "inject a message with queue position for the caller in question" - could you detail please ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11.10.2016 13:36, Jonathan Hunter wrote: Hi guys, I have implemented an opensips/freeswitch environment, and I wish to add call queues to it, and I like the look of call_center, so just checking this out in comparison to mod_callcenter in FS world. My main question is if using the call_center module if you can inject a message with queue position for the caller in question, as I cant see that in documentation, I only see message_queue which I assume could be used to report the callers position, but just wondered if anyone has done this and if they could give me some tips as to if possible? Many thanks Jon _______________________________________________ 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: From eric.freeman at tbwachiat.com Wed Nov 2 21:40:04 2016 From: eric.freeman at tbwachiat.com (Eric Freeman) Date: Wed, 2 Nov 2016 20:40:04 +0000 Subject: [OpenSIPS-Users] Routing in opensips In-Reply-To: References: <316e9a04-7742-ab9e-329d-e0615cc64179@opensips.org> <5bf7c4cc-285a-2a7a-f5fe-62cbc4601e1d@opensips.org> <9a3d5834-6396-ca9e-898b-21e31cd8b661@opensips.org> , Message-ID: I am not clear of what I am doing. I did some googling. I added the if nat_uac line to the fix_nated line. It did not fix my issue. In the Invite Request Packet I see the Owner Address as the 10 address next to the Owner Address section of the packet. The same for the Connection information.Does that mean I didn't set up the fix_nates_sdp correctly? Let me know if you want to see my entire opensips.cfg file. route[relay] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { if(nat_uac_test("8")) { xlog("We have incoming SDP, let's fix if it's behind NAT\n"); fix_nated_sdp("2"); } t_on_branch("per_branch_ops"); t_on_reply("handle_nat"); t_on_failure("missed_call"); Thank you for all of your help, Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Tuesday, November 1, 2016 8:34:05 AM To: Eric Freeman; users at lists.opensips.org Subject: Re: [OpenSIPS-Users] Routing in opensips Eric, You can simply change it with the fix_nated_sdp() function: http://www.opensips.org/html/docs/modules/2.2.x/nathelper.html#id294042 But you have to be careful that the IP:port you force in SDP is also valid from IP perspective - like any RTP traffic landing on that IP is actually getting to the right application. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 01.11.2016 14:24, Eric Freeman wrote: Thank you. I will test with that IP. How do I change the SDP to my public IP address so I can get RTP information back? Thank you, Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Tuesday, November 1, 2016 7:10:45 AM To: Eric Freeman; users at lists.opensips.org Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, The outgoing INVITE request looks ok - the RR and VIA headers carry the public IP of your OpenSIPS. You should get back some reply. Not sure how valid is that test server, but you can try sending to sip:opensips.org:5060 ( or 78.46.64.50:5060 ) - this sip server is definitely up . BTW, the SDP you send out is bogus as it contain only private IPs, so the other end point will not be able to send you ant RTP back. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 31.10.2016 14:21, Eric Freeman wrote: Please attached pcap file. Is this what you need? Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Monday, October 31, 2016 6:36:18 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, What I'm asking here is to post the full INVITE packet from your opensips server to the external host - I Want to to check the SIP headers and the SDP. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.10.2016 16:38, Eric Freeman wrote: The opensips server is 10.88.23.13 the video conference server is 10.89.71.12. The IP I am trying to connect to 199.48.152.152, I believe is a valid host. I found it on a test SIP site on the Internet 10:02:59.346842 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:02:59.351769 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 100 Giving a try 10:02:59.352232 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:02:59.352238 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:02:59.871480 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:02:59.871489 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:03:00.874461 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:03:00.874483 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:03:02.877430 IP 10.88.23.13.sip > sj1-con-01-04.bluejeansnet.com.sip: SIP: INVITE sip:111 at 199.48.152.152 SIP/2.0 10:03:02.877440 IP 10.88.23.13 > sj1-con-01-04.bluejeansnet.com: udp 10:03:03.930697 IP 10.88.23.13.sip > 10.89.71.12.sip: SIP: SIP/2.0 408 Request Timeout 10:03:03.958682 IP 10.89.71.12.sip > 10.88.23.13.sip: SIP: ACK sip:111 at 199.48.152.152 SIP/2.0 Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Tuesday, October 25, 2016 7:04:15 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, By traffic (coming back), you understand RTP or SIP traffic ? Could you post the INVITE message getting out of your server ? I suspect the INVITE has in SDP a private IP that is not reachable for the end device (where the call is sent). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.10.2016 18:46, Eric Freeman wrote: Yes, I see Request INVITE going to the device I am calling. I do not see any traffic coming back. I am following up with my Firewall team. My Firewall team suggested I might need to change the RTP ports to use UDP 2326-2485. Where do I change/check these settings on the OpenSIPs server to see if I have the traffic going out those ports. Thanks, Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Monday, October 3, 2016 4:44:26 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, Not the OpenSIPs logs I'm looking for, but the actual SIP packet at network level (use ngrep or tcpdump) for the INVITE leaving your OpenSIPS. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 30.09.2016 16:52, Eric Freeman wrote: Hopefully this is the relevant information you need from the log. I am trying to call 111 at 199.48.152.152. The IP of the opensips server si 10.88.23.10 and has a public IP of 204.17.231.3. The IP address of the video conference server is 10.89.71.12. Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: SIP Request: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: method: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: uri: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_msg: version: Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=2 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: end of header reached, state=10 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: display={}, ruri={sip:111 at 199.48.152.152} Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: [26]; uri=[sip:111 at 199.48.152.152] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: to body [#015#012] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: cseq : <1> Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_via_param: found param type 235, = ; state=6 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_via_param: found param type 232, = ; state=16 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_via: end of header reached, state=5 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: via found, flags=2 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: this is the first via Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:receive_msg: After parse_msg... Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:receive_msg: preparing to run routing scripts... Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=100 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:maxfwd:is_maxfwd_present: value = 70 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:uri:has_totag: no totag Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=78 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:tm:t_lookup_request: start searching: hash=25578, isACK=0 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:tm:matching_3261: RFC3261 transaction matching failed Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:tm:t_lookup_request: no transaction found Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to_param: tag=2c770a98-c47590a-13c4-45026-57ed3cdd-1bac9941-57ed3cdd Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: end of header reached, state=29 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_to: display={"Conference Room"}, ruri={sip:LifeSize at 10.88.23.13;transport=UDP} Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if host==us: 11==11 && [10.88.23.13] == [10.88.23.13] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=200 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: content_length=1759 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:get_hdr_field: found end of header Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:rr:find_first_route: No Route headers found Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if host==us: 14==11 && [199.48.152.152] == [10.88.23.13] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if host==us: 14==11 && [199.48.152.152] == [10.88.23.13] Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:check_self: host != me Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 29 12:10:17 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:do_action_set_adv_address: setting adv address = [204.17.231.3] Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Friday, September 30, 2016 4:32:01 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips Hi Eric, As a first step, can you confirm that the INVITE (sent out by your OPenSIPS to the internet) has in VIA hdr the public IP of your NAT ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 29.09.2016 19:14, Eric Freeman wrote: It is still not working, I added my public IP as requested. I do not have any gateways or anything set up. Do I need to add anything? I added this to the route statement: if (!uri==myself) { append_hf("P-hint: outbound\r\n"); set_advertised_address("XXX.XX.XXX.X"); route(relay); I am still receiving these errors: Sep 29 12:10:22 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:rr:find_first_route: No Route headers found Sep 29 12:10:22 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:rr:loose_route: There is no Route HF Sep 29 12:10:22 cd-ubuntu-opensips /usr/local/sbin/opensips[12878]: DBG:core:parse_headers: flags=78 Eric Freeman Technical Director/NA for TBWA\Chiat\Day TBWA\Chiat\Day New York 488 Madison Ave. New York NY 10022 United States of America Tel: +12128041324 ________________________________ From: Bogdan-Andrei Iancu Sent: Tuesday, September 20, 2016 8:38:31 AM To: Eric Freeman; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Routing in opensips He Eric, In the script (generated by menuconfig), you have an IF block with : append_hf("P-hint: outbound\r\n"); That block is executed if one of your users is dialing an external SIP domain. So, that is the place where the calls will break out to public internet. As your OpenSIPS has a private IP (not routable in internet), you need to configure it to advertise the public IP of your NAT via the set_advertise_address() - see: http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc46 Put there the public IP of your NAT. Also, be sure you create in your router (running the NAT) a port forwarding from the public IP port 5060 UDP to the private IP of your OpenSIPS port 5060 UDP. Best regards, ------------------------------------------------------------------------------- This e-mail is intended only for the named person or entity to which it is addressed and contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure. If you received this e-mail in error, any review, use, dissemination, distribution or copying of this e-mail is strictly prohibited. Please notify us immediately of the error via e-mail to disclaimer at email-abuse.com and please delete the e-mail from your system, retaining no copies in any media. We appreciate your cooperation. -------------------------------------------------------------------disc99999999 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Nov 3 11:39:42 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 3 Nov 2016 12:39:42 +0200 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> Message-ID: <5d601c3e-ac5b-b6d1-fc0a-7959f1f0e4a0@opensips.org> Hi Jonathan, Have you installed OpenSIPS via packages ? or directly via "make install" ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 02.11.2016 11:33, Jonathan Hunter wrote: > > Hi Bogdan, > > > I am getting the core dumps, but containing no symbol tables, so I > presume I need to recompile with debug flags enabled? > > > Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid'. > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004ed7fb in ?? () > "/core.24882" is a core file. > Please specify an executable to debug. > (gdb) bt full > #0 0x00000000004ed7fb in ?? () > No symbol table info available. > #1 0x00007f6af7604468 in ?? () > No symbol table info available. > #2 0x000000000000001a in ?? () > No symbol table info available. > #3 0x0000000000000000 in ?? () > No symbol table info available. > > > > I installed 2.1 from sources, so whats the best way to do this? > > > thanks > > > Jon > > > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *Sent:* 02 November 2016 08:09 > *To:* Jonathan Hunter; OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position > For sure it is a patch issue. if you have a backtrace, it will useful. > > Thanks, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > Home ? OpenSIPS Solutions > www.opensips-solutions.com > OpenSIPS is a mature Open Source implementation of a SIP server. > OpenSIPS is more than a SIP proxy/router as it includes > application-level functionalities. > > > On 02.11.2016 09:56, Jonathan Hunter wrote: >> >> Hi Bogdan, >> >> >> Thanks very much for this. >> >> >> I have just applied patch (installed from sources so when to >> call_center module directory and ran patch < call_center_pos.patch) >> then did a recompile. >> >> >> However when I now route to the call center (cc_handle_call) it >> generates a core and kills opensips; >> >> >> !!!!user 2000 has Callqueue set so send to Call Queue Route >> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: >> NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set >> event EPOLLHUP - connection closed by the remote peer! >> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: >> CRITICAL:core:receive_fd: EOF on 19 >> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >> INFO:core:handle_sigs: child process 21119 exited by a signal 11 >> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >> INFO:core:handle_sigs: core was generated >> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >> INFO:core:handle_sigs: terminating due to SIGCHLD >> >> >> >> Do you need me to backtrace/debug through to get the issue? Or is >> problem how I applied patch? >> >> >> Many thanks >> >> >> Jon >> >> >> >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* 01 November 2016 21:44 >> *To:* Jonathan Hunter; OpenSIPS users mailling list >> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >> Hi Jonathan, >> >> Please give it a try to this patch - it is not really tested, but >> when the call is sent the Queue announcement, it should have a >> ";cc_pos=xxx" parameter giving the position is the queue (0 being the >> first to be dispatched to agents). >> >> Let me know if it works. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> Home ? OpenSIPS Solutions >> www.opensips-solutions.com >> OpenSIPS is a mature Open Source implementation of a SIP server. >> OpenSIPS is more than a SIP proxy/router as it includes >> application-level functionalities. >> >> >> On 28.10.2016 15:59, Jonathan Hunter wrote: >>> >>> Hi Bogdan, >>> >>> >>> Great news, really do appreciate that. >>> >>> >>> Many thanks >>> >>> >>> Jon >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Bogdan-Andrei Iancu >>> *Sent:* 28 October 2016 12:48 >>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>> Hi Jonathan, >>> >>> No, it is no yet available. Give me couple of days and I will make a >>> patch for it. >>> >>> Best regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> Home ? OpenSIPS Solutions >>> www.opensips-solutions.com >>> OpenSIPS is a mature Open Source implementation of a SIP server. >>> OpenSIPS is more than a SIP proxy/router as it includes >>> application-level functionalities. >>> >>> >>> On 25.10.2016 19:22, Jonathan Hunter wrote: >>>> >>>> Hi Bogdan, >>>> >>>> >>>> Sorry cant recall If I replied to this. >>>> >>>> >>>> Is cc_pos available now to extract from the module? >>>> >>>> >>>> Thats the only thing I need then I can implement call center which >>>> I think will be much more scale-able than the other approach I am >>>> using with FreeSWITCH, I would use that just for announcements. >>>> >>>> >>>> Any response/help appreciated. >>>> >>>> >>>> Jon >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Bogdan-Andrei Iancu >>>> *Sent:* 13 October 2016 10:59 >>>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>> position >>>> Hi Jonathan, >>>> >>>> No, currently this is not possible. I was trying to envision a >>>> solution for your need. >>>> >>>> But, checking the code, it is really difficult to add the headers >>>> to the INVITEs originated by OpenSIPS (via the B2BUA), as we need >>>> some flexibility (different headers to different INVITEs belonging >>>> to the same B2B scenario , and even more, we need to traverse >>>> couple of internal APIs - to propagate the hdrs from Call center >>>> module all the way to TM). >>>> >>>> So, a simpler approach may be to add such extra info as URI params >>>> to the RURI. Like if you have the RURI >>>> "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the >>>> RURI in the INVITE to the media server will look like : >>>> sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the >>>> estimated time to wait in seconds and cc_pos the position in the queue. >>>> >>>> What do you think of this ? >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 12.10.2016 17:21, Jonathan Hunter wrote: >>>>> Hi Bogdan, >>>>> >>>>> Yes being able to grab the queue position would be perfect. >>>>> >>>>> Is that possible? >>>>> >>>>> Thanks >>>>> >>>>> Jon >>>>> >>>>> ------------------------------------------------------------------------ >>>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>>>> To: hunterj91 at hotmail.com; users at lists.opensips.org >>>>> From: bogdan at opensips.org >>>>> Date: Wed, 12 Oct 2016 15:42:43 +0300 >>>>> >>>>> Hi Jonathan, >>>>> >>>>> When a call is mapped to a flow / queue (before playing the >>>>> welcome message), we know the ETA (estimated time to wait) and >>>>> when is placed in the queue (before playing the queuing) we >>>>> internally know the position in the queue. >>>>> >>>>> Would it help to have the position in the queue placed into a >>>>> custome SIP header, when sending the INVITE to the message_queue >>>>> URL ? or to the welcome message ? >>>>> >>>>> Regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 12.10.2016 12:06, Jonathan Hunter wrote: >>>>> >>>>> Hello Bogdan, >>>>> >>>>> Thanks for the response. >>>>> >>>>> In terms of my question, with a number of queuing platforms, >>>>> they have the capability to tell the caller, what position >>>>> they are in , and when they are likely to be answered. >>>>> >>>>> I just wondered if this logic was already within the module, >>>>> or if I would need to use an external code/script to >>>>> facilitate this function? >>>>> >>>>> As I presume call_center tracks the number of calls currently >>>>> in a queue ? I would then want to be able to extract that >>>>> information, and if a caller was for example in 3rd place in a >>>>> queue, I could inject the relevant audio from freeswitch to >>>>> tell them their current position? >>>>> >>>>> Does that make sense? :) Just wanted to know if its >>>>> something this module can do? >>>>> >>>>> Thanks >>>>> >>>>> Jon >>>>> >>>>> ------------------------------------------------------------------------ >>>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>>> position >>>>> To: users at lists.opensips.org >>>>> ; hunterj91 at hotmail.com >>>>> >>>>> From: bogdan at opensips.org >>>>> Date: Wed, 12 Oct 2016 11:23:45 +0300 >>>>> >>>>> Hello Jon, >>>>> >>>>> The message_queue is a SIP URI pointing to an audio >>>>> announcement to play to roll of the waiting/in-queue playback. >>>>> This needs to be an announcements that never ends (from the >>>>> perspective of the media server); only the the OpenSIPS Queue >>>>> may terminate the playback, when it decides to take out the >>>>> call from waiting and to deliver it to an agent. >>>>> >>>>> As for your question, I'm not sure I understand what you mean >>>>> by "inject a message with queue position for the caller in >>>>> question" - could you detail please ? >>>>> >>>>> Regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> >>>>> On 11.10.2016 13:36, Jonathan Hunter wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I have implemented an opensips/freeswitch environment, and >>>>> I wish to add call queues to it, and I like the look of >>>>> call_center, so just checking this out in comparison to >>>>> mod_callcenter in FS world. >>>>> >>>>> My main question is if using the call_center module if you >>>>> can inject a message with queue position for the caller in >>>>> question, as I cant see that in documentation, I only see >>>>> message_queue which I assume could be used to report the >>>>> callers position, but just wondered if anyone has done >>>>> this and if they could give me some tips as to if possible? >>>>> >>>>> Many thanks >>>>> >>>>> Jon >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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: From bogdan at opensips.org Mon Nov 7 16:15:25 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 7 Nov 2016 17:15:25 +0200 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> <5d601c3e-ac5b-b6d1-fc0a-7959f1f0e4a0@opensips.org> Message-ID: <698e1be4-ce83-9782-5286-e8154bccd0b8@opensips.org> Hi Jonathan, Please revert the prev patch and try this new one - hopefully it will fix the crash. Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06.11.2016 18:50, Jonathan Hunter wrote: > > Hi Bogdan, > > > Sorry for the delay. > > > I installed directly via make install, not via packages. > > > Jon > > > > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *Sent:* 03 November 2016 10:39 > *To:* Jonathan Hunter; OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position > Hi Jonathan, > > Have you installed OpenSIPS via packages ? or directly via "make > install" ? > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > Home ? OpenSIPS Solutions > www.opensips-solutions.com > OpenSIPS is a mature Open Source implementation of a SIP server. > OpenSIPS is more than a SIP proxy/router as it includes > application-level functionalities. > > > On 02.11.2016 11:33, Jonathan Hunter wrote: >> >> Hi Bogdan, >> >> >> I am getting the core dumps, but containing no symbol tables, so I >> presume I need to recompile with debug flags enabled? >> >> >> Core was generated by `/usr/local/sbin/opensips -P >> /var/run/opensips.pid'. >> Program terminated with signal 11, Segmentation fault. >> #0 0x00000000004ed7fb in ?? () >> "/core.24882" is a core file. >> Please specify an executable to debug. >> (gdb) bt full >> #0 0x00000000004ed7fb in ?? () >> No symbol table info available. >> #1 0x00007f6af7604468 in ?? () >> No symbol table info available. >> #2 0x000000000000001a in ?? () >> No symbol table info available. >> #3 0x0000000000000000 in ?? () >> No symbol table info available. >> >> >> >> I installed 2.1 from sources, so whats the best way to do this? >> >> >> thanks >> >> >> Jon >> >> >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* 02 November 2016 08:09 >> *To:* Jonathan Hunter; OpenSIPS users mailling list >> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >> For sure it is a patch issue. if you have a backtrace, it will useful. >> >> Thanks, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> Home ? OpenSIPS Solutions >> www.opensips-solutions.com >> OpenSIPS is a mature Open Source implementation of a SIP server. >> OpenSIPS is more than a SIP proxy/router as it includes >> application-level functionalities. >> >> >> On 02.11.2016 09:56, Jonathan Hunter wrote: >>> >>> Hi Bogdan, >>> >>> >>> Thanks very much for this. >>> >>> >>> I have just applied patch (installed from sources so when to >>> call_center module directory and ran patch < call_center_pos.patch) >>> then did a recompile. >>> >>> >>> However when I now route to the call center (cc_handle_call) it >>> generates a core and kills opensips; >>> >>> >>> !!!!user 2000 has Callqueue set so send to Call Queue Route >>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: >>> NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set >>> event EPOLLHUP - connection closed by the remote peer! >>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: >>> CRITICAL:core:receive_fd: EOF on 19 >>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >>> INFO:core:handle_sigs: child process 21119 exited by a signal 11 >>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >>> INFO:core:handle_sigs: core was generated >>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >>> INFO:core:handle_sigs: terminating due to SIGCHLD >>> >>> >>> >>> Do you need me to backtrace/debug through to get the issue? Or is >>> problem how I applied patch? >>> >>> >>> Many thanks >>> >>> >>> Jon >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Bogdan-Andrei Iancu >>> *Sent:* 01 November 2016 21:44 >>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>> Hi Jonathan, >>> >>> Please give it a try to this patch - it is not really tested, but >>> when the call is sent the Queue announcement, it should have a >>> ";cc_pos=xxx" parameter giving the position is the queue (0 being >>> the first to be dispatched to agents). >>> >>> Let me know if it works. >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> Home ? OpenSIPS Solutions >>> www.opensips-solutions.com >>> OpenSIPS is a mature Open Source implementation of a SIP server. >>> OpenSIPS is more than a SIP proxy/router as it includes >>> application-level functionalities. >>> >>> >>> On 28.10.2016 15:59, Jonathan Hunter wrote: >>>> >>>> Hi Bogdan, >>>> >>>> >>>> Great news, really do appreciate that. >>>> >>>> >>>> Many thanks >>>> >>>> >>>> Jon >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Bogdan-Andrei Iancu >>>> *Sent:* 28 October 2016 12:48 >>>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>> position >>>> Hi Jonathan, >>>> >>>> No, it is no yet available. Give me couple of days and I will make >>>> a patch for it. >>>> >>>> Best regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> Home ? OpenSIPS Solutions >>>> www.opensips-solutions.com >>>> OpenSIPS is a mature Open Source implementation of a SIP server. >>>> OpenSIPS is more than a SIP proxy/router as it includes >>>> application-level functionalities. >>>> >>>> >>>> On 25.10.2016 19:22, Jonathan Hunter wrote: >>>>> >>>>> Hi Bogdan, >>>>> >>>>> >>>>> Sorry cant recall If I replied to this. >>>>> >>>>> >>>>> Is cc_pos available now to extract from the module? >>>>> >>>>> >>>>> Thats the only thing I need then I can implement call center which >>>>> I think will be much more scale-able than the other approach I am >>>>> using with FreeSWITCH, I would use that just for announcements. >>>>> >>>>> >>>>> Any response/help appreciated. >>>>> >>>>> >>>>> Jon >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Bogdan-Andrei Iancu >>>>> *Sent:* 13 October 2016 10:59 >>>>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>>>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>>> position >>>>> Hi Jonathan, >>>>> >>>>> No, currently this is not possible. I was trying to envision a >>>>> solution for your need. >>>>> >>>>> But, checking the code, it is really difficult to add the headers >>>>> to the INVITEs originated by OpenSIPS (via the B2BUA), as we need >>>>> some flexibility (different headers to different INVITEs belonging >>>>> to the same B2B scenario , and even more, we need to traverse >>>>> couple of internal APIs - to propagate the hdrs from Call center >>>>> module all the way to TM). >>>>> >>>>> So, a simpler approach may be to add such extra info as URI params >>>>> to the RURI. Like if you have the RURI >>>>> "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the >>>>> RURI in the INVITE to the media server will look like : >>>>> sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the >>>>> estimated time to wait in seconds and cc_pos the position in the >>>>> queue. >>>>> >>>>> What do you think of this ? >>>>> >>>>> Regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 12.10.2016 17:21, Jonathan Hunter wrote: >>>>>> Hi Bogdan, >>>>>> >>>>>> Yes being able to grab the queue position would be perfect. >>>>>> >>>>>> Is that possible? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jon >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>>>>> To: hunterj91 at hotmail.com; users at lists.opensips.org >>>>>> From: bogdan at opensips.org >>>>>> Date: Wed, 12 Oct 2016 15:42:43 +0300 >>>>>> >>>>>> Hi Jonathan, >>>>>> >>>>>> When a call is mapped to a flow / queue (before playing the >>>>>> welcome message), we know the ETA (estimated time to wait) and >>>>>> when is placed in the queue (before playing the queuing) we >>>>>> internally know the position in the queue. >>>>>> >>>>>> Would it help to have the position in the queue placed into a >>>>>> custome SIP header, when sending the INVITE to the message_queue >>>>>> URL ? or to the welcome message ? >>>>>> >>>>>> Regards, >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> On 12.10.2016 12:06, Jonathan Hunter wrote: >>>>>> >>>>>> Hello Bogdan, >>>>>> >>>>>> Thanks for the response. >>>>>> >>>>>> In terms of my question, with a number of queuing platforms, >>>>>> they have the capability to tell the caller, what position >>>>>> they are in , and when they are likely to be answered. >>>>>> >>>>>> I just wondered if this logic was already within the module, >>>>>> or if I would need to use an external code/script to >>>>>> facilitate this function? >>>>>> >>>>>> As I presume call_center tracks the number of calls currently >>>>>> in a queue ? I would then want to be able to extract that >>>>>> information, and if a caller was for example in 3rd place in >>>>>> a queue, I could inject the relevant audio from freeswitch to >>>>>> tell them their current position? >>>>>> >>>>>> Does that make sense? :) Just wanted to know if its >>>>>> something this module can do? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jon >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>>>> position >>>>>> To: users at lists.opensips.org >>>>>> ; hunterj91 at hotmail.com >>>>>> >>>>>> From: bogdan at opensips.org >>>>>> Date: Wed, 12 Oct 2016 11:23:45 +0300 >>>>>> >>>>>> Hello Jon, >>>>>> >>>>>> The message_queue is a SIP URI pointing to an audio >>>>>> announcement to play to roll of the waiting/in-queue >>>>>> playback. This needs to be an announcements that never ends >>>>>> (from the perspective of the media server); only the the >>>>>> OpenSIPS Queue may terminate the playback, when it decides to >>>>>> take out the call from waiting and to deliver it to an agent. >>>>>> >>>>>> As for your question, I'm not sure I understand what you mean >>>>>> by "inject a message with queue position for the caller in >>>>>> question" - could you detail please ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> >>>>>> On 11.10.2016 13:36, Jonathan Hunter wrote: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> I have implemented an opensips/freeswitch environment, >>>>>> and I wish to add call queues to it, and I like the look >>>>>> of call_center, so just checking this out in comparison >>>>>> to mod_callcenter in FS world. >>>>>> >>>>>> My main question is if using the call_center module if >>>>>> you can inject a message with queue position for the >>>>>> caller in question, as I cant see that in documentation, >>>>>> I only see message_queue which I assume could be used to >>>>>> report the callers position, but just wondered if anyone >>>>>> has done this and if they could give me some tips as to >>>>>> if possible? >>>>>> >>>>>> Many thanks >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: call_center_pos.patch Type: text/x-patch Size: 2579 bytes Desc: not available URL: From bogdan at opensips.org Mon Nov 7 21:41:54 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 7 Nov 2016 22:41:54 +0200 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> <5d601c3e-ac5b-b6d1-fc0a-7959f1f0e4a0@opensips.org> <698e1be4-ce83-9782-5286-e8154bccd0b8@opensips.org> Message-ID: <63f2329e-066b-ed10-5629-dd8fbe075758@opensips.org> Hi Jonathan, I was not able to test it with a real queue, so let me know if it really does the job (in terms of reporting the real position in the queue). Some questions: 1) currently I add that value only when sending to the queue / MOH - do you foresee any need to be added for other announcements like for welcome ? 2) will it be useful to add the ETW (estimate time to wait) ? is it useful ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.11.2016 22:35, Jonathan Hunter wrote: > > Hi Bogdan, > > > Hope you are well. > > > Yes that patch works, it stops the crash, and adds the parameter; > > > Request-Line: INVITE sip:7777 at 1.2.3.4:5080;cc_pos=0 SIP/2.0 > > > Which is great! > > > I will now get to work on the solution, thanks again. > > > Jon > > > > *From:* Bogdan-Andrei Iancu > *Sent:* 07 November 2016 15:15 > *To:* Jonathan Hunter; OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position > Hi Jonathan, > > Please revert the prev patch and try this new one - hopefully it will > fix the crash. > > Thanks and regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > Home ? OpenSIPS Solutions > www.opensips-solutions.com > OpenSIPS is a mature Open Source implementation of a SIP server. > OpenSIPS is more than a SIP proxy/router as it includes > application-level functionalities. > > > On 06.11.2016 18:50, Jonathan Hunter wrote: >> >> Hi Bogdan, >> >> >> Sorry for the delay. >> >> >> I installed directly via make install, not via packages. >> >> >> Jon >> >> >> >> ------------------------------------------------------------------------ >> *From:* Bogdan-Andrei Iancu >> *Sent:* 03 November 2016 10:39 >> *To:* Jonathan Hunter; OpenSIPS users mailling list >> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >> Hi Jonathan, >> >> Have you installed OpenSIPS via packages ? or directly via "make >> install" ? >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> Home ? OpenSIPS Solutions >> www.opensips-solutions.com >> OpenSIPS is a mature Open Source implementation of a SIP server. >> OpenSIPS is more than a SIP proxy/router as it includes >> application-level functionalities. >> >> >> On 02.11.2016 11:33, Jonathan Hunter wrote: >>> >>> Hi Bogdan, >>> >>> >>> I am getting the core dumps, but containing no symbol tables, so I >>> presume I need to recompile with debug flags enabled? >>> >>> >>> Core was generated by `/usr/local/sbin/opensips -P >>> /var/run/opensips.pid'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 0x00000000004ed7fb in ?? () >>> "/core.24882" is a core file. >>> Please specify an executable to debug. >>> (gdb) bt full >>> #0 0x00000000004ed7fb in ?? () >>> No symbol table info available. >>> #1 0x00007f6af7604468 in ?? () >>> No symbol table info available. >>> #2 0x000000000000001a in ?? () >>> No symbol table info available. >>> #3 0x0000000000000000 in ?? () >>> No symbol table info available. >>> >>> >>> >>> I installed 2.1 from sources, so whats the best way to do this? >>> >>> >>> thanks >>> >>> >>> Jon >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Bogdan-Andrei Iancu >>> *Sent:* 02 November 2016 08:09 >>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue position >>> For sure it is a patch issue. if you have a backtrace, it will useful. >>> >>> Thanks, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> Home ? OpenSIPS Solutions >>> www.opensips-solutions.com >>> OpenSIPS is a mature Open Source implementation of a SIP server. >>> OpenSIPS is more than a SIP proxy/router as it includes >>> application-level functionalities. >>> >>> >>> On 02.11.2016 09:56, Jonathan Hunter wrote: >>>> >>>> Hi Bogdan, >>>> >>>> >>>> Thanks very much for this. >>>> >>>> >>>> I have just applied patch (installed from sources so when to >>>> call_center module directory and ran patch < call_center_pos.patch) >>>> then did a recompile. >>>> >>>> >>>> However when I now route to the call center (cc_handle_call) it >>>> generates a core and kills opensips; >>>> >>>> >>>> !!!!user 2000 has Callqueue set so send to Call Queue Route >>>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: >>>> NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() >>>> set event EPOLLHUP - connection closed by the remote peer! >>>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: >>>> CRITICAL:core:receive_fd: EOF on 19 >>>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >>>> INFO:core:handle_sigs: child process 21119 exited by a signal 11 >>>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >>>> INFO:core:handle_sigs: core was generated >>>> Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: >>>> INFO:core:handle_sigs: terminating due to SIGCHLD >>>> >>>> >>>> >>>> Do you need me to backtrace/debug through to get the issue? Or is >>>> problem how I applied patch? >>>> >>>> >>>> Many thanks >>>> >>>> >>>> Jon >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Bogdan-Andrei Iancu >>>> *Sent:* 01 November 2016 21:44 >>>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>> position >>>> Hi Jonathan, >>>> >>>> Please give it a try to this patch - it is not really tested, but >>>> when the call is sent the Queue announcement, it should have a >>>> ";cc_pos=xxx" parameter giving the position is the queue (0 being >>>> the first to be dispatched to agents). >>>> >>>> Let me know if it works. >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> Home ? OpenSIPS Solutions >>>> www.opensips-solutions.com >>>> OpenSIPS is a mature Open Source implementation of a SIP server. >>>> OpenSIPS is more than a SIP proxy/router as it includes >>>> application-level functionalities. >>>> >>>> >>>> On 28.10.2016 15:59, Jonathan Hunter wrote: >>>>> >>>>> Hi Bogdan, >>>>> >>>>> >>>>> Great news, really do appreciate that. >>>>> >>>>> >>>>> Many thanks >>>>> >>>>> >>>>> Jon >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Bogdan-Andrei Iancu >>>>> *Sent:* 28 October 2016 12:48 >>>>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>>>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>>> position >>>>> Hi Jonathan, >>>>> >>>>> No, it is no yet available. Give me couple of days and I will make >>>>> a patch for it. >>>>> >>>>> Best regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> Home ? OpenSIPS Solutions >>>>> www.opensips-solutions.com >>>>> OpenSIPS is a mature Open Source implementation of a SIP server. >>>>> OpenSIPS is more than a SIP proxy/router as it includes >>>>> application-level functionalities. >>>>> >>>>> >>>>> On 25.10.2016 19:22, Jonathan Hunter wrote: >>>>>> >>>>>> Hi Bogdan, >>>>>> >>>>>> >>>>>> Sorry cant recall If I replied to this. >>>>>> >>>>>> >>>>>> Is cc_pos available now to extract from the module? >>>>>> >>>>>> >>>>>> Thats the only thing I need then I can implement call center >>>>>> which I think will be much more scale-able than the other >>>>>> approach I am using with FreeSWITCH, I would use that just for >>>>>> announcements. >>>>>> >>>>>> >>>>>> Any response/help appreciated. >>>>>> >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* Bogdan-Andrei Iancu >>>>>> *Sent:* 13 October 2016 10:59 >>>>>> *To:* Jonathan Hunter; OpenSIPS users mailling list >>>>>> *Subject:* Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>>>> position >>>>>> Hi Jonathan, >>>>>> >>>>>> No, currently this is not possible. I was trying to envision a >>>>>> solution for your need. >>>>>> >>>>>> But, checking the code, it is really difficult to add the headers >>>>>> to the INVITEs originated by OpenSIPS (via the B2BUA), as we need >>>>>> some flexibility (different headers to different INVITEs >>>>>> belonging to the same B2B scenario , and even more, we need to >>>>>> traverse couple of internal APIs - to propagate the hdrs from >>>>>> Call center module all the way to TM). >>>>>> >>>>>> So, a simpler approach may be to add such extra info as URI >>>>>> params to the RURI. Like if you have the RURI >>>>>> "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the >>>>>> RURI in the INVITE to the media server will look like : >>>>>> sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being >>>>>> the estimated time to wait in seconds and cc_pos the position in >>>>>> the queue. >>>>>> >>>>>> What do you think of this ? >>>>>> >>>>>> Regards, >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> On 12.10.2016 17:21, Jonathan Hunter wrote: >>>>>>> Hi Bogdan, >>>>>>> >>>>>>> Yes being able to grab the queue position would be perfect. >>>>>>> >>>>>>> Is that possible? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>>>>> position >>>>>>> To: hunterj91 at hotmail.com; users at lists.opensips.org >>>>>>> From: bogdan at opensips.org >>>>>>> Date: Wed, 12 Oct 2016 15:42:43 +0300 >>>>>>> >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> When a call is mapped to a flow / queue (before playing the >>>>>>> welcome message), we know the ETA (estimated time to wait) and >>>>>>> when is placed in the queue (before playing the queuing) we >>>>>>> internally know the position in the queue. >>>>>>> >>>>>>> Would it help to have the position in the queue placed into a >>>>>>> custome SIP header, when sending the INVITE to the message_queue >>>>>>> URL ? or to the welcome message ? >>>>>>> >>>>>>> Regards, >>>>>>> Bogdan-Andrei Iancu >>>>>>> OpenSIPS Founder and Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> On 12.10.2016 12:06, Jonathan Hunter wrote: >>>>>>> >>>>>>> Hello Bogdan, >>>>>>> >>>>>>> Thanks for the response. >>>>>>> >>>>>>> In terms of my question, with a number of queuing platforms, >>>>>>> they have the capability to tell the caller, what position >>>>>>> they are in , and when they are likely to be answered. >>>>>>> >>>>>>> I just wondered if this logic was already within the module, >>>>>>> or if I would need to use an external code/script to >>>>>>> facilitate this function? >>>>>>> >>>>>>> As I presume call_center tracks the number of calls >>>>>>> currently in a queue ? I would then want to be able to >>>>>>> extract that information, and if a caller was for example in >>>>>>> 3rd place in a queue, I could inject the relevant audio from >>>>>>> freeswitch to tell them their current position? >>>>>>> >>>>>>> Does that make sense? :) Just wanted to know if its >>>>>>> something this module can do? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue >>>>>>> position >>>>>>> To: users at lists.opensips.org >>>>>>> ; hunterj91 at hotmail.com >>>>>>> >>>>>>> From: bogdan at opensips.org >>>>>>> Date: Wed, 12 Oct 2016 11:23:45 +0300 >>>>>>> >>>>>>> Hello Jon, >>>>>>> >>>>>>> The message_queue is a SIP URI pointing to an audio >>>>>>> announcement to play to roll of the waiting/in-queue >>>>>>> playback. This needs to be an announcements that never ends >>>>>>> (from the perspective of the media server); only the the >>>>>>> OpenSIPS Queue may terminate the playback, when it decides >>>>>>> to take out the call from waiting and to deliver it to an agent. >>>>>>> >>>>>>> As for your question, I'm not sure I understand what you >>>>>>> mean by "inject a message with queue position for the caller >>>>>>> in question" - could you detail please ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Bogdan-Andrei Iancu >>>>>>> OpenSIPS Founder and Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> >>>>>>> On 11.10.2016 13:36, Jonathan Hunter wrote: >>>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> I have implemented an opensips/freeswitch environment, >>>>>>> and I wish to add call queues to it, and I like the look >>>>>>> of call_center, so just checking this out in comparison >>>>>>> to mod_callcenter in FS world. >>>>>>> >>>>>>> My main question is if using the call_center module if >>>>>>> you can inject a message with queue position for the >>>>>>> caller in question, as I cant see that in documentation, >>>>>>> I only see message_queue which I assume could be used to >>>>>>> report the callers position, but just wondered if anyone >>>>>>> has done this and if they could give me some tips as to >>>>>>> if possible? >>>>>>> >>>>>>> Many thanks >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: From rob.dyck at telus.net Tue Nov 8 01:15:18 2016 From: rob.dyck at telus.net (Robert Dyck) Date: Mon, 07 Nov 2016 16:15:18 -0800 Subject: [OpenSIPS-Users] Rtpproxy and IPV4 IPV6 interworking Message-ID: <1779817.2kyhvzfVrv@blacky.mylan> I have some question regarding rtpproxy capabilities in relation to IPV4-IPV6 interworking. The articles I have read say that you need to assign an address from each address family to rtpproxy. They go on to say that rtpproxy will then be in bridged mode. Others define bridge mode as assigning two interfaces to rtpproxy. If the IPV4 and IPV6 addresses are on the same interface, is the rtpproxy indeed in bridged mode? Should one avoid the use of engage_rtpproxy? Assuming that IPV4- IPV6 interworking is actually possible using opensips and rtpproxy, does that mean that an instance of rtpproxy is not available to enable NAT traversal - would NAT traversal require using another instance of rtpproxy using a single IPV4 address? Furthermore is the multihome parameter relevant to IPV4-IPV6 interworking if opensips only listens on one interface? Thank you all From acmicrox at gmail.com Tue Nov 8 03:01:53 2016 From: acmicrox at gmail.com (Chen-Che Huang) Date: Mon, 7 Nov 2016 19:01:53 -0700 (MST) Subject: [OpenSIPS-Users] No TLS-related files in OpenSIPS 1.11.9 src.tar.gz In-Reply-To: <99df1d60-5c6e-68f6-163d-5f1f7de3960b@opensips.org> References: <1478509456538-7604883.post@n2.nabble.com> <0760d5ba-565d-b46c-06c9-6bb9572bbb1f@opensips.org> <99df1d60-5c6e-68f6-163d-5f1f7de3960b@opensips.org> Message-ID: <1478570513195-7604909.post@n2.nabble.com> Hi R?zvan, Thanks for your help. The updated archive contains the TLS-related files. However, the generated deb files from the archived are having the 1.11.8-1 on their names rather than 1.11.9. Can you kindly help to take a look? Thanks. Best regards, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/No-TLS-related-files-in-OpenSIPS-1-11-9-src-tar-gz-tp7604883p7604909.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Tue Nov 8 08:57:30 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 8 Nov 2016 09:57:30 +0200 Subject: [OpenSIPS-Users] Rtpproxy and IPV4 IPV6 interworking In-Reply-To: <1779817.2kyhvzfVrv@blacky.mylan> References: <1779817.2kyhvzfVrv@blacky.mylan> Message-ID: <7ca184f6-832f-97c6-938e-14aec33a3f04@opensips.org> Hi, Robert! See my answers inline. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 02:15 AM, Robert Dyck wrote: > I have some question regarding rtpproxy capabilities in relation to IPV4-IPV6 > interworking. > > The articles I have read say that you need to assign an address from each > address family to rtpproxy. They go on to say that rtpproxy will then be in > bridged mode. Others define bridge mode as assigning two interfaces to > rtpproxy. As long as you have RTPProxy listening on two IPs, you have it set in bridge mode. It doesn't matther whether one of them is IPv6, or both are. > If the IPV4 and IPV6 addresses are on the same interface, is the rtpproxy > indeed in bridged mode? Should one avoid the use of engage_rtpproxy? Yes, as stated above, RTPProxy is in bridged mode and you should avoid using engage_rtpproxy(). That's because the function can't know/decide which interface is which and cannot map with the RTPProxy's one. > > Assuming that IPV4- IPV6 interworking is actually possible using opensips and > rtpproxy, does that mean that an instance of rtpproxy is not available to > enable NAT traversal - would NAT traversal require using another instance of > rtpproxy using a single IPV4 address? No, you don't need an extra instance - a single instance will do both bridging and nat traversal. > > Furthermore is the multihome parameter relevant to IPV4-IPV6 interworking if > opensips only listens on one interface? The multihome parameter is only relevant for OpenSIPS, it doesn't influence RTPProxy's behavior at all. From razvan at opensips.org Tue Nov 8 09:03:26 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 8 Nov 2016 10:03:26 +0200 Subject: [OpenSIPS-Users] No TLS-related files in OpenSIPS 1.11.9 src.tar.gz In-Reply-To: <1478570513195-7604909.post@n2.nabble.com> References: <1478509456538-7604883.post@n2.nabble.com> <0760d5ba-565d-b46c-06c9-6bb9572bbb1f@opensips.org> <99df1d60-5c6e-68f6-163d-5f1f7de3960b@opensips.org> <1478570513195-7604909.post@n2.nabble.com> Message-ID: Hi, Chen-Che! Are you talking about the deb files generated here [1]? If not, can you send me a link to the affected archive? [1] http://apt.opensips.org/packages.php Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 04:01 AM, Chen-Che Huang wrote: > Hi R?zvan, > > Thanks for your help. The updated archive contains the TLS-related files. > However, the generated deb files from the archived are having the 1.11.8-1 > on their names rather than 1.11.9. Can you kindly help to take a look? > Thanks. > > Best regards, > Chen-Che > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/No-TLS-related-files-in-OpenSIPS-1-11-9-src-tar-gz-tp7604883p7604909.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From spanda at 3clogic.com Tue Nov 8 09:05:31 2016 From: spanda at 3clogic.com (Sasmita Panda) Date: Tue, 8 Nov 2016 13:35:31 +0530 Subject: [OpenSIPS-Users] Regarding Option request . Message-ID: Hi All , I am using opensips-1.11 . I have a requirement that when an "Option" request will come to my proxy from the gateways I have added in my dr_gateways table then only I will process the request and will send 200 OK . Previously , I was sending 200 Ok to all the Options requests , So I have written the config file like bellow . route{ if (method=="OPTIONS") { sl_send_reply("200", "OK"); exit; } ....................... ............................... route(1); } I have tried many possible ways but its not happening . What should I do to achieve my goal ? *Thanks & Regards* *Sasmita Panda* *Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Nov 8 09:16:49 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 8 Nov 2016 10:16:49 +0200 Subject: [OpenSIPS-Users] Regarding Option request . In-Reply-To: References: Message-ID: Hello! You chould use the is_from_gw()[1] function to detect if a message is coming from a gateway. So basically your code should look like this: if (method == "OPTIONS" && is_from_gw()) { sl_send_reply("200", "OK"); exit; } [1] http://www.opensips.org/html/docs/modules/1.11.x/drouting.html#id295343 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 10:05 AM, Sasmita Panda wrote: > Hi All , > > I am using opensips-1.11 . I have a requirement that when an > "Option" request will come to my proxy from the gateways I have added > in my dr_gateways table then only I will process the request and will > send 200 OK . > > Previously , I was sending 200 Ok to all the Options requests , > So I have written the config file like bellow . > > route{ > if (method=="OPTIONS") { > sl_send_reply("200", "OK"); > exit; > } > ....................... > ............................... > route(1); > } > > I have tried many possible ways but its not happening . What should I > do to achieve my goal ? > > */Thanks & Regards/* > /Sasmita Panda/ > /Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > > _______________________________________________ > 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: From denis7979 at mail.ru Tue Nov 8 13:33:46 2016 From: denis7979 at mail.ru (Denis) Date: Tue, 8 Nov 2016 15:33:46 +0300 Subject: [OpenSIPS-Users] B2B top hiding In-Reply-To: <88207606-7394-b3ce-97d2-cd94d6946ac4@opensips.org> References: <595252113.20161107152005@ptl.ru> <03255b67-44f7-a9bd-3729-060a04e37c45@opensips.org> <1129145584.20161107162013@ptl.ru> <88207606-7394-b3ce-97d2-cd94d6946ac4@opensips.org> Message-ID: <74706983.20161108153346@ptl.ru> Hello, Razvan! I found the problem (that was not correctly analyzing log). Everything working if i set host and port before b2b_init_request. Thank you for help. mailto:denis7979 at mail.ru Hi, Denis! Are you seeing any other ERROR messages in the logs? When you see those errors in the log, does OpenSIPS send any message out (even to himself)? Can you provide a full trace? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/07/2016 03:20 PM, Denis wrote: Re: [OpenSIPS-Users] B2B top hiding Hello, Razvan! I want to make some input point to my SIP network which will make authentication and topology hiding. Authentication works (i checked it by inserting in client SIP UA wrong password), but b2b doesn`t. When i try to setting port before b2b_init_request i see in log " ERROR:b2b_logic:create_top_hiding_entities: failed to create new b2b server instance" mailto:denis7979 at mail.ru Hi, Denis! Can you please detail a bit what you are trying to achieve? In the trace attached, all I can see is that OpenSIPS doesn't authenticate the UA - I don't see why it should even try to send the INVITE anywhere. However, if you are saying that you see both lines in the log, it means at a certain point the INVITE was authenticated and the topo-hiding was engaged. Did you try setting the port before calling b2b_init_request(), in route(1)? BR R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/07/2016 02:20 PM, Denis wrote: B2B top hiding Hello! Opensips 2.2.2. I want to make an installation of Opensips which will include auth and top hiding functionality. First of all, in the main route, i catch INVITE "if (is_method("INVITE") && !has_totag()) { route(1); exit; }" then, in route [1], i make some auth procedure using "pv_proxy_authorize" and "proxy_authorize" functions if auth procedure is successful i make "xlog("L_INFO", "Route1:$rm was received with auth (IP=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) AND B2B prepared"); b2b_init_request("top hiding"); exit;" In the local route i try to edit port of the destination, using "xlog("L_INFO", "Local:$rm was received with auth (IP=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au)"); rewritehostport("1.1.1.1:5065");" where 1.1.1.1 - ip address of Opensips. In attachment you can see debug of unsuccessful call, where 1.1.1.1 - ip address of Opensips. 2.2.2.2 - caller SIP UA I can see in syslog both messages, in local route and in route [1]. As you can see from the debug Opensips doesn`t try to send INVITE to 1.1.1.1:5065. Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From denis7979 at mail.ru Tue Nov 8 14:41:30 2016 From: denis7979 at mail.ru (Denis) Date: Tue, 8 Nov 2016 16:41:30 +0300 Subject: [OpenSIPS-Users] Common points in B2B top hiding Message-ID: <1082603211.20161108164130@ptl.ru> Hello! Sorry that it was, but are there any common points between received INVITE and new generated INVITE while using B2B top hiding? I need some points, gotten in local_route, which will uniquely identified the call and which i can use, for example, to add some headers (based on that points). Thank you for any help. mailto:denis7979 at mail.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenberg11219 at gmail.com Tue Nov 8 15:02:02 2016 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Tue, 8 Nov 2016 16:02:02 +0200 Subject: [OpenSIPS-Users] Pickup group help Message-ID: Can someone please guide me how I should build pickup groups feature in OpenSIPS? thank you S. Rosenberg -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Nov 8 15:09:10 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 8 Nov 2016 16:09:10 +0200 Subject: [OpenSIPS-Users] Common points in B2B top hiding In-Reply-To: <1082603211.20161108164130@ptl.ru> References: <1082603211.20161108164130@ptl.ru> Message-ID: Hi, Denis! You can copy headers from the initial request to the B2B one by using the custom headers[1]. [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id293556 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 03:41 PM, Denis wrote: > Common points in B2B top hiding Hello! > > Sorry that it was, but are there any common points between received > INVITE and new generated INVITE while using B2B top hiding? > > I need some points, gotten in local_route, which will uniquely > identified the call and which i can use, for example, to add some > headers (based on that points). > > Thank you for any help. > > > > mailto:denis7979 at mail.ru > > > _______________________________________________ > 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: From denis7979 at mail.ru Tue Nov 8 15:19:37 2016 From: denis7979 at mail.ru (Denis) Date: Tue, 8 Nov 2016 17:19:37 +0300 Subject: [OpenSIPS-Users] Common points in B2B top hiding In-Reply-To: References: <1082603211.20161108164130@ptl.ru> Message-ID: <122556688.20161108171937@ptl.ru> Hello, Razvan! No, it is not quite what i am looking for. For example, before top hiding i make authentication procedure during which i got login. For some call processing logging i need to translate this login to some proxy instance. How can i do that? mailto:denis7979 at mail.ru Hi, Denis! You can copy headers from the initial request to the B2B one by using the custom headers[1]. [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id293556 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 03:41 PM, Denis wrote: Common points in B2B top hiding Hello! Sorry that it was, but are there any common points between received INVITE and new generated INVITE while using B2B top hiding? I need some points, gotten in local_route, which will uniquely identified the call and which i can use, for example, to add some headers (based on that points). Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From pimenta at inatel.br Tue Nov 8 17:10:13 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Tue, 8 Nov 2016 16:10:13 +0000 Subject: [OpenSIPS-Users] How to find out which TCP sockes OpenSIPS is listening on? Message-ID: Hi. Is it possible to find which is every socket that is currently opened to opensips listens on SIP messages from peers, while using TCP? I have examined opensipsctl command, but it doesn't show the sockets. I need see if a new socket is being created and opened when a peer sends a SIP UPDATE. Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Nov 8 17:31:33 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 8 Nov 2016 18:31:33 +0200 Subject: [OpenSIPS-Users] Common points in B2B top hiding In-Reply-To: <122556688.20161108171937@ptl.ru> References: <1082603211.20161108164130@ptl.ru> <122556688.20161108171937@ptl.ru> Message-ID: Hi, Denis! Take a look at the "a" flag used by the b2b_init_request()[1] function. This might help you achieve what you want. May I ask you why you are using the b2b topology hiding, and not the dedicated module for topology hiding[2]? It would be far more easier to use the latter one in most of the cases. [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 [2] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 04:19 PM, Denis wrote: > Re: [OpenSIPS-Users] Common points in B2B top hiding Hello, Razvan! > > No, it is not quite what i am looking for. > > For example, before top hiding i make authentication procedure during > which i got login. > For some call processing logging i need to translate this login to > some proxy instance. > > How can i do that? > > mailto:denis7979 at mail.ru > > > Hi, Denis! > > You can copy headers from the initial request to the B2B one by using > the custom headers[1]. > > [1] > http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id293556 > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/08/2016 03:41 PM, Denis wrote: > > Common points in B2B top hiding Hello! > > Sorry that it was, but are there any common points between received > INVITE and new generated INVITE while using B2B top hiding? > > I need some points, gotten in local_route, which will uniquely > identified the call and which i can use, for example, to add some > headers (based on that points). > > Thank you for any help. > > > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: From razvan at opensips.org Tue Nov 8 17:34:57 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 8 Nov 2016 18:34:57 +0200 Subject: [OpenSIPS-Users] How to find out which TCP sockes OpenSIPS is listening on? In-Reply-To: References: Message-ID: Hi, Rodrigo! So are you interested in finding the opened TCP connections? If so, you should try the list_tcp_conns command[1]. [1] http://www.opensips.org/Documentation/Interface-CoreMI-2-2#toc5 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 06:10 PM, Rodrigo Pimenta Carvalho wrote: > > > Hi. > > > Is it possible to find which is every socket that is currently opened > to opensips listens on SIP messages from peers, while using TCP? > > > I have examined opensipsctl command, but it doesn't show the sockets. > > I need see if a new socket is being created and opened when a peer > sends a SIP UPDATE. > > > Any hint will be very helpful! > > > Best regards. > > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > 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: From Agalya_Ramachandran at comcast.com Tue Nov 8 18:10:27 2016 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Tue, 8 Nov 2016 17:10:27 +0000 Subject: [OpenSIPS-Users] Support for https in async In-Reply-To: <63ac95ab-d6e5-d2c6-7f77-18816256ceae@opensips.org> References: <63ac95ab-d6e5-d2c6-7f77-18816256ceae@opensips.org> Message-ID: Hi Liviu, Thank you for response. I have few questions, can you please clarify me on these. * Is there is a roadmap in future targeting async() to handle https queries? * In start_async_http_request(), why is curl_multi_wait is not used to overcome 1024 fds limitation? and is there plan to use it in future? * What is the use of read_fds[] in rest_methods.c and who uses it? * Why select() is not used ? Regards, Agalya From: Liviu Chircu [mailto:liviu at opensips.org] Sent: Monday, October 31, 2016 12:27 PM To: Ramachandran, Agalya (Contractor) ; OpenSIPS users mailling list Subject: Re: Support for https in async Hi, Agalya! We have not done any development in that direction, and I assume it won't work out of the box, as we need to instruct libcurl on where to find the CA certificate before we can expect it to establish the TLS connection. As an alternative, we could add the option of disabling host/peer verifications like here [1] [1]: https://curl.haxx.se/libcurl/c/https.html Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 31.10.2016 16:41, Ramachandran, Agalya (Contractor) wrote: Hi team, Have you tried with https://url with async and does that work without issue ? When I try, resume_async_http_req is called, but crash is occurring at libcurl library. So helpless to debug further. async(rest_put("https://url", "$fU,$tU,$ci ", "application/json", "$var(body)", "$var(ct)", "$var(rcode)"),resume); My question is crash occring only in my scenario or OpenSIPS doesn't support async as https? Here is my dump just in case for reference. #0 0x00007f567248da1e in Curl_raw_nequal () from /lib64/libcurl.so.4 #1 0x00007f567245bd0f in Curl_checkheaders () from /lib64/libcurl.so.4 #2 0x00007f567245d1e5 in Curl_http () from /lib64/libcurl.so.4 #3 0x00007f567246db4b in Curl_do () from /lib64/libcurl.so.4 #4 0x00007f567247da1b in multi_runsingle () from /lib64/libcurl.so.4 #5 0x00007f567247e121 in curl_multi_perform () from /lib64/libcurl.so.4 #6 0x00007f56726b75ca in resume_async_http_req (fd=9, msg=0x7f56739c0640 , _param=0x7f56b3e354d0) at rest_methods.c:380 #7 0x00007f56737771ff in t_resume_async (fd=0x7f56b3e26840, param=0x7f567405c3e8) at async.c:125 #8 0x0000000000509975 in handle_io (fm=0x7f56b3e26840, idx=1, event_type=1) at net/net_udp.c:267 #9 0x00000000005082b3 in io_wait_loop_epoll (h=0x806e00 <_worker_io>, t=1, repeat=0) at net/../io_wait_loop.h:221 #10 0x0000000000509c30 in udp_rcv_loop (si=0x7f56b3dd6808) at net/net_udp.c:308 #11 0x000000000050a1c8 in udp_start_processes (chd_rank=0x7d30e8 , startup_done=0x0) at net/net_udp.c:372 #12 0x0000000000492304 in main_loop () at main.c:671 #13 0x0000000000494d8f in main (argc=7, argv=0x7fff38a979f8) at main.c:1261 Regards, Agalya From: Ramachandran, Agalya (Contractor) Sent: Thursday, October 27, 2016 4:24 PM To: users at lists.opensips.org; 'Liviu Chircu' Subject: Support for https in async Hi team, Just a quick question.. Does async(), method supports https request? When I try to use https, resume_async_http_req is called, but I never got the response and rather OpenSIPS crashed at libcurl. Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Nov 8 18:29:02 2016 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 8 Nov 2016 19:29:02 +0200 Subject: [OpenSIPS-Users] Support for https in async In-Reply-To: References: <63ac95ab-d6e5-d2c6-7f77-18816256ceae@opensips.org> Message-ID: <6a1bda52-ac41-6029-fbdc-e0734d8a82f5@opensips.org> Hi Agalya! > handle https queries Regarding HTTPSqueries, could you try to build your rest_client with "libcurl-openssl-dev" instead of "libcurl-gnutls-dev"as a possible fix? > why is curl_multi_wait is not used We don't want to block OpenSIPS after issuing an async query, but rather use the core async interface in order to quickly resume processing the next SIP message. >What is the use of read_fds[] in rest_methods.c Helps us find the needle in the haystack. If we find the needle (i.e. the new fd), we can throw it into the reactor and successfully exit. Otherwise, the connect operation is still going, and we need to wait a bit more. >Why select() is not used ? We don't want to do select() in the module code. The core reactor already does that for us. The module's only job in the async pattern is to produce file descriptors and feed them to the core async engine. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 08.11.2016 19:10, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > Thank you for response. I have few questions, can you please clarify > me on these. > > ?Is there is a roadmap in future targeting async() to handle https > queries? > > ?In start_async_http_request(), why is curl_multi_wait is not used to > overcome 1024 fds limitation? and is there plan to use it in future? > > ?What is the use of read_fds[] in rest_methods.c and who uses it? > > ?Why select() is not used ? > > Regards, > > Agalya > > *From:*Liviu Chircu [mailto:liviu at opensips.org] > *Sent:* Monday, October 31, 2016 12:27 PM > *To:* Ramachandran, Agalya (Contractor) > ; OpenSIPS users mailling list > > *Subject:* Re: Support for https in async > > Hi, Agalya! > > We have not done any development in that direction, and I assume it > won't work out of the box, as we need to instruct libcurl on where to > find the CA certificate before we can expect it to establish the TLS > connection. As an alternative, we could add the option of disabling > host/peer verifications like here [1] > > [1]: https://curl.haxx.se/libcurl/c/https.html > > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 31.10.2016 16:41, Ramachandran, Agalya (Contractor) wrote: > > Hi team, > > Have you tried with *https://url*with async and does that work > without issue ? > > When I try, resume_async_http_req is called, but crash is > occurring at libcurl library. So helpless to debug further. > > async(rest_put(*"https://url" , *"$fU,$tU,$ci ", > "application/json", "$var(body)", "$var(ct)", "$var(rcode)"),resume); > > My question is crash occring only in my scenario or OpenSIPS > doesn?t support async as https? > > Here is my dump just in case for reference. > > /#0 0x00007f567248da1e in Curl_raw_nequal () from /lib64/libcurl.so.4/ > > /#1 0x00007f567245bd0f in Curl_checkheaders () from > /lib64/libcurl.so.4/ > > /#2 0x00007f567245d1e5 in Curl_http () from /lib64/libcurl.so.4/ > > /#3 0x00007f567246db4b in Curl_do () from /lib64/libcurl.so.4/ > > /#4 0x00007f567247da1b in multi_runsingle () from /lib64/libcurl.so.4/ > > /#5 0x00007f567247e121 in curl_multi_perform () from > /lib64/libcurl.so.4/ > > #6 0x00007f56726b75ca in resume_async_http_req (fd=9, > msg=0x7f56739c0640 , _param=0x7f56b3e354d0) > > at rest_methods.c:380 > > #7 0x00007f56737771ff in t_resume_async (fd=0x7f56b3e26840, > param=0x7f567405c3e8) at async.c:125 > > #8 0x0000000000509975 in handle_io (fm=0x7f56b3e26840, idx=1, > event_type=1) at net/net_udp.c:267 > > #9 0x00000000005082b3 in io_wait_loop_epoll (h=0x806e00 > <_worker_io>, t=1, repeat=0) at net/../io_wait_loop.h:221 > > #10 0x0000000000509c30 in udp_rcv_loop (si=0x7f56b3dd6808) at > net/net_udp.c:308 > > #11 0x000000000050a1c8 in udp_start_processes (chd_rank=0x7d30e8 > , startup_done=0x0) at net/net_udp.c:372 > > #12 0x0000000000492304 in main_loop () at main.c:671 > > #13 0x0000000000494d8f in main (argc=7, argv=0x7fff38a979f8) at > main.c:1261 > > Regards, > > Agalya > > *From:* Ramachandran, Agalya (Contractor) > *Sent:* Thursday, October 27, 2016 4:24 PM > *To:* users at lists.opensips.org ; > 'Liviu Chircu' > *Subject:* Support for https in async > > Hi team, > > Just a quick question.. Does async(), method supports https request? > > When I try to use https, resume_async_http_req is called, but I > never got the response and rather OpenSIPS crashed at libcurl. > > Regards, > Agalya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Tue Nov 8 20:51:57 2016 From: rob.dyck at telus.net (Robert Dyck) Date: Tue, 08 Nov 2016 11:51:57 -0800 Subject: [OpenSIPS-Users] Rtpproxy and IPV4 IPV6 interworking References: <1779817.2kyhvzfVrv@blacky.mylan> Message-ID: <2780361.W64aQsUSPm@blacky.mylan> Thank you Assuming rtpproxy was started with IPV4 as the first address and IPV6 as the second, then in the NAT scenario, are the II flags mandatory in offer/answer? Slightly off topic, what sort of scenario would require the address parameter for offer/answer? On November 8, 2016 09:57:30 AM R?zvan Crainea wrote: > Hi, Robert! > > See my answers inline. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/08/2016 02:15 AM, Robert Dyck wrote: > > I have some question regarding rtpproxy capabilities in relation to > > IPV4-IPV6 interworking. > > > > The articles I have read say that you need to assign an address from each > > address family to rtpproxy. They go on to say that rtpproxy will then be > > in > > bridged mode. Others define bridge mode as assigning two interfaces to > > rtpproxy. > > As long as you have RTPProxy listening on two IPs, you have it set in > bridge mode. It doesn't matther whether one of them is IPv6, or both are. > > > If the IPV4 and IPV6 addresses are on the same interface, is the rtpproxy > > indeed in bridged mode? Should one avoid the use of engage_rtpproxy? > > Yes, as stated above, RTPProxy is in bridged mode and you should avoid > using engage_rtpproxy(). That's because the function can't know/decide > which interface is which and cannot map with the RTPProxy's one. > > > Assuming that IPV4- IPV6 interworking is actually possible using opensips > > and rtpproxy, does that mean that an instance of rtpproxy is not > > available to enable NAT traversal - would NAT traversal require using > > another instance of rtpproxy using a single IPV4 address? > > No, you don't need an extra instance - a single instance will do both > bridging and nat traversal. > > > Furthermore is the multihome parameter relevant to IPV4-IPV6 interworking > > if opensips only listens on one interface? > > The multihome parameter is only relevant for OpenSIPS, it doesn't > influence RTPProxy's behavior at all. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From pimenta at inatel.br Tue Nov 8 21:07:54 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Tue, 8 Nov 2016 20:07:54 +0000 Subject: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? Message-ID: Hi. Dialogs in my OpenSIPS is programmed to finish after 60 seconds. (timeout = 1 minute). So, when 2 peers are in a dialog, OpenSIPS sends SIP BYE to both peers, automatically after 60 seconds. Is it possible to make OpenSIPS send this exact kind of SIP BYE to both peers, before the dialog timeout? I mean, in a configured way (opensips.cfg)? When OpenSISP sends SIP BYE automatically, both peers receive the SIP BYE correctly. However, when a peer sends SIP BYE, it reaches the OpenSIPS, but OpenSIPS is unable to forward this SIP BYE. Due to some unknown reason, in this moment there is no open socket to communicate with such peer. That is why I would like to make OpenSIPS send 'its own' SIP BYE, and see if such idea will simulate a normal situation, until I discover why there is a socket problem. Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Nov 9 11:23:09 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 9 Nov 2016 12:23:09 +0200 Subject: [OpenSIPS-Users] Rtpproxy and IPV4 IPV6 interworking In-Reply-To: <2780361.W64aQsUSPm@blacky.mylan> References: <1779817.2kyhvzfVrv@blacky.mylan> <2780361.W64aQsUSPm@blacky.mylan> Message-ID: <69228361-aa03-bf7a-4c55-b826e9c17344@opensips.org> Hi, Robert! Yes, the I and E parameters are mandatory, and they should describe how the RTP will flow. For example if the flow is from IPv4 to IPv6, you should use EI; if the flow is from IPv4 to IPv6, then you should use IE. And so on, depending on the call flow. Regarding the address parameter, that is used when you want to overwrite the address indicated by RTPProxy. This is used mainly for setups where RTPProxy is behind NAT and the address inidcated is the private one. You should swap this IP with the public advertised one. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 09:51 PM, Robert Dyck wrote: > Thank you > > Assuming rtpproxy was started with IPV4 as the first address and IPV6 as the > second, then in the NAT scenario, are the II flags mandatory in offer/answer? > > Slightly off topic, what sort of scenario would require the address parameter > for offer/answer? > > On November 8, 2016 09:57:30 AM R?zvan Crainea wrote: >> Hi, Robert! >> >> See my answers inline. >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 11/08/2016 02:15 AM, Robert Dyck wrote: >>> I have some question regarding rtpproxy capabilities in relation to >>> IPV4-IPV6 interworking. >>> >>> The articles I have read say that you need to assign an address from each >>> address family to rtpproxy. They go on to say that rtpproxy will then be >>> in >>> bridged mode. Others define bridge mode as assigning two interfaces to >>> rtpproxy. >> As long as you have RTPProxy listening on two IPs, you have it set in >> bridge mode. It doesn't matther whether one of them is IPv6, or both are. >> >>> If the IPV4 and IPV6 addresses are on the same interface, is the rtpproxy >>> indeed in bridged mode? Should one avoid the use of engage_rtpproxy? >> Yes, as stated above, RTPProxy is in bridged mode and you should avoid >> using engage_rtpproxy(). That's because the function can't know/decide >> which interface is which and cannot map with the RTPProxy's one. >> >>> Assuming that IPV4- IPV6 interworking is actually possible using opensips >>> and rtpproxy, does that mean that an instance of rtpproxy is not >>> available to enable NAT traversal - would NAT traversal require using >>> another instance of rtpproxy using a single IPV4 address? >> No, you don't need an extra instance - a single instance will do both >> bridging and nat traversal. >> >>> Furthermore is the multihome parameter relevant to IPV4-IPV6 interworking >>> if opensips only listens on one interface? >> The multihome parameter is only relevant for OpenSIPS, it doesn't >> influence RTPProxy's behavior at all. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From razvan at opensips.org Wed Nov 9 11:29:00 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 9 Nov 2016 12:29:00 +0200 Subject: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? In-Reply-To: References: Message-ID: <68cb5e9d-0bf0-08f1-9b92-d31cb5f0aa91@opensips.org> Hi, Rodrigo! The only HACK that I can think of is when you get the BYE message, set the dialog timeout to 0, match it against the dialog, and then drop the message. OpenSIPS will behave as if the dialog expired in that moment. However, you seem to have a flow logic - most likely the Contact header in the BYE is not correct. Could you send us a trace to help you figure out what the problem is? Also, did you try to validate the message against the dialog[1] and fix it accordingly[2]? [1] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295894 [2] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295982 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 10:07 PM, Rodrigo Pimenta Carvalho wrote: > > Hi. > > > Dialogs in my OpenSIPS is programmed to finish after 60 seconds. > (timeout = 1 minute). > > So, when 2 peers are in a dialog, OpenSIPS sends SIP BYE to both > peers, automatically after 60 seconds. > > > Is it possible to make OpenSIPS send this exact kind of SIP BYE to > both peers, before the dialog timeout? I mean, in a configured way > (opensips.cfg)? > > > When OpenSISP sends SIP BYE automatically, both peers receive the SIP > BYE correctly. > > However, when a peer sends SIP BYE, it reaches the OpenSIPS, but > OpenSIPS is unable to forward this SIP BYE. Due to some unknown > reason, in this moment there is no open socket to communicate with > such peer. That is why I would like to make OpenSIPS send 'its own' > SIP BYE, and see if such idea will simulate a normal situation, until > I discover why there is a socket problem. > > > Any hint will be very helpful! > > > Best regards. > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > 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: From alain.bieuzent at free.fr Wed Nov 9 16:06:47 2016 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 09 Nov 2016 16:06:47 +0100 Subject: [OpenSIPS-Users] Migrating form 1.11.5 to 1.11.9 Message-ID: <4A6A16DE-D0C3-4D0B-B7EE-24E04CBFA51B@free.fr> Hi All, I?m trying to migrate form 1.11.5 to 1.11.9 and i have a problem to test the value of a mysql query when the reseult is null. In 1.11.5 this test ? if (!$avp(redirect) == NULL) ? works, but doesn?t work in 1.11.9. Is there a change in code ? What is the corect way to test a null value from avp ? Regards Alain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Nov 9 16:38:17 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 9 Nov 2016 17:38:17 +0200 Subject: [OpenSIPS-Users] Migrating form 1.11.5 to 1.11.9 In-Reply-To: <4A6A16DE-D0C3-4D0B-B7EE-24E04CBFA51B@free.fr> References: <4A6A16DE-D0C3-4D0B-B7EE-24E04CBFA51B@free.fr> Message-ID: <38eb7d66-39f9-0a41-f4ef-3aed77f9d9bd@opensips.org> Hi Alain, yes, it was a fix in avp_db_query() - if you query for multiple columns in a row, and if one of these columns returns NULL, it will not be reported as empty AVP , but as an AVP holding "" value : https://github.com/OpenSIPS/opensips/commit/e1257269bcc30df56dd9b6bc90a243c5839d5922 Is was a must to properly handle multi row results with multiple columns. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.11.2016 17:06, Alain Bieuzent wrote: > > Hi All, > > I?m trying to migrate form 1.11.5 to 1.11.9 and i have a problem to > test the value of a mysql query when the reseult is null. > > In 1.11.5 this test ? if (!$avp(redirect) == NULL) ? works, but > doesn?t work in 1.11.9. > > Is there a change in code ? > > What is the corect way to test a null value from avp ? > > Regards > > Alain. > > > > _______________________________________________ > 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: From razvan at opensips.org Wed Nov 9 16:39:20 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 9 Nov 2016 17:39:20 +0200 Subject: [OpenSIPS-Users] Migrating form 1.11.5 to 1.11.9 In-Reply-To: <4A6A16DE-D0C3-4D0B-B7EE-24E04CBFA51B@free.fr> References: <4A6A16DE-D0C3-4D0B-B7EE-24E04CBFA51B@free.fr> Message-ID: Hi, Alain! Somewhere between 1.11.5 and 1.11.9 we figured out a problem related to mysql queries: if your database entry is NULL, we can't just simply set a NULL value to an AVP, because that just deletes the previous value. So you end up in a very inconsistent state. That's why we decided to set the value "" to all the fields that are NULL in the database (this token is used in serveral other scenarios, that's why we picked this name). Therefore, in order to properly test if a column is provisioned NULL in the database is: if ($avp(redirect) != "") { } Let us know how this goes. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/09/2016 05:06 PM, Alain Bieuzent wrote: > > Hi All, > > I?m trying to migrate form 1.11.5 to 1.11.9 and i have a problem to > test the value of a mysql query when the reseult is null. > > In 1.11.5 this test ? if (!$avp(redirect) == NULL) ? works, but > doesn?t work in 1.11.9. > > Is there a change in code ? > > What is the corect way to test a null value from avp ? > > Regards > > Alain. > > > > _______________________________________________ > 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: From bogdan at opensips.org Wed Nov 9 16:40:40 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 9 Nov 2016 17:40:40 +0200 Subject: [OpenSIPS-Users] Pickup group help In-Reply-To: References: Message-ID: <140b9421-ecea-5d8a-daf0-5e520f83dbe4@opensips.org> Hi, You mean parallel calling groups, where a call to the group is sent to all the parties of the group (simultaneous ringing) and first to answer will pick up the call ? if so , this is parallel forking. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 08.11.2016 16:02, Schneur Rosenberg wrote: > Can someone please guide me how I should build pickup groups feature > in OpenSIPS? > > thank you > S. Rosenberg > > > _______________________________________________ > 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: From alain.bieuzent at free.fr Wed Nov 9 16:46:55 2016 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 09 Nov 2016 16:46:55 +0100 Subject: [OpenSIPS-Users] Migrating form 1.11.5 to 1.11.9 In-Reply-To: References: <4A6A16DE-D0C3-4D0B-B7EE-24E04CBFA51B@free.fr> Message-ID: Hi R?zvan, I will test that, many thanks Regards De : au nom de R?zvan Crainea R?pondre ? : OpenSIPS users mailling list Date : mercredi 9 novembre 2016 ? 16:39 ? : Objet : Re: [OpenSIPS-Users] Migrating form 1.11.5 to 1.11.9 Hi, Alain! Somewhere between 1.11.5 and 1.11.9 we figured out a problem related to mysql queries: if your database entry is NULL, we can't just simply set a NULL value to an AVP, because that just deletes the previous value. So you end up in a very inconsistent state. That's why we decided to set the value "" to all the fields that are NULL in the database (this token is used in serveral other scenarios, that's why we picked this name). Therefore, in order to properly test if a column is provisioned NULL in the database is: if ($avp(redirect) != "") { } Let us know how this goes. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/09/2016 05:06 PM, Alain Bieuzent wrote: Hi All, I?m trying to migrate form 1.11.5 to 1.11.9 and i have a problem to test the value of a mysql query when the reseult is null. In 1.11.5 this test ? if (!$avp(redirect) == NULL) ? works, but doesn?t work in 1.11.9. Is there a change in code ? What is the corect way to test a null value from avp ? Regards Alain. _______________________________________________ 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: From mbgatherer at gmail.com Wed Nov 9 17:41:06 2016 From: mbgatherer at gmail.com (Maciej Bylica) Date: Wed, 9 Nov 2016 17:41:06 +0100 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue Message-ID: Hello I am struggling with memcached installation with the latest git opensips 2.2.2 and centos 6.8 Here are version releases i am using: libmemcached-1.0.18 (./configure, make && make install) memcached-1.4.33 (./configure, make && make install) with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 does not produce any error but what is really puzzling me during the opensips start is the error below: DBG:core:load_module: loading module /usr/local/lib64/opensips/modules/cachedb_memcached.so ERROR:core:sr_load_module: could not open module : /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once Can someone please guide me how to put memcached up and running ? Opensips is compiled with cachedb_memcached module. Thanks in advance. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From pimenta at inatel.br Wed Nov 9 18:34:39 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Wed, 9 Nov 2016 17:34:39 +0000 Subject: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? In-Reply-To: <68cb5e9d-0bf0-08f1-9b92-d31cb5f0aa91@opensips.org> References: , <68cb5e9d-0bf0-08f1-9b92-d31cb5f0aa91@opensips.org> Message-ID: Hi. R?zvan. Thanks to your support, I have found the issue, after some weeks of tests! Now I need to discover how to fix it or a workaround. The problem is: Peer A and peer B is connected to the OpenSIPS (OpenSIPS is behind a NAT with public IP = 111.111.240.71). A is in the same hardware as OpenSIPs and B is in another machine. So, OpenSIPs has: Connection A :: ID=1 Type=tcp State=0 Source=127.0.0.1:32908 Destination=127.0.0.1:5060 Lifetime=1970-01-02 05:26:31 Connection B :: ID=2 Type=tcp State=0 Source=111.111.240.71:55229 Destination=192.168.0.101:5060 Lifetime=1970-01-02 05:29:50 When A calls B, the 'contact' in SIP INVITE has Source=127.0.0.1:3290. When B answers with SIP OK, A sends a SIP UPDATE. This UPDATE has a 'contact' with a new value: Source=111.111.240.71:57186. So, OpenSIPS has: Connection A':: ID=1 Type=tcp State=0 Source=127.0.0.1:32908 Destination=127.0.0.1:5060 Lifetime=1970-01-02 05:33:43 Connection B:: ID=2 Type=tcp State=0 Source=111.111.240.71:55229 Destination=192.168.0.101:5060 Lifetime=1970-01-02 05:29:51 Connection A":: ID=3 Type=tcp State=0 Source=111.111.240.71:57186 Destination=192.168.0.101:5060 Lifetime=1970-01-02 05:29:51 (new socket to A) However, the new socket between A and OpenSIPS expires in 30 seconds. Then, when B sends SIP BYE, OpenSIPS tries to forward such SIP message to Source=111.111.240.71:57186, which is expired. Peer A and B use ICE. I would like to fix this issue by means of the OpenSIPS script, to avoid changing the client's code. Could you suggest me some idea? Any hint will be very helpful! Best regards. P.S.: I'm using validate_dialog, but not fix_route_dialog() yet. Could this las function be the solution? RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: users-bounces at lists.opensips.org em nome de R?zvan Crainea Enviado: quarta-feira, 9 de novembro de 2016 08:29 Para: users at lists.opensips.org Assunto: Re: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? Hi, Rodrigo! The only HACK that I can think of is when you get the BYE message, set the dialog timeout to 0, match it against the dialog, and then drop the message. OpenSIPS will behave as if the dialog expired in that moment. However, you seem to have a flow logic - most likely the Contact header in the BYE is not correct. Could you send us a trace to help you figure out what the problem is? Also, did you try to validate the message against the dialog[1] and fix it accordingly[2]? [1] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295894 [2] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295982 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 11/08/2016 10:07 PM, Rodrigo Pimenta Carvalho wrote: Hi. Dialogs in my OpenSIPS is programmed to finish after 60 seconds. (timeout = 1 minute). So, when 2 peers are in a dialog, OpenSIPS sends SIP BYE to both peers, automatically after 60 seconds. Is it possible to make OpenSIPS send this exact kind of SIP BYE to both peers, before the dialog timeout? I mean, in a configured way (opensips.cfg)? When OpenSISP sends SIP BYE automatically, both peers receive the SIP BYE correctly. However, when a peer sends SIP BYE, it reaches the OpenSIPS, but OpenSIPS is unable to forward this SIP BYE. Due to some unknown reason, in this moment there is no open socket to communicate with such peer. That is why I would like to make OpenSIPS send 'its own' SIP BYE, and see if such idea will simulate a normal situation, until I discover why there is a socket problem. Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 _______________________________________________ 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: From razvan at opensips.org Wed Nov 9 18:37:40 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 9 Nov 2016 19:37:40 +0200 Subject: [OpenSIPS-Users] Rtpproxy and IPV4 IPV6 interworking In-Reply-To: <2566829.ExfhvV83KV@blacky.mylan> References: <1779817.2kyhvzfVrv@blacky.mylan> <2780361.W64aQsUSPm@blacky.mylan> <2566829.ExfhvV83KV@blacky.mylan> Message-ID: Hi, Robert! Yes, in cases where you don't need IPv6, use II for those requests. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/09/2016 07:12 PM, Robert Dyck wrote: > I should have described the scenario in more detail. > > The rtproxy is in bridge mode because two addresses were specified. This was to > accommodate IPV4 - IPV6 interworking. However the rtpproxy is also to be used > for NAT traversal. This is not a bridge in the physical sense because there > only one interface. For NAT traversal the IPV6 address should be ignored. Am I > correct in thinking that one should use either II flags or EE flags depending on > the order of the addresses given to rtpproxy? > > Thank you for taking the time for this. > > On November 9, 2016 12:23:09 PM you wrote: >> Hi, Robert! >> >> Yes, the I and E parameters are mandatory, and they should describe how >> the RTP will flow. For example if the flow is from IPv4 to IPv6, you >> should use EI; if the flow is from IPv4 to IPv6, then you should use IE. >> And so on, depending on the call flow. >> >> Regarding the address parameter, that is used when you want to overwrite >> the address indicated by RTPProxy. This is used mainly for setups where >> RTPProxy is behind NAT and the address inidcated is the private one. You >> should swap this IP with the public advertised one. >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 11/08/2016 09:51 PM, Robert Dyck wrote: >>> Thank you >>> >>> Assuming rtpproxy was started with IPV4 as the first address and IPV6 as >>> the second, then in the NAT scenario, are the II flags mandatory in >>> offer/answer? >>> >>> Slightly off topic, what sort of scenario would require the address >>> parameter for offer/answer? >>> >>> On November 8, 2016 09:57:30 AM R?zvan Crainea wrote: >>>> Hi, Robert! >>>> >>>> See my answers inline. >>>> >>>> Best regards, >>>> >>>> R?zvan Crainea >>>> OpenSIPS Solutions >>>> www.opensips-solutions.com >>>> >>>> On 11/08/2016 02:15 AM, Robert Dyck wrote: >>>>> I have some question regarding rtpproxy capabilities in relation to >>>>> IPV4-IPV6 interworking. >>>>> >>>>> The articles I have read say that you need to assign an address from >>>>> each >>>>> address family to rtpproxy. They go on to say that rtpproxy will then be >>>>> in >>>>> bridged mode. Others define bridge mode as assigning two interfaces to >>>>> rtpproxy. >>>> As long as you have RTPProxy listening on two IPs, you have it set in >>>> bridge mode. It doesn't matther whether one of them is IPv6, or both are. >>>> >>>>> If the IPV4 and IPV6 addresses are on the same interface, is the >>>>> rtpproxy >>>>> indeed in bridged mode? Should one avoid the use of engage_rtpproxy? >>>> Yes, as stated above, RTPProxy is in bridged mode and you should avoid >>>> using engage_rtpproxy(). That's because the function can't know/decide >>>> which interface is which and cannot map with the RTPProxy's one. >>>> >>>>> Assuming that IPV4- IPV6 interworking is actually possible using >>>>> opensips >>>>> and rtpproxy, does that mean that an instance of rtpproxy is not >>>>> available to enable NAT traversal - would NAT traversal require using >>>>> another instance of rtpproxy using a single IPV4 address? >>>> No, you don't need an extra instance - a single instance will do both >>>> bridging and nat traversal. >>>> >>>>> Furthermore is the multihome parameter relevant to IPV4-IPV6 >>>>> interworking >>>>> if opensips only listens on one interface? >>>> The multihome parameter is only relevant for OpenSIPS, it doesn't >>>> influence RTPProxy's behavior at all. >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From hunterj91 at hotmail.com Tue Nov 8 11:01:24 2016 From: hunterj91 at hotmail.com (Jonathan Hunter) Date: Tue, 8 Nov 2016 10:01:24 +0000 Subject: [OpenSIPS-Users] opensips 2.1 call_center queue position In-Reply-To: <63f2329e-066b-ed10-5629-dd8fbe075758@opensips.org> References: <71eb5aca-98bb-9b55-5bce-764d1e9e08d4@opensips.org> <96c0390f-2502-2b99-d4a9-a9133ee2b44d@opensips.org> <5d601c3e-ac5b-b6d1-fc0a-7959f1f0e4a0@opensips.org> <698e1be4-ce83-9782-5286-e8154bccd0b8@opensips.org> , <63f2329e-066b-ed10-5629-dd8fbe075758@opensips.org> Message-ID: Hi Bogdan, Yes I will test with a real queue and let you know, hopefully I will have a test scenario up and running this week. In terms of your questions; For 1) For my needs I think I only require it for the MOH/queue announcement, however if its simple to add, I can test it out for sure, I think the more information available the better, certainly when looking to replace older systems such as a cisco which provide quite alot of information to the caller. And for 2), adding ETW would be useful for sure, as the more information options available the better when looking to implement a queue system like this for me. I will keep you posted with the testing. Thanks again for the patch! Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 07 November 2016 20:41 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, I was not able to test it with a real queue, so let me know if it really does the job (in terms of reporting the real position in the queue). Some questions: 1) currently I add that value only when sending to the queue / MOH - do you foresee any need to be added for other announcements like for welcome ? 2) will it be useful to add the ETW (estimate time to wait) ? is it useful ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 07.11.2016 22:35, Jonathan Hunter wrote: Hi Bogdan, Hope you are well. Yes that patch works, it stops the crash, and adds the parameter; Request-Line: INVITE sip:7777 at 1.2.3.4:5080;cc_pos=0 SIP/2.0 Which is great! I will now get to work on the solution, thanks again. Jon From: Bogdan-Andrei Iancu Sent: 07 November 2016 15:15 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Please revert the prev patch and try this new one - hopefully it will fix the crash. Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 06.11.2016 18:50, Jonathan Hunter wrote: Hi Bogdan, Sorry for the delay. I installed directly via make install, not via packages. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 03 November 2016 10:39 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Have you installed OpenSIPS via packages ? or directly via "make install" ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 02.11.2016 11:33, Jonathan Hunter wrote: Hi Bogdan, I am getting the core dumps, but containing no symbol tables, so I presume I need to recompile with debug flags enabled? Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004ed7fb in ?? () "/core.24882" is a core file. Please specify an executable to debug. (gdb) bt full #0 0x00000000004ed7fb in ?? () No symbol table info available. #1 0x00007f6af7604468 in ?? () No symbol table info available. #2 0x000000000000001a in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. I installed 2.1 from sources, so whats the best way to do this? thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 02 November 2016 08:09 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position For sure it is a patch issue. if you have a backtrace, it will useful. Thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 02.11.2016 09:56, Jonathan Hunter wrote: Hi Bogdan, Thanks very much for this. I have just applied patch (installed from sources so when to call_center module directory and ran patch < call_center_pos.patch) then did a recompile. However when I now route to the call center (cc_handle_call) it generates a core and kills opensips; !!!!user 2000 has Callqueue set so send to Call Queue Route Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: NOTICE:core:io_wait_loop_epoll: EPOLLIN(read) event: epollwait() set event EPOLLHUP - connection closed by the remote peer! Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21141]: CRITICAL:core:receive_fd: EOF on 19 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: child process 21119 exited by a signal 11 Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: core was generated Nov 2 07:53:42 HPBXProxy1-beta /sbin/opensips[21112]: INFO:core:handle_sigs: terminating due to SIGCHLD Do you need me to backtrace/debug through to get the issue? Or is problem how I applied patch? Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 01 November 2016 21:44 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, Please give it a try to this patch - it is not really tested, but when the call is sent the Queue announcement, it should have a ";cc_pos=xxx" parameter giving the position is the queue (0 being the first to be dispatched to agents). Let me know if it works. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 28.10.2016 15:59, Jonathan Hunter wrote: Hi Bogdan, Great news, really do appreciate that. Many thanks Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 28 October 2016 12:48 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, it is no yet available. Give me couple of days and I will make a patch for it. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 25.10.2016 19:22, Jonathan Hunter wrote: Hi Bogdan, Sorry cant recall If I replied to this. Is cc_pos available now to extract from the module? Thats the only thing I need then I can implement call center which I think will be much more scale-able than the other approach I am using with FreeSWITCH, I would use that just for announcements. Any response/help appreciated. Jon ________________________________ From: Bogdan-Andrei Iancu Sent: 13 October 2016 10:59 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position Hi Jonathan, No, currently this is not possible. I was trying to envision a solution for your need. But, checking the code, it is really difficult to add the headers to the INVITEs originated by OpenSIPS (via the B2BUA), as we need some flexibility (different headers to different INVITEs belonging to the same B2B scenario , and even more, we need to traverse couple of internal APIs - to propagate the hdrs from Call center module all the way to TM). So, a simpler approach may be to add such extra info as URI params to the RURI. Like if you have the RURI "sip:queue at 192.168.1.10:5060" for the queue/waiting playback, the RURI in the INVITE to the media server will look like : sip:queue at 192.168.1.10:5060;cc_eta=40;cc_pos=10 - cc_eta being the estimated time to wait in seconds and cc_pos the position in the queue. What do you think of this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 17:21, Jonathan Hunter wrote: Hi Bogdan, Yes being able to grab the queue position would be perfect. Is that possible? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: hunterj91 at hotmail.com; users at lists.opensips.org From: bogdan at opensips.org Date: Wed, 12 Oct 2016 15:42:43 +0300 Hi Jonathan, When a call is mapped to a flow / queue (before playing the welcome message), we know the ETA (estimated time to wait) and when is placed in the queue (before playing the queuing) we internally know the position in the queue. Would it help to have the position in the queue placed into a custome SIP header, when sending the INVITE to the message_queue URL ? or to the welcome message ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 12.10.2016 12:06, Jonathan Hunter wrote: Hello Bogdan, Thanks for the response. In terms of my question, with a number of queuing platforms, they have the capability to tell the caller, what position they are in , and when they are likely to be answered. I just wondered if this logic was already within the module, or if I would need to use an external code/script to facilitate this function? As I presume call_center tracks the number of calls currently in a queue ? I would then want to be able to extract that information, and if a caller was for example in 3rd place in a queue, I could inject the relevant audio from freeswitch to tell them their current position? Does that make sense? :) Just wanted to know if its something this module can do? Thanks Jon ________________________________ Subject: Re: [OpenSIPS-Users] opensips 2.1 call_center queue position To: users at lists.opensips.org; hunterj91 at hotmail.com From: bogdan at opensips.org Date: Wed, 12 Oct 2016 11:23:45 +0300 Hello Jon, The message_queue is a SIP URI pointing to an audio announcement to play to roll of the waiting/in-queue playback. This needs to be an announcements that never ends (from the perspective of the media server); only the the OpenSIPS Queue may terminate the playback, when it decides to take out the call from waiting and to deliver it to an agent. As for your question, I'm not sure I understand what you mean by "inject a message with queue position for the caller in question" - could you detail please ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11.10.2016 13:36, Jonathan Hunter wrote: Hi guys, I have implemented an opensips/freeswitch environment, and I wish to add call queues to it, and I like the look of call_center, so just checking this out in comparison to mod_callcenter in FS world. My main question is if using the call_center module if you can inject a message with queue position for the caller in question, as I cant see that in documentation, I only see message_queue which I assume could be used to report the callers position, but just wondered if anyone has done this and if they could give me some tips as to if possible? Many thanks Jon _______________________________________________ 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: From denis7979 at mail.ru Thu Nov 10 10:14:28 2016 From: denis7979 at mail.ru (=?utf-8?B?0JTQtdC90LjRgSDQn9GD0YLRj9GC0L4=?=) Date: Thu, 10 Nov 2016 12:14:28 +0300 Subject: [OpenSIPS-Users] Common points in B2B top hiding In-Reply-To: References: <1082603211.20161108164130@ptl.ru> <122556688.20161108171937@ptl.ru> Message-ID: <1431301661.20161110121428@ptl.ru> Hello, Razvan! Does "topology hiding" make full top hiding? For example, if callid will include SIP UA IP address, will "topology hiding" hide it? Thank you. mailto:denis7979 at mail.ru Hi, Denis! Take a look at the "a" flag used by the b2b_init_request()[1] function. This might help you achieve what you want. May I ask you why you are using the b2b topology hiding, and not the dedicated module for topology hiding[2]? It would be far more easier to use the latter one in most of the cases. [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 [2] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 04:19 PM, Denis wrote: Re: [OpenSIPS-Users] Common points in B2B top hiding Hello, Razvan! No, it is not quite what i am looking for. For example, before top hiding i make authentication procedure during which i got login. For some call processing logging i need to translate this login to some proxy instance. How can i do that? mailto:denis7979 at mail.ru Hi, Denis! You can copy headers from the initial request to the B2B one by using the custom headers[1]. [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id293556 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 03:41 PM, Denis wrote: Common points in B2B top hiding Hello! Sorry that it was, but are there any common points between received INVITE and new generated INVITE while using B2B top hiding? I need some points, gotten in local_route, which will uniquely identified the call and which i can use, for example, to add some headers (based on that points). Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From razvan at opensips.org Thu Nov 10 12:03:14 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 10 Nov 2016 13:03:14 +0200 Subject: [OpenSIPS-Users] Common points in B2B top hiding In-Reply-To: <1431301661.20161110121428@ptl.ru> References: <1082603211.20161108164130@ptl.ru> <122556688.20161108171937@ptl.ru> <1431301661.20161110121428@ptl.ru> Message-ID: Yes, it will, if you are using OpenSIPS 2.1 or 2.2 and pass the "C" flag to topology_hiding() function[1]. [1] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html#id293540 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/10/2016 11:14 AM, ????? ?????? wrote: > Re: [OpenSIPS-Users] Common points in B2B top hiding Hello, Razvan! > > Does "topology hiding" make full top hiding? For example, if callid > will include SIP UA IP address, will "topology hiding" hide it? > > Thank you. > > mailto:denis7979 at mail.ru > > > Hi, Denis! > > Take a look at the "a" flag used by the b2b_init_request()[1] > function. This might help you achieve what you want. > May I ask you why you are using the b2b topology hiding, and not the > dedicated module for topology hiding[2]? It would be far more easier > to use the latter one in most of the cases. > > [1] > http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 > [2] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/08/2016 04:19 PM, Denis wrote: > > Re: [OpenSIPS-Users] Common points in B2B top hiding Hello, Razvan! > > No, it is not quite what i am looking for. > > For example, before top hiding i make authentication procedure during > which i got login. > For some call processing logging i need to translate this login to > some proxy instance. > > How can i do that? > > mailto:denis7979 at mail.ru > > > Hi, Denis! > > You can copy headers from the initial request to the B2B one by using > the custom headers[1]. > > [1] > http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id293556 > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/08/2016 03:41 PM, Denis wrote: > > Common points in B2B top hiding Hello! > > Sorry that it was, but are there any common points between received > INVITE and new generated INVITE while using B2B top hiding? > > I need some points, gotten in local_route, which will uniquely > identified the call and which i can use, for example, to add some > headers (based on that points). > > Thank you for any help. > > > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: From denis7979 at mail.ru Thu Nov 10 12:45:43 2016 From: denis7979 at mail.ru (Denis) Date: Thu, 10 Nov 2016 14:45:43 +0300 Subject: [OpenSIPS-Users] Common points in B2B top hiding In-Reply-To: References: <1082603211.20161108164130@ptl.ru> <122556688.20161108171937@ptl.ru> <1431301661.20161110121428@ptl.ru> Message-ID: <794188392.20161110144543@ptl.ru> I missed that. Thank you very much. I will try "topology hiding". mailto:denis7979 at mail.ru Yes, it will, if you are using OpenSIPS 2.1 or 2.2 and pass the "C" flag to topology_hiding() function[1]. [1] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html#id293540 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/10/2016 11:14 AM, ????? ?????? wrote: Re: [OpenSIPS-Users] Common points in B2B top hiding Hello, Razvan! Does "topology hiding" make full top hiding? For example, if callid will include SIP UA IP address, will "topology hiding" hide it? Thank you. mailto:denis7979 at mail.ru Hi, Denis! Take a look at the "a" flag used by the b2b_init_request()[1] function. This might help you achieve what you want. May I ask you why you are using the b2b topology hiding, and not the dedicated module for topology hiding[2]? It would be far more easier to use the latter one in most of the cases. [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 [2] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 04:19 PM, Denis wrote: Re: [OpenSIPS-Users] Common points in B2B top hiding Hello, Razvan! No, it is not quite what i am looking for. For example, before top hiding i make authentication procedure during which i got login. For some call processing logging i need to translate this login to some proxy instance. How can i do that? mailto:denis7979 at mail.ru Hi, Denis! You can copy headers from the initial request to the B2B one by using the custom headers[1]. [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id293556 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/08/2016 03:41 PM, Denis wrote: Common points in B2B top hiding Hello! Sorry that it was, but are there any common points between received INVITE and new generated INVITE while using B2B top hiding? I need some points, gotten in local_route, which will uniquely identified the call and which i can use, for example, to add some headers (based on that points). Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From bogdan at opensips.org Thu Nov 10 12:56:42 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 10 Nov 2016 13:56:42 +0200 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: References: Message-ID: Hi Maciej, As I see, you are manually compiling and installing the memcached stuff - any special reason for doing that ? (versus using packages) As the problem seems to be in the lib, not in the OpenSIPS module. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.11.2016 18:41, Maciej Bylica wrote: > Hello > > I am struggling with memcached installation with the latest git > opensips 2.2.2 and centos 6.8 > Here are version releases i am using: > libmemcached-1.0.18 (./configure, make && make install) > memcached-1.4.33 (./configure, make && make install) > with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH > > memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 > does not produce any error > > but what is really puzzling me during the opensips start is the error > below: > DBG:core:load_module: loading module > /usr/local/lib64/opensips/modules/cachedb_memcached.so > ERROR:core:sr_load_module: could not open module > : > /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once > > Can someone please guide me how to put memcached up and running ? > Opensips is compiled with cachedb_memcached module. > > Thanks in advance. > Maciej > > > _______________________________________________ > 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: From denis7979 at mail.ru Thu Nov 10 13:27:25 2016 From: denis7979 at mail.ru (Denis) Date: Thu, 10 Nov 2016 15:27:25 +0300 Subject: [OpenSIPS-Users] Fraud_detection module Message-ID: <1526240772.20161110152725@ptl.ru> Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? 2) At the beginning of the next period, a counts of events begin 0? 3) is there any method to reset counts of events for certain user? Thank you. mailto:denis7979 at mail.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Thu Nov 10 14:18:07 2016 From: denis7979 at mail.ru (Denis) Date: Thu, 10 Nov 2016 16:18:07 +0300 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <1526240772.20161110152725@ptl.ru> References: <1526240772.20161110152725@ptl.ru> Message-ID: <714079455.20161110161807@ptl.ru> In additional. My script logging says, that if critical event has been triggered email should be sent to some email. I received email where Opensips told me that "call_duration" critical event has been triggered with 1314 value for some user. The Profile has a value of 60. In documentation http://www.opensips.org/Documentation/Tutorials-FraudDetection-2-1 i read, that call duration calculated in minutes. I checked accounting table to find that calls of duration 1314 minutes, and see only one calls with duration 1314. But documentation, dealing with acc modules, tells, that duration calculated in seconds. So, what is the value used to calculate duration in fraud_module, minutes or seconds? mailto:denis7979 at mail.ru Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? 2) At the beginning of the next period, a counts of events begin 0? 3) is there any method to reset counts of events for certain user? Thank you. mailto:denis7979 at mail.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Nov 10 14:50:26 2016 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 10 Nov 2016 15:50:26 +0200 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <714079455.20161110161807@ptl.ru> References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> Message-ID: Hi, Deniz! Answers below. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 15:18, Denis wrote: > Re: Fraud_detection modul > > Hello! > > Opensips 2.2.1 > > A couple of questions about fraud_detection: > > 1) In documentation says "*consecutive calls* to the same destination > ". Same destination = same number, or prefix? > Same prefix, taken from the fraud detection rule > 2) At the beginning of the next period, a counts of events begin 0? > The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. > 3) is there any method to reset counts of events for certain user? > Currently there is no way of doing this. > 4) what is the value used to calculate duration in fraud_module, > minutes or seconds? > It should be "seconds", I will fix the misleading example in the tutorial. > ______________________________________________ > 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: From denis7979 at mail.ru Thu Nov 10 15:29:27 2016 From: denis7979 at mail.ru (Denis) Date: Thu, 10 Nov 2016 17:29:27 +0300 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <109788976.20161110172831@ptl.ru> References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> Message-ID: <136401369.20161110172927@ptl.ru> Hello, Liviu! Thank you for your answer. About 2) "Calls per minute" - ok, but what about other parameters? For example, "total calls"? Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. If in Mon user makes 25 calls, on Tue since 09:00 counts of "total calls" begin from 0 or 25? mailto:denis7979 at mail.ru Hi, Deniz! Answers below. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 15:18, Denis wrote: Re: Fraud_detection modul Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? Same prefix, taken from the fraud detection rule 2) At the beginning of the next period, a counts of events begin 0? The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. 3) is there any method to reset counts of events for certain user? Currently there is no way of doing this. 4) what is the value used to calculate duration in fraud_module, minutes or seconds? It should be "seconds", I will fix the misleading example in the tutorial. ______________________________________________ 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: From liviu at opensips.org Thu Nov 10 15:53:31 2016 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 10 Nov 2016 16:53:31 +0200 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <136401369.20161110172927@ptl.ru> References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> <136401369.20161110172927@ptl.ru> Message-ID: Upon looking through the source code, it seems that calls_per_min / total_calls / concurrent_calls are also reset to 0 every time a new rule is matched, or if the day has changed since we last matched the current rule. I will make sure this info ^ is more easily accessible: either in a new tutorial section or the module doc. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 16:29, Denis wrote: > Re: [OpenSIPS-Users] Fraud_detection module > > Hello, Liviu! > > Thank you for your answer. > > About 2) > > "Calls per minute" - ok, but what about other parameters? > For example, "total calls"? > Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. > If in Mon user makes 25 calls, on Tue since 09:00 counts of "total > calls" begin from 0 or 25? > > mailto:denis7979 at mail.ru > > > Hi, Deniz! > Answers below. > Regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 10.11.2016 15:18, Denis wrote: > > Re: Fraud_detection modul > > Hello! > > Opensips 2.2.1 > > A couple of questions about fraud_detection: > > 1) In documentation says "*consecutive calls* to the same destination > ". Same destination = same number, or prefix? > > Same prefix, taken from the fraud detection rule > > > 2) At the beginning of the next period, a counts of events begin 0? > > The module uses a gliding window of 60 seconds, in order to keep track > of "calls per minute". When changing time intervals, hence putting new > thresholds in place, the "calls per minute" will not reset. In other > words, when switching intervals, the new "calls per minute" thresholds > will initially work with calls placed during the last minute when the > old thresholds were in place. > > > 3) is there any method to reset counts of events for certain user? > > Currently there is no way of doing this. > > > > 4) what is the value used to calculate duration in fraud_module, > minutes or seconds? > > It should be "seconds", I will fix the misleading example in the > tutorial. > > ______________________________________________ > 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: From rosenberg11219 at gmail.com Thu Nov 10 19:09:17 2016 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Thu, 10 Nov 2016 20:09:17 +0200 Subject: [OpenSIPS-Users] Pickup group help In-Reply-To: <140b9421-ecea-5d8a-daf0-5e520f83dbe4@opensips.org> References: <140b9421-ecea-5d8a-daf0-5e520f83dbe4@opensips.org> Message-ID: No, I mean where a phone or group of phones ring, and you are at another extension that does not ring, you dial a code and grab the ringing extension. On Wed, Nov 9, 2016 at 5:40 PM, Bogdan-Andrei Iancu wrote: > Hi, > > You mean parallel calling groups, where a call to the group is sent to all > the parties of the group (simultaneous ringing) and first to answer will > pick up the call ? if so , this is parallel forking. > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 08.11.2016 16:02, Schneur Rosenberg wrote: > > Can someone please guide me how I should build pickup groups feature in > OpenSIPS? > > thank you > S. Rosenberg > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pimenta at inatel.br Thu Nov 10 20:59:22 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Thu, 10 Nov 2016 19:59:22 +0000 Subject: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? In-Reply-To: <68cb5e9d-0bf0-08f1-9b92-d31cb5f0aa91@opensips.org> References: , <68cb5e9d-0bf0-08f1-9b92-d31cb5f0aa91@opensips.org> Message-ID: Hi Razvan. I answered your questions yesterday. I'm not sure if you saw my message. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: users-bounces at lists.opensips.org em nome de Razvan Crainea Enviado: quarta-feira, 9 de novembro de 2016 08:29 Para: users at lists.opensips.org Assunto: Re: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? Hi, Rodrigo! The only HACK that I can think of is when you get the BYE message, set the dialog timeout to 0, match it against the dialog, and then drop the message. OpenSIPS will behave as if the dialog expired in that moment. However, you seem to have a flow logic - most likely the Contact header in the BYE is not correct. Could you send us a trace to help you figure out what the problem is? Also, did you try to validate the message against the dialog[1] and fix it accordingly[2]? [1] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295894 [2] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295982 Best regards, Razvan Crainea OpenSIPS Solutions www.opensips-solutions.com Home - OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 11/08/2016 10:07 PM, Rodrigo Pimenta Carvalho wrote: Hi. Dialogs in my OpenSIPS is programmed to finish after 60 seconds. (timeout = 1 minute). So, when 2 peers are in a dialog, OpenSIPS sends SIP BYE to both peers, automatically after 60 seconds. Is it possible to make OpenSIPS send this exact kind of SIP BYE to both peers, before the dialog timeout? I mean, in a configured way (opensips.cfg)? When OpenSISP sends SIP BYE automatically, both peers receive the SIP BYE correctly. However, when a peer sends SIP BYE, it reaches the OpenSIPS, but OpenSIPS is unable to forward this SIP BYE. Due to some unknown reason, in this moment there is no open socket to communicate with such peer. That is why I would like to make OpenSIPS send 'its own' SIP BYE, and see if such idea will simulate a normal situation, until I discover why there is a socket problem. Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 _______________________________________________ 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: From Agalya_Ramachandran at comcast.com Thu Nov 10 22:35:15 2016 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Thu, 10 Nov 2016 21:35:15 +0000 Subject: [OpenSIPS-Users] usage of setdsturi Message-ID: Hi team, I have a question in usage of setdsturi(). When I hardcode the uri in the function, such as setdsturi("sip:test at test.com:5060") - this works. But why I try to use script variable, it complains as bad_uri. $var(test) = "sip:"+$var(Fqdn)+ ":5060"; setdsturi("$var(test)"); How do I setdsturi() dynamically, with the value in script variable and not by hardcoding? Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at inin.com Thu Nov 10 22:58:53 2016 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Thu, 10 Nov 2016 21:58:53 +0000 Subject: [OpenSIPS-Users] usage of setdsturi Message-ID: <1B5505EA-045F-4856-A976-661B906AD1F1@inin.com> I would recommend just using $du. [1] $du = ?sip:? + $var(Fqdn) + ?:5060?; [1] http://www.opensips.org/Documentation/Script-CoreVar-2-2#toc35 Ben Newlin From: on behalf of "Ramachandran, Agalya (Contractor)" Reply-To: OpenSIPS users mailling list Date: Thursday, November 10, 2016 at 4:35 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] usage of setdsturi Hi team, I have a question in usage of setdsturi(). When I hardcode the uri in the function, such as setdsturi(?sip:test at test.com:5060?) ? this works. But why I try to use script variable, it complains as bad_uri. $var(test) = "sip:"+$var(Fqdn)+ ":5060"; setdsturi("$var(test)"); How do I setdsturi() dynamically, with the value in script variable and not by hardcoding? Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Fri Nov 11 08:46:40 2016 From: denis7979 at mail.ru (Denis) Date: Fri, 11 Nov 2016 10:46:40 +0300 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <216131351.20161111103855@ptl.ru> References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> <136401369.20161110172927@ptl.ru> <216131351.20161111103855@ptl.ru> Message-ID: <1010339564.20161111104640@ptl.ru> Liviu i forgot about the size of the massage. All attachment you can find here https://cloud.mail.ru/public/LGq2/EuAroXoFq mailto:denis7979 at mail.ru Hello, Liviu! OK, thank you. Additionally i will ask you to analyze one case. In attachment you can find a log of calls, which were made by one user some time ago (with the number 1234567). It`s a fraud. Also i attached a piece of opensips.cfg related to a fraud detection (see script.txt). When critical event triggered Opensips sends email to some address (see script.txt). As you can see in the call log, fraud began at 01:40 2016-10-01. Value of the field "sip_reason" "fraud_detected" means that fraud_module detects the fraud and a call was discarded by script logging (see script.txt) First email about that i received at 01:41 with fraud param " calls per minute". Next email i received only at 11:08 with fraud param "total calls". Between these two time stamps i have no emails about fraud, and as you can see from the call log, there were many successful calls in this period with "big" duration. Fraud_detection table had such content: profileid = 1 prefix = 810 start_hour = 00:00 end_hour = 23:59 daysoftheweek = Mon-Sun cpm_critical = 6 call_duration_critical = 3600 tatal_calls_critical = 30 concurant_calls_critical = 30 sequential_calls_critical = 5000 The questions is: - Why module didn`t detect fraud based on "call duration"? Thank you. mailto:denis7979 at mail.ru Upon looking through the source code, it seems that calls_per_min / total_calls / concurrent_calls are also reset to 0 every time a new rule is matched, or if the day has changed since we last matched the current rule. I will make sure this info ^ is more easily accessible: either in a new tutorial section or the module doc. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 16:29, Denis wrote: Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! Thank you for your answer. About 2) "Calls per minute" - ok, but what about other parameters? For example, "total calls"? Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. If in Mon user makes 25 calls, on Tue since 09:00 counts of "total calls" begin from 0 or 25? mailto:denis7979 at mail.ru Hi, Deniz! Answers below. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 15:18, Denis wrote: Re: Fraud_detection modul Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? Same prefix, taken from the fraud detection rule 2) At the beginning of the next period, a counts of events begin 0? The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. 3) is there any method to reset counts of events for certain user? Currently there is no way of doing this. 4) what is the value used to calculate duration in fraud_module, minutes or seconds? It should be "seconds", I will fix the misleading example in the tutorial. ______________________________________________ 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: From razvan at opensips.org Fri Nov 11 14:30:47 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 11 Nov 2016 15:30:47 +0200 Subject: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? In-Reply-To: References: <68cb5e9d-0bf0-08f1-9b92-d31cb5f0aa91@opensips.org> Message-ID: Hi, Rodrigo! Sorry, I've just seen the message, I've missed it earlier. As far as I understand, OpenSIPS is listening on two interfaces: 127.0.01:5060 and 192.168.0.101:5060. Is the UPDATE coming on the same TCP connection as the initial one? Or the client opens a new connection for it, over the PUBLIC interface? Could you send over (privately) a PCAP trace? Also, you'd probably need to make sure that you call fix_nated_contact() and force_rport() on the UPDATE request. Also, are you setting the tcp_accept_aliases[1] or force_tcp_alias()[2] in your script? [1] http://www.opensips.org/Documentation/Script-CoreParameters-2-2#toc95 [2] http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#force_tcp_alias Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/10/2016 09:59 PM, Rodrigo Pimenta Carvalho wrote: > > Hi Razvan. > > > I answered your questions yesterday. > > > I'm not sure if you saw my message. > > > Best regards. > > > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > ------------------------------------------------------------------------ > *De:* users-bounces at lists.opensips.org > em nome de R?zvan Crainea > > *Enviado:* quarta-feira, 9 de novembro de 2016 08:29 > *Para:* users at lists.opensips.org > *Assunto:* Re: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by > configuration, , before dialog timout? > Hi, Rodrigo! > > The only HACK that I can think of is when you get the BYE message, set > the dialog timeout to 0, match it against the dialog, and then drop > the message. OpenSIPS will behave as if the dialog expired in that moment. > > However, you seem to have a flow logic - most likely the Contact > header in the BYE is not correct. Could you send us a trace to help > you figure out what the problem is? Also, did you try to validate the > message against the dialog[1] and fix it accordingly[2]? > > [1] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295894 > [2] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295982 > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > Home ? OpenSIPS Solutions > www.opensips-solutions.com > OpenSIPS is a mature Open Source implementation of a SIP server. > OpenSIPS is more than a SIP proxy/router as it includes > application-level functionalities. > > On 11/08/2016 10:07 PM, Rodrigo Pimenta Carvalho wrote: >> >> Hi. >> >> >> Dialogs in my OpenSIPS is programmed to finish after 60 seconds. >> (timeout = 1 minute). >> >> So, when 2 peers are in a dialog, OpenSIPS sends SIP BYE to both >> peers, automatically after 60 seconds. >> >> >> Is it possible to make OpenSIPS send this exact kind of SIP BYE to >> both peers, before the dialog timeout? I mean, in a configured way >> (opensips.cfg)? >> >> >> When OpenSISP sends SIP BYE automatically, both peers receive the SIP >> BYE correctly. >> >> However, when a peer sends SIP BYE, it reaches the OpenSIPS, but >> OpenSIPS is unable to forward this SIP BYE. Due to some unknown >> reason, in this moment there is no open socket to communicate with >> such peer. That is why I would like to make OpenSIPS send 'its own' >> SIP BYE, and see if such idea will simulate a normal situation, until >> I discover why there is a socket problem. >> >> >> Any hint will be very helpful! >> >> >> Best regards. >> >> >> RODRIGO PIMENTA CARVALHO >> Inatel Competence Center >> Software >> Ph: +55 35 3471 9200 RAMAL 979 >> >> >> _______________________________________________ >> 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: From razvan at opensips.org Fri Nov 11 14:33:13 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 11 Nov 2016 15:33:13 +0200 Subject: [OpenSIPS-Users] usage of setdsturi In-Reply-To: <1B5505EA-045F-4856-A976-661B906AD1F1@inin.com> References: <1B5505EA-045F-4856-A976-661B906AD1F1@inin.com> Message-ID: Hi, Agalya! The setdsturi() function only accepts strings as parameters, not pseudo-variables[1]. As Ben suggested, the $du pseudo-variable is more flexible and recommended. [1] http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc49 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/10/2016 11:58 PM, Newlin, Ben wrote: > > I would recommend just using $du. [1] > > $du = ?sip:? + $var(Fqdn) + ?:5060?; > > [1] http://www.opensips.org/Documentation/Script-CoreVar-2-2#toc35 > > Ben Newlin > > *From: * on behalf of "Ramachandran, > Agalya (Contractor)" > *Reply-To: *OpenSIPS users mailling list > *Date: *Thursday, November 10, 2016 at 4:35 PM > *To: *OpenSIPS users mailling list > *Subject: *[OpenSIPS-Users] usage of setdsturi > > Hi team, > > I have a question in usage of setdsturi(). > > When I hardcode the uri in the function, such as > setdsturi(?sip:test at test.com:5060?) ? this works. > > But why I try to use script variable, it complains as bad_uri. > > $var(test) = "sip:"+$var(Fqdn)+ ":5060"; > > setdsturi("$var(test)"); > > How do I setdsturi() dynamically, with the value in script variable > and not by hardcoding? > > Regards, > Agalya > > > > _______________________________________________ > 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: From pimenta at inatel.br Fri Nov 11 16:49:52 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Fri, 11 Nov 2016 15:49:52 +0000 Subject: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? In-Reply-To: References: <68cb5e9d-0bf0-08f1-9b92-d31cb5f0aa91@opensips.org> , Message-ID: Hi Rasvan Crainea. Thank you very much for the reply! You gave me new points to be checked and understood. I will work for a while in such points and then I will give you a feedback. So, wait for my next post, please. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: users-bounces at lists.opensips.org em nome de R?zvan Crainea Enviado: sexta-feira, 11 de novembro de 2016 11:30 Para: users at lists.opensips.org Assunto: Re: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? Hi, Rodrigo! Sorry, I've just seen the message, I've missed it earlier. As far as I understand, OpenSIPS is listening on two interfaces: 127.0.01:5060 and 192.168.0.101:5060. Is the UPDATE coming on the same TCP connection as the initial one? Or the client opens a new connection for it, over the PUBLIC interface? Could you send over (privately) a PCAP trace? Also, you'd probably need to make sure that you call fix_nated_contact() and force_rport() on the UPDATE request. Also, are you setting the tcp_accept_aliases[1] or force_tcp_alias()[2] in your script? [1] http://www.opensips.org/Documentation/Script-CoreParameters-2-2#toc95 [2] http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#force_tcp_alias Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 11/10/2016 09:59 PM, Rodrigo Pimenta Carvalho wrote: Hi Razvan. I answered your questions yesterday. I'm not sure if you saw my message. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: users-bounces at lists.opensips.org em nome de R?zvan Crainea Enviado: quarta-feira, 9 de novembro de 2016 08:29 Para: users at lists.opensips.org Assunto: Re: [OpenSIPS-Users] How to make OpenSIPS send SIP BYE, by configuration, , before dialog timout? Hi, Rodrigo! The only HACK that I can think of is when you get the BYE message, set the dialog timeout to 0, match it against the dialog, and then drop the message. OpenSIPS will behave as if the dialog expired in that moment. However, you seem to have a flow logic - most likely the Contact header in the BYE is not correct. Could you send us a trace to help you figure out what the problem is? Also, did you try to validate the message against the dialog[1] and fix it accordingly[2]? [1] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295894 [2] http://www.opensips.org/html/docs/modules/2.2.x/dialog#id295982 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 11/08/2016 10:07 PM, Rodrigo Pimenta Carvalho wrote: Hi. Dialogs in my OpenSIPS is programmed to finish after 60 seconds. (timeout = 1 minute). So, when 2 peers are in a dialog, OpenSIPS sends SIP BYE to both peers, automatically after 60 seconds. Is it possible to make OpenSIPS send this exact kind of SIP BYE to both peers, before the dialog timeout? I mean, in a configured way (opensips.cfg)? When OpenSISP sends SIP BYE automatically, both peers receive the SIP BYE correctly. However, when a peer sends SIP BYE, it reaches the OpenSIPS, but OpenSIPS is unable to forward this SIP BYE. Due to some unknown reason, in this moment there is no open socket to communicate with such peer. That is why I would like to make OpenSIPS send 'its own' SIP BYE, and see if such idea will simulate a normal situation, until I discover why there is a socket problem. Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 _______________________________________________ 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: From govoiper at gmail.com Fri Nov 11 23:33:05 2016 From: govoiper at gmail.com (SamyGo) Date: Fri, 11 Nov 2016 17:33:05 -0500 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header Message-ID: Hi, I'm using OpenSIPS 2.2.1 version and I'm facing a weird situation where OpenSIPS is adding a duplicated VIA header to the 200 OK, This only happens when I've topology_hiding() engaged into the call. The scenario is very simple; two users making call to each other on the same OpenSIPS but with topology_hiding(). As a consequence of this double VIA the caller device doesn't trigger the ACK and hence we don't get media stream established between devices. *WITH TOPOLOGYHIDING:* SIP/2.0 200 OK Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch= z9hG4bK-607165482-63 Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch= z9hG4bK-607165482-63 CSeq: 1 INVITE ... *WITHOUT TOPOHIDING:* SIP/2.0 200 OK Via: SIP/2.0/TLS 10.1.10.51:59223;received=7X.XX.XX.X7;rport=59223;branch= z9hG4bK-607166212-58 CSeq: 1 INVITE The only difference between the two scenarios is the function topology_hiding(); is commented out. It seems like a bug to me, can anyone guide me here validate this. *OpenSIPS Version:* version: opensips 2.2.1 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. git revision: 68ace2e main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 Thanks, Sammy -------------- next part -------------- An HTML attachment was scrubbed... URL: From y at jettel.ru Sun Nov 13 19:55:14 2016 From: y at jettel.ru (Ehrny) Date: Sun, 13 Nov 2016 18:55:14 +0000 Subject: [OpenSIPS-Users] $ai transformation Message-ID: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> Hello team, I'm trying to follow my carrier's request to transform P-Asserted-Identity header. Is there any possibilities to do that on the fly with opensips (v2.2.2)? Yet another project assume to add the redirecting number even if it's not exists. Would it be possible to add it in the route? Your help is really appreciated, Best Regards, Ehrny -------------- next part -------------- An HTML attachment was scrubbed... URL: From acmicrox at gmail.com Mon Nov 14 03:23:03 2016 From: acmicrox at gmail.com (Chen-Che Huang) Date: Sun, 13 Nov 2016 19:23:03 -0700 (MST) Subject: [OpenSIPS-Users] No TLS-related files in OpenSIPS 1.11.9 src.tar.gz In-Reply-To: References: <1478509456538-7604883.post@n2.nabble.com> <0760d5ba-565d-b46c-06c9-6bb9572bbb1f@opensips.org> <99df1d60-5c6e-68f6-163d-5f1f7de3960b@opensips.org> <1478570513195-7604909.post@n2.nabble.com> Message-ID: <1479090183982-7604980.post@n2.nabble.com> Hi R?zvan, I visited http://opensips.org/pub/opensips/1.11.9/ and called wget http://opensips.org/pub/opensips/1.11.9/opensips-1.11.9-tls.tar.gz to download the archive with TLS files. Then, I removed the comment of #TLS=1 in the Makefile and started to generate deb files by ``sudo TLS=1 make deb''. During the process, it seemed that some problem occurred (shown below) and the generated deb files were not with the expected version 1.11.9. For instance, the main deb is opensips_1.11.8-1_amd64.deb rather than opensips_1.11.9-1_amd64.deb. If anything is not clear, please feel free to let me know. Thanks. Best regards, Chen-Che dh_clean make[1]: Leaving directory `/home/ubuntu/opensips-1.11.9/opensips-1.11.9-tls' dpkg-source -b opensips-1.11.9-tls dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1) dpkg-source: info: using source format `1.0' dpkg-source: warning: source directory 'opensips-1.11.9-tls' is not - 'opensips-1.11.8' dpkg-source: info: building opensips in opensips_1.11.8-1.tar.gz dpkg-source: info: building opensips in opensips_1.11.8-1.dsc debian/rules build make[1]: Entering directory `/home/ubuntu/opensips-1.11.9/opensips-1.11.9-tls' dh_testdir -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/No-TLS-related-files-in-OpenSIPS-1-11-9-src-tar-gz-tp7604883p7604980.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Mon Nov 14 09:02:37 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 14 Nov 2016 10:02:37 +0200 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> Message-ID: Hi, Ehrny! Yes, you can transform the P-Asserted-Identity header as you wish, by dropping the existing one and creating a new one. Use the remove_hf()[1] and append_hf()[2] headers for that, i.e.: if (is_present_hf("P-Asserted-Identity")) { remove_hf("P-Asserted-Identity"); $avp(rpid) = "new-header"; append_hf("P-Asserted-Identity: $avp(rpid) \r\n"); } [1] http://www.opensips.org/html/docs/modules/2.2.x/sipmsgops.html#id293937 [2] http://www.opensips.org/html/docs/modules/2.2.x/sipmsgops.html#id249696 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/13/2016 08:55 PM, Ehrny wrote: > > Hello team, > > I?m trying to follow my carrier?s request to transform > P-Asserted-Identity header. > > Is there any possibilities to do that on the fly with opensips (v2.2.2)? > > Yet another project assume to add the redirecting number even if it?s > not exists. Would it be possible to add it in the route? > > Your help is really appreciated, > > Best Regards, > > Ehrny > > > > _______________________________________________ > 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: From razvan at opensips.org Mon Nov 14 09:36:08 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 14 Nov 2016 10:36:08 +0200 Subject: [OpenSIPS-Users] No TLS-related files in OpenSIPS 1.11.9 src.tar.gz In-Reply-To: <1479090183982-7604980.post@n2.nabble.com> References: <1478509456538-7604883.post@n2.nabble.com> <0760d5ba-565d-b46c-06c9-6bb9572bbb1f@opensips.org> <99df1d60-5c6e-68f6-163d-5f1f7de3960b@opensips.org> <1478570513195-7604909.post@n2.nabble.com> <1479090183982-7604980.post@n2.nabble.com> Message-ID: <848d8ecf-8b99-7771-04fe-ee730fb8a544@opensips.org> Hi, Chen-Che! You are right; the building system has changed a bit and I forgot to update the version in the new files! I've done a fix on all affected branches. However, they will only be visible in the next release. Until then, you can apply this patch[1] on the current archive in order to generate debs with the proper version. Thanks for reporting this! [1] https://github.com/OpenSIPS/opensips/commit/bf7f401109312dc2a914350866545bb44b4a9f7b.patch Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/14/2016 04:23 AM, Chen-Che Huang wrote: > Hi R?zvan, > > I visited http://opensips.org/pub/opensips/1.11.9/ and called wget > http://opensips.org/pub/opensips/1.11.9/opensips-1.11.9-tls.tar.gz to > download the archive with TLS files. Then, I removed the comment of #TLS=1 > in the Makefile and started to generate deb files by ``sudo TLS=1 make > deb''. During the process, it seemed that some problem occurred (shown > below) and the generated deb files were not with the expected version > 1.11.9. For instance, the main deb is opensips_1.11.8-1_amd64.deb rather > than opensips_1.11.9-1_amd64.deb. If anything is not clear, please feel free > to let me know. Thanks. > > Best regards, > Chen-Che > > dh_clean > make[1]: Leaving directory > `/home/ubuntu/opensips-1.11.9/opensips-1.11.9-tls' > dpkg-source -b opensips-1.11.9-tls > dpkg-source: warning: no source format specified in debian/source/format, > see dpkg-source(1) > dpkg-source: info: using source format `1.0' > dpkg-source: warning: source directory 'opensips-1.11.9-tls' is not > - 'opensips-1.11.8' > dpkg-source: info: building opensips in opensips_1.11.8-1.tar.gz > dpkg-source: info: building opensips in opensips_1.11.8-1.dsc > debian/rules build > make[1]: Entering directory > `/home/ubuntu/opensips-1.11.9/opensips-1.11.9-tls' > dh_testdir > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/No-TLS-related-files-in-OpenSIPS-1-11-9-src-tar-gz-tp7604883p7604980.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From razvan at opensips.org Mon Nov 14 09:48:52 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 14 Nov 2016 10:48:52 +0200 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header In-Reply-To: References: Message-ID: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> Hi, Samy! Can you post on pastebin debugging logs related to this call? Also, can you also post the Via headers of the initial INVITE and for the 200 OK received by OpenSIPS? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/12/2016 12:33 AM, SamyGo wrote: > Hi, > > I'm using OpenSIPS 2.2.1 version and I'm facing a weird situation > where OpenSIPS is adding a duplicated VIA header to the 200 OK, This > only happens when I've topology_hiding() engaged into the call. > > The scenario is very simple; two users making call to each other on > the same OpenSIPS but with topology_hiding(). As a consequence of this > double VIA the caller device doesn't trigger the ACK and hence we > don't get media stream established between devices. > > > *WITH TOPOLOGYHIDING:* > SIP/2.0 200 OK > Via: SIP/2.0/TLS > 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 > Via: SIP/2.0/TLS > 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 > CSeq: 1 INVITE > ... > > *WITHOUT TOPOHIDING: > * > SIP/2.0 200 OK > Via: SIP/2.0/TLS > 10.1.10.51:59223;received=7X.XX.XX.X7;rport=59223;branch=z9hG4bK-607166212-58 > CSeq: 1 INVITE > > > The only difference between the two scenarios is the function > topology_hiding(); is commented out. > > It seems like a bug to me, can anyone guide me here validate this. > * > OpenSIPS Version:* > version: opensips 2.2.1 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > git revision: 68ace2e > main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 > > > Thanks, > Sammy > > > > > _______________________________________________ > 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: From liviu at opensips.org Mon Nov 14 10:34:58 2016 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 14 Nov 2016 11:34:58 +0200 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <216131351.20161111103855@ptl.ru> References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> <136401369.20161110172927@ptl.ru> <216131351.20161111103855@ptl.ru> Message-ID: <7e88434c-19fa-ed41-20da-ac38f1ca785b@opensips.org> Hi, Denis! First of all, thank you for taking the time to gather this nice data! Looking at the calls, to me it looks like the module behaved as expected. Here are some thoughts: - all call durations were less under 1500 seconds, while your fraud rule is set to 3600 seconds, so it never got triggered. - the "calls-per-minute" rule worked! Your rule was set to max 6 cpm, thus calls #7 - #9 to prefix "810" were considered fraudulent (at 01:41), as the caller was starting to exceed this quota. The proper critical warnings were raised, calls blocked, emails sent. - the attacker now _learned_ about your 6 cpm limitation and _lowered_ his cpm to 3 during the following 10 hours (until 11:08), thus bypassing the cpm rate limiting, managing to place 21 fraudulent calls. It seems like the 21 successful fraudulent calls between 03:06 - 11:08 could _maybe_ have been avoided by setting a better value for "sequential-calls". This is a bit tricky though, as we also don't want to block calls of honest users because of false positives. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 11.11.2016 09:38, Denis wrote: > Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! > > OK, thank you. > > Additionally i will ask you to analyze one case. > In attachment you can find a log of calls, which were made by one user > some time ago (with the number 1234567). It`s a fraud. > Also i attached a piece of opensips.cfg related to a fraud detection > (see script.txt). When critical event triggered Opensips sends email > to some address (see script.txt). > > As you can see in the call log, fraud began at 01:40 2016-10-01. Value > of the field "sip_reason" "fraud_detected" means that fraud_module > detects the fraud and a call was discarded by script logging (see > script.txt) > First email about that i received at 01:41 with fraud param " calls > per minute". > Next email i received only at 11:08 with fraud param "total calls". > > Between these two time stamps i have no emails about fraud, and as you > can see from the call log, there were many successful calls in this > period with "big" duration. > > Fraud_detection table had such content: > profileid = 1 > prefix = 810 > start_hour = 00:00 > end_hour = 23:59 > daysoftheweek = Mon-Sun > cpm_critical = 6 > call_duration_critical = 3600 > tatal_calls_critical = 30 > concurant_calls_critical = 30 > sequential_calls_critical = 5000 > > The questions is: > - Why module didn`t detect fraud based on "call duration"? > > Thank you. > > mailto:denis7979 at mail.ru > > > Upon looking through the source code, it seems that calls_per_min / > total_calls / concurrent_calls are also reset to 0 every time a new > rule is matched, or if the day has changed since we last matched the > current rule. > I will make sure this info ^ is more easily accessible: either in a > new tutorial section or the module doc. > Regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 10.11.2016 16:29, Denis wrote: > > Re: [OpenSIPS-Users] Fraud_detection module > > Hello, Liviu! > > Thank you for your answer. > > About 2) > > "Calls per minute" - ok, but what about other parameters? > For example, "total calls"? > Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. > If in Mon user makes 25 calls, on Tue since 09:00 counts of "total > calls" begin from 0 or 25? > > mailto:denis7979 at mail.ru > > > Hi, Deniz! > Answers below. > Regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 10.11.2016 15:18, Denis wrote: > > Re: Fraud_detection modul > > Hello! > > Opensips 2.2.1 > > A couple of questions about fraud_detection: > > 1) In documentation says "*consecutive calls* to the same destination > ". Same destination = same number, or prefix? > > Same prefix, taken from the fraud detection rule > > > 2) At the beginning of the next period, a counts of events begin 0? > > The module uses a gliding window of 60 seconds, in order to keep track > of "calls per minute". When changing time intervals, hence putting new > thresholds in place, the "calls per minute" will not reset. In other > words, when switching intervals, the new "calls per minute" thresholds > will initially work with calls placed during the last minute when the > old thresholds were in place. > > > 3) is there any method to reset counts of events for certain user? > > Currently there is no way of doing this. > > > > 4) what is the value used to calculate duration in fraud_module, > minutes or seconds? > > It should be "seconds", I will fix the misleading example in the > tutorial. > > ______________________________________________ > 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: From denis7979 at mail.ru Mon Nov 14 11:17:04 2016 From: denis7979 at mail.ru (Denis) Date: Mon, 14 Nov 2016 13:17:04 +0300 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <7e88434c-19fa-ed41-20da-ac38f1ca785b@opensips.org> References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> <136401369.20161110172927@ptl.ru> <216131351.20161111103855@ptl.ru> <7e88434c-19fa-ed41-20da-ac38f1ca785b@opensips.org> Message-ID: <72829925.20161114131704@ptl.ru> Hello, Liviu! Thank you very much for your answer! I understood my main mistake. I thought that "call duration" is the total value for all calls but not of only one. Ok, "sequential-calls" may be that thing which can help to avoid such situation, but the main problem is (and as you wrote in the previous letter), that this value doesn`t go to 0 at the next period. Because of this i have to increase this value to 5000, otherwise i blocked honest users. Can "sequential-calls" be set to 0 at the next period? mailto:denis7979 at mail.ru Hi, Denis! First of all, thank you for taking the time to gather this nice data! Looking at the calls, to me it looks like the module behaved as expected. Here are some thoughts: - all call durations were less under 1500 seconds, while your fraud rule is set to 3600 seconds, so it never got triggered. - the "calls-per-minute" rule worked! Your rule was set to max 6 cpm, thus calls #7 - #9 to prefix "810" were considered fraudulent (at 01:41), as the caller was starting to exceed this quota. The proper critical warnings were raised, calls blocked, emails sent. - the attacker now _learned_ about your 6 cpm limitation and _lowered_ his cpm to 3 during the following 10 hours (until 11:08), thus bypassing the cpm rate limiting, managing to place 21 fraudulent calls. It seems like the 21 successful fraudulent calls between 03:06 - 11:08 could _maybe_ have been avoided by setting a better value for "sequential-calls". This is a bit tricky though, as we also don't want to block calls of honest users because of false positives. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 11.11.2016 09:38, Denis wrote: Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! OK, thank you. Additionally i will ask you to analyze one case. In attachment you can find a log of calls, which were made by one user some time ago (with the number 1234567). It`s a fraud. Also i attached a piece of opensips.cfg related to a fraud detection (see script.txt). When critical event triggered Opensips sends email to some address (see script.txt). As you can see in the call log, fraud began at 01:40 2016-10-01. Value of the field "sip_reason" "fraud_detected" means that fraud_module detects the fraud and a call was discarded by script logging (see script.txt) First email about that i received at 01:41 with fraud param " calls per minute". Next email i received only at 11:08 with fraud param "total calls". Between these two time stamps i have no emails about fraud, and as you can see from the call log, there were many successful calls in this period with "big" duration. Fraud_detection table had such content: profileid = 1 prefix = 810 start_hour = 00:00 end_hour = 23:59 daysoftheweek = Mon-Sun cpm_critical = 6 call_duration_critical = 3600 tatal_calls_critical = 30 concurant_calls_critical = 30 sequential_calls_critical = 5000 The questions is: - Why module didn`t detect fraud based on "call duration"? Thank you. mailto:denis7979 at mail.ru Upon looking through the source code, it seems that calls_per_min / total_calls / concurrent_calls are also reset to 0 every time a new rule is matched, or if the day has changed since we last matched the current rule. I will make sure this info ^ is more easily accessible: either in a new tutorial section or the module doc. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 16:29, Denis wrote: Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! Thank you for your answer. About 2) "Calls per minute" - ok, but what about other parameters? For example, "total calls"? Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. If in Mon user makes 25 calls, on Tue since 09:00 counts of "total calls" begin from 0 or 25? mailto:denis7979 at mail.ru Hi, Deniz! Answers below. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 15:18, Denis wrote: Re: Fraud_detection modul Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? Same prefix, taken from the fraud detection rule 2) At the beginning of the next period, a counts of events begin 0? The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. 3) is there any method to reset counts of events for certain user? Currently there is no way of doing this. 4) what is the value used to calculate duration in fraud_module, minutes or seconds? It should be "seconds", I will fix the misleading example in the tutorial. ______________________________________________ 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: From bogdan at opensips.org Mon Nov 14 11:42:10 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 14 Nov 2016 12:42:10 +0200 Subject: [OpenSIPS-Users] Pickup group help In-Reply-To: References: <140b9421-ecea-5d8a-daf0-5e520f83dbe4@opensips.org> Message-ID: <04b30a69-5e9d-ef0a-0513-68e706a53566@opensips.org> Hi Schneur, Well, this exact behavior cannot be achieved with OpenSIPS only, as some advanced Class 5 capabilities are required. What you can do is slightly different - when you call to the ringing group (to pick the call), your call will be terminated and immediately your phone will start ringing (as your phone will also receive the call). Is this behavior acceptable ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.11.2016 20:09, Schneur Rosenberg wrote: > No, I mean where a phone or group of phones ring, and you are at > another extension that does not ring, you dial a code and grab the > ringing extension. > > On Wed, Nov 9, 2016 at 5:40 PM, Bogdan-Andrei Iancu > > wrote: > > Hi, > > You mean parallel calling groups, where a call to the group is > sent to all the parties of the group (simultaneous ringing) and > first to answer will pick up the call ? if so , this is parallel > forking. > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 08.11.2016 16:02, Schneur Rosenberg wrote: >> Can someone please guide me how I should build pickup groups >> feature in OpenSIPS? >> thank you >> S. Rosenberg >> >> _______________________________________________ >> 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: From y at jettel.ru Mon Nov 14 12:03:34 2016 From: y at jettel.ru (Ehrny) Date: Mon, 14 Nov 2016 11:03:34 +0000 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> Message-ID: <8B36F227BD22B041AEA7015FD914CD95027889916F@JET-EX02.jettel.ru> Hi, R?zvan, Very helpful, Thank you very much. Best Regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 14, 2016 11:03 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! Yes, you can transform the P-Asserted-Identity header as you wish, by dropping the existing one and creating a new one. Use the remove_hf()[1] and append_hf()[2] headers for that, i.e.: if (is_present_hf("P-Asserted-Identity")) { remove_hf("P-Asserted-Identity"); $avp(rpid) = "new-header"; append_hf("P-Asserted-Identity: $avp(rpid) \r\n"); } [1] http://www.opensips.org/html/docs/modules/2.2.x/sipmsgops.html#id293937 [2] http://www.opensips.org/html/docs/modules/2.2.x/sipmsgops.html#id249696 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/13/2016 08:55 PM, Ehrny wrote: Hello team, I?m trying to follow my carrier?s request to transform P-Asserted-Identity header. Is there any possibilities to do that on the fly with opensips (v2.2.2)? Yet another project assume to add the redirecting number even if it?s not exists. Would it be possible to add it in the route? Your help is really appreciated, Best Regards, Ehrny _______________________________________________ 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: From liviu at opensips.org Mon Nov 14 12:39:53 2016 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 14 Nov 2016 13:39:53 +0200 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: <72829925.20161114131704@ptl.ru> References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> <136401369.20161110172927@ptl.ru> <216131351.20161111103855@ptl.ru> <7e88434c-19fa-ed41-20da-ac38f1ca785b@opensips.org> <72829925.20161114131704@ptl.ru> Message-ID: The "sequential-calls" is the only statistic which may also benefit from a periodical reset (daily / weekly / monthly, etc.). IMO, calls-per-min / total-calls / concurrent-calls _should not_ reset to 0 at midnight. Since a rule's "sequential-calls" cannot be easily reused with multiple reset intervals (it requires either small/big numbers), a check_fraud() parameter will not work so well. This information should be tied to the rule, either in a simplistic string "flags" column (with "d"/"w"/"m" as values), or we could even re-design "sequential_calls" into "seq_daily" / "seq_weekly" / "seq_monthly" and concurrently monitor 0 - 3 of them, depending on their values. Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 14.11.2016 12:17, Denis wrote: > Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! > > Thank you very much for your answer! > I understood my main mistake. I thought that "call duration" is the > total value for all calls but not of only one. > Ok, "sequential-calls" may be that thing which can help to avoid such > situation, but the main problem is (and as you wrote in the previous > letter), that this value doesn`t go to 0 at the next period. > Because of this i have to increase this value to 5000, otherwise i > blocked honest users. > Can "sequential-calls" be set to 0 at the next period? > > mailto:denis7979 at mail.ru > > > Hi, Denis! > First of all, thank you for taking the time to gather this nice data! > Looking at the calls, to me it looks like the module behaved as > expected. Here are some thoughts: > - all call durations were less under 1500 seconds, while your fraud > rule is set to 3600 seconds, so it never got triggered. > - the "calls-per-minute" rule worked! Your rule was set to max 6 cpm, > thus calls #7 - #9 to prefix "810" were considered fraudulent (at > 01:41), as the caller was starting to exceed this quota. The proper > critical warnings were raised, calls blocked, emails sent. > - the attacker now _learned_ about your 6 cpm limitation and _lowered_ > his cpm to 3 during the following 10 hours (until 11:08), thus > bypassing the cpm rate limiting, managing to place 21 fraudulent calls. > It seems like the 21 successful fraudulent calls between 03:06 - 11:08 > could _maybe_ have been avoided by setting a better value for > "sequential-calls". This is a bit tricky though, as we also don't want > to block calls of honest users because of false positives. > Regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 11.11.2016 09:38, Denis wrote: > > Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! > > OK, thank you. > > Additionally i will ask you to analyze one case. > In attachment you can find a log of calls, which were made by one user > some time ago (with the number 1234567). It`s a fraud. > Also i attached a piece of opensips.cfg related to a fraud detection > (see script.txt). When critical event triggered Opensips sends email > to some address (see script.txt). > > As you can see in the call log, fraud began at 01:40 2016-10-01. Value > of the field "sip_reason" "fraud_detected" means that fraud_module > detects the fraud and a call was discarded by script logging (see > script.txt) > First email about that i received at 01:41 with fraud param " calls > per minute". > Next email i received only at 11:08 with fraud param "total calls". > > Between these two time stamps i have no emails about fraud, and as you > can see from the call log, there were many successful calls in this > period with "big" duration. > > Fraud_detection table had such content: > profileid = 1 > prefix = 810 > start_hour = 00:00 > end_hour = 23:59 > daysoftheweek = Mon-Sun > cpm_critical = 6 > call_duration_critical = 3600 > tatal_calls_critical = 30 > concurant_calls_critical = 30 > sequential_calls_critical = 5000 > > The questions is: > - Why module didn`t detect fraud based on "call duration"? > > Thank you. > > mailto:denis7979 at mail.ru > > > Upon looking through the source code, it seems that calls_per_min / > total_calls / concurrent_calls are also reset to 0 every time a new > rule is matched, or if the day has changed since we last matched the > current rule. > I will make sure this info ^ is more easily accessible: either in a > new tutorial section or the module doc. > Regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 10.11.2016 16:29, Denis wrote: > > Re: [OpenSIPS-Users] Fraud_detection module > > Hello, Liviu! > > Thank you for your answer. > > About 2) > > "Calls per minute" - ok, but what about other parameters? > For example, "total calls"? > Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. > If in Mon user makes 25 calls, on Tue since 09:00 counts of "total > calls" begin from 0 or 25? > > mailto:denis7979 at mail.ru > > > Hi, Deniz! > Answers below. > Regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 10.11.2016 15:18, Denis wrote: > > Re: Fraud_detection modul > > Hello! > > Opensips 2.2.1 > > A couple of questions about fraud_detection: > > 1) In documentation says "*consecutive calls* to the same destination > ". Same destination = same number, or prefix? > > Same prefix, taken from the fraud detection rule > > > 2) At the beginning of the next period, a counts of events begin 0? > > The module uses a gliding window of 60 seconds, in order to keep track > of "calls per minute". When changing time intervals, hence putting new > thresholds in place, the "calls per minute" will not reset. In other > words, when switching intervals, the new "calls per minute" thresholds > will initially work with calls placed during the last minute when the > old thresholds were in place. > > > 3) is there any method to reset counts of events for certain user? > > Currently there is no way of doing this. > > > > 4) what is the value used to calculate duration in fraud_module, > minutes or seconds? > > It should be "seconds", I will fix the misleading example in the > tutorial. > > ______________________________________________ > 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: From denis7979 at mail.ru Mon Nov 14 13:32:40 2016 From: denis7979 at mail.ru (Denis) Date: Mon, 14 Nov 2016 15:32:40 +0300 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> <136401369.20161110172927@ptl.ru> <216131351.20161111103855@ptl.ru> <7e88434c-19fa-ed41-20da-ac38f1ca785b@opensips.org> <72829925.20161114131704@ptl.ru> Message-ID: <1223306304.20161114153240@ptl.ru> Ok, Liviu, where this realization can be expected (if any)? Thank you. mailto:denis7979 at mail.ru The "sequential-calls" is the only statistic which may also benefit from a periodical reset (daily / weekly / monthly, etc.). IMO, calls-per-min / total-calls / concurrent-calls _should not_ reset to 0 at midnight. Since a rule's "sequential-calls" cannot be easily reused with multiple reset intervals (it requires either small/big numbers), a check_fraud() parameter will not work so well. This information should be tied to the rule, either in a simplistic string "flags" column (with "d"/"w"/"m" as values), or we could even re-design "sequential_calls" into "seq_daily" / "seq_weekly" / "seq_monthly" and concurrently monitor 0 - 3 of them, depending on their values. Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 14.11.2016 12:17, Denis wrote: Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! Thank you very much for your answer! I understood my main mistake. I thought that "call duration" is the total value for all calls but not of only one. Ok, "sequential-calls" may be that thing which can help to avoid such situation, but the main problem is (and as you wrote in the previous letter), that this value doesn`t go to 0 at the next period. Because of this i have to increase this value to 5000, otherwise i blocked honest users. Can "sequential-calls" be set to 0 at the next period? mailto:denis7979 at mail.ru Hi, Denis! First of all, thank you for taking the time to gather this nice data! Looking at the calls, to me it looks like the module behaved as expected. Here are some thoughts: - all call durations were less under 1500 seconds, while your fraud rule is set to 3600 seconds, so it never got triggered. - the "calls-per-minute" rule worked! Your rule was set to max 6 cpm, thus calls #7 - #9 to prefix "810" were considered fraudulent (at 01:41), as the caller was starting to exceed this quota. The proper critical warnings were raised, calls blocked, emails sent. - the attacker now _learned_ about your 6 cpm limitation and _lowered_ his cpm to 3 during the following 10 hours (until 11:08), thus bypassing the cpm rate limiting, managing to place 21 fraudulent calls. It seems like the 21 successful fraudulent calls between 03:06 - 11:08 could _maybe_ have been avoided by setting a better value for "sequential-calls". This is a bit tricky though, as we also don't want to block calls of honest users because of false positives. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 11.11.2016 09:38, Denis wrote: Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! OK, thank you. Additionally i will ask you to analyze one case. In attachment you can find a log of calls, which were made by one user some time ago (with the number 1234567). It`s a fraud. Also i attached a piece of opensips.cfg related to a fraud detection (see script.txt). When critical event triggered Opensips sends email to some address (see script.txt). As you can see in the call log, fraud began at 01:40 2016-10-01. Value of the field "sip_reason" "fraud_detected" means that fraud_module detects the fraud and a call was discarded by script logging (see script.txt) First email about that i received at 01:41 with fraud param " calls per minute". Next email i received only at 11:08 with fraud param "total calls". Between these two time stamps i have no emails about fraud, and as you can see from the call log, there were many successful calls in this period with "big" duration. Fraud_detection table had such content: profileid = 1 prefix = 810 start_hour = 00:00 end_hour = 23:59 daysoftheweek = Mon-Sun cpm_critical = 6 call_duration_critical = 3600 tatal_calls_critical = 30 concurant_calls_critical = 30 sequential_calls_critical = 5000 The questions is: - Why module didn`t detect fraud based on "call duration"? Thank you. mailto:denis7979 at mail.ru Upon looking through the source code, it seems that calls_per_min / total_calls / concurrent_calls are also reset to 0 every time a new rule is matched, or if the day has changed since we last matched the current rule. I will make sure this info ^ is more easily accessible: either in a new tutorial section or the module doc. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 16:29, Denis wrote: Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! Thank you for your answer. About 2) "Calls per minute" - ok, but what about other parameters? For example, "total calls"? Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. If in Mon user makes 25 calls, on Tue since 09:00 counts of "total calls" begin from 0 or 25? mailto:denis7979 at mail.ru Hi, Deniz! Answers below. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 15:18, Denis wrote: Re: Fraud_detection modul Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? Same prefix, taken from the fraud detection rule 2) At the beginning of the next period, a counts of events begin 0? The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. 3) is there any method to reset counts of events for certain user? Currently there is no way of doing this. 4) what is the value used to calculate duration in fraud_module, minutes or seconds? It should be "seconds", I will fix the misleading example in the tutorial. ______________________________________________ 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: From fedorna at anura.com.ar Mon Nov 14 15:05:36 2016 From: fedorna at anura.com.ar (Federico Edorna) Date: Mon, 14 Nov 2016 11:05:36 -0300 Subject: [OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it? In-Reply-To: <246f0971-48bb-411c-945a-c9f1b2af2f88@opensips.org> References: <246f0971-48bb-411c-945a-c9f1b2af2f88@opensips.org> Message-ID: Hi R?zvan, related to this topic, it seems that tcp_no_new_conn_bflag is not working on "on_reply" routes I've tried changing modules/tm/t_reply.c (opensips 2.2), using something like this: if (tcp_no_new_conn_bflag) tcp_no_new_conn = 1; in "relay_reply" function and now opensips doesn't try to open a new tcp connection. Without this code I cannot manage to avoid the TCP SYN from opensips to client when receiving a reply and tcp connection is not available. Just to clarify, the scenario is something like this: A opensips B --- INVITE ---> --- INVITE ---> <--- 100 Trying --- <--- 100 Trying --- <--- 183 Session Progress--- <--- 183 Session Progress--- --- At this point I wait opensips to close tcp connection (tcp_connection_lifetime=10) and then "B" answers the call ---- <--- 200 OK --- Thanks! Federico On Thu, Oct 27, 2016 at 4:58 AM, R?zvan Crainea wrote: > Hi, Rodrigo! > > Having OpenSIPS opening TCP connections towards client is a bit dangerous, > especially if the clients are behind NAT. That's because most likely you > will not be able to reach them, and opensips will get stuck trying to > connect (until it triggers a timeout). That's why the best way to go is to > try to keep the connection (ideally opened by the client at REGISTER) as > much as possible. This is usually done by pinging (as discussed in a > previous email). So my suggestion is to try to avoid opening new TCP > connections with clients, unless you really know they will always be > reachable. > > The behavior you are describing (INVITE vs BYE handling), might be related > to the fact that you are setting the tcp_no_new_conn_bflag[1] flag for BYE > messages, but not for INVITEs. Is this correct? If not, do you see any > errors in the script? > > [1] http://www.opensips.org/Documentation/Script-CoreParameters-2-2#toc101 > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 10/26/2016 10:59 PM, Rodrigo Pimenta Carvalho wrote: > > Hi. > > > After some log debug I have observed the following behavior in the > OpenSISP (2.2.1): > > > When OpenSIPS has to send a SIP INVITE to a peer through a TCP connection > that was closed before by some way, OpenSIPS open a new one and then sends > the SIP message to the peer successfully. > > > However, when OpenSIPS has to send a SIP BYE to a peer through a TCP > connection that was closed before, OpenSIPS open a new one, but doesn't > send the SIP BYE. In this case SIP BYE is discarded. > > > How to change the behavior of OpenSIPS to make it to send the SIP BYE is > such case? > > > I'm looking for ways of fix or workaround of a TCP tear down connection > that happens during dialogs. > > > Any hint will be very helpful! > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://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: From jim at devito.cc Mon Nov 14 15:20:08 2016 From: jim at devito.cc (Jim DeVito) Date: Mon, 14 Nov 2016 06:20:08 -0800 Subject: [OpenSIPS-Users] =?utf-8?q?Possible_Memory_Leak_in_rest=5Fclient_?= =?utf-8?q?module=2E?= In-Reply-To: <95a5b0e2-5c81-184d-9fd9-3f0e72886284@opensips.org> References: <10fe005ba618cd93d4b9d4abc31f968b@mail.devito.cc> <95a5b0e2-5c81-184d-9fd9-3f0e72886284@opensips.org> Message-ID: Hi Bogdan, Took about a week in production for the problem to crop up again so I was able to get the mem dump. I hope this can provide you some insight. Let me know if you need anything else. http://pastebin.com/WQWqhhiA Thanks!! --- Jim DeVito On 2016-11-07 12:04, Bogdan-Andrei Iancu wrote: > Hi Jim, > > Please see > http://www.opensips.org/Documentation/TroubleShooting-OutOfMem - let > me know if you managed to get the mem dump. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 07.11.2016 21:20, Jim DeVito wrote: >> Hi All, >> >> This happened prior to 2.2.2 and I thought I saw a bug report that was >> fixed in 2.2.2. However it still seems to be a thing with using the >> res_curl module. After about a week I get this... >> >> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >> ERROR:core:fm_malloc: not enough free pkg memory (4296 bytes left), >> please increase the "-M" command line parameter! >> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >> INFO:core:fm_malloc: attempting defragmentation... (need 1808 bytes) >> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >> INFO:core:fm_malloc: unable to alloc a big enough fragment! >> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >> ERROR:rest_client:rest_get_method: curl_easy_perform: Out of memory >> >> I reboot and all is well for another week. Like res_client is not >> releasing the memory it is using. shmem:used_size:: seems to always be >> going up until it runs out of the memory I allotted with the -M >> switch. What else can I do to see where this is coming from? >> >> Thanks!! >> From razvan at opensips.org Mon Nov 14 15:24:55 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 14 Nov 2016 16:24:55 +0200 Subject: [OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it? In-Reply-To: References: <246f0971-48bb-411c-945a-c9f1b2af2f88@opensips.org> Message-ID: <4a237c7b-c6f0-b9bf-c7c9-5db2cf90d0ed@opensips.org> Hi, Federico! Not sure I understand your problem. That flag indicates OpenSIPS to avoid opening a new connection if he doesn't have one available. Therefore, if the connection to the caller closes between INVITE and 200 OK, that flag prevents OpenSIPS from opening a new one. Why would you like to get rid of the TCP SYN message? That happens and the TCP layer, saying that the data arrived successfully. Why would you like to prevent that? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/14/2016 04:05 PM, Federico Edorna wrote: > Hi R?zvan, > > related to this topic, it seems that tcp_no_new_conn_bflag is not > working on "on_reply" routes > > I've tried changing modules/tm/t_reply.c (opensips 2.2), using > something like this: > > > if (tcp_no_new_conn_bflag) > tcp_no_new_conn = 1; > > > in "relay_reply" function and now opensips doesn't try to open a new > tcp connection. Without this code I cannot manage to avoid the TCP SYN > from opensips to client when receiving a reply and tcp connection is > not available. > > > Just to clarify, the scenario is something like this: > > > AopensipsB > > ---INVITE---> > > ---INVITE---> > <---100 Trying--- > <---100 Trying--- > > <---183 Session Progress--- > > > <---183 Session Progress--- > > > --- At this point I wait opensips to close tcp connection > (tcp_connection_lifetime=10) and then "B" answers the call ---- > > > <---200 OK--- > > > Thanks! > > Federico > > On Thu, Oct 27, 2016 at 4:58 AM, R?zvan Crainea > wrote: > > Hi, Rodrigo! > > Having OpenSIPS opening TCP connections towards client is a bit > dangerous, especially if the clients are behind NAT. That's > because most likely you will not be able to reach them, and > opensips will get stuck trying to connect (until it triggers a > timeout). That's why the best way to go is to try to keep the > connection (ideally opened by the client at REGISTER) as much as > possible. This is usually done by pinging (as discussed in a > previous email). So my suggestion is to try to avoid opening new > TCP connections with clients, unless you really know they will > always be reachable. > > The behavior you are describing (INVITE vs BYE handling), might be > related to the fact that you are setting the > tcp_no_new_conn_bflag[1] flag for BYE messages, but not for > INVITEs. Is this correct? If not, do you see any errors in the script? > > [1] > http://www.opensips.org/Documentation/Script-CoreParameters-2-2#toc101 > > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 10/26/2016 10:59 PM, Rodrigo Pimenta Carvalho wrote: >> >> Hi. >> >> >> After some log debug I have observed the following behavior in >> the OpenSISP (2.2.1): >> >> >> When OpenSIPS has to send a SIP INVITE to a peer through a TCP >> connection that was closed before by some way, OpenSIPS open a >> new one and then sends the SIP message to the peer successfully. >> >> >> However, when OpenSIPS has to send a SIP BYE to a peer through a >> TCP connection that was closed before, OpenSIPS open a new one, >> but doesn't send the SIP BYE. In this case SIP BYE is discarded. >> >> >> How to change the behavior of OpenSIPS to make it to send the SIP >> BYE is such case? >> >> >> I'm looking for ways of fix or workaround of a TCP tear down >> connection that happens during dialogs. >> >> >> Any hint will be very helpful! >> >> >> RODRIGO PIMENTA CARVALHO >> Inatel Competence Center >> Software >> Ph: +55 35 3471 9200 RAMAL 979 >> >> >> _______________________________________________ >> 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: From fedorna at anura.com.ar Mon Nov 14 17:06:53 2016 From: fedorna at anura.com.ar (Federico Edorna) Date: Mon, 14 Nov 2016 13:06:53 -0300 Subject: [OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it? In-Reply-To: <4a237c7b-c6f0-b9bf-c7c9-5db2cf90d0ed@opensips.org> References: <246f0971-48bb-411c-945a-c9f1b2af2f88@opensips.org> <4a237c7b-c6f0-b9bf-c7c9-5db2cf90d0ed@opensips.org> Message-ID: Hi Razvan, thanks for your response I agree that it is dangerous to try to open a new tcp connection, that's why we want to set always the flag and never try to open a new tcp connection to the UAC. What I'm trying to say is that setting tcp_no_new_conn_bflag doesn't seem to work for a reply, for example what I've described in my previous email. When opensips receives a reply from the callee (and has to do the relay to the caller) but the caller tcp connection has gone, opensips will try to open a new connection, even with the flag set. It is not a common scenario, but it happens sometimes, that the tcp connection is reseted before the call is answered. Maybe I cannot explain the problem in my English :(, please let me know... Best Regards Federico On Mon, Nov 14, 2016 at 11:24 AM, R?zvan Crainea wrote: > Hi, Federico! > > Not sure I understand your problem. That flag indicates OpenSIPS to avoid > opening a new connection if he doesn't have one available. Therefore, if > the connection to the caller closes between INVITE and 200 OK, that flag > prevents OpenSIPS from opening a new one. > Why would you like to get rid of the TCP SYN message? That happens and the > TCP layer, saying that the data arrived successfully. Why would you like to > prevent that? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 11/14/2016 04:05 PM, Federico Edorna wrote: > > Hi R?zvan, > > related to this topic, it seems that tcp_no_new_conn_bflag is not working > on "on_reply" routes > > I've tried changing modules/tm/t_reply.c (opensips 2.2), using something > like this: > > > if (tcp_no_new_conn_bflag) > tcp_no_new_conn = 1; > > > in "relay_reply" function and now opensips doesn't try to open a new tcp > connection. Without this code I cannot manage to avoid the TCP SYN from > opensips to client when receiving a reply and tcp connection is not > available. > > > Just to clarify, the scenario is something like this: > > > A opensips B > > --- INVITE ---> > > --- INVITE ---> > <--- 100 Trying --- > <--- 100 Trying --- > > <--- 183 Session Progress--- > > > <--- 183 Session Progress--- > > > --- At this point I wait opensips to close tcp connection > (tcp_connection_lifetime=10) and then "B" answers the call ---- > > > <--- 200 OK --- > > > Thanks! > > Federico > > On Thu, Oct 27, 2016 at 4:58 AM, R?zvan Crainea > wrote: > >> Hi, Rodrigo! >> >> Having OpenSIPS opening TCP connections towards client is a bit >> dangerous, especially if the clients are behind NAT. That's because most >> likely you will not be able to reach them, and opensips will get stuck >> trying to connect (until it triggers a timeout). That's why the best way to >> go is to try to keep the connection (ideally opened by the client at >> REGISTER) as much as possible. This is usually done by pinging (as >> discussed in a previous email). So my suggestion is to try to avoid opening >> new TCP connections with clients, unless you really know they will always >> be reachable. >> >> The behavior you are describing (INVITE vs BYE handling), might be >> related to the fact that you are setting the tcp_no_new_conn_bflag[1] flag >> for BYE messages, but not for INVITEs. Is this correct? If not, do you see >> any errors in the script? >> >> [1] http://www.opensips.org/Documentation/Script-CoreParameters- >> 2-2#toc101 >> >> R?zvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 10/26/2016 10:59 PM, Rodrigo Pimenta Carvalho wrote: >> >> Hi. >> >> >> After some log debug I have observed the following behavior in the >> OpenSISP (2.2.1): >> >> >> When OpenSIPS has to send a SIP INVITE to a peer through a TCP connection >> that was closed before by some way, OpenSIPS open a new one and then sends >> the SIP message to the peer successfully. >> >> >> However, when OpenSIPS has to send a SIP BYE to a peer through a TCP >> connection that was closed before, OpenSIPS open a new one, but doesn't >> send the SIP BYE. In this case SIP BYE is discarded. >> >> >> How to change the behavior of OpenSIPS to make it to send the SIP BYE is >> such case? >> >> >> I'm looking for ways of fix or workaround of a TCP tear down connection >> that happens during dialogs. >> >> >> Any hint will be very helpful! >> >> >> RODRIGO PIMENTA CARVALHO >> Inatel Competence Center >> Software >> Ph: +55 35 3471 9200 RAMAL 979 >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://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 listUsers at lists.opensips.orghttp://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: From razvan at opensips.org Mon Nov 14 18:02:57 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 14 Nov 2016 19:02:57 +0200 Subject: [OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it? In-Reply-To: References: <246f0971-48bb-411c-945a-c9f1b2af2f88@opensips.org> <4a237c7b-c6f0-b9bf-c7c9-5db2cf90d0ed@opensips.org> Message-ID: <0e8c4712-5e06-c012-05a6-94c7db7e9218@opensips.org> I got you now: so you are trying to set the tcp_no_new_conn_bflag in the reply_route, but OpenSIPS still tries to connect to the client? After you added the code in reply_received function, OpenSIPS still tries to connect? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/14/2016 06:06 PM, Federico Edorna wrote: > Hi Razvan, thanks for your response > > I agree that it is dangerous to try to open a new tcp connection, > that's why we want to set always the flag and never try to open a new > tcp connection to the UAC. > > What I'm trying to say is that setting tcp_no_new_conn_bflag doesn't > seem to work for a reply, for example what I've described in my > previous email. When opensips receives a reply from the callee (and > has to do the relay to the caller) but the caller tcp connection has > gone, opensips will try to open a new connection, even with the flag > set. It is not a common scenario, but it happens sometimes, that the > tcp connection is reseted before the call is answered. > > Maybe I cannot explain the problem in my English :(, please let me know... > > Best Regards > Federico > > On Mon, Nov 14, 2016 at 11:24 AM, R?zvan Crainea > wrote: > > Hi, Federico! > > Not sure I understand your problem. That flag indicates OpenSIPS > to avoid opening a new connection if he doesn't have one > available. Therefore, if the connection to the caller closes > between INVITE and 200 OK, that flag prevents OpenSIPS from > opening a new one. > Why would you like to get rid of the TCP SYN message? That happens > and the TCP layer, saying that the data arrived successfully. Why > would you like to prevent that? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/14/2016 04:05 PM, Federico Edorna wrote: >> Hi R?zvan, >> >> related to this topic, it seems that tcp_no_new_conn_bflag is not >> working on "on_reply" routes >> >> I've tried changing modules/tm/t_reply.c (opensips 2.2), using >> something like this: >> >> >> if (tcp_no_new_conn_bflag) >> tcp_no_new_conn = 1; >> >> >> in "relay_reply" function and now opensips doesn't try to open a >> new tcp connection. Without this code I cannot manage to avoid >> the TCP SYN from opensips to client when receiving a reply and >> tcp connection is not available. >> >> >> Just to clarify, the scenario is something like this: >> >> >> AopensipsB >> >> ---INVITE---> >> >> ---INVITE---> >> <---100 Trying--- >> <---100 Trying--- >> >> <---183 Session Progress--- >> >> >> <---183 Session Progress--- >> >> >> --- At this point I wait opensips to close tcp connection >> (tcp_connection_lifetime=10) and then "B" answers the call ---- >> >> >> <---200 OK--- >> >> >> Thanks! >> >> Federico >> >> On Thu, Oct 27, 2016 at 4:58 AM, R?zvan Crainea >> > wrote: >> >> Hi, Rodrigo! >> >> Having OpenSIPS opening TCP connections towards client is a >> bit dangerous, especially if the clients are behind NAT. >> That's because most likely you will not be able to reach >> them, and opensips will get stuck trying to connect (until it >> triggers a timeout). That's why the best way to go is to try >> to keep the connection (ideally opened by the client at >> REGISTER) as much as possible. This is usually done by >> pinging (as discussed in a previous email). So my suggestion >> is to try to avoid opening new TCP connections with clients, >> unless you really know they will always be reachable. >> >> The behavior you are describing (INVITE vs BYE handling), >> might be related to the fact that you are setting the >> tcp_no_new_conn_bflag[1] flag for BYE messages, but not for >> INVITEs. Is this correct? If not, do you see any errors in >> the script? >> >> [1] >> http://www.opensips.org/Documentation/Script-CoreParameters-2-2#toc101 >> >> >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 10/26/2016 10:59 PM, Rodrigo Pimenta Carvalho wrote: >>> >>> Hi. >>> >>> >>> After some log debug I have observed the following behavior >>> in the OpenSISP (2.2.1): >>> >>> >>> When OpenSIPS has to send a SIP INVITE to a peer through a >>> TCP connection that was closed before by some way, OpenSIPS >>> open a new one and then sends the SIP message to the peer >>> successfully. >>> >>> >>> However, when OpenSIPS has to send a SIP BYE to a peer >>> through a TCP connection that was closed before, OpenSIPS >>> open a new one, but doesn't send the SIP BYE. In this case >>> SIP BYE is discarded. >>> >>> >>> How to change the behavior of OpenSIPS to make it to send >>> the SIP BYE is such case? >>> >>> >>> I'm looking for ways of fix or workaround of a TCP tear down >>> connection that happens during dialogs. >>> >>> >>> Any hint will be very helpful! >>> >>> >>> RODRIGO PIMENTA CARVALHO >>> Inatel Competence Center >>> Software >>> Ph: +55 35 3471 9200 RAMAL 979 >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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: From fedorna at anura.com.ar Mon Nov 14 18:10:54 2016 From: fedorna at anura.com.ar (Federico Edorna) Date: Mon, 14 Nov 2016 14:10:54 -0300 Subject: [OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it? In-Reply-To: <0e8c4712-5e06-c012-05a6-94c7db7e9218@opensips.org> References: <246f0971-48bb-411c-945a-c9f1b2af2f88@opensips.org> <4a237c7b-c6f0-b9bf-c7c9-5db2cf90d0ed@opensips.org> <0e8c4712-5e06-c012-05a6-94c7db7e9218@opensips.org> Message-ID: Right! Actually I've added the code in relay_reply function, not in reply_route, but I guess it has the same effect... Thanks! On Mon, Nov 14, 2016 at 2:02 PM, R?zvan Crainea wrote: > I got you now: so you are trying to set the tcp_no_new_conn_bflag in the > reply_route, but OpenSIPS still tries to connect to the client? > After you added the code in reply_received function, OpenSIPS still tries > to connect? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 11/14/2016 06:06 PM, Federico Edorna wrote: > > Hi Razvan, thanks for your response > > I agree that it is dangerous to try to open a new tcp connection, that's > why we want to set always the flag and never try to open a new tcp > connection to the UAC. > > What I'm trying to say is that setting tcp_no_new_conn_bflag doesn't seem > to work for a reply, for example what I've described in my previous email. > When opensips receives a reply from the callee (and has to do the relay to > the caller) but the caller tcp connection has gone, opensips will try to > open a new connection, even with the flag set. It is not a common scenario, > but it happens sometimes, that the tcp connection is reseted before the > call is answered. > > Maybe I cannot explain the problem in my English :(, please let me know... > > Best Regards > Federico > > > On Mon, Nov 14, 2016 at 11:24 AM, R?zvan Crainea > wrote: > >> Hi, Federico! >> >> Not sure I understand your problem. That flag indicates OpenSIPS to avoid >> opening a new connection if he doesn't have one available. Therefore, if >> the connection to the caller closes between INVITE and 200 OK, that flag >> prevents OpenSIPS from opening a new one. >> Why would you like to get rid of the TCP SYN message? That happens and >> the TCP layer, saying that the data arrived successfully. Why would you >> like to prevent that? >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 11/14/2016 04:05 PM, Federico Edorna wrote: >> >> Hi R?zvan, >> >> related to this topic, it seems that tcp_no_new_conn_bflag is not working >> on "on_reply" routes >> >> I've tried changing modules/tm/t_reply.c (opensips 2.2), using something >> like this: >> >> >> if (tcp_no_new_conn_bflag) >> tcp_no_new_conn = 1; >> >> >> in "relay_reply" function and now opensips doesn't try to open a new tcp >> connection. Without this code I cannot manage to avoid the TCP SYN from >> opensips to client when receiving a reply and tcp connection is not >> available. >> >> >> Just to clarify, the scenario is something like this: >> >> >> A opensips B >> >> --- INVITE ---> >> >> --- INVITE ---> >> <--- 100 Trying --- >> <--- 100 Trying --- >> >> <--- 183 Session Progress--- >> >> >> <--- 183 Session Progress--- >> >> >> --- At this point I wait opensips to close tcp connection >> (tcp_connection_lifetime=10) and then "B" answers the call ---- >> >> >> <--- 200 OK --- >> >> >> Thanks! >> >> Federico >> >> On Thu, Oct 27, 2016 at 4:58 AM, R?zvan Crainea >> wrote: >> >>> Hi, Rodrigo! >>> >>> Having OpenSIPS opening TCP connections towards client is a bit >>> dangerous, especially if the clients are behind NAT. That's because most >>> likely you will not be able to reach them, and opensips will get stuck >>> trying to connect (until it triggers a timeout). That's why the best way to >>> go is to try to keep the connection (ideally opened by the client at >>> REGISTER) as much as possible. This is usually done by pinging (as >>> discussed in a previous email). So my suggestion is to try to avoid opening >>> new TCP connections with clients, unless you really know they will always >>> be reachable. >>> >>> The behavior you are describing (INVITE vs BYE handling), might be >>> related to the fact that you are setting the tcp_no_new_conn_bflag[1] flag >>> for BYE messages, but not for INVITEs. Is this correct? If not, do you see >>> any errors in the script? >>> >>> [1] http://www.opensips.org/Documentation/Script-CoreParameters- >>> 2-2#toc101 >>> >>> R?zvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 10/26/2016 10:59 PM, Rodrigo Pimenta Carvalho wrote: >>> >>> Hi. >>> >>> >>> After some log debug I have observed the following behavior in the >>> OpenSISP (2.2.1): >>> >>> >>> When OpenSIPS has to send a SIP INVITE to a peer through a TCP >>> connection that was closed before by some way, OpenSIPS open a new one and >>> then sends the SIP message to the peer successfully. >>> >>> >>> However, when OpenSIPS has to send a SIP BYE to a peer through a TCP >>> connection that was closed before, OpenSIPS open a new one, but doesn't >>> send the SIP BYE. In this case SIP BYE is discarded. >>> >>> >>> How to change the behavior of OpenSIPS to make it to send the SIP BYE is >>> such case? >>> >>> >>> I'm looking for ways of fix or workaround of a TCP tear down connection >>> that happens during dialogs. >>> >>> >>> Any hint will be very helpful! >>> >>> >>> RODRIGO PIMENTA CARVALHO >>> Inatel Competence Center >>> Software >>> Ph: +55 35 3471 9200 RAMAL 979 >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://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 listUsers at lists.opensips.orghttp://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 listUsers at lists.opensips.orghttp://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: From fedorna at anura.com.ar Mon Nov 14 18:27:10 2016 From: fedorna at anura.com.ar (Federico Edorna) Date: Mon, 14 Nov 2016 14:27:10 -0300 Subject: [OpenSIPS-Users] OpenSIPS reopen TCP connectios and sends INVITE, but not BYE. How to change it? In-Reply-To: References: <246f0971-48bb-411c-945a-c9f1b2af2f88@opensips.org> <4a237c7b-c6f0-b9bf-c7c9-5db2cf90d0ed@opensips.org> <0e8c4712-5e06-c012-05a6-94c7db7e9218@opensips.org> Message-ID: Sorry!, after I added the code, opensips does NOT tries to connect. That is my wanted result On Mon, Nov 14, 2016 at 2:10 PM, Federico Edorna wrote: > Right! Actually I've added the code in relay_reply function, not in > reply_route, but I guess it has the same effect... > > Thanks! > > > On Mon, Nov 14, 2016 at 2:02 PM, R?zvan Crainea > wrote: > >> I got you now: so you are trying to set the tcp_no_new_conn_bflag in the >> reply_route, but OpenSIPS still tries to connect to the client? >> After you added the code in reply_received function, OpenSIPS still tries >> to connect? >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 11/14/2016 06:06 PM, Federico Edorna wrote: >> >> Hi Razvan, thanks for your response >> >> I agree that it is dangerous to try to open a new tcp connection, that's >> why we want to set always the flag and never try to open a new tcp >> connection to the UAC. >> >> What I'm trying to say is that setting tcp_no_new_conn_bflag doesn't seem >> to work for a reply, for example what I've described in my previous email. >> When opensips receives a reply from the callee (and has to do the relay to >> the caller) but the caller tcp connection has gone, opensips will try to >> open a new connection, even with the flag set. It is not a common scenario, >> but it happens sometimes, that the tcp connection is reseted before the >> call is answered. >> >> Maybe I cannot explain the problem in my English :(, please let me know... >> >> Best Regards >> Federico >> >> >> On Mon, Nov 14, 2016 at 11:24 AM, R?zvan Crainea >> wrote: >> >>> Hi, Federico! >>> >>> Not sure I understand your problem. That flag indicates OpenSIPS to >>> avoid opening a new connection if he doesn't have one available. Therefore, >>> if the connection to the caller closes between INVITE and 200 OK, that flag >>> prevents OpenSIPS from opening a new one. >>> Why would you like to get rid of the TCP SYN message? That happens and >>> the TCP layer, saying that the data arrived successfully. Why would you >>> like to prevent that? >>> >>> Best regards, >>> >>> R?zvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 11/14/2016 04:05 PM, Federico Edorna wrote: >>> >>> Hi R?zvan, >>> >>> related to this topic, it seems that tcp_no_new_conn_bflag is not >>> working on "on_reply" routes >>> >>> I've tried changing modules/tm/t_reply.c (opensips 2.2), using something >>> like this: >>> >>> >>> if (tcp_no_new_conn_bflag) >>> tcp_no_new_conn = 1; >>> >>> >>> in "relay_reply" function and now opensips doesn't try to open a new tcp >>> connection. Without this code I cannot manage to avoid the TCP SYN from >>> opensips to client when receiving a reply and tcp connection is not >>> available. >>> >>> >>> Just to clarify, the scenario is something like this: >>> >>> >>> A opensips B >>> >>> --- INVITE ---> >>> >>> --- INVITE ---> >>> <--- 100 Trying --- >>> <--- 100 Trying --- >>> >>> <--- 183 Session Progress--- >>> >>> >>> <--- 183 Session Progress--- >>> >>> >>> --- At this point I wait opensips to close tcp connection >>> (tcp_connection_lifetime=10) and then "B" answers the call ---- >>> >>> >>> <--- 200 OK --- >>> >>> >>> Thanks! >>> >>> Federico >>> >>> On Thu, Oct 27, 2016 at 4:58 AM, R?zvan Crainea >>> wrote: >>> >>>> Hi, Rodrigo! >>>> >>>> Having OpenSIPS opening TCP connections towards client is a bit >>>> dangerous, especially if the clients are behind NAT. That's because most >>>> likely you will not be able to reach them, and opensips will get stuck >>>> trying to connect (until it triggers a timeout). That's why the best way to >>>> go is to try to keep the connection (ideally opened by the client at >>>> REGISTER) as much as possible. This is usually done by pinging (as >>>> discussed in a previous email). So my suggestion is to try to avoid opening >>>> new TCP connections with clients, unless you really know they will always >>>> be reachable. >>>> >>>> The behavior you are describing (INVITE vs BYE handling), might be >>>> related to the fact that you are setting the tcp_no_new_conn_bflag[1] flag >>>> for BYE messages, but not for INVITEs. Is this correct? If not, do you see >>>> any errors in the script? >>>> >>>> [1] http://www.opensips.org/Documentation/Script-CoreParameters- >>>> 2-2#toc101 >>>> >>>> R?zvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 10/26/2016 10:59 PM, Rodrigo Pimenta Carvalho wrote: >>>> >>>> Hi. >>>> >>>> >>>> After some log debug I have observed the following behavior in the >>>> OpenSISP (2.2.1): >>>> >>>> >>>> When OpenSIPS has to send a SIP INVITE to a peer through a TCP >>>> connection that was closed before by some way, OpenSIPS open a new one and >>>> then sends the SIP message to the peer successfully. >>>> >>>> >>>> However, when OpenSIPS has to send a SIP BYE to a peer through a TCP >>>> connection that was closed before, OpenSIPS open a new one, but doesn't >>>> send the SIP BYE. In this case SIP BYE is discarded. >>>> >>>> >>>> How to change the behavior of OpenSIPS to make it to send the SIP BYE >>>> is such case? >>>> >>>> >>>> I'm looking for ways of fix or workaround of a TCP tear down connection >>>> that happens during dialogs. >>>> >>>> >>>> Any hint will be very helpful! >>>> >>>> >>>> RODRIGO PIMENTA CARVALHO >>>> Inatel Competence Center >>>> Software >>>> Ph: +55 35 3471 9200 RAMAL 979 >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://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 listUsers at lists.opensips.orghttp://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 listUsers at lists.opensips.orghttp://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: From govoiper at gmail.com Mon Nov 14 19:30:43 2016 From: govoiper at gmail.com (SamyGo) Date: Mon, 14 Nov 2016 13:30:43 -0500 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header In-Reply-To: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> References: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> Message-ID: Hi Razvan, Here is the requested data. *INITIAL INVITE: *Via: SIP/2.0/TLS 123.123.212.123:5061 ;branch=z9hG4bK442.8373b213.0;i=35f5 *200 OK from the B party as received by OpenSIPS:* Via: SIP/2.0/TLS 118.151.101.64:5061;branch=z9hG4bK442.9a584727.0;i=11 *200 OK as sent out by OpenSIPS:* Via: SIP/2.0/TLS 123.123.212.123:5061 ;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 Via: SIP/2.0/TLS 123.123.212.123:5061 ;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 Here is the portion of debug log where the destination Answers the call and topology Hiding restore VIA twice. http://pastebin.com/z7pt7cwM Thanks for your response and time looking at this for me. Regards, Sammy. On Nov 14, 2016 3:49 AM, "R?zvan Crainea" wrote: > Hi, Samy! > > Can you post on pastebin debugging logs related to this call? Also, can > you also post the Via headers of the initial INVITE and for the 200 OK > received by OpenSIPS? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 11/12/2016 12:33 AM, SamyGo wrote: > > Hi, > > I'm using OpenSIPS 2.2.1 version and I'm facing a weird situation where > OpenSIPS is adding a duplicated VIA header to the 200 OK, This only happens > when I've topology_hiding() engaged into the call. > > The scenario is very simple; two users making call to each other on the > same OpenSIPS but with topology_hiding(). As a consequence of this double > VIA the caller device doesn't trigger the ACK and hence we don't get media > stream established between devices. > > > *WITH TOPOLOGYHIDING:* > SIP/2.0 200 OK > Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.X > X.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 > Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.XX.XX.X7 > ;rport=59231;branch=z9hG4bK-607165482-63 > CSeq: 1 INVITE > ... > > > *WITHOUT TOPOHIDING: * > SIP/2.0 200 OK > Via: SIP/2.0/TLS 10.1.10.51:59223;received=7X.XX.XX.X7 > ;rport=59223;branch=z9hG4bK-607166212-58 > CSeq: 1 INVITE > > > The only difference between the two scenarios is the function > topology_hiding(); is commented out. > > It seems like a bug to me, can anyone guide me here validate this. > > * OpenSIPS Version:* > version: opensips 2.2.1 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > git revision: 68ace2e > main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 > > > Thanks, > Sammy > > > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://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: From Agalya_Ramachandran at comcast.com Mon Nov 14 20:47:29 2016 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Mon, 14 Nov 2016 19:47:29 +0000 Subject: [OpenSIPS-Users] usage of setdsturi In-Reply-To: References: <1B5505EA-045F-4856-A976-661B906AD1F1@inin.com> Message-ID: Thank you. Got it. Regards, Agalya From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Friday, November 11, 2016 8:33 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] usage of setdsturi Hi, Agalya! The setdsturi() function only accepts strings as parameters, not pseudo-variables[1]. As Ben suggested, the $du pseudo-variable is more flexible and recommended. [1] http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc49 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/10/2016 11:58 PM, Newlin, Ben wrote: I would recommend just using $du. [1] $du = ?sip:? + $var(Fqdn) + ?:5060?; [1] http://www.opensips.org/Documentation/Script-CoreVar-2-2#toc35 Ben Newlin From: on behalf of "Ramachandran, Agalya (Contractor)" Reply-To: OpenSIPS users mailling list Date: Thursday, November 10, 2016 at 4:35 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] usage of setdsturi Hi team, I have a question in usage of setdsturi(). When I hardcode the uri in the function, such as setdsturi(?sip:test at test.com:5060?) ? this works. But why I try to use script variable, it complains as bad_uri. $var(test) = "sip:"+$var(Fqdn)+ ":5060"; setdsturi("$var(test)"); How do I setdsturi() dynamically, with the value in script variable and not by hardcoding? Regards, Agalya _______________________________________________ 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: From saul at ag-projects.com Mon Nov 14 22:39:04 2016 From: saul at ag-projects.com (=?utf-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?=) Date: Mon, 14 Nov 2016 22:39:04 +0100 Subject: [OpenSIPS-Users] [OpenSIPS-users] FOSDEM Real Time Communications devroom seeks speakers / volunteers Message-ID: <7A33F425-9D76-4945-9FCC-688C42FF1235@ag-projects.com> Hi there! It?s that time of the year again, time for FOSDEM paper submissions! Next FOSDEM we?ll have a ?Real Time Communications? devroom, which is a good fit for OpenSIPS and all things VoIP / RTC. All the information regarding the process is available here: https://lists.fosdem.org/pipermail/fosdem/2016-October/002481.html I?m part of the organising team, so please do reach out if you have any questions / problems. Cheers, -- Sa?l Ibarra Corretg? AG Projects -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From miha at softnet.si Tue Nov 15 08:11:24 2016 From: miha at softnet.si (Miha) Date: Tue, 15 Nov 2016 08:11:24 +0100 Subject: [OpenSIPS-Users] nat issue Message-ID: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> Hello i need one info. I have one phone behind NAT and it is registered on OpenSIPS. IN register packet, which is send to OpenSIPS I can see contact: "sip:11181600519 at 192.168.0.101:5060;transport=UDP" and let says that the public ip for this device is xxx.xxx.xxx.xxx. When opensips sends INVITE it send to right public ip and right port (source ip and source port generated by router). The issue is this: Invite is like: "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this request is then fw to this UAC behind router. The UAC replays to this INVITE with 404 Not found as it is waiting to receive the same URI which was written in contact (the userpart is ok, put the ip is public, not private and this is the issue).From what I can see in RFC this is the case. Till now Idid not have any issues with this, but now I found first phone which replays with 404 and from RFC point of view there should be private ip request :) . So is there anything I can do :)? tnx miha -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Tue Nov 15 13:22:01 2016 From: denis7979 at mail.ru (Denis) Date: Tue, 15 Nov 2016 15:22:01 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Message-ID: <1681910255.20161115152201@ptl.ru> Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: trace.txt URL: From razvan at opensips.org Tue Nov 15 13:40:06 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 15 Nov 2016 14:40:06 +0200 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header In-Reply-To: References: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> Message-ID: Hi, Samy! Can you make sure you are not calling topology_hiding() twice on the same request? Can you put an xlog just before each topology_hiding() apearence in your code to make sure? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/14/2016 08:30 PM, SamyGo wrote: > > Hi Razvan, > > > Here is the requested data. > > > *INITIAL INVITE: > *Via: SIP/2.0/TLS 123.123.212.123:5061;branch=z9hG4bK442.8373b213.0;i=35f5 > > * > * > *200 OK from the B party as received by OpenSIPS: > * > Via: SIP/2.0/TLS 118.151.101.64:5061;branch=z9hG4bK442.9a584727.0;i=11 > > > *200 OK as sent out by OpenSIPS: > * > Via: SIP/2.0/TLS > 123.123.212.123:5061;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > Via: SIP/2.0/TLS > 123.123.212.123:5061;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > > > Here is the portion of debug log where the destination Answers the > call and topology Hiding restore VIA twice. > > http://pastebin.com/z7pt7cwM > > > Thanks for your response and time looking at this for me. > > > Regards, > Sammy. > > > On Nov 14, 2016 3:49 AM, "R?zvan Crainea" > wrote: > > Hi, Samy! > > Can you post on pastebin debugging logs related to this call? > Also, can you also post the Via headers of the initial INVITE and > for the 200 OK received by OpenSIPS? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/12/2016 12:33 AM, SamyGo wrote: >> Hi, >> >> I'm using OpenSIPS 2.2.1 version and I'm facing a weird situation >> where OpenSIPS is adding a duplicated VIA header to the 200 OK, >> This only happens when I've topology_hiding() engaged into the call. >> >> The scenario is very simple; two users making call to each other >> on the same OpenSIPS but with topology_hiding(). As a consequence >> of this double VIA the caller device doesn't trigger the ACK and >> hence we don't get media stream established between devices. >> >> >> *WITH TOPOLOGYHIDING:* >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS >> 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >> Via: SIP/2.0/TLS >> 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >> CSeq: 1 INVITE >> ... >> >> *WITHOUT TOPOHIDING: >> * >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS >> 10.1.10.51:59223;received=7X.XX.XX.X7;rport=59223;branch=z9hG4bK-607166212-58 >> CSeq: 1 INVITE >> >> >> The only difference between the two scenarios is the function >> topology_hiding(); is commented out. >> >> It seems like a bug to me, can anyone guide me here validate this. >> * >> OpenSIPS Version:* >> version: opensips 2.2.1 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN >> 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >> git revision: 68ace2e >> main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 >> >> >> Thanks, >> Sammy >> >> >> >> >> _______________________________________________ >> 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: From razvan at opensips.org Tue Nov 15 13:49:28 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 15 Nov 2016 14:49:28 +0200 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <1681910255.20161115152201@ptl.ru> References: <1681910255.20161115152201@ptl.ru> Message-ID: <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: > Opensips 2.2.2 and top hiding Hello! > > I try to make top hiding using topology_hiding module. > In attachment you can find a log of unsuccessful call. > > Scheme of the call > > SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another > Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. > > As i understand, the problem is that Opensips proxy cannot send ACK > (on 200 OK) to PSTN GW because RURI and Route header has similar IP, > namely 3.3.3.3. > > I am using "topology_hiding("C");" function for top hiding. > > The call log was gathered from 1.1.1.1 > > Thank you for any help. > > P.S. On 1.1.1.1 i also try to make load balancing. > > mailto:denis7979 at mail.ru > > > _______________________________________________ > 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: From denis7979 at mail.ru Tue Nov 15 14:19:03 2016 From: denis7979 at mail.ru (Denis) Date: Tue, 15 Nov 2016 16:19:03 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> Message-ID: <1084147120.20161115161903@ptl.ru> Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: From Ben.Newlin at inin.com Tue Nov 15 14:37:23 2016 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Tue, 15 Nov 2016 13:37:23 +0000 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <1084147120.20161115161903@ptl.ru> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> Message-ID: You said you are doing load balancing as well. Are you doing load balancing on the ACK? What module are you using (dispatcher, loadbalancer, etc.)? Load balancing functions can change the R-URI. Ben Newlin From: on behalf of Denis Reply-To: OpenSIPS users mailling list Date: Tuesday, November 15, 2016 at 8:19 AM To: R?zvan Crainea , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: From denis7979 at mail.ru Tue Nov 15 14:44:07 2016 From: denis7979 at mail.ru (Denis) Date: Tue, 15 Nov 2016 16:44:07 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> Message-ID: <1986770232.20161115164407@ptl.ru> Hello Ben. I am using loadbalacer module and using only for initial INVITE. mailto:denis7979 at mail.ru You said you are doing load balancing as well. Are you doing load balancing on the ACK? What module are you using (dispatcher, loadbalancer, etc.)? Load balancing functions can change the R-URI. Ben Newlin From: on behalf of Denis Reply-To: OpenSIPS users mailling list Date: Tuesday, November 15, 2016 at 8:19 AM To: R?zvan Crainea , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: From razvan at opensips.org Tue Nov 15 15:02:15 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 15 Nov 2016 16:02:15 +0200 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <1986770232.20161115164407@ptl.ru> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> Message-ID: Can you put on pastebin the debug logs for the ACK? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 03:44 PM, Denis wrote: > Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. > > I am using loadbalacer module and using only for initial INVITE. > > mailto:denis7979 at mail.ru > > > You said you are doing load balancing as well. Are you doing load > balancing on the ACK? What module are you using (dispatcher, > loadbalancer, etc.)? > > Load balancing functions can change the R-URI. > > > Ben Newlin > > *From: * on behalf of Denis > > *Reply-To: *OpenSIPS users mailling list > *Date: *Tuesday, November 15, 2016 at 8:19 AM > *To: *R?zvan Crainea , OpenSIPS users mailling > list > *Subject: *Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding > > Hello, Razvan! > > No, i don`t make any modification for that variables > > " if (match_dialog() || topology_hiding_match()) { > > if (!$DLG_status == NULL) { > xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, > CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); > force_rport(); > route(1); > exit; > } > > }" > > The information from a syslog. > > "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, > CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, > FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = > sip:3364021 at 3.3.3.3:5068/3.3.3.3" > > mailto:denis7979 at mail.ru > > Hi, Denis! > > Are you modifying the $ru/$rd variables anyhwere in your script for > that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: > ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. > However, it should be: > ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. > > Can you try printing the $ru variable just after the > topology_hiding_match() function? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/15/2016 02:22 PM, Denis wrote: > > Opensips 2.2.2 and top hiding Hello! > > I try to make top hiding using topology_hiding module. > In attachment you can find a log of unsuccessful call. > > Scheme of the call > > SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another > Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. > > As i understand, the problem is that Opensips proxy cannot send ACK > (on 200 OK) to PSTN GW because RURI and Route header has similar IP, > namely 3.3.3.3. > > I am using "topology_hiding("C");" function for top hiding. > > The call log was gathered from 1.1.1.1 > > Thank you for any help. > > P.S. On 1.1.1.1 i also try to make load balancing. > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: From denis7979 at mail.ru Tue Nov 15 15:34:47 2016 From: denis7979 at mail.ru (Denis) Date: Tue, 15 Nov 2016 17:34:47 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> Message-ID: <589878424.20161115173447@ptl.ru> In attachment. mailto:denis7979 at mail.ru Can you put on pastebin the debug logs for the ACK? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 03:44 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. I am using loadbalacer module and using only for initial INVITE. mailto:denis7979 at mail.ru You said you are doing load balancing as well. Are you doing load balancing on the ACK? What module are you using (dispatcher, loadbalancer, etc.)? Load balancing functions can change the R-URI. Ben Newlin From: on behalf of Denis Reply-To: OpenSIPS users mailling list Date: Tuesday, November 15, 2016 at 8:19 AM To: R?zvan Crainea , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: trace1.txt URL: From Agalya_Ramachandran at comcast.com Tue Nov 15 16:34:41 2016 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Tue, 15 Nov 2016 15:34:41 +0000 Subject: [OpenSIPS-Users] Support for https in async In-Reply-To: <6a1bda52-ac41-6029-fbdc-e0734d8a82f5@opensips.org> References: <63ac95ab-d6e5-d2c6-7f77-18816256ceae@opensips.org> <6a1bda52-ac41-6029-fbdc-e0734d8a82f5@opensips.org> Message-ID: <985aa74f8b84453fa621c90b15c9910f@COPDCEX28.cable.comcast.com> Hi Liviu, How can I point to opensips to use "libcurl-openssl-dev" instead of "gnutls-dev" -? Would be great if you guide me here. Regards, Agalya From: Liviu Chircu [mailto:liviu at opensips.org] Sent: Tuesday, November 08, 2016 12:29 PM To: Ramachandran, Agalya (Contractor) ; OpenSIPS users mailling list Subject: Re: Support for https in async Hi Agalya! > handle https queries Regarding HTTPS queries, could you try to build your rest_client with "libcurl-openssl-dev" instead of "libcurl-gnutls-dev" as a possible fix? > why is curl_multi_wait is not used We don't want to block OpenSIPS after issuing an async query, but rather use the core async interface in order to quickly resume processing the next SIP message. > What is the use of read_fds[] in rest_methods.c Helps us find the needle in the haystack. If we find the needle (i.e. the new fd), we can throw it into the reactor and successfully exit. Otherwise, the connect operation is still going, and we need to wait a bit more. > Why select() is not used ? We don't want to do select() in the module code. The core reactor already does that for us. The module's only job in the async pattern is to produce file descriptors and feed them to the core async engine. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 08.11.2016 19:10, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, Thank you for response. I have few questions, can you please clarify me on these. * Is there is a roadmap in future targeting async() to handle https queries? * In start_async_http_request(), why is curl_multi_wait is not used to overcome 1024 fds limitation? and is there plan to use it in future? * What is the use of read_fds[] in rest_methods.c and who uses it? * Why select() is not used ? Regards, Agalya From: Liviu Chircu [mailto:liviu at opensips.org] Sent: Monday, October 31, 2016 12:27 PM To: Ramachandran, Agalya (Contractor) ; OpenSIPS users mailling list Subject: Re: Support for https in async Hi, Agalya! We have not done any development in that direction, and I assume it won't work out of the box, as we need to instruct libcurl on where to find the CA certificate before we can expect it to establish the TLS connection. As an alternative, we could add the option of disabling host/peer verifications like here [1] [1]: https://curl.haxx.se/libcurl/c/https.html Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 31.10.2016 16:41, Ramachandran, Agalya (Contractor) wrote: Hi team, Have you tried with https://url with async and does that work without issue ? When I try, resume_async_http_req is called, but crash is occurring at libcurl library. So helpless to debug further. async(rest_put("https://url", "$fU,$tU,$ci ", "application/json", "$var(body)", "$var(ct)", "$var(rcode)"),resume); My question is crash occring only in my scenario or OpenSIPS doesn't support async as https? Here is my dump just in case for reference. #0 0x00007f567248da1e in Curl_raw_nequal () from /lib64/libcurl.so.4 #1 0x00007f567245bd0f in Curl_checkheaders () from /lib64/libcurl.so.4 #2 0x00007f567245d1e5 in Curl_http () from /lib64/libcurl.so.4 #3 0x00007f567246db4b in Curl_do () from /lib64/libcurl.so.4 #4 0x00007f567247da1b in multi_runsingle () from /lib64/libcurl.so.4 #5 0x00007f567247e121 in curl_multi_perform () from /lib64/libcurl.so.4 #6 0x00007f56726b75ca in resume_async_http_req (fd=9, msg=0x7f56739c0640 , _param=0x7f56b3e354d0) at rest_methods.c:380 #7 0x00007f56737771ff in t_resume_async (fd=0x7f56b3e26840, param=0x7f567405c3e8) at async.c:125 #8 0x0000000000509975 in handle_io (fm=0x7f56b3e26840, idx=1, event_type=1) at net/net_udp.c:267 #9 0x00000000005082b3 in io_wait_loop_epoll (h=0x806e00 <_worker_io>, t=1, repeat=0) at net/../io_wait_loop.h:221 #10 0x0000000000509c30 in udp_rcv_loop (si=0x7f56b3dd6808) at net/net_udp.c:308 #11 0x000000000050a1c8 in udp_start_processes (chd_rank=0x7d30e8 , startup_done=0x0) at net/net_udp.c:372 #12 0x0000000000492304 in main_loop () at main.c:671 #13 0x0000000000494d8f in main (argc=7, argv=0x7fff38a979f8) at main.c:1261 Regards, Agalya From: Ramachandran, Agalya (Contractor) Sent: Thursday, October 27, 2016 4:24 PM To: users at lists.opensips.org; 'Liviu Chircu' Subject: Support for https in async Hi team, Just a quick question.. Does async(), method supports https request? When I try to use https, resume_async_http_req is called, but I never got the response and rather OpenSIPS crashed at libcurl. Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Nov 15 16:41:40 2016 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 15 Nov 2016 17:41:40 +0200 Subject: [OpenSIPS-Users] Support for https in async In-Reply-To: <985aa74f8b84453fa621c90b15c9910f@COPDCEX28.cable.comcast.com> References: <63ac95ab-d6e5-d2c6-7f77-18816256ceae@opensips.org> <6a1bda52-ac41-6029-fbdc-e0734d8a82f5@opensips.org> <985aa74f8b84453fa621c90b15c9910f@COPDCEX28.cable.comcast.com> Message-ID: <1bd756fe-6977-cc96-6da5-fad7219c5570@opensips.org> Just make sure "libcurl-gnutls-dev"is uninstalled. Should do the trick. Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 15.11.2016 17:34, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > How can I point to opensips to use "libcurl-openssl-dev" instead of > ?gnutls-dev? -? > > Would be great if you guide me here. > > Regards, > Agalya > > *From:*Liviu Chircu [mailto:liviu at opensips.org] > *Sent:* Tuesday, November 08, 2016 12:29 PM > *To:* Ramachandran, Agalya (Contractor) > ; OpenSIPS users mailling list > > *Subject:* Re: Support for https in async > > Hi Agalya! > > > handle https queries > > Regarding HTTPS queries, could you try to build your rest_client with > "libcurl-openssl-dev" instead of "libcurl-gnutls-dev" as a possible fix? > > >why is curl_multi_wait is not used > > We don't want to block OpenSIPS after issuing an async query, but > rather use the core async interface in order to quickly resume > processing the next SIP message. > > >What is the use of read_fds[] in rest_methods.c > > Helps us find the needle in the haystack. If we find the needle (i.e. > the new fd), we can throw it into the reactor and successfully exit. > Otherwise, the connect operation is still going, and we need to wait a > bit more. > > > Why select() is not used ? > > We don't want to do select() in the module code. The core reactor > already does that for us. The module's only job in the async pattern > is to produce file descriptors and feed them to the core async engine. > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 08.11.2016 19:10, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > Thank you for response. I have few questions, can you please > clarify me on these. > > ?Is there is a roadmap in future targeting async() to handle https > queries? > > ?In start_async_http_request(), why is curl_multi_wait is not used > to overcome 1024 fds limitation? and is there plan to use it in > future? > > ?What is the use of read_fds[] in rest_methods.c and who uses it? > > ?Why select() is not used ? > > Regards, > > Agalya > > *From:*Liviu Chircu [mailto:liviu at opensips.org] > *Sent:* Monday, October 31, 2016 12:27 PM > *To:* Ramachandran, Agalya (Contractor) > > ; OpenSIPS users mailling > list > *Subject:* Re: Support for https in async > > Hi, Agalya! > > We have not done any development in that direction, and I assume > it won't work out of the box, as we need to instruct libcurl on > where to find the CA certificate before we can expect it to > establish the TLS connection. As an alternative, we could add the > option of disabling host/peer verifications like here [1] > > [1]: https://curl.haxx.se/libcurl/c/https.html > > > Liviu Chircu > > OpenSIPS Developer > > http://www.opensips-solutions.com > > On 31.10.2016 16:41, Ramachandran, Agalya (Contractor) wrote: > > Hi team, > > Have you tried with *https://url*with async and does that work > without issue ? > > When I try, resume_async_http_req is called, but crash is > occurring at libcurl library. So helpless to debug further. > > async(rest_put(*"https://url" , *"$fU,$tU,$ci ", > "application/json", "$var(body)", "$var(ct)", > "$var(rcode)"),resume); > > My question is crash occring only in my scenario or OpenSIPS > doesn?t support async as https? > > Here is my dump just in case for reference. > > /#0 0x00007f567248da1e in Curl_raw_nequal () from > /lib64/libcurl.so.4/ > > /#1 0x00007f567245bd0f in Curl_checkheaders () from > /lib64/libcurl.so.4/ > > /#2 0x00007f567245d1e5 in Curl_http () from /lib64/libcurl.so.4/ > > /#3 0x00007f567246db4b in Curl_do () from /lib64/libcurl.so.4/ > > /#4 0x00007f567247da1b in multi_runsingle () from > /lib64/libcurl.so.4/ > > /#5 0x00007f567247e121 in curl_multi_perform () from > /lib64/libcurl.so.4/ > > #6 0x00007f56726b75ca in resume_async_http_req (fd=9, > msg=0x7f56739c0640 , _param=0x7f56b3e354d0) > > at rest_methods.c:380 > > #7 0x00007f56737771ff in t_resume_async (fd=0x7f56b3e26840, > param=0x7f567405c3e8) at async.c:125 > > #8 0x0000000000509975 in handle_io (fm=0x7f56b3e26840, idx=1, > event_type=1) at net/net_udp.c:267 > > #9 0x00000000005082b3 in io_wait_loop_epoll (h=0x806e00 > <_worker_io>, t=1, repeat=0) at net/../io_wait_loop.h:221 > > #10 0x0000000000509c30 in udp_rcv_loop (si=0x7f56b3dd6808) at > net/net_udp.c:308 > > #11 0x000000000050a1c8 in udp_start_processes > (chd_rank=0x7d30e8 , startup_done=0x0) at > net/net_udp.c:372 > > #12 0x0000000000492304 in main_loop () at main.c:671 > > #13 0x0000000000494d8f in main (argc=7, argv=0x7fff38a979f8) > at main.c:1261 > > Regards, > > Agalya > > *From:* Ramachandran, Agalya (Contractor) > *Sent:* Thursday, October 27, 2016 4:24 PM > *To:* users at lists.opensips.org > ; 'Liviu Chircu' > > *Subject:* Support for https in async > > Hi team, > > Just a quick question.. Does async(), method supports https > request? > > When I try to use https, resume_async_http_req is called, but > I never got the response and rather OpenSIPS crashed at libcurl. > > Regards, > Agalya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbgatherer at gmail.com Tue Nov 15 17:28:59 2016 From: mbgatherer at gmail.com (Maciej Bylica) Date: Tue, 15 Nov 2016 17:28:59 +0100 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: References: Message-ID: Hi Bogdan, Thanks for reply. Right, Opensips module was not the source of the problem. I've managed to solve the issue, memcache is working fine. Thanks Maciej. 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu : > Hi Maciej, > > As I see, you are manually compiling and installing the memcached stuff - > any special reason for doing that ? (versus using packages) > > As the problem seems to be in the lib, not in the OpenSIPS module. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 09.11.2016 18:41, Maciej Bylica wrote: > > Hello > > I am struggling with memcached installation with the latest git opensips > 2.2.2 and centos 6.8 > Here are version releases i am using: > libmemcached-1.0.18 (./configure, make && make install) > memcached-1.4.33 (./configure, make && make install) > with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH > > memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 > does not produce any error > > but what is really puzzling me during the opensips start is the error > below: > DBG:core:load_module: loading module /usr/local/lib64/opensips/ > modules/cachedb_memcached.so > ERROR:core:sr_load_module: could not open module > : > /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once > > Can someone please guide me how to put memcached up and running ? > Opensips is compiled with cachedb_memcached module. > > Thanks in advance. > Maciej > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmontassier at openip.fr Tue Nov 15 18:12:09 2016 From: gmontassier at openip.fr (guillaume Montassier) Date: Tue, 15 Nov 2016 18:12:09 +0100 Subject: [OpenSIPS-Users] Strange behavior with BYE message on Opensips 2.1 Message-ID: <582B41E9.7000008@openip.fr> Hello all, I'm working a project with multiples opensips (each handling a particular role). So when an invite goes in our plateform, it crosse multiples openips and can even sometime go though a specific opensips multiples times. My problem is: When the called send a BYE I have a strange behavior. One of my opensips which receive the BYE resend it to itself and suppress the wrong route (last route instead of the first route...). - For example this is the BYE message my opensips receive : 2016/11/15 15:24:08.316573*172.99.37.70:5060* -> *172.99.37.52:5060* BYE sip:*test2-o36onlarnncrd at 172.99.37.52:5060*;transport=udp SIP/2.0 Route: =>*itself* Route: =>*Next hope* Route: Route: Route: Route: Route: - This is what I should have as result (It remove itself from the Route header and send the BYE to the next hop (which is 172.99.37.52:5061) ): 2016/11/15 15:24:08.316573 *172.99.37.52:5060* -> *172.99.37.52:5061* =>*Send to Next hope* BYE sip:test2-o36onlarnncrd at 172.99.37.52:5060;transport=udp SIP/2.0 *Route*: =>*Next hope is the first route header* Route: Route: Route: Route: Route: - This is what I have (send to itself and remove the wrong route...): 2016/11/15 15:24:08.316573 *172.99.37.52:5060* -> *172.99.37.52:5060* =>*send to itself* BYE*sip:172.99.37.52:5060*;transport=udp SIP/2.0 =>*modify bye?* *Route*: =>*don't supress the route header* Route: Route: Route: Route: Route: =>*The last route is suppress* I know that my first header route is the same than my last header route, and maybe this is why I have this beavior, but this seems really odd to me. Thank you all, /Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Nov 15 18:09:25 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 15 Nov 2016 19:09:25 +0200 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: References: Message-ID: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> OK, thank you for the update Maciej, Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.11.2016 18:28, Maciej Bylica wrote: > Hi Bogdan, > > Thanks for reply. > Right, Opensips module was not the source of the problem. > I've managed to solve the issue, memcache is working fine. > > Thanks > Maciej. > > 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu >: > > Hi Maciej, > > As I see, you are manually compiling and installing the memcached > stuff - any special reason for doing that ? (versus using packages) > > As the problem seems to be in the lib, not in the OpenSIPS module. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 09.11.2016 18:41, Maciej Bylica wrote: >> Hello I am struggling with memcached installation with the latest >> git opensips 2.2.2 and centos 6.8 Here are version releases i am >> using: libmemcached-1.0.18 (./configure, make && make install) >> memcached-1.4.33 (./configure, make && make install) with >> LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH memcached -d -u >> nobody -m 1048 -p 9999 127.0.0.1 does not produce any error but >> what is really puzzling me during the opensips start is the error >> below: DBG:core:load_module: loading module >> /usr/local/lib64/opensips/modules/cachedb_memcached.so >> ERROR:core:sr_load_module: could not open module >> : >> /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once >> Can someone please guide me how to put memcached up and running ? >> Opensips is compiled with cachedb_memcached module. >> Thanks in advance. >> Maciej >> >> _______________________________________________ >> 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: From razvan at opensips.org Tue Nov 15 18:15:25 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 15 Nov 2016 19:15:25 +0200 Subject: [OpenSIPS-Users] [OpenSIPS-users] FOSDEM Real Time Communications devroom seeks speakers / volunteers In-Reply-To: <7A33F425-9D76-4945-9FCC-688C42FF1235@ag-projects.com> References: <7A33F425-9D76-4945-9FCC-688C42FF1235@ag-projects.com> Message-ID: Hi, Saul! Thanks for the heads-up, we'll definitely be there! See you in Brussels! Cheers, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/14/2016 11:39 PM, Sa?l Ibarra Corretg? wrote: > Hi there! > > It?s that time of the year again, time for FOSDEM paper submissions! Next FOSDEM we?ll have a ?Real Time Communications? devroom, which is a good fit for OpenSIPS and all things VoIP / RTC. > > All the information regarding the process is available here: https://lists.fosdem.org/pipermail/fosdem/2016-October/002481.html > > I?m part of the organising team, so please do reach out if you have any questions / problems. > > > Cheers, > > -- > Sa?l Ibarra Corretg? > AG Projects > > > > > > > > _______________________________________________ > 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: From govoiper at gmail.com Tue Nov 15 18:19:15 2016 From: govoiper at gmail.com (SamyGo) Date: Tue, 15 Nov 2016 12:19:15 -0500 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header In-Reply-To: References: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> Message-ID: Hi Razvan, I just noticed that since Topo hiding function gives error, the calls using this do not show any changes in CallID or Contact or any other details , seems like topohiding is not doing it's job for such calls anymore. ! Kindly let me know of anything further required to get this resolved. Thanks, Sammy. On Mon, Nov 14, 2016 at 1:30 PM, SamyGo wrote: > Hi Razvan, > > > Here is the requested data. > > > > *INITIAL INVITE: *Via: SIP/2.0/TLS 123.123.212.123:5061;branch= > z9hG4bK442.8373b213.0;i=35f5 > > > *200 OK from the B party as received by OpenSIPS:* > Via: SIP/2.0/TLS 118.151.101.64:5061;branch=z9hG4bK442.9a584727.0;i=11 > > > > *200 OK as sent out by OpenSIPS:* > Via: SIP/2.0/TLS 123.123.212.123:5061;received= > 123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > Via: SIP/2.0/TLS 123.123.212.123:5061;received= > 123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > > > Here is the portion of debug log where the destination Answers the call > and topology Hiding restore VIA twice. > > http://pastebin.com/z7pt7cwM > > > Thanks for your response and time looking at this for me. > > > Regards, > Sammy. > > > On Nov 14, 2016 3:49 AM, "R?zvan Crainea" wrote: > >> Hi, Samy! >> >> Can you post on pastebin debugging logs related to this call? Also, can >> you also post the Via headers of the initial INVITE and for the 200 OK >> received by OpenSIPS? >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 11/12/2016 12:33 AM, SamyGo wrote: >> >> Hi, >> >> I'm using OpenSIPS 2.2.1 version and I'm facing a weird situation where >> OpenSIPS is adding a duplicated VIA header to the 200 OK, This only happens >> when I've topology_hiding() engaged into the call. >> >> The scenario is very simple; two users making call to each other on the >> same OpenSIPS but with topology_hiding(). As a consequence of this double >> VIA the caller device doesn't trigger the ACK and hence we don't get media >> stream established between devices. >> >> >> *WITH TOPOLOGYHIDING:* >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.X >> X.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >> Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.XX.XX.X7 >> ;rport=59231;branch=z9hG4bK-607165482-63 >> CSeq: 1 INVITE >> ... >> >> >> *WITHOUT TOPOHIDING: * >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS 10.1.10.51:59223;received=7X.XX.XX.X7 >> ;rport=59223;branch=z9hG4bK-607166212-58 >> CSeq: 1 INVITE >> >> >> The only difference between the two scenarios is the function >> topology_hiding(); is commented out. >> >> It seems like a bug to me, can anyone guide me here validate this. >> >> * OpenSIPS Version:* >> version: opensips 2.2.1 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >> MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >> git revision: 68ace2e >> main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 >> >> >> Thanks, >> Sammy >> >> >> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://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: From bogdan at opensips.org Tue Nov 15 18:33:27 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 15 Nov 2016 19:33:27 +0200 Subject: [OpenSIPS-Users] Strange behavior with BYE message on Opensips 2.1 In-Reply-To: <582B41E9.7000008@openip.fr> References: <582B41E9.7000008@openip.fr> Message-ID: <60e977f8-6fb2-ab71-01d9-c33061eba1b7@opensips.org> Hi Guillaume, The incoming BYE is broken - the IP of your OpenSIPS can be found both in RURI and in the top Route header. As the IP is found in RURI makes OpenSIPS think that the previous hop was a strict router. and this leads to the infinite loop. Looking at it, I see the typical mistake of doing a fix_nated_contact() and overwriting the original contact URI in the 200 OK for INVITE (this contact is used as part of the routing set for routing back sequential requests like BYE) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.11.2016 19:12, guillaume Montassier wrote: > Hello all, > > I'm working a project with multiples opensips (each handling a > particular role). > So when an invite goes in our plateform, it crosse multiples openips > and can even sometime go though a specific opensips multiples times. > My problem is: When the called send a BYE I have a strange behavior. > One of my opensips which receive the BYE resend it to itself and > suppress the wrong route (last route instead of the first route...). > > - For example this is the BYE message my opensips receive : > > 2016/11/15 15:24:08.316573*172.99.37.70:5060* -> *172.99.37.52:5060* > BYE sip:*test2-o36onlarnncrd at 172.99.37.52:5060*;transport=udp SIP/2.0 > Route: > =>*itself* > Route: > =>*Next hope* > Route: > Route: > Route: > Route: > Route: > > > - This is what I should have as result (It remove itself from the > Route header and send the BYE to the next hop (which is > 172.99.37.52:5061) ): > > 2016/11/15 15:24:08.316573 *172.99.37.52:5060* -> *172.99.37.52:5061* > =>*Send to Next hope* > BYE sip:test2-o36onlarnncrd at 172.99.37.52:5060;transport=udp SIP/2.0 > *Route*: > =>*Next hope is the first route > header* > Route: > Route: > Route: > Route: > Route: > > > - This is what I have (send to itself and remove the wrong route...): > > 2016/11/15 15:24:08.316573 *172.99.37.52:5060* -> *172.99.37.52:5060* > =>*send to itself* > BYE*sip:172.99.37.52:5060*;transport=udp SIP/2.0 > =>*modify bye?* > *Route*: > =>*don't supress the route header* > Route: > Route: > Route: > Route: > Route: > =>*The last route is suppress* > > > I know that my first header route is the same than my last header > route, and maybe this is why I have this beavior, but this seems > really odd to me. > > Thank you all, > > /Guillaume > > > _______________________________________________ > 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: From bogdan at opensips.org Tue Nov 15 18:35:05 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 15 Nov 2016 19:35:05 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> Message-ID: <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> Hi Miha, When you handle REGISTER requests (from behind NAT) most probably you use fix_nated_contact() instead of fix_nated_register(). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.11.2016 09:11, Miha wrote: > Hello > > i need one info. > I have one phone behind NAT and it is registered on OpenSIPS. IN > register packet, which is send to OpenSIPS I can see contact: > "sip:11181600519 at 192.168.0.101:5060;transport=UDP" > > and let says that the public ip for this device is xxx.xxx.xxx.xxx. > > > When opensips sends INVITE it send to right public ip and right port > (source ip and source port generated by router). The issue is this: > Invite is like: "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" > and this request is then fw to this UAC behind router. The UAC replays > to this INVITE with 404 Not found as it is waiting to receive the same > URI which was written in contact (the userpart is ok, put the ip is > public, not private and this is the issue).From what I can see in RFC > this is the case. > > > Till now Idid not have any issues with this, but now I found first > phone which replays with 404 and from RFC point of view there should > be private ip request :) . So is there anything I can do :)? > > > tnx > miha > > > _______________________________________________ > 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: From razvan at opensips.org Tue Nov 15 18:57:08 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 15 Nov 2016 19:57:08 +0200 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <589878424.20161115173447@ptl.ru> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> <589878424.20161115173447@ptl.ru> Message-ID: <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> Hi, Denis! Could you also send the logs for INVITE? It seems like the dialog is storing a bogus Contact header. PS: please attach the logs on pastebin.com, not directly in the email. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 04:34 PM, Denis wrote: > Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In attachment. > > mailto:denis7979 at mail.ru > > > Can you put on pastebin the debug logs for the ACK? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/15/2016 03:44 PM, Denis wrote: > > Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. > > I am using loadbalacer module and using only for initial INVITE. > > mailto:denis7979 at mail.ru > > > You said you are doing load balancing as well. Are you doing load > balancing on the ACK? What module are you using (dispatcher, > loadbalancer, etc.)? > > Load balancing functions can change the R-URI. > > > Ben Newlin > > *From: * > on behalf of Denis > > *Reply-To: *OpenSIPS users mailling list > > *Date: *Tuesday, November 15, 2016 at 8:19 AM > *To: *R?zvan Crainea > , OpenSIPS users mailling list > > *Subject: *Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding > > Hello, Razvan! > > No, i don`t make any modification for that variables > > " if (match_dialog() || topology_hiding_match()) { > > if (!$DLG_status == NULL) { > xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, > FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); > force_rport(); > route(1); > exit; > } > > }" > > The information from a syslog. > > "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, > CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, > FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = > sip:3364021 at 3.3.3.3:5068/3.3.3.3 > " > > mailto:denis7979 at mail.ru > > Hi, Denis! > > Are you modifying the $ru/$rd variables anyhwere in your script for > that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: > ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. > However, it should be: > ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. > > Can you try printing the $ru variable just after the > topology_hiding_match() function? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/15/2016 02:22 PM, Denis wrote: > > Opensips 2.2.2 and top hiding Hello! > > I try to make top hiding using topology_hiding module. > In attachment you can find a log of unsuccessful call. > > Scheme of the call > > SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another > Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. > > As i understand, the problem is that Opensips proxy cannot send ACK > (on 200 OK) to PSTN GW because RURI and Route header has similar IP, > namely 3.3.3.3. > > I am using "topology_hiding("C");" function for top hiding. > > The call log was gathered from 1.1.1.1 > > Thank you for any help. > > P.S. On 1.1.1.1 i also try to make load balancing. > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: From razvan at opensips.org Tue Nov 15 18:58:12 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 15 Nov 2016 19:58:12 +0200 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header In-Reply-To: References: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> Message-ID: <67001bb0-3406-33b1-2528-a7156ea202de@opensips.org> Hi, Sammy! What errors is the topo hiding function logging? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 07:19 PM, SamyGo wrote: > Hi Razvan, > > I just noticed that since Topo hiding function gives error, the calls > using this do not show any changes in CallID or Contact or any other > details , seems like topohiding is not doing it's job for such calls > anymore. ! > > Kindly let me know of anything further required to get this resolved. > > Thanks, > Sammy. > > > > On Mon, Nov 14, 2016 at 1:30 PM, SamyGo > wrote: > > Hi Razvan, > > > Here is the requested data. > > > *INITIAL INVITE: > *Via: SIP/2.0/TLS > 123.123.212.123:5061;branch=z9hG4bK442.8373b213.0;i=35f5 > > * > * > *200 OK from the B party as received by OpenSIPS: > * > Via: SIP/2.0/TLS 118.151.101.64:5061;branch=z9hG4bK442.9a584727.0;i=11 > > > *200 OK as sent out by OpenSIPS: > * > Via: SIP/2.0/TLS > 123.123.212.123:5061;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > Via: SIP/2.0/TLS > 123.123.212.123:5061;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > > > Here is the portion of debug log where the destination Answers the > call and topology Hiding restore VIA twice. > > http://pastebin.com/z7pt7cwM > > > Thanks for your response and time looking at this for me. > > > Regards, > Sammy. > > > On Nov 14, 2016 3:49 AM, "R?zvan Crainea" > wrote: > > Hi, Samy! > > Can you post on pastebin debugging logs related to this call? > Also, can you also post the Via headers of the initial INVITE > and for the 200 OK received by OpenSIPS? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/12/2016 12:33 AM, SamyGo wrote: >> Hi, >> >> I'm using OpenSIPS 2.2.1 version and I'm facing a weird >> situation where OpenSIPS is adding a duplicated VIA header to >> the 200 OK, This only happens when I've topology_hiding() >> engaged into the call. >> >> The scenario is very simple; two users making call to each >> other on the same OpenSIPS but with topology_hiding(). As a >> consequence of this double VIA the caller device doesn't >> trigger the ACK and hence we don't get media stream >> established between devices. >> >> >> *WITH TOPOLOGYHIDING:* >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS >> 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >> Via: SIP/2.0/TLS >> 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >> CSeq: 1 INVITE >> ... >> >> *WITHOUT TOPOHIDING: >> * >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS >> 10.1.10.51:59223;received=7X.XX.XX.X7;rport=59223;branch=z9hG4bK-607166212-58 >> CSeq: 1 INVITE >> >> >> The only difference between the two scenarios is the function >> topology_hiding(); is commented out. >> >> It seems like a bug to me, can anyone guide me here validate >> this. >> * >> OpenSIPS Version:* >> version: opensips 2.2.1 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, >> PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, >> MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >> git revision: 68ace2e >> main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 >> >> >> Thanks, >> Sammy >> >> >> >> >> _______________________________________________ >> 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: From govoiper at gmail.com Tue Nov 15 20:56:16 2016 From: govoiper at gmail.com (SamyGo) Date: Tue, 15 Nov 2016 14:56:16 -0500 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header In-Reply-To: References: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> Message-ID: Hi Again, Is this related to the "*Work Still in progress"* related to Topology_hiding module as mentioned here at changelog: http://opensips.org/pub/opensips/2.2.2/ChangeLog 2015-10-14 Vlad Paiu * [c0f25f7] : Added Re-INVITE in-dialog pinging support Controlled via the new "R" and "r" flags available to create_dialog() as well as the new reinvite_ping_interval module param Work still in progress : - Properly handle late negociation between endpoints - Ensure SDP persistency ( DB and BIN replication ) - Ensure compatibility with topology hiding ( currently the Contact header will be bogus when doing TH ) - Whitelist or blacklist logic ( terminate call for 481 and 408 timeout, or terminate call for anything else other than 200 and 491 ) - Extensive testing needed for race conditions specified in rfc 5407 The module paramns in my opensips.cfg look like this. loadmodule "topology_hiding.so" modparam("topology_hiding", "force_dialog", 1)modparam("topology_hiding", "th_callid_prefix", "myvoip_box1") modparam("topology_hiding", "th_passed_contact_uri_params", "account_id") modparam("topology_hiding", "th_passed_contact_params", "+mediabx1.wholevoip.se;device;caller") Looking for some answers thanks, Regards, Sammy On Tue, Nov 15, 2016 at 12:19 PM, SamyGo wrote: > Hi Razvan, > > I just noticed that since Topo hiding function gives error, the calls > using this do not show any changes in CallID or Contact or any other > details , seems like topohiding is not doing it's job for such calls > anymore. ! > > Kindly let me know of anything further required to get this resolved. > > Thanks, > Sammy. > > > > On Mon, Nov 14, 2016 at 1:30 PM, SamyGo wrote: > >> Hi Razvan, >> >> >> Here is the requested data. >> >> >> >> *INITIAL INVITE: *Via: SIP/2.0/TLS 123.123.212.123:5061;branch=z9 >> hG4bK442.8373b213.0;i=35f5 >> >> >> *200 OK from the B party as received by OpenSIPS:* >> Via: SIP/2.0/TLS 118.151.101.64:5061;branch=z9hG4bK442.9a584727.0;i=11 >> >> >> >> *200 OK as sent out by OpenSIPS:* >> Via: SIP/2.0/TLS 123.123.212.123:5061;received= >> 123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 >> Via: SIP/2.0/TLS 123.123.212.123:5061;received= >> 123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 >> >> >> Here is the portion of debug log where the destination Answers the call >> and topology Hiding restore VIA twice. >> >> http://pastebin.com/z7pt7cwM >> >> >> Thanks for your response and time looking at this for me. >> >> >> Regards, >> Sammy. >> >> >> On Nov 14, 2016 3:49 AM, "R?zvan Crainea" wrote: >> >>> Hi, Samy! >>> >>> Can you post on pastebin debugging logs related to this call? Also, can >>> you also post the Via headers of the initial INVITE and for the 200 OK >>> received by OpenSIPS? >>> >>> Best regards, >>> >>> R?zvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 11/12/2016 12:33 AM, SamyGo wrote: >>> >>> Hi, >>> >>> I'm using OpenSIPS 2.2.1 version and I'm facing a weird situation where >>> OpenSIPS is adding a duplicated VIA header to the 200 OK, This only happens >>> when I've topology_hiding() engaged into the call. >>> >>> The scenario is very simple; two users making call to each other on the >>> same OpenSIPS but with topology_hiding(). As a consequence of this double >>> VIA the caller device doesn't trigger the ACK and hence we don't get media >>> stream established between devices. >>> >>> >>> *WITH TOPOLOGYHIDING:* >>> SIP/2.0 200 OK >>> Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.X >>> X.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >>> Via: SIP/2.0/TLS 10.1.10.51:59231;received=7X.XX.XX.X7 >>> ;rport=59231;branch=z9hG4bK-607165482-63 >>> CSeq: 1 INVITE >>> ... >>> >>> >>> *WITHOUT TOPOHIDING: * >>> SIP/2.0 200 OK >>> Via: SIP/2.0/TLS 10.1.10.51:59223;received=7X.XX.XX.X7 >>> ;rport=59223;branch=z9hG4bK-607166212-58 >>> CSeq: 1 INVITE >>> >>> >>> The only difference between the two scenarios is the function >>> topology_hiding(); is commented out. >>> >>> It seems like a bug to me, can anyone guide me here validate this. >>> >>> * OpenSIPS Version:* >>> version: opensips 2.2.1 (x86_64/linux) >>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>> MAX_URI_SIZE 1024, BUF_SIZE 65535 >>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>> git revision: 68ace2e >>> main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 >>> >>> >>> Thanks, >>> Sammy >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://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: From duane.larson at gmail.com Wed Nov 16 04:58:01 2016 From: duane.larson at gmail.com (Duane Larson) Date: Tue, 15 Nov 2016 21:58:01 -0600 Subject: [OpenSIPS-Users] Does OpenSIPS support RFC 5626 (Require Outbound) Message-ID: I was doing some testing with Snom phones to try and get the phone to register to two Edge Proxies at once. With Snom you are able to configure multiple outbound proxies for a user. Snom sends a REGISTER to the first proxy without issue but the 200 response back from OpenSIPS doesn't have the following header When I read RFC 5626 I see the following is required The UAC examines successful registration responses for the *presence* * of an outbound option-tag in a Require header field value*. Presence of this option-tag indicates that the registrar is compliant with this specification, and that any edge proxies which needed to participate are also compliant. If the registrar did not support Jennings, et al. Standards Track [Page 15] ------------------------------ RFC 5626 Client-Initiated Connections in SIP October 2009 outbound, the UA has potentially registered an un-routable contact. It is the responsibility of the UA to remove any inappropriate Contacts. So the issue I see with the Snom phone is that it registers with the first Edge Proxy but doesn't send a REGISTER request to the second Edge Proxy. I figure this is because it is not seeing the "Require: outbound" in the 200 response. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duane.larson at gmail.com Wed Nov 16 06:09:58 2016 From: duane.larson at gmail.com (osiris123d) Date: Tue, 15 Nov 2016 22:09:58 -0700 (MST) Subject: [OpenSIPS-Users] Does OpenSIPS support RFC 5626 (Require Outbound) In-Reply-To: References: Message-ID: <1479272998431-7605042.post@n2.nabble.com> Nevermind Missed the part about the REGISTER request having a Loose Route In message #9, Bob's UA sends its first registration through the first edge proxy in the outbound-proxy-set *by including a loose route* *Route: * If Snom can't do that then it cannot register twice I don't think. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Does-OpenSIPS-support-RFC-5626-Require-Outbound-tp7605041p7605042.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From denis7979 at mail.ru Wed Nov 16 07:24:14 2016 From: denis7979 at mail.ru (Denis) Date: Wed, 16 Nov 2016 09:24:14 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> <589878424.20161115173447@ptl.ru> <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> Message-ID: <1537113452.20161116092414@ptl.ru> Hello, Razvan! http://pastebin.com/8crHznky mailto:denis7979 at mail.ru Hi, Denis! Could you also send the logs for INVITE? It seems like the dialog is storing a bogus Contact header. PS: please attach the logs on pastebin.com, not directly in the email. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 04:34 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In attachment. mailto:denis7979 at mail.ru Can you put on pastebin the debug logs for the ACK? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 03:44 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. I am using loadbalacer module and using only for initial INVITE. mailto:denis7979 at mail.ru You said you are doing load balancing as well. Are you doing load balancing on the ACK? What module are you using (dispatcher, loadbalancer, etc.)? Load balancing functions can change the R-URI. Ben Newlin From: on behalf of Denis Reply-To: OpenSIPS users mailling list Date: Tuesday, November 15, 2016 at 8:19 AM To: R?zvan Crainea , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: From miha at softnet.si Wed Nov 16 08:11:45 2016 From: miha at softnet.si (Miha) Date: Wed, 16 Nov 2016 08:11:45 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> Message-ID: <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> Hello Bogdan yes this was the case... thank you! br miha On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: > Hi Miha, > > When you handle REGISTER requests (from behind NAT) most probably you > use fix_nated_contact() instead of fix_nated_register(). > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 15.11.2016 09:11, Miha wrote: >> Hello >> >> i need one info. >> I have one phone behind NAT and it is registered on OpenSIPS. IN >> register packet, which is send to OpenSIPS I can see contact: >> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >> >> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >> >> >> When opensips sends INVITE it send to right public ip and right port >> (source ip and source port generated by router). The issue is this: >> Invite is like: "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" >> and this request is then fw to this UAC behind router. The UAC >> replays to this INVITE with 404 Not found as it is waiting to receive >> the same URI which was written in contact (the userpart is ok, put >> the ip is public, not private and this is the issue).From what I can >> see in RFC this is the case. >> >> >> Till now Idid not have any issues with this, but now I found first >> phone which replays with 404 and from RFC point of view there should >> be private ip request :) . So is there anything I can do :)? >> >> >> tnx >> miha >> >> >> _______________________________________________ >> 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: From denis7979 at mail.ru Wed Nov 16 10:51:18 2016 From: denis7979 at mail.ru (Denis) Date: Wed, 16 Nov 2016 12:51:18 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <1547235528.20161116121830@ptl.ru> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> <589878424.20161115173447@ptl.ru> <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> <1547235528.20161116121830@ptl.ru> Message-ID: <1421027473.20161116125118@ptl.ru> Razvan, all logs here https://cloud.mail.ru/public/MtcT/r3p7mRkhF mailto:denis7979 at mail.ru Razvan, i found the problem (there was in reply_route, where i have done fix_nated_contact()). This problem is closed. But, unfortunately, i still cannot make successful call, and i want to ask you to analyze the new problem it this branch. The next problem appears in Opensis proxy (we have the same scheme). In attachment you can see a call log (trace3) and a log from syslog (trace4). All logs from Opensips proxy (3.3.3.3). Opensips proxy is the main proxy in my SIP network, while Opensips with tophiding (1.1.1.1) is a new instance. Opensips proxy serves many calls and i didn`t see such problem before. I want to notice you on callid in 183 and 200 code, received from PSTN GW. It is changed by Opensips proxy for unknown reason. Thank you for any help. mailto:denis7979 at mail.ru Hi, Denis! Could you also send the logs for INVITE? It seems like the dialog is storing a bogus Contact header. PS: please attach the logs on pastebin.com, not directly in the email. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 04:34 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In attachment. mailto:denis7979 at mail.ru Can you put on pastebin the debug logs for the ACK? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 03:44 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. I am using loadbalacer module and using only for initial INVITE. mailto:denis7979 at mail.ru You said you are doing load balancing as well. Are you doing load balancing on the ACK? What module are you using (dispatcher, loadbalancer, etc.)? Load balancing functions can change the R-URI. Ben Newlin From: on behalf of Denis Reply-To: OpenSIPS users mailling list Date: Tuesday, November 15, 2016 at 8:19 AM To: R?zvan Crainea , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: From denis7979 at mail.ru Wed Nov 16 10:58:14 2016 From: denis7979 at mail.ru (Denis) Date: Wed, 16 Nov 2016 12:58:14 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <1421027473.20161116125118@ptl.ru> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> <589878424.20161115173447@ptl.ru> <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> <1547235528.20161116121830@ptl.ru> <1421027473.20161116125118@ptl.ru> Message-ID: <312260284.20161116125814@ptl.ru> And a version of Opensips proxy - Server:: OpenSIPS (2.2.1 (x86_64/linux)). mailto:denis7979 at mail.ru Razvan, all logs here https://cloud.mail.ru/public/MtcT/r3p7mRkhF mailto:denis7979 at mail.ru Razvan, i found the problem (there was in reply_route, where i have done fix_nated_contact()). This problem is closed. But, unfortunately, i still cannot make successful call, and i want to ask you to analyze the new problem it this branch. The next problem appears in Opensis proxy (we have the same scheme). In attachment you can see a call log (trace3) and a log from syslog (trace4). All logs from Opensips proxy (3.3.3.3). Opensips proxy is the main proxy in my SIP network, while Opensips with tophiding (1.1.1.1) is a new instance. Opensips proxy serves many calls and i didn`t see such problem before. I want to notice you on callid in 183 and 200 code, received from PSTN GW. It is changed by Opensips proxy for unknown reason. Thank you for any help. mailto:denis7979 at mail.ru Hi, Denis! Could you also send the logs for INVITE? It seems like the dialog is storing a bogus Contact header. PS: please attach the logs on pastebin.com, not directly in the email. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 04:34 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In attachment. mailto:denis7979 at mail.ru Can you put on pastebin the debug logs for the ACK? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 03:44 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. I am using loadbalacer module and using only for initial INVITE. mailto:denis7979 at mail.ru You said you are doing load balancing as well. Are you doing load balancing on the ACK? What module are you using (dispatcher, loadbalancer, etc.)? Load balancing functions can change the R-URI. Ben Newlin From: on behalf of Denis Reply-To: OpenSIPS users mailling list Date: Tuesday, November 15, 2016 at 8:19 AM To: R?zvan Crainea , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: From bogdan at opensips.org Wed Nov 16 13:46:19 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 16 Nov 2016 14:46:19 +0200 Subject: [OpenSIPS-Users] Does OpenSIPS support RFC 5626 (Require Outbound) In-Reply-To: <1479272998431-7605042.post@n2.nabble.com> References: <1479272998431-7605042.post@n2.nabble.com> Message-ID: Hi Duane, Not sure if the Route hdr is a real must - this is a preloaded Route just in enforce the routing to EP1 (in this case). This hdr will be consumed by the Edge Proxy - it will not be visible to the registrar. As time as the UAC sends the REGISTER to the address of EP1, the Route hdr is not really needed, IMHO. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 16.11.2016 07:09, osiris123d wrote: > Nevermind > > Missed the part about the REGISTER request having a Loose Route > > In message #9, Bob's UA sends its first registration through the > first edge proxy in the outbound-proxy-set *by including a loose > route* > > *Route: * > > If Snom can't do that then it cannot register twice I don't think. > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Does-OpenSIPS-support-RFC-5626-Require-Outbound-tp7605041p7605042.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Wed Nov 16 15:17:50 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 16 Nov 2016 16:17:50 +0200 Subject: [OpenSIPS-Users] Strange behavior with BYE message on Opensips 2.1 In-Reply-To: <582C60D7.6010505@openip.fr> References: <582B41E9.7000008@openip.fr> <60e977f8-6fb2-ab71-01d9-c33061eba1b7@opensips.org> <582C60D7.6010505@openip.fr> Message-ID: <71c45603-ff7b-d349-32c4-b14c802cef35@opensips.org> Hi Guillaume, You need to keep in mind that the fix_nated_contact() should be done (usually) for replies coming from users (potentially behind a NAT). You should not do it for traffic coming from other SIP servers. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 16.11.2016 15:36, guillaume Montassier wrote: > Hi Bogdan, > > Thank you for your answer. > You were right, our SBC was sending us a broken BYE. > > Thank you for your enlightenment, it really save me this time. > > Guillaume, > > > On 15/11/2016 18:33, Bogdan-Andrei Iancu wrote: >> Hi Guillaume, >> >> The incoming BYE is broken - the IP of your OpenSIPS can be found >> both in RURI and in the top Route header. As the IP is found in RURI >> makes OpenSIPS think that the previous hop was a strict router. and >> this leads to the infinite loop. >> >> Looking at it, I see the typical mistake of doing a >> fix_nated_contact() and overwriting the original contact URI in the >> 200 OK for INVITE (this contact is used as part of the routing set >> for routing back sequential requests like BYE) >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 15.11.2016 19:12, guillaume Montassier wrote: >>> Hello all, >>> >>> I'm working a project with multiples opensips (each handling a >>> particular role). >>> So when an invite goes in our plateform, it crosse multiples openips >>> and can even sometime go though a specific opensips multiples times. >>> My problem is: When the called send a BYE I have a strange behavior. >>> One of my opensips which receive the BYE resend it to itself and >>> suppress the wrong route (last route instead of the first route...). >>> >>> - For example this is the BYE message my opensips receive : >>> >>> 2016/11/15 15:24:08.316573*172.99.37.70:5060* -> *172.99.37.52:5060* >>> BYE sip:*test2-o36onlarnncrd at 172.99.37.52:5060*;transport=udp SIP/2.0 >>> Route: >>> =>*itself* >>> Route: >>> =>*Next hope* >>> Route: >>> Route: >>> Route: >>> Route: >>> Route: >>> >>> >>> - This is what I should have as result (It remove itself from the >>> Route header and send the BYE to the next hop (which is >>> 172.99.37.52:5061) ): >>> >>> 2016/11/15 15:24:08.316573 *172.99.37.52:5060* -> >>> *172.99.37.52:5061* =>*Send to >>> Next hope* >>> BYE sip:test2-o36onlarnncrd at 172.99.37.52:5060;transport=udp SIP/2.0 >>> *Route*: >>> >>> =>*Next hope is the first route header* >>> Route: >>> Route: >>> Route: >>> Route: >>> Route: >>> >>> >>> - This is what I have (send to itself and remove the wrong route...): >>> >>> 2016/11/15 15:24:08.316573 *172.99.37.52:5060* -> >>> *172.99.37.52:5060* =>*send to >>> itself* >>> BYE*sip:172.99.37.52:5060*;transport=udp SIP/2.0 >>> =>*modify bye?* >>> *Route*: >>> =>*don't supress the route header* >>> Route: >>> Route: >>> Route: >>> Route: >>> Route: >>> =>*The last route is suppress* >>> >>> >>> I know that my first header route is the same than my last header >>> route, and maybe this is why I have this beavior, but this seems >>> really odd to me. >>> >>> Thank you all, >>> >>> /Guillaume >>> >>> >>> _______________________________________________ >>> 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: From fosdem-rtc-admin at freertc.org Wed Nov 16 14:20:15 2016 From: fosdem-rtc-admin at freertc.org (FOSDEM RTC Team) Date: Wed, 16 Nov 2016 14:20:15 +0100 (CET) Subject: [OpenSIPS-Users] [CFP] reminder! FOSDEM RTC dev-room talks: deadline tomorrow Message-ID: <20161116132015.25D7432515@daniel1.office.readytechnology.co.uk> Reminder: speaker's deadline tomorrow, 17 November at 23:59 UTC The Free RTC dev-room has already received some really exciting talk proposals but there is still time for people to propose talks or encourage friends or colleagues to speak. Many other dev-rooms also have a deadline in the next few days and if your topic is applicable to more than one dev-room, you are welcome to make more than one submission. Please contact us or put a note in the memo field at the top of the talk proposal if you do that. All projects are encouraged to consider making a lightning talk too, it is an excellent opportunity to get exposure for your project: even though you only have 15 minutes, it can be a much larger and more diverse audience than in some dev-rooms. For full details, please see the original call for participation: https://danielpocock.com/fosdem-2017-rtc-cfp We invite all potential speakers and participants to discuss the selection process and other aspects of FOSDEM on the Free-RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc From razvan at opensips.org Wed Nov 16 17:39:53 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 16 Nov 2016 18:39:53 +0200 Subject: [OpenSIPS-Users] Topology_Hiding adding extra VIA header In-Reply-To: References: <48d902c6-d1f5-5b9f-28cd-9b5558db8c44@opensips.org> Message-ID: <3262abd8-120b-bb1e-641d-587f561db2ea@opensips.org> Hi, Sammy! Most likely that WIP refers to the re-invites generated for pinging purposes. Are you using the "R/r" flags for the create_dialog() function? Best regards, R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 11/15/2016 09:56 PM, SamyGo wrote: > Hi Again, > > Is this related to the "/Work Still in progress"/ related to > Topology_hiding module as mentioned here at changelog: > > http://opensips.org/pub/opensips/2.2.2/ChangeLog > > 2015-10-14 Vlad Paiu > * [c0f25f7] : > > Added Re-INVITE in-dialog pinging support > Controlled via the new "R" and "r" flags available to create_dialog() as well as the new reinvite_ping_interval module param > > Work still in progress : > - Properly handle late negociation between endpoints > - Ensure SDP persistency ( DB and BIN replication ) > - Ensure compatibility with topology hiding ( currently the Contact header > will be bogus when doing TH ) > - Whitelist or blacklist logic ( terminate call for 481 and 408 timeout, or terminate call for anything else other than 200 and 491 ) > - Extensive testing needed for race conditions specified in rfc 5407 > > The module paramns in my opensips.cfg look like this. > > loadmodule "topology_hiding.so" modparam("topology_hiding", > "force_dialog", 1) modparam("topology_hiding", "th_callid_prefix", "myvoip_box1") > modparam("topology_hiding", "th_passed_contact_uri_params", "account_id") > modparam("topology_hiding", "th_passed_contact_params", "+mediabx1.wholevoip.se ;device;caller") > > Looking for some answers thanks, > > Regards, > Sammy > > > On Tue, Nov 15, 2016 at 12:19 PM, SamyGo > wrote: > > Hi Razvan, > > I just noticed that since Topo hiding function gives error, the > calls using this do not show any changes in CallID or Contact or any > other details , seems like topohiding is not doing it's job for such > calls anymore. ! > > Kindly let me know of anything further required to get this resolved. > > Thanks, > Sammy. > > > > On Mon, Nov 14, 2016 at 1:30 PM, SamyGo > wrote: > > Hi Razvan, > > > Here is the requested data. > > > *INITIAL INVITE: > *Via: SIP/2.0/TLS > 123.123.212.123:5061;branch=z9hG4bK442.8373b213.0;i=35f5 > > * > * > *200 OK from the B party as received by OpenSIPS: > * > Via: SIP/2.0/TLS > 118.151.101.64:5061;branch=z9hG4bK442.9a584727.0;i=11 > > > *200 OK as sent out by OpenSIPS: > * > Via: SIP/2.0/TLS > 123.123.212.123:5061;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > Via: SIP/2.0/TLS > 123.123.212.123:5061;received=123.123.212.123;rport=48664;branch=z9hG4bK442.8373b213.0;i=35f5 > > > Here is the portion of debug log where the destination Answers > the call and topology Hiding restore VIA twice. > > http://pastebin.com/z7pt7cwM > > > Thanks for your response and time looking at this for me. > > > Regards, > Sammy. > > > On Nov 14, 2016 3:49 AM, "R?zvan Crainea" > wrote: > > Hi, Samy! > > Can you post on pastebin debugging logs related to this > call? Also, can you also post the Via headers of the initial > INVITE and for the 200 OK received by OpenSIPS? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/12/2016 12:33 AM, SamyGo wrote: >> Hi, >> >> I'm using OpenSIPS 2.2.1 version and I'm facing a weird >> situation where OpenSIPS is adding a duplicated VIA header >> to the 200 OK, This only happens when I've >> topology_hiding() engaged into the call. >> >> The scenario is very simple; two users making call to each >> other on the same OpenSIPS but with topology_hiding(). As >> a consequence of this double VIA the caller device doesn't >> trigger the ACK and hence we don't get media stream >> established between devices. >> >> >> *WITH TOPOLOGYHIDING:* >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS >> 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >> Via: SIP/2.0/TLS >> 10.1.10.51:59231;received=7X.XX.XX.X7;rport=59231;branch=z9hG4bK-607165482-63 >> CSeq: 1 INVITE >> ... >> >> *WITHOUT TOPOHIDING: >> * >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS >> 10.1.10.51:59223;received=7X.XX.XX.X7;rport=59223;branch=z9hG4bK-607166212-58 >> CSeq: 1 INVITE >> >> >> The only difference between the two scenarios is the >> function topology_hiding(); is commented out. >> >> It seems like a bug to me, can anyone guide me here >> validate this. >> * >> OpenSIPS Version:* >> version: opensips 2.2.1 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, >> PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, >> MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, >> select. >> git revision: 68ace2e >> main.c compiled on 18:34:37 Sep 28 2016 with gcc 4.8 >> >> >> Thanks, >> Sammy >> >> >> >> >> >> _______________________________________________ >> 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 > From razvan at opensips.org Wed Nov 16 18:25:42 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 16 Nov 2016 19:25:42 +0200 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <312260284.20161116125814@ptl.ru> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> <589878424.20161115173447@ptl.ru> <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> <1547235528.20161116121830@ptl.ru> <1421027473.20161116125118@ptl.ru> <312260284.20161116125814@ptl.ru> Message-ID: <9b9e7709-1dfb-bab4-5e40-e1404fe2a851@opensips.org> Hi, Denis! Do you have the topology_hiding module loaded on the OpenSIPS Proxy? Can you remove it? My assumption is that OpenSIPS thinks you are trying to use topology hiding, and he is mangling the CallID (because he "sees" the marker in there). Alternatively, you could change the topo hiding marker to something else[1]. [1] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html#id249610 Best regards, R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 11/16/2016 11:58 AM, Denis wrote: > And a version of Opensips proxy - Server:: OpenSIPS (2.2.1 (x86_64/linux)). > > mailto:denis7979 at mail.ru > > > Razvan, all logs here > https://cloud.mail.ru/public/MtcT/r3p7mRkhF > > mailto:denis7979 at mail.ru > > > Razvan, i found the problem (there was in reply_route, where i have > done fix_nated_contact()). This problem is closed. > But, unfortunately, i still cannot make successful call, and i want to > ask you to analyze the new problem it this branch. > > The next problem appears in Opensis proxy (we have the same scheme). > In attachment you can see a call log (trace3) and a log from syslog > (trace4). All logs from Opensips proxy (3.3.3.3). > Opensips proxy is the main proxy in my SIP network, while Opensips with > tophiding (1.1.1.1) is a new instance. > Opensips proxy serves many calls and i didn`t see such problem before. > > I want to notice you on callid in 183 and 200 code, received from PSTN > GW. It is changed by Opensips proxy for unknown reason. > > Thank you for any help. > > mailto:denis7979 at mail.ru > > > Hi, Denis! > > Could you also send the logs for INVITE? It seems like the dialog is > storing a bogus Contact header. > > PS: please attach the logs on pastebin.com, not directly in the email. > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/15/2016 04:34 PM, Denis wrote: > > Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In attachment. > > mailto:denis7979 at mail.ru > > > Can you put on pastebin the debug logs for the ACK? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/15/2016 03:44 PM, Denis wrote: > > Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. > > I am using loadbalacer module and using only for initial INVITE. > > mailto:denis7979 at mail.ru > > > You said you are doing load balancing as well. Are you doing load > balancing on the ACK? What module are you using (dispatcher, > loadbalancer, etc.)? > > Load balancing functions can change the R-URI. > > > Ben Newlin > > *From: * > on behalf of Denis > > *Reply-To: *OpenSIPS users mailling list > > *Date: *Tuesday, November 15, 2016 at 8:19 AM > *To: *R?zvan Crainea , > OpenSIPS users mailling list > > *Subject: *Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding > > Hello, Razvan! > > No, i don`t make any modification for that variables > > " if (match_dialog() || topology_hiding_match()) { > > if (!$DLG_status == NULL) { > xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, > FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); > force_rport(); > route(1); > exit; > } > > }" > > The information from a syslog. > > "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, > CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, > FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = > sip:3364021 at 3.3.3.3:5068/3.3.3.3 " > > mailto:denis7979 at mail.ru > > Hi, Denis! > > Are you modifying the $ru/$rd variables anyhwere in your script for that > ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: > ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. > However, it should be: > ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. > > Can you try printing the $ru variable just after the > topology_hiding_match() function? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/15/2016 02:22 PM, Denis wrote: > > Opensips 2.2.2 and top hiding Hello! > > I try to make top hiding using topology_hiding module. > In attachment you can find a log of unsuccessful call. > > Scheme of the call > > SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another > Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. > > As i understand, the problem is that Opensips proxy cannot send ACK (on > 200 OK) to PSTN GW because RURI and Route header has similar IP, namely > 3.3.3.3. > > I am using "topology_hiding("C");" function for top hiding. > > The call log was gathered from 1.1.1.1 > > Thank you for any help. > > P.S. On 1.1.1.1 i also try to make load balancing. > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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 > From y at jettel.ru Thu Nov 17 00:00:27 2016 From: y at jettel.ru (Ehrny) Date: Wed, 16 Nov 2016 23:00:27 +0000 Subject: [OpenSIPS-Users] $ai transformation References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> Dear R?zvan, Thanks again for the prompt help. I was able to change the headers as needed but I?m stuck with another problem( I?ve got opensips with two Ethernet adapters, eth1 as a private and another one eth0 as public. Opensips works fine when the call is coming on the public eth0 and leaves opensips through the same public adapter. (All the GWs are behind that public eth0 instead of one ). The problem happens when the call comes in through the private eth1, please see the drawing in attachment. - sip1. After I?ve got invite from provider on the private eth1 , I send it through the public eth0. - sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the call to be able to pass through the opensips and come back from external GW (x.x.82.139). I also change SIP Request's URI and use uac_replace_to () to change these fields as needed. - sip4. Opensips has got 180 Ringing from external GW (x.x.82.139) - sip5. Opensips tries to send it back to originator (10.250.242.74) which is behind private NIC eth0 (10.197.26.170) the call can not be set up because I send reply from my public eth1 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.250.242.74:5060;branch=z9hG4bKqci5ec Record-Route: > Record-Route: > From: sip:300940 at domain.com;tag=2F81324631 To: sip:300905 at domain.com:5060;tag=231469dIr894 Call-ID: 020A3EA03A8 at SFESIP4-id1-ext CSeq: 1 INVITE Contact: I?m not sure if I do it right way because the packet (sip5) goes to 10.250.242.74 with the source ip of public eth0 and not the one it should pass through to be able to come back. What is the right way in my case to get the call through? Thank you for all of your help, Regards, Ehrny -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2016-11-17_1-42-56-5.jpg Type: image/jpeg Size: 14896 bytes Desc: 2016-11-17_1-42-56-5.jpg URL: From denis7979 at mail.ru Thu Nov 17 07:49:41 2016 From: denis7979 at mail.ru (Denis) Date: Thu, 17 Nov 2016 09:49:41 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <9b9e7709-1dfb-bab4-5e40-e1404fe2a851@opensips.org> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> <589878424.20161115173447@ptl.ru> <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> <1547235528.20161116121830@ptl.ru> <1421027473.20161116125118@ptl.ru> <312260284.20161116125814@ptl.ru> <9b9e7709-1dfb-bab4-5e40-e1404fe2a851@opensips.org> Message-ID: <59519751.20161117094941@ptl.ru> Hello, Razvan! Yes i am using top. hiding on proxy. I understand, thank you! mailto:denis7979 at mail.ru > Hi, Denis! > Do you have the topology_hiding module loaded on the OpenSIPS Proxy? Can > you remove it? My assumption is that OpenSIPS thinks you are trying to > use topology hiding, and he is mangling the CallID (because he "sees" > the marker in there). > Alternatively, you could change the topo hiding marker to something else[1]. > [1] > http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html#id249610 > Best regards, > R?zvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > On 11/16/2016 11:58 AM, Denis wrote: >> And a version of Opensips proxy - Server:: OpenSIPS (2.2.1 (x86_64/linux)). >> >> mailto:denis7979 at mail.ru >> >> >> Razvan, all logs here >> https://cloud.mail.ru/public/MtcT/r3p7mRkhF >> >> mailto:denis7979 at mail.ru >> >> >> Razvan, i found the problem (there was in reply_route, where i have >> done fix_nated_contact()). This problem is closed. >> But, unfortunately, i still cannot make successful call, and i want to >> ask you to analyze the new problem it this branch. >> >> The next problem appears in Opensis proxy (we have the same scheme). >> In attachment you can see a call log (trace3) and a log from syslog >> (trace4). All logs from Opensips proxy (3.3.3.3). >> Opensips proxy is the main proxy in my SIP network, while Opensips with >> tophiding (1.1.1.1) is a new instance. >> Opensips proxy serves many calls and i didn`t see such problem before. >> >> I want to notice you on callid in 183 and 200 code, received from PSTN >> GW. It is changed by Opensips proxy for unknown reason. >> >> Thank you for any help. >> >> mailto:denis7979 at mail.ru >> >> >> Hi, Denis! >> >> Could you also send the logs for INVITE? It seems like the dialog is >> storing a bogus Contact header. >> >> PS: please attach the logs on pastebin.com, not directly in the email. >> >> Best regards, >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> On 11/15/2016 04:34 PM, Denis wrote: >> >> Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In attachment. >> >> mailto:denis7979 at mail.ru >> >> >> Can you put on pastebin the debug logs for the ACK? >> >> Best regards, >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> On 11/15/2016 03:44 PM, Denis wrote: >> >> Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. >> >> I am using loadbalacer module and using only for initial INVITE. >> >> mailto:denis7979 at mail.ru >> >> >> You said you are doing load balancing as well. Are you doing load >> balancing on the ACK? What module are you using (dispatcher, >> loadbalancer, etc.)? >> >> Load balancing functions can change the R-URI. >> >> >> Ben Newlin >> >> *From: * >> on behalf of Denis >> >> *Reply-To: *OpenSIPS users mailling list >> >> *Date: *Tuesday, November 15, 2016 at 8:19 AM >> *To: *R?zvan Crainea , >> OpenSIPS users mailling list >> >> *Subject: *Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding >> >> Hello, Razvan! >> >> No, i don`t make any modification for that variables >> >> " if (match_dialog() || topology_hiding_match()) { >> >> if (!$DLG_status == NULL) { >> xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, >> FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); >> force_rport(); >> route(1); >> exit; >> } >> >> }" >> >> The information from a syslog. >> >> "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, >> CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, >> FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = >> sip:3364021 at 3.3.3.3:5068/3.3.3.3 " >> >> mailto:denis7979 at mail.ru >> >> Hi, Denis! >> >> Are you modifying the $ru/$rd variables anyhwere in your script for that >> ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: >> ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. >> However, it should be: >> ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. >> >> Can you try printing the $ru variable just after the >> topology_hiding_match() function? >> >> Best regards, >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> On 11/15/2016 02:22 PM, Denis wrote: >> >> Opensips 2.2.2 and top hiding Hello! >> >> I try to make top hiding using topology_hiding module. >> In attachment you can find a log of unsuccessful call. >> >> Scheme of the call >> >> SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another >> Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. >> >> As i understand, the problem is that Opensips proxy cannot send ACK (on >> 200 OK) to PSTN GW because RURI and Route header has similar IP, namely >> 3.3.3.3. >> >> I am using "topology_hiding("C");" function for top hiding. >> >> The call log was gathered from 1.1.1.1 >> >> Thank you for any help. >> >> P.S. On 1.1.1.1 i also try to make load balancing. >> >> mailto:denis7979 at mail.ru >> >> _______________________________________________ >> 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: From denis7979 at mail.ru Thu Nov 17 08:11:50 2016 From: denis7979 at mail.ru (Denis) Date: Thu, 17 Nov 2016 10:11:50 +0300 Subject: [OpenSIPS-Users] Memory free problem Message-ID: <1024256996.20161117101150@ptl.ru> Hello! Today i have a temporary problem with out of free memory (about 4 minutes). Unfortunately, i noticed the problem when everything became fine, so i didn`t make standard procedure of detecting problems with memory which has been described in documentation. In syslog i see such sequence of events. Before the first message about out of free memory "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes left), please increase the "-m" command line parameter!" i see many messages "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c531c95f0 [3855:951170645] with clid '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1' and tags '96x8v2xkj9of92j' '332693C-EF5'" "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c4735d130 [4072:1150064691] with clid 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2' and tags '1czw3nbhw632pzn' '3326728-1DC1'" dialing with two callid. The question is, can such Warning influence on shm. allocation? Thank you for any help. mailto:denis7979 at mail.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.putyato at ptl.ru Thu Nov 10 15:28:31 2016 From: d.putyato at ptl.ru (=?windows-1251?B?xOXt6PEgz/Py//Lu?=) Date: Thu, 10 Nov 2016 17:28:31 +0300 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> Message-ID: <109788976.20161110172831@ptl.ru> Hello, Liviu! Thank you for your answer. About 2) "Calls per minute" - ok, but what about other parameters? For example, "total calls"? Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. If in Mon user makes 25 calls, on Tue since 09:00 counts of "total calls" begin from 0 or 25? -- ? ?????????, ?????? ?????, ???????????? ?????? ????????? ?? "???????" ???.: 8123364000, ???.244 199178, ?????-?????????, ???.?.????????, ?.19/21 ???.? www.ptl.ru mailto:d.putyato at ptl.ru Hi, Deniz! Answers below. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 15:18, Denis wrote: Re: Fraud_detection modul Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? Same prefix, taken from the fraud detection rule 2) At the beginning of the next period, a counts of events begin 0? The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. 3) is there any method to reset counts of events for certain user? Currently there is no way of doing this. 4) what is the value used to calculate duration in fraud_module, minutes or seconds? It should be "seconds", I will fix the misleading example in the tutorial. ______________________________________________ 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: From denis7979 at mail.ru Fri Nov 11 08:38:55 2016 From: denis7979 at mail.ru (Denis) Date: Fri, 11 Nov 2016 10:38:55 +0300 Subject: [OpenSIPS-Users] Fraud_detection module In-Reply-To: References: <1526240772.20161110152725@ptl.ru> <714079455.20161110161807@ptl.ru> <109788976.20161110172831@ptl.ru> <136401369.20161110172927@ptl.ru> Message-ID: <216131351.20161111103855@ptl.ru> Hello, Liviu! OK, thank you. Additionally i will ask you to analyze one case. In attachment you can find a log of calls, which were made by one user some time ago (with the number 1234567). It`s a fraud. Also i attached a piece of opensips.cfg related to a fraud detection (see script.txt). When critical event triggered Opensips sends email to some address (see script.txt). As you can see in the call log, fraud began at 01:40 2016-10-01. Value of the field "sip_reason" "fraud_detected" means that fraud_module detects the fraud and a call was discarded by script logging (see script.txt) First email about that i received at 01:41 with fraud param " calls per minute". Next email i received only at 11:08 with fraud param "total calls". Between these two time stamps i have no emails about fraud, and as you can see from the call log, there were many successful calls in this period with "big" duration. Fraud_detection table had such content: profileid = 1 prefix = 810 start_hour = 00:00 end_hour = 23:59 daysoftheweek = Mon-Sun cpm_critical = 6 call_duration_critical = 3600 tatal_calls_critical = 30 concurant_calls_critical = 30 sequential_calls_critical = 5000 The questions is: - Why module didn`t detect fraud based on "call duration"? Thank you. mailto:denis7979 at mail.ru Upon looking through the source code, it seems that calls_per_min / total_calls / concurrent_calls are also reset to 0 every time a new rule is matched, or if the day has changed since we last matched the current rule. I will make sure this info ^ is more easily accessible: either in a new tutorial section or the module doc. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 16:29, Denis wrote: Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu! Thank you for your answer. About 2) "Calls per minute" - ok, but what about other parameters? For example, "total calls"? Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30. If in Mon user makes 25 calls, on Tue since 09:00 counts of "total calls" begin from 0 or 25? mailto:denis7979 at mail.ru Hi, Deniz! Answers below. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10.11.2016 15:18, Denis wrote: Re: Fraud_detection modul Hello! Opensips 2.2.1 A couple of questions about fraud_detection: 1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix? Same prefix, taken from the fraud detection rule 2) At the beginning of the next period, a counts of events begin 0? The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. 3) is there any method to reset counts of events for certain user? Currently there is no way of doing this. 4) what is the value used to calculate duration in fraud_module, minutes or seconds? It should be "seconds", I will fix the misleading example in the tutorial. ______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: fraud.xls Type: application/vnd.ms-excel Size: 61440 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: script.txt URL: From denis7979 at mail.ru Wed Nov 16 10:18:30 2016 From: denis7979 at mail.ru (Denis) Date: Wed, 16 Nov 2016 12:18:30 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In-Reply-To: <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> References: <1681910255.20161115152201@ptl.ru> <7ad9a7b4-bc6c-e4ef-be79-fb97c20c675e@opensips.org> <1084147120.20161115161903@ptl.ru> <1986770232.20161115164407@ptl.ru> <589878424.20161115173447@ptl.ru> <675f3d09-3b70-608b-668d-1f5d67eb10c6@opensips.org> Message-ID: <1547235528.20161116121830@ptl.ru> Razvan, i found the problem (there was in reply_route, where i have done fix_nated_contact()). This problem is closed. But, unfortunately, i still cannot make successful call, and i want to ask you to analyze the new problem it this branch. The next problem appears in Opensis proxy (we have the same scheme). In attachment you can see a call log (trace3) and a log from syslog (trace4). All logs from Opensips proxy (3.3.3.3). Opensips proxy is the main proxy in my SIP network, while Opensips with tophiding (1.1.1.1) is a new instance. Opensips proxy serves many calls and i didn`t see such problem before. I want to notice you on callid in 183 and 200 code, received from PSTN GW. It is changed by Opensips proxy for unknown reason. Thank you for any help. mailto:denis7979 at mail.ru Hi, Denis! Could you also send the logs for INVITE? It seems like the dialog is storing a bogus Contact header. PS: please attach the logs on pastebin.com, not directly in the email. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 04:34 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding In attachment. mailto:denis7979 at mail.ru Can you put on pastebin the debug logs for the ACK? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 03:44 PM, Denis wrote: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello Ben. I am using loadbalacer module and using only for initial INVITE. mailto:denis7979 at mail.ru You said you are doing load balancing as well. Are you doing load balancing on the ACK? What module are you using (dispatcher, loadbalancer, etc.)? Load balancing functions can change the R-URI. Ben Newlin From: on behalf of Denis Reply-To: OpenSIPS users mailling list Date: Tuesday, November 15, 2016 at 8:19 AM To: R?zvan Crainea , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips 2.2.2 and top hiding Hello, Razvan! No, i don`t make any modification for that variables " if (match_dialog() || topology_hiding_match()) { if (!$DLG_status == NULL) { xlog("L_INFO", "Route0:$rm was received (IPS=$si, IPD=$rd, CALLID=$ci, FROMTAG=$ft, TOTAG=$tt, AUTH=$au) and RURI = $ru/$rd"); force_rport(); route(1); exit; } }" The information from a syslog. "Route0:ACK was received (IPS=2.2.2.2, IPD=3.3.3.3, CALLID=82158NWE4MmU0NmJiZDU2MzA4OWM1MGFiZjU1Zjg2YTA4NWM, FROMTAG=b83b533d, TOTAG=6A3BE0-1AA9, AUTH=) and RURI = sip:3364021 at 3.3.3.3:5068/3.3.3.3" mailto:denis7979 at mail.ru Hi, Denis! Are you modifying the $ru/$rd variables anyhwere in your script for that ACK? I am seeing the R-URI of the ACK going to 3.3.3.3:5068: ACK sip:3364021 at 3.3.3.3:5068 SIP/2.0. However, it should be: ACK sip:3364021 at 4.4.4.4:5060 SIP/2.0. Can you try printing the $ru variable just after the topology_hiding_match() function? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/15/2016 02:22 PM, Denis wrote: Opensips 2.2.2 and top hiding Hello! I try to make top hiding using topology_hiding module. In attachment you can find a log of unsuccessful call. Scheme of the call SIP UA (2.2.2.2) -> Opensips with top hiding (1.1.1.1) -> another Opensis proxy (3.3.3.3) - > PSTN GW (4.4.4.4) -> PSTN. As i understand, the problem is that Opensips proxy cannot send ACK (on 200 OK) to PSTN GW because RURI and Route header has similar IP, namely 3.3.3.3. I am using "topology_hiding("C");" function for top hiding. The call log was gathered from 1.1.1.1 Thank you for any help. P.S. On 1.1.1.1 i also try to make load balancing. mailto:denis7979 at mail.ru _______________________________________________ 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: trace3.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: trace4.txt URL: From y at jettel.ru Wed Nov 16 23:29:57 2016 From: y at jettel.ru (Ehrny) Date: Wed, 16 Nov 2016 22:29:57 +0000 Subject: [OpenSIPS-Users] $ai transformation References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788A3E13@JET-EX02.jettel.ru> Dear R?zvan, Thanks again for the prompt help. I was able to change the headers as needed but I?m stuck with another problem( I?ve got opensips with two Ethernet adapters, eth1 as a private and another one eth0 as public. Opensips works fine when the call is coming on the public eth0 and leaves opensips through the same public adapter. (All the GWs are behind that public eth0 instead of one ). The problem happens when the call comes in through the private eth1, please see the drawing in attachment. - sip1. After I?ve got invite from provider on the private eth1 , I send it through the public eth0. - sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the call to be able to pass through the opensips and come back from external GW (x.x.82.139). I also change SIP Request's URI and use uac_replace_to () to change these fields as needed. - sip4. Opensips has got 180 Ringing from external GW (x.x.82.139) - sip5. Opensips tries to send it back to originator (10.250.242.74) which is behind private NIC eth0 (10.197.26.170) the call can not be set up because I send reply from my public eth1 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.250.242.74:5060;branch=z9hG4bKqci5ec Record-Route: > Record-Route: > From: sip:300940 at domain.com;tag=2F81324631 To: sip:300905 at domain.com:5060;tag=231469dIr894p0D461D0t66 Call-ID: 020A3EA03A8 at SFESIP4-id1-ext CSeq: 1 INVITE Contact: I?m not sure if I do it right way because the packet (sip5) goes to 10.250.242.74 with the source ip of public eth0 and not the one it should pass through to be able to come back. What is the right way in my case to get the call through? Thank you for all of your help, Regards, Ehrny -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2016-11-16.jpg Type: image/jpeg Size: 27645 bytes Desc: 2016-11-16.jpg URL: From miha at softnet.si Thu Nov 17 11:13:37 2016 From: miha at softnet.si (Miha) Date: Thu, 17 Nov 2016 11:13:37 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> Message-ID: <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> Hello Bogdan i changed this and it works in all cases, only in one I noticed today this (Opensips reply only in this case with two URI on contact): UAC:5060 ->OpenSIPS:5060 REGISTER sip:opsp.test.net:5060 SIP/2.0. Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. Max-Forwards: 70. From: 042335040 ;tag=1f62205074. To: 042335040 . Call-ID: 61c67f739bef5a2e. CSeq: 1804289391 REGISTER. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, INFO. Authorization: Digest username="99942335040",realm="opsp.test.net",nonce="582d810c000058b d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res ponse="bc0c757c17f9b0976af35ec633dd83ca". Contact: 042335040 ;ex pires=3600. Privacy: none. Supported: path. User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. Content-Length: 0. UOpenSIPS:5060 -> UAC:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 5bd7495297c6. From: 042335040 ;tag=1f62205074. To: 042335040 ;tag=0c7ff67d927afc274 b272138ce65100a.ac4d. Call-ID: 61c67f739bef5a2e. CSeq: 1804289391 REGISTER. WWW-Authenticate: Digest realm="opsp.test.net", nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). Content-Length: 0. U UAC:5060 ->OpenSIPS:5060 REGISTER sip:opsp.test.net:5060 SIP/2.0. Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. Max-Forwards: 70. From: 042335040 ;tag=1f62205074. To: 042335040 . Call-ID: 61c67f739bef5a2e. CSeq: 1804289392 REGISTER. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, INFO. Authorization: Digest username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res ponse="9ce3622addeedf74622a23697e6f3728". Contact: 042335040 ;ex pires=3600. Privacy: none. Supported: path. User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. Content-Length: 0. . UOpenSIPS:5060 -> UAC:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b bbf80e346f48. From: 042335040 ;tag=1f62205074. To: 042335040 ;tag=766e4f757c55b3450 c9992a50fb64799-9163. Call-ID: 61c67f739bef5a2e. CSeq: 1804289392 REGISTER. Contact: ;expires=3600 ;received="sip:UAC:5060", ;expires=119. Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). Content-Length: 0. Do you see where could be an issue? tnx miha On 16/11/2016 08:11, Miha wrote: > Hello Bogdan > > yes this was the case... > > thank you! > > > br > miha > > On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >> Hi Miha, >> >> When you handle REGISTER requests (from behind NAT) most probably you >> use fix_nated_contact() instead of fix_nated_register(). >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 15.11.2016 09:11, Miha wrote: >>> Hello >>> >>> i need one info. >>> I have one phone behind NAT and it is registered on OpenSIPS. IN >>> register packet, which is send to OpenSIPS I can see contact: >>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>> >>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>> >>> >>> When opensips sends INVITE it send to right public ip and right port >>> (source ip and source port generated by router). The issue is this: >>> Invite is like: >>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>> request is then fw to this UAC behind router. The UAC replays to >>> this INVITE with 404 Not found as it is waiting to receive the same >>> URI which was written in contact (the userpart is ok, put the ip is >>> public, not private and this is the issue).From what I can see in >>> RFC this is the case. >>> >>> >>> Till now Idid not have any issues with this, but now I found first >>> phone which replays with 404 and from RFC point of view there should >>> be private ip request :) . So is there anything I can do :)? >>> >>> >>> tnx >>> miha >>> >>> >>> _______________________________________________ >>> 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: From bogdan at opensips.org Thu Nov 17 11:22:22 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Nov 2016 12:22:22 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> Message-ID: <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> Hi Miha, OpenSIPS returns in the 200 OK for a REGISTER all the valid registrations for that user (for all the devices the user may have). I guess your user has 2 registrations, so the 200 OK will report back both of them. You can check via "opensipsctl ul show" Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.11.2016 12:13, Miha wrote: > Hello Bogdan > > i changed this and it works in all cases, only in one I noticed today > this (Opensips reply only in this case with two URI on contact): > > UAC:5060 ->OpenSIPS:5060 > REGISTER sip:opsp.test.net:5060 SIP/2.0. > Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. > Max-Forwards: 70. > From: 042335040 ;tag=1f62205074. > To: 042335040 . > Call-ID: 61c67f739bef5a2e. > CSeq: 1804289391 REGISTER. > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, > PRACK, INFO. > Authorization: Digest > username="99942335040",realm="opsp.test.net",nonce="582d810c000058b > d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res > ponse="bc0c757c17f9b0976af35ec633dd83ca". > Contact: 042335040 ;ex > pires=3600. > Privacy: none. > Supported: path. > User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. > Content-Length: 0. > > UOpenSIPS:5060 -> UAC:5060 > SIP/2.0 401 Unauthorized. > Via: SIP/2.0/UDP > opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 > 5bd7495297c6. > From: 042335040 ;tag=1f62205074. > To: 042335040 ;tag=0c7ff67d927afc274 > b272138ce65100a.ac4d. > Call-ID: 61c67f739bef5a2e. > CSeq: 1804289391 REGISTER. > WWW-Authenticate: Digest realm="opsp.test.net", > nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. > Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). > Content-Length: 0. > > > U UAC:5060 ->OpenSIPS:5060 > REGISTER sip:opsp.test.net:5060 SIP/2.0. > Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. > Max-Forwards: 70. > From: 042335040 ;tag=1f62205074. > To: 042335040 . > Call-ID: 61c67f739bef5a2e. > CSeq: 1804289392 REGISTER. > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, > PRACK, INFO. > Authorization: Digest > username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 > 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res > ponse="9ce3622addeedf74622a23697e6f3728". > Contact: 042335040 ;ex > pires=3600. > Privacy: none. > Supported: path. > User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. > Content-Length: 0. > . > > > UOpenSIPS:5060 -> UAC:5060 > SIP/2.0 200 OK. > Via: SIP/2.0/UDP > opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b > bbf80e346f48. > From: 042335040 ;tag=1f62205074. > To: 042335040 ;tag=766e4f757c55b3450 > c9992a50fb64799-9163. > Call-ID: 61c67f739bef5a2e. > CSeq: 1804289392 REGISTER. > Contact: ;expires=3600 > ;received="sip:UAC:5060", > ;expires=119. > Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). > Content-Length: 0. > > Do you see where could be an issue? > > > tnx > miha > > > On 16/11/2016 08:11, Miha wrote: >> Hello Bogdan >> >> yes this was the case... >> >> thank you! >> >> >> br >> miha >> >> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>> Hi Miha, >>> >>> When you handle REGISTER requests (from behind NAT) most probably >>> you use fix_nated_contact() instead of fix_nated_register(). >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 15.11.2016 09:11, Miha wrote: >>>> Hello >>>> >>>> i need one info. >>>> I have one phone behind NAT and it is registered on OpenSIPS. IN >>>> register packet, which is send to OpenSIPS I can see contact: >>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>> >>>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>>> >>>> >>>> When opensips sends INVITE it send to right public ip and right >>>> port (source ip and source port generated by router). The issue is >>>> this: >>>> Invite is like: >>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>> request is then fw to this UAC behind router. The UAC replays to >>>> this INVITE with 404 Not found as it is waiting to receive the same >>>> URI which was written in contact (the userpart is ok, put the ip is >>>> public, not private and this is the issue).From what I can see in >>>> RFC this is the case. >>>> >>>> >>>> Till now Idid not have any issues with this, but now I found first >>>> phone which replays with 404 and from RFC point of view there >>>> should be private ip request :) . So is there anything I can do :)? >>>> >>>> >>>> tnx >>>> miha >>>> >>>> >>>> _______________________________________________ >>>> 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: From miha at softnet.si Thu Nov 17 11:35:46 2016 From: miha at softnet.si (Miha) Date: Thu, 17 Nov 2016 11:35:46 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> Message-ID: <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> Bodan so this is dual forking...? So if you have one account and you have two phones on it and first will try to register, 200 ok will will have contact of both phones? In location table I can see only one registration for this user but for "opensipsctl ul show" it shows me two contacts, which is strange? (When i do trace only one invite is send) and UAC replay with Busy all the time due to two contacts (this what i have been told). Ok, but if you look at rfc there is only one URI allowed in contact if I understand this right? The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog Please correct me if I am wrong. tnx so much! Miha On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: > Hi Miha, > > OpenSIPS returns in the 200 OK for a REGISTER all the valid > registrations for that user (for all the devices the user may have). > > I guess your user has 2 registrations, so the 200 OK will report back > both of them. You can check via "opensipsctl ul show" > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 17.11.2016 12:13, Miha wrote: >> Hello Bogdan >> >> i changed this and it works in all cases, only in one I noticed today >> this (Opensips reply only in this case with two URI on contact): >> >> UAC:5060 ->OpenSIPS:5060 >> REGISTER sip:opsp.test.net:5060 SIP/2.0. >> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >> Max-Forwards: 70. >> From: 042335040 ;tag=1f62205074. >> To: 042335040 . >> Call-ID: 61c67f739bef5a2e. >> CSeq: 1804289391 REGISTER. >> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >> PRACK, INFO. >> Authorization: Digest >> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >> ponse="bc0c757c17f9b0976af35ec633dd83ca". >> Contact: 042335040 ;ex >> pires=3600. >> Privacy: none. >> Supported: path. >> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >> Content-Length: 0. >> >> UOpenSIPS:5060 -> UAC:5060 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >> 5bd7495297c6. >> From: 042335040 ;tag=1f62205074. >> To: 042335040 ;tag=0c7ff67d927afc274 >> b272138ce65100a.ac4d. >> Call-ID: 61c67f739bef5a2e. >> CSeq: 1804289391 REGISTER. >> WWW-Authenticate: Digest realm="opsp.test.net", >> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. >> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >> Content-Length: 0. >> >> >> U UAC:5060 ->OpenSIPS:5060 >> REGISTER sip:opsp.test.net:5060 SIP/2.0. >> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >> Max-Forwards: 70. >> From: 042335040 ;tag=1f62205074. >> To: 042335040 . >> Call-ID: 61c67f739bef5a2e. >> CSeq: 1804289392 REGISTER. >> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >> PRACK, INFO. >> Authorization: Digest >> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >> ponse="9ce3622addeedf74622a23697e6f3728". >> Contact: 042335040 ;ex >> pires=3600. >> Privacy: none. >> Supported: path. >> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >> Content-Length: 0. >> . >> >> >> UOpenSIPS:5060 -> UAC:5060 >> SIP/2.0 200 OK. >> Via: SIP/2.0/UDP >> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >> bbf80e346f48. >> From: 042335040 ;tag=1f62205074. >> To: 042335040 ;tag=766e4f757c55b3450 >> c9992a50fb64799-9163. >> Call-ID: 61c67f739bef5a2e. >> CSeq: 1804289392 REGISTER. >> Contact: ;expires=3600 >> ;received="sip:UAC:5060", > > ;expires=119. >> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >> Content-Length: 0. >> >> Do you see where could be an issue? >> >> >> tnx >> miha >> >> >> On 16/11/2016 08:11, Miha wrote: >>> Hello Bogdan >>> >>> yes this was the case... >>> >>> thank you! >>> >>> >>> br >>> miha >>> >>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>> Hi Miha, >>>> >>>> When you handle REGISTER requests (from behind NAT) most probably >>>> you use fix_nated_contact() instead of fix_nated_register(). >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 15.11.2016 09:11, Miha wrote: >>>>> Hello >>>>> >>>>> i need one info. >>>>> I have one phone behind NAT and it is registered on OpenSIPS. IN >>>>> register packet, which is send to OpenSIPS I can see contact: >>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>> >>>>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>>>> >>>>> >>>>> When opensips sends INVITE it send to right public ip and right >>>>> port (source ip and source port generated by router). The issue is >>>>> this: >>>>> Invite is like: >>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>> request is then fw to this UAC behind router. The UAC replays to >>>>> this INVITE with 404 Not found as it is waiting to receive the >>>>> same URI which was written in contact (the userpart is ok, put the >>>>> ip is public, not private and this is the issue).From what I can >>>>> see in RFC this is the case. >>>>> >>>>> >>>>> Till now Idid not have any issues with this, but now I found first >>>>> phone which replays with 404 and from RFC point of view there >>>>> should be private ip request :) . So is there anything I can do :)? >>>>> >>>>> >>>>> tnx >>>>> miha >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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: From bogdan at opensips.org Thu Nov 17 12:11:52 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Nov 2016 13:11:52 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> Message-ID: Hi Miha, yes, that is parallel forking (you may have more than 2 contacts only). Are you sure your DB was sync'ed? OpenSIPS is periodically flushing the memory cache into the location table (see the "state" of the contact (as per "ul show") if marked as DIRTY). In regards to RFC, I think you quote the wrong section (maybe about callings?) - for REGISTERs, any number of URIs are allowed AFAIK. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.11.2016 12:35, Miha wrote: > Bodan > > so this is dual forking...? > So if you have one account and you have two phones on it and first > will try to register, 200 ok will will have contact of both phones? > In location table I can see only one registration for this user but > for "opensipsctl ul show" it shows me two contacts, which is strange? > (When i do trace only one invite is send) and UAC replay with Busy all > the time due to two contacts (this what i have been told). > > Ok, but if you look at rfc there is only one URI allowed in contact if > I understand this right? > > > The Contact header field MUST be present and contain exactly one SIP > or SIPS URI in any request that can result in the establishment of a > dialog > > Please correct me if I am wrong. tnx so much! Miha > > On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >> Hi Miha, >> >> OpenSIPS returns in the 200 OK for a REGISTER all the valid >> registrations for that user (for all the devices the user may have). >> >> I guess your user has 2 registrations, so the 200 OK will report back >> both of them. You can check via "opensipsctl ul show" >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 17.11.2016 12:13, Miha wrote: >>> Hello Bogdan >>> >>> i changed this and it works in all cases, only in one I noticed >>> today this (Opensips reply only in this case with two URI on contact): >>> >>> UAC:5060 ->OpenSIPS:5060 >>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>> Max-Forwards: 70. >>> From: 042335040 ;tag=1f62205074. >>> To: 042335040 . >>> Call-ID: 61c67f739bef5a2e. >>> CSeq: 1804289391 REGISTER. >>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>> PRACK, INFO. >>> Authorization: Digest >>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>> Contact: 042335040 ;ex >>> pires=3600. >>> Privacy: none. >>> Supported: path. >>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>> Content-Length: 0. >>> >>> UOpenSIPS:5060 -> UAC:5060 >>> SIP/2.0 401 Unauthorized. >>> Via: SIP/2.0/UDP >>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>> 5bd7495297c6. >>> From: 042335040 ;tag=1f62205074. >>> To: 042335040 ;tag=0c7ff67d927afc274 >>> b272138ce65100a.ac4d. >>> Call-ID: 61c67f739bef5a2e. >>> CSeq: 1804289391 REGISTER. >>> WWW-Authenticate: Digest realm="opsp.test.net", >>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. >>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>> Content-Length: 0. >>> >>> >>> U UAC:5060 ->OpenSIPS:5060 >>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>> Max-Forwards: 70. >>> From: 042335040 ;tag=1f62205074. >>> To: 042335040 . >>> Call-ID: 61c67f739bef5a2e. >>> CSeq: 1804289392 REGISTER. >>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>> PRACK, INFO. >>> Authorization: Digest >>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>> ponse="9ce3622addeedf74622a23697e6f3728". >>> Contact: 042335040 ;ex >>> pires=3600. >>> Privacy: none. >>> Supported: path. >>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>> Content-Length: 0. >>> . >>> >>> >>> UOpenSIPS:5060 -> UAC:5060 >>> SIP/2.0 200 OK. >>> Via: SIP/2.0/UDP >>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>> bbf80e346f48. >>> From: 042335040 ;tag=1f62205074. >>> To: 042335040 ;tag=766e4f757c55b3450 >>> c9992a50fb64799-9163. >>> Call-ID: 61c67f739bef5a2e. >>> CSeq: 1804289392 REGISTER. >>> Contact: ;expires=3600 >>> ;received="sip:UAC:5060", >> > ;expires=119. >>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>> Content-Length: 0. >>> >>> Do you see where could be an issue? >>> >>> >>> tnx >>> miha >>> >>> >>> On 16/11/2016 08:11, Miha wrote: >>>> Hello Bogdan >>>> >>>> yes this was the case... >>>> >>>> thank you! >>>> >>>> >>>> br >>>> miha >>>> >>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>> Hi Miha, >>>>> >>>>> When you handle REGISTER requests (from behind NAT) most probably >>>>> you use fix_nated_contact() instead of fix_nated_register(). >>>>> >>>>> Regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 15.11.2016 09:11, Miha wrote: >>>>>> Hello >>>>>> >>>>>> i need one info. >>>>>> I have one phone behind NAT and it is registered on OpenSIPS. IN >>>>>> register packet, which is send to OpenSIPS I can see contact: >>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>> >>>>>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>>>>> >>>>>> >>>>>> When opensips sends INVITE it send to right public ip and right >>>>>> port (source ip and source port generated by router). The issue >>>>>> is this: >>>>>> Invite is like: >>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>>> request is then fw to this UAC behind router. The UAC replays to >>>>>> this INVITE with 404 Not found as it is waiting to receive the >>>>>> same URI which was written in contact (the userpart is ok, put >>>>>> the ip is public, not private and this is the issue).From what I >>>>>> can see in RFC this is the case. >>>>>> >>>>>> >>>>>> Till now Idid not have any issues with this, but now I found >>>>>> first phone which replays with 404 and from RFC point of view >>>>>> there should be private ip request :) . So is there anything I >>>>>> can do :)? >>>>>> >>>>>> >>>>>> tnx >>>>>> miha >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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: From miha at softnet.si Thu Nov 17 13:36:27 2016 From: miha at softnet.si (Miha) Date: Thu, 17 Nov 2016 13:36:27 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> Message-ID: <7a9262a7-ec41-e754-760a-f69478b10787@softnet.si> Hello Bogdan how would I know that is marked as DIRTY? how this will look like? tnx miha On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: > Hi Miha, > > yes, that is parallel forking (you may have more than 2 contacts only). > > Are you sure your DB was sync'ed? OpenSIPS is periodically flushing > the memory cache into the location table (see the "state" of the > contact (as per "ul show") if marked as DIRTY). > > In regards to RFC, I think you quote the wrong section (maybe about > callings?) - for REGISTERs, any number of URIs are allowed AFAIK. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 17.11.2016 12:35, Miha wrote: >> Bodan >> >> so this is dual forking...? >> So if you have one account and you have two phones on it and first >> will try to register, 200 ok will will have contact of both phones? >> In location table I can see only one registration for this user but >> for "opensipsctl ul show" it shows me two contacts, which is strange? >> (When i do trace only one invite is send) and UAC replay with Busy >> all the time due to two contacts (this what i have been told). >> >> Ok, but if you look at rfc there is only one URI allowed in contact >> if I understand this right? >> >> >> The Contact header field MUST be present and contain exactly one SIP >> or SIPS URI in any request that can result in the establishment of a >> dialog >> >> Please correct me if I am wrong. tnx so much! Miha >> >> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>> Hi Miha, >>> >>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>> registrations for that user (for all the devices the user may have). >>> >>> I guess your user has 2 registrations, so the 200 OK will report >>> back both of them. You can check via "opensipsctl ul show" >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 17.11.2016 12:13, Miha wrote: >>>> Hello Bogdan >>>> >>>> i changed this and it works in all cases, only in one I noticed >>>> today this (Opensips reply only in this case with two URI on contact): >>>> >>>> UAC:5060 ->OpenSIPS:5060 >>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>> Max-Forwards: 70. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 . >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289391 REGISTER. >>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>> PRACK, INFO. >>>> Authorization: Digest >>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>> Contact: 042335040 ;ex >>>> pires=3600. >>>> Privacy: none. >>>> Supported: path. >>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>> Content-Length: 0. >>>> >>>> UOpenSIPS:5060 -> UAC:5060 >>>> SIP/2.0 401 Unauthorized. >>>> Via: SIP/2.0/UDP >>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>> 5bd7495297c6. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 ;tag=0c7ff67d927afc274 >>>> b272138ce65100a.ac4d. >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289391 REGISTER. >>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. >>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>> Content-Length: 0. >>>> >>>> >>>> U UAC:5060 ->OpenSIPS:5060 >>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>> Max-Forwards: 70. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 . >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289392 REGISTER. >>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>> PRACK, INFO. >>>> Authorization: Digest >>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>> Contact: 042335040 ;ex >>>> pires=3600. >>>> Privacy: none. >>>> Supported: path. >>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>> Content-Length: 0. >>>> . >>>> >>>> >>>> UOpenSIPS:5060 -> UAC:5060 >>>> SIP/2.0 200 OK. >>>> Via: SIP/2.0/UDP >>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>> bbf80e346f48. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 ;tag=766e4f757c55b3450 >>>> c9992a50fb64799-9163. >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289392 REGISTER. >>>> Contact: ;expires=3600 >>>> ;received="sip:UAC:5060", >>> > ;expires=119. >>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>> Content-Length: 0. >>>> >>>> Do you see where could be an issue? >>>> >>>> >>>> tnx >>>> miha >>>> >>>> >>>> On 16/11/2016 08:11, Miha wrote: >>>>> Hello Bogdan >>>>> >>>>> yes this was the case... >>>>> >>>>> thank you! >>>>> >>>>> >>>>> br >>>>> miha >>>>> >>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>> Hi Miha, >>>>>> >>>>>> When you handle REGISTER requests (from behind NAT) most probably >>>>>> you use fix_nated_contact() instead of fix_nated_register(). >>>>>> >>>>>> Regards, >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>> Hello >>>>>>> >>>>>>> i need one info. >>>>>>> I have one phone behind NAT and it is registered on OpenSIPS. IN >>>>>>> register packet, which is send to OpenSIPS I can see contact: >>>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>> >>>>>>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>>>>>> >>>>>>> >>>>>>> When opensips sends INVITE it send to right public ip and right >>>>>>> port (source ip and source port generated by router). The issue >>>>>>> is this: >>>>>>> Invite is like: >>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>>>> request is then fw to this UAC behind router. The UAC replays to >>>>>>> this INVITE with 404 Not found as it is waiting to receive the >>>>>>> same URI which was written in contact (the userpart is ok, put >>>>>>> the ip is public, not private and this is the issue).From what I >>>>>>> can see in RFC this is the case. >>>>>>> >>>>>>> >>>>>>> Till now Idid not have any issues with this, but now I found >>>>>>> first phone which replays with 404 and from RFC point of view >>>>>>> there should be private ip request :) . So is there anything I >>>>>>> can do :)? >>>>>>> >>>>>>> >>>>>>> tnx >>>>>>> miha >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: From saul at ag-projects.com Thu Nov 17 16:35:37 2016 From: saul at ag-projects.com (=?utf-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?=) Date: Thu, 17 Nov 2016 16:35:37 +0100 Subject: [OpenSIPS-Users] [OpenSIPS-users] FOSDEM Real Time Communications devroom seeks speakers / volunteers In-Reply-To: References: <7A33F425-9D76-4945-9FCC-688C42FF1235@ag-projects.com> Message-ID: <5E832040-FF78-4167-9BB7-F86E8FEEC736@ag-projects.com> Received, excellent! See you there, > On 15 Nov 2016, at 18:15, R?zvan Crainea wrote: > > Hi, Saul! > > Thanks for the heads-up, we'll definitely be there! See you in Brussels! > > Cheers, > > R?zvan Crainea > OpenSIPS Solutions > > www.opensips-solutions.com > On 11/14/2016 11:39 PM, Sa?l Ibarra Corretg? wrote: >> Hi there! >> >> It?s that time of the year again, time for FOSDEM paper submissions! Next FOSDEM we?ll have a ?Real Time Communications? devroom, which is a good fit for OpenSIPS and all things VoIP / RTC. >> >> All the information regarding the process is available here: >> https://lists.fosdem.org/pipermail/fosdem/2016-October/002481.html >> >> >> I?m part of the organising team, so please do reach out if you have any questions / problems. >> >> >> Cheers, >> >> -- >> Sa?l Ibarra Corretg? >> AG Projects >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 -- Sa?l Ibarra Corretg? AG Projects -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From miha at softnet.si Fri Nov 18 09:15:00 2016 From: miha at softnet.si (Miha) Date: Fri, 18 Nov 2016 09:15:00 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> Message-ID: Hi Bogdan I did few more test. This contact bothers UAC. Is there anything i can do in this case in OpenSIPS so that it will only reply with one URI in contact? Contact:;expires=1518 ;received="sip:84.41.125.21:5060",; expires=180. tnx so much! MIha On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: > Hi Miha, > > yes, that is parallel forking (you may have more than 2 contacts only). > > Are you sure your DB was sync'ed? OpenSIPS is periodically flushing > the memory cache into the location table (see the "state" of the > contact (as per "ul show") if marked as DIRTY). > > In regards to RFC, I think you quote the wrong section (maybe about > callings?) - for REGISTERs, any number of URIs are allowed AFAIK. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 17.11.2016 12:35, Miha wrote: >> Bodan >> >> so this is dual forking...? >> So if you have one account and you have two phones on it and first >> will try to register, 200 ok will will have contact of both phones? >> In location table I can see only one registration for this user but >> for "opensipsctl ul show" it shows me two contacts, which is strange? >> (When i do trace only one invite is send) and UAC replay with Busy >> all the time due to two contacts (this what i have been told). >> >> Ok, but if you look at rfc there is only one URI allowed in contact >> if I understand this right? >> >> >> The Contact header field MUST be present and contain exactly one SIP >> or SIPS URI in any request that can result in the establishment of a >> dialog >> >> Please correct me if I am wrong. tnx so much! Miha >> >> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>> Hi Miha, >>> >>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>> registrations for that user (for all the devices the user may have). >>> >>> I guess your user has 2 registrations, so the 200 OK will report >>> back both of them. You can check via "opensipsctl ul show" >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 17.11.2016 12:13, Miha wrote: >>>> Hello Bogdan >>>> >>>> i changed this and it works in all cases, only in one I noticed >>>> today this (Opensips reply only in this case with two URI on contact): >>>> >>>> UAC:5060 ->OpenSIPS:5060 >>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>> Max-Forwards: 70. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 . >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289391 REGISTER. >>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>> PRACK, INFO. >>>> Authorization: Digest >>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>> Contact: 042335040 ;ex >>>> pires=3600. >>>> Privacy: none. >>>> Supported: path. >>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>> Content-Length: 0. >>>> >>>> UOpenSIPS:5060 -> UAC:5060 >>>> SIP/2.0 401 Unauthorized. >>>> Via: SIP/2.0/UDP >>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>> 5bd7495297c6. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 ;tag=0c7ff67d927afc274 >>>> b272138ce65100a.ac4d. >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289391 REGISTER. >>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. >>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>> Content-Length: 0. >>>> >>>> >>>> U UAC:5060 ->OpenSIPS:5060 >>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>> Max-Forwards: 70. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 . >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289392 REGISTER. >>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>> PRACK, INFO. >>>> Authorization: Digest >>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>> Contact: 042335040 ;ex >>>> pires=3600. >>>> Privacy: none. >>>> Supported: path. >>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>> Content-Length: 0. >>>> . >>>> >>>> >>>> UOpenSIPS:5060 -> UAC:5060 >>>> SIP/2.0 200 OK. >>>> Via: SIP/2.0/UDP >>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>> bbf80e346f48. >>>> From: 042335040 ;tag=1f62205074. >>>> To: 042335040 ;tag=766e4f757c55b3450 >>>> c9992a50fb64799-9163. >>>> Call-ID: 61c67f739bef5a2e. >>>> CSeq: 1804289392 REGISTER. >>>> Contact: ;expires=3600 >>>> ;received="sip:UAC:5060", >>> > ;expires=119. >>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>> Content-Length: 0. >>>> >>>> Do you see where could be an issue? >>>> >>>> >>>> tnx >>>> miha >>>> >>>> >>>> On 16/11/2016 08:11, Miha wrote: >>>>> Hello Bogdan >>>>> >>>>> yes this was the case... >>>>> >>>>> thank you! >>>>> >>>>> >>>>> br >>>>> miha >>>>> >>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>> Hi Miha, >>>>>> >>>>>> When you handle REGISTER requests (from behind NAT) most probably >>>>>> you use fix_nated_contact() instead of fix_nated_register(). >>>>>> >>>>>> Regards, >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>> Hello >>>>>>> >>>>>>> i need one info. >>>>>>> I have one phone behind NAT and it is registered on OpenSIPS. IN >>>>>>> register packet, which is send to OpenSIPS I can see contact: >>>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>> >>>>>>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>>>>>> >>>>>>> >>>>>>> When opensips sends INVITE it send to right public ip and right >>>>>>> port (source ip and source port generated by router). The issue >>>>>>> is this: >>>>>>> Invite is like: >>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>>>> request is then fw to this UAC behind router. The UAC replays to >>>>>>> this INVITE with 404 Not found as it is waiting to receive the >>>>>>> same URI which was written in contact (the userpart is ok, put >>>>>>> the ip is public, not private and this is the issue).From what I >>>>>>> can see in RFC this is the case. >>>>>>> >>>>>>> >>>>>>> Till now Idid not have any issues with this, but now I found >>>>>>> first phone which replays with 404 and from RFC point of view >>>>>>> there should be private ip request :) . So is there anything I >>>>>>> can do :)? >>>>>>> >>>>>>> >>>>>>> tnx >>>>>>> miha >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: From bogdan at opensips.org Fri Nov 18 09:42:04 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 18 Nov 2016 10:42:04 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <7a9262a7-ec41-e754-760a-f69478b10787@softnet.si> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> <7a9262a7-ec41-e754-760a-f69478b10787@softnet.si> Message-ID: <0ec164ad-dcbd-a632-e577-c41bda386461@opensips.org> Hi Miha, In the "ul show" output, each contact has a "State" field: State:: CS_SYNC It can be CS_SYNC which means the contact from memory was synced to DB or CS_DIRTY which means the contact in memory was changed since the last sync to DB. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.11.2016 14:36, Miha wrote: > Hello Bogdan > > how would I know that is marked as DIRTY? how this will look like? > > > tnx > miha > > On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >> Hi Miha, >> >> yes, that is parallel forking (you may have more than 2 contacts only). >> >> Are you sure your DB was sync'ed? OpenSIPS is periodically flushing >> the memory cache into the location table (see the "state" of the >> contact (as per "ul show") if marked as DIRTY). >> >> In regards to RFC, I think you quote the wrong section (maybe about >> callings?) - for REGISTERs, any number of URIs are allowed AFAIK. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 17.11.2016 12:35, Miha wrote: >>> Bodan >>> >>> so this is dual forking...? >>> So if you have one account and you have two phones on it and first >>> will try to register, 200 ok will will have contact of both phones? >>> In location table I can see only one registration for this user but >>> for "opensipsctl ul show" it shows me two contacts, which is >>> strange? (When i do trace only one invite is send) and UAC replay >>> with Busy all the time due to two contacts (this what i have been told). >>> >>> Ok, but if you look at rfc there is only one URI allowed in contact >>> if I understand this right? >>> >>> >>> The Contact header field MUST be present and contain exactly one SIP >>> or SIPS URI in any request that can result in the establishment of a >>> dialog >>> >>> Please correct me if I am wrong. tnx so much! Miha >>> >>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>> Hi Miha, >>>> >>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>> registrations for that user (for all the devices the user may have). >>>> >>>> I guess your user has 2 registrations, so the 200 OK will report >>>> back both of them. You can check via "opensipsctl ul show" >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 17.11.2016 12:13, Miha wrote: >>>>> Hello Bogdan >>>>> >>>>> i changed this and it works in all cases, only in one I noticed >>>>> today this (Opensips reply only in this case with two URI on contact): >>>>> >>>>> UAC:5060 ->OpenSIPS:5060 >>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>> Max-Forwards: 70. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 . >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289391 REGISTER. >>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>> PRACK, INFO. >>>>> Authorization: Digest >>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>> Contact: 042335040 ;ex >>>>> pires=3600. >>>>> Privacy: none. >>>>> Supported: path. >>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>> Content-Length: 0. >>>>> >>>>> UOpenSIPS:5060 -> UAC:5060 >>>>> SIP/2.0 401 Unauthorized. >>>>> Via: SIP/2.0/UDP >>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>> 5bd7495297c6. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 ;tag=0c7ff67d927afc274 >>>>> b272138ce65100a.ac4d. >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289391 REGISTER. >>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. >>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>> Content-Length: 0. >>>>> >>>>> >>>>> U UAC:5060 ->OpenSIPS:5060 >>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>> Max-Forwards: 70. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 . >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289392 REGISTER. >>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>> PRACK, INFO. >>>>> Authorization: Digest >>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>> Contact: 042335040 ;ex >>>>> pires=3600. >>>>> Privacy: none. >>>>> Supported: path. >>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>> Content-Length: 0. >>>>> . >>>>> >>>>> >>>>> UOpenSIPS:5060 -> UAC:5060 >>>>> SIP/2.0 200 OK. >>>>> Via: SIP/2.0/UDP >>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>> bbf80e346f48. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 ;tag=766e4f757c55b3450 >>>>> c9992a50fb64799-9163. >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289392 REGISTER. >>>>> Contact: ;expires=3600 >>>>> ;received="sip:UAC:5060", >>>> > ;expires=119. >>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>> Content-Length: 0. >>>>> >>>>> Do you see where could be an issue? >>>>> >>>>> >>>>> tnx >>>>> miha >>>>> >>>>> >>>>> On 16/11/2016 08:11, Miha wrote: >>>>>> Hello Bogdan >>>>>> >>>>>> yes this was the case... >>>>>> >>>>>> thank you! >>>>>> >>>>>> >>>>>> br >>>>>> miha >>>>>> >>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>> Hi Miha, >>>>>>> >>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>> probably you use fix_nated_contact() instead of >>>>>>> fix_nated_register(). >>>>>>> >>>>>>> Regards, >>>>>>> Bogdan-Andrei Iancu >>>>>>> OpenSIPS Founder and Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> i need one info. >>>>>>>> I have one phone behind NAT and it is registered on OpenSIPS. >>>>>>>> IN register packet, which is send to OpenSIPS I can see >>>>>>>> contact: "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>> >>>>>>>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>>>>>>> >>>>>>>> >>>>>>>> When opensips sends INVITE it send to right public ip and right >>>>>>>> port (source ip and source port generated by router). The issue >>>>>>>> is this: >>>>>>>> Invite is like: >>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>>>>> request is then fw to this UAC behind router. The UAC replays >>>>>>>> to this INVITE with 404 Not found as it is waiting to receive >>>>>>>> the same URI which was written in contact (the userpart is ok, >>>>>>>> put the ip is public, not private and this is the issue).From >>>>>>>> what I can see in RFC this is the case. >>>>>>>> >>>>>>>> >>>>>>>> Till now Idid not have any issues with this, but now I found >>>>>>>> first phone which replays with 404 and from RFC point of view >>>>>>>> there should be private ip request :) . So is there anything I >>>>>>>> can do :)? >>>>>>>> >>>>>>>> >>>>>>>> tnx >>>>>>>> miha >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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: From bogdan at opensips.org Fri Nov 18 09:48:21 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 18 Nov 2016 10:48:21 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> Message-ID: <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> Hi Miha, You mean the UAC does not like the multi-URI Contact header in the 200 OK ???? If so, that UAC is really broken as 1) breaks the SIP syntax (which allows it) and 2) breaks the the SIP Registration as per RFC3261. What about the second contact (the one already existing in usrloc when this registration comes) ? can it be discarded ? If YES, you can try passing the "c1f" flags to save() : http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 That will make OpenSIPS to accept only 1 contact per AOR/user and any new contact will override the existing one. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 10:15, Miha wrote: > Hi Bogdan > > I did few more test. This contact bothers UAC. Is there anything i can > do in this case in OpenSIPS so that it will only reply with one URI in > contact? > > Contact:;expires=1518 > ;received="sip:84.41.125.21:5060",; > expires=180. > > > tnx so much! > MIha > > On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >> Hi Miha, >> >> yes, that is parallel forking (you may have more than 2 contacts only). >> >> Are you sure your DB was sync'ed? OpenSIPS is periodically flushing >> the memory cache into the location table (see the "state" of the >> contact (as per "ul show") if marked as DIRTY). >> >> In regards to RFC, I think you quote the wrong section (maybe about >> callings?) - for REGISTERs, any number of URIs are allowed AFAIK. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 17.11.2016 12:35, Miha wrote: >>> Bodan >>> >>> so this is dual forking...? >>> So if you have one account and you have two phones on it and first >>> will try to register, 200 ok will will have contact of both phones? >>> In location table I can see only one registration for this user but >>> for "opensipsctl ul show" it shows me two contacts, which is >>> strange? (When i do trace only one invite is send) and UAC replay >>> with Busy all the time due to two contacts (this what i have been told). >>> >>> Ok, but if you look at rfc there is only one URI allowed in contact >>> if I understand this right? >>> >>> >>> The Contact header field MUST be present and contain exactly one SIP >>> or SIPS URI in any request that can result in the establishment of a >>> dialog >>> >>> Please correct me if I am wrong. tnx so much! Miha >>> >>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>> Hi Miha, >>>> >>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>> registrations for that user (for all the devices the user may have). >>>> >>>> I guess your user has 2 registrations, so the 200 OK will report >>>> back both of them. You can check via "opensipsctl ul show" >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 17.11.2016 12:13, Miha wrote: >>>>> Hello Bogdan >>>>> >>>>> i changed this and it works in all cases, only in one I noticed >>>>> today this (Opensips reply only in this case with two URI on contact): >>>>> >>>>> UAC:5060 ->OpenSIPS:5060 >>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>> Max-Forwards: 70. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 . >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289391 REGISTER. >>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>> PRACK, INFO. >>>>> Authorization: Digest >>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>> Contact: 042335040 ;ex >>>>> pires=3600. >>>>> Privacy: none. >>>>> Supported: path. >>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>> Content-Length: 0. >>>>> >>>>> UOpenSIPS:5060 -> UAC:5060 >>>>> SIP/2.0 401 Unauthorized. >>>>> Via: SIP/2.0/UDP >>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>> 5bd7495297c6. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 ;tag=0c7ff67d927afc274 >>>>> b272138ce65100a.ac4d. >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289391 REGISTER. >>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. >>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>> Content-Length: 0. >>>>> >>>>> >>>>> U UAC:5060 ->OpenSIPS:5060 >>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>> Max-Forwards: 70. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 . >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289392 REGISTER. >>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>> PRACK, INFO. >>>>> Authorization: Digest >>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>> Contact: 042335040 ;ex >>>>> pires=3600. >>>>> Privacy: none. >>>>> Supported: path. >>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>> Content-Length: 0. >>>>> . >>>>> >>>>> >>>>> UOpenSIPS:5060 -> UAC:5060 >>>>> SIP/2.0 200 OK. >>>>> Via: SIP/2.0/UDP >>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>> bbf80e346f48. >>>>> From: 042335040 ;tag=1f62205074. >>>>> To: 042335040 ;tag=766e4f757c55b3450 >>>>> c9992a50fb64799-9163. >>>>> Call-ID: 61c67f739bef5a2e. >>>>> CSeq: 1804289392 REGISTER. >>>>> Contact: ;expires=3600 >>>>> ;received="sip:UAC:5060", >>>> > ;expires=119. >>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>> Content-Length: 0. >>>>> >>>>> Do you see where could be an issue? >>>>> >>>>> >>>>> tnx >>>>> miha >>>>> >>>>> >>>>> On 16/11/2016 08:11, Miha wrote: >>>>>> Hello Bogdan >>>>>> >>>>>> yes this was the case... >>>>>> >>>>>> thank you! >>>>>> >>>>>> >>>>>> br >>>>>> miha >>>>>> >>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>> Hi Miha, >>>>>>> >>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>> probably you use fix_nated_contact() instead of >>>>>>> fix_nated_register(). >>>>>>> >>>>>>> Regards, >>>>>>> Bogdan-Andrei Iancu >>>>>>> OpenSIPS Founder and Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> i need one info. >>>>>>>> I have one phone behind NAT and it is registered on OpenSIPS. >>>>>>>> IN register packet, which is send to OpenSIPS I can see >>>>>>>> contact: "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>> >>>>>>>> and let says that the public ip for this device is xxx.xxx.xxx.xxx. >>>>>>>> >>>>>>>> >>>>>>>> When opensips sends INVITE it send to right public ip and right >>>>>>>> port (source ip and source port generated by router). The issue >>>>>>>> is this: >>>>>>>> Invite is like: >>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>>>>> request is then fw to this UAC behind router. The UAC replays >>>>>>>> to this INVITE with 404 Not found as it is waiting to receive >>>>>>>> the same URI which was written in contact (the userpart is ok, >>>>>>>> put the ip is public, not private and this is the issue).From >>>>>>>> what I can see in RFC this is the case. >>>>>>>> >>>>>>>> >>>>>>>> Till now Idid not have any issues with this, but now I found >>>>>>>> first phone which replays with 404 and from RFC point of view >>>>>>>> there should be private ip request :) . So is there anything I >>>>>>>> can do :)? >>>>>>>> >>>>>>>> >>>>>>>> tnx >>>>>>>> miha >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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: From bogdan at opensips.org Fri Nov 18 09:58:31 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 18 Nov 2016 10:58:31 +0200 Subject: [OpenSIPS-Users] Memory free problem In-Reply-To: <1024256996.20161117101150@ptl.ru> References: <1024256996.20161117101150@ptl.ru> Message-ID: <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> Hi Denis, I do not think they are related. The warnings report some traffic anomalies - a PRACK request for a confirmed dialog (with 200 OK). On the memory part, if the log is correct, it says you have 180M free. What are the ERROR line just after that log ? I want to see which was the module trying to allocate memory. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.11.2016 09:11, Denis wrote: > Memory free problem Hello! > > Today i have a temporary problem with out of free memory (about 4 > minutes). > Unfortunately, i noticed the problem when everything became fine, so i > didn`t make standard procedure of detecting problems with memory which > has been described in documentation. > > In syslog i see such sequence of events. > > Before the first message about out of free memory > > "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes > left), please increase the "-m" command line parameter!" > > i see many messages > > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c531c95f0 [3855:951170645] with clid > '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1' and tags '96x8v2xkj9of92j' > '332693C-EF5'" > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c4735d130 [4072:1150064691] with clid > 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2' and tags '1czw3nbhw632pzn' > '3326728-1DC1'" > > dialing with two callid. > > The question is, can such Warning influence on shm. allocation? > > Thank you for any help. > > mailto:denis7979 at mail.ru > > > _______________________________________________ > 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: From miha at softnet.si Fri Nov 18 10:20:51 2016 From: miha at softnet.si (Miha) Date: Fri, 18 Nov 2016 10:20:51 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> Message-ID: I do not know if this is the case. But from what I can see what I register it on some Innovaphone PBX, innovaphone sends back in contact (200 ok) just ip of IPBX and also when INVITE is send in contact there is URI of PBX and only and it works. i tried this but did not have any luck. br miha On 18/11/2016 09:48, Bogdan-Andrei Iancu wrote: > Hi Miha, > > You mean the UAC does not like the multi-URI Contact header in the 200 > OK ???? If so, that UAC is really broken as 1) breaks the SIP syntax > (which allows it) and 2) breaks the the SIP Registration as per RFC3261. > > What about the second contact (the one already existing in usrloc when > this registration comes) ? can it be discarded ? If YES, you can try > passing the "c1f" flags to save() : > http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 > > That will make OpenSIPS to accept only 1 contact per AOR/user and any > new contact will override the existing one. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 18.11.2016 10:15, Miha wrote: >> Hi Bogdan >> >> I did few more test. This contact bothers UAC. Is there anything i >> can do in this case in OpenSIPS so that it will only reply with one >> URI in contact? >> >> Contact:;expires=1518 >> ;received="sip:84.41.125.21:5060",; >> expires=180. >> >> >> tnx so much! >> MIha >> >> On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >>> Hi Miha, >>> >>> yes, that is parallel forking (you may have more than 2 contacts only). >>> >>> Are you sure your DB was sync'ed? OpenSIPS is periodically flushing >>> the memory cache into the location table (see the "state" of the >>> contact (as per "ul show") if marked as DIRTY). >>> >>> In regards to RFC, I think you quote the wrong section (maybe about >>> callings?) - for REGISTERs, any number of URIs are allowed AFAIK. >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 17.11.2016 12:35, Miha wrote: >>>> Bodan >>>> >>>> so this is dual forking...? >>>> So if you have one account and you have two phones on it and first >>>> will try to register, 200 ok will will have contact of both phones? >>>> In location table I can see only one registration for this user but >>>> for "opensipsctl ul show" it shows me two contacts, which is >>>> strange? (When i do trace only one invite is send) and UAC replay >>>> with Busy all the time due to two contacts (this what i have been >>>> told). >>>> >>>> Ok, but if you look at rfc there is only one URI allowed in contact >>>> if I understand this right? >>>> >>>> >>>> The Contact header field MUST be present and contain exactly one SIP >>>> or SIPS URI in any request that can result in the establishment of a >>>> dialog >>>> >>>> Please correct me if I am wrong. tnx so much! Miha >>>> >>>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>>> Hi Miha, >>>>> >>>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>>> registrations for that user (for all the devices the user may have). >>>>> >>>>> I guess your user has 2 registrations, so the 200 OK will report >>>>> back both of them. You can check via "opensipsctl ul show" >>>>> >>>>> Regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 17.11.2016 12:13, Miha wrote: >>>>>> Hello Bogdan >>>>>> >>>>>> i changed this and it works in all cases, only in one I noticed >>>>>> today this (Opensips reply only in this case with two URI on >>>>>> contact): >>>>>> >>>>>> UAC:5060 ->OpenSIPS:5060 >>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>>> Max-Forwards: 70. >>>>>> From: 042335040 ;tag=1f62205074. >>>>>> To: 042335040 . >>>>>> Call-ID: 61c67f739bef5a2e. >>>>>> CSeq: 1804289391 REGISTER. >>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>> PRACK, INFO. >>>>>> Authorization: Digest >>>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>>> Contact: 042335040 ;ex >>>>>> pires=3600. >>>>>> Privacy: none. >>>>>> Supported: path. >>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>> Content-Length: 0. >>>>>> >>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>> SIP/2.0 401 Unauthorized. >>>>>> Via: SIP/2.0/UDP >>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>>> 5bd7495297c6. >>>>>> From: 042335040 ;tag=1f62205074. >>>>>> To: 042335040 ;tag=0c7ff67d927afc274 >>>>>> b272138ce65100a.ac4d. >>>>>> Call-ID: 61c67f739bef5a2e. >>>>>> CSeq: 1804289391 REGISTER. >>>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", stale=true. >>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>> Content-Length: 0. >>>>>> >>>>>> >>>>>> U UAC:5060 ->OpenSIPS:5060 >>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>>> Max-Forwards: 70. >>>>>> From: 042335040 ;tag=1f62205074. >>>>>> To: 042335040 . >>>>>> Call-ID: 61c67f739bef5a2e. >>>>>> CSeq: 1804289392 REGISTER. >>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>> PRACK, INFO. >>>>>> Authorization: Digest >>>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>>> Contact: 042335040 ;ex >>>>>> pires=3600. >>>>>> Privacy: none. >>>>>> Supported: path. >>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>> Content-Length: 0. >>>>>> . >>>>>> >>>>>> >>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>> SIP/2.0 200 OK. >>>>>> Via: SIP/2.0/UDP >>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>>> bbf80e346f48. >>>>>> From: 042335040 ;tag=1f62205074. >>>>>> To: 042335040 ;tag=766e4f757c55b3450 >>>>>> c9992a50fb64799-9163. >>>>>> Call-ID: 61c67f739bef5a2e. >>>>>> CSeq: 1804289392 REGISTER. >>>>>> Contact: ;expires=3600 >>>>>> ;received="sip:UAC:5060", >>>>> > ;expires=119. >>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>> Content-Length: 0. >>>>>> >>>>>> Do you see where could be an issue? >>>>>> >>>>>> >>>>>> tnx >>>>>> miha >>>>>> >>>>>> >>>>>> On 16/11/2016 08:11, Miha wrote: >>>>>>> Hello Bogdan >>>>>>> >>>>>>> yes this was the case... >>>>>>> >>>>>>> thank you! >>>>>>> >>>>>>> >>>>>>> br >>>>>>> miha >>>>>>> >>>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>>> Hi Miha, >>>>>>>> >>>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>>> probably you use fix_nated_contact() instead of >>>>>>>> fix_nated_register(). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Bogdan-Andrei Iancu >>>>>>>> OpenSIPS Founder and Developer >>>>>>>> http://www.opensips-solutions.com >>>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> i need one info. >>>>>>>>> I have one phone behind NAT and it is registered on OpenSIPS. >>>>>>>>> IN register packet, which is send to OpenSIPS I can see >>>>>>>>> contact: "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>>> >>>>>>>>> and let says that the public ip for this device is >>>>>>>>> xxx.xxx.xxx.xxx. >>>>>>>>> >>>>>>>>> >>>>>>>>> When opensips sends INVITE it send to right public ip and >>>>>>>>> right port (source ip and source port generated by router). >>>>>>>>> The issue is this: >>>>>>>>> Invite is like: >>>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>>>>>> request is then fw to this UAC behind router. The UAC replays >>>>>>>>> to this INVITE with 404 Not found as it is waiting to receive >>>>>>>>> the same URI which was written in contact (the userpart is ok, >>>>>>>>> put the ip is public, not private and this is the issue).From >>>>>>>>> what I can see in RFC this is the case. >>>>>>>>> >>>>>>>>> >>>>>>>>> Till now Idid not have any issues with this, but now I found >>>>>>>>> first phone which replays with 404 and from RFC point of view >>>>>>>>> there should be private ip request :) . So is there anything I >>>>>>>>> can do :)? >>>>>>>>> >>>>>>>>> >>>>>>>>> tnx >>>>>>>>> miha >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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: From razvan at opensips.org Fri Nov 18 10:22:06 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 18 Nov 2016 11:22:06 +0200 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> Message-ID: <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> Hi, Ehrny! Did you try setting the private socket on the reply? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/17/2016 01:00 AM, Ehrny wrote: > > Dear R?zvan, > > Thanks again for the prompt help. I was able to change the headers as > needed but I?m stuck with another problem( > > I?ve got opensips with two Ethernet adapters, eth1 as a private and > another one eth0 as public. Opensips works fine when the call is > coming on the public eth0 and leaves opensips through the same public > adapter. (All the GWs are behind that public eth0 instead of one ). > The problem happens when the call comes in through the private eth1, > please see the drawing in attachment. > > -sip1. After I?ve got invite from provider on the private eth1 , I > send it through the public eth0. > > -sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the call to be > able to pass through the opensips and come back from external GW > (x.x.82.139). I also change SIP Request's URI and use uac_replace_to > () to change these fields as needed. > > -sip4. Opensips has got 180 Ringing from external GW (x.x.82.139) > > -sip5. Opensips tries to send it back to originator (10.250.242.74) > which is behind private NIC eth0 (10.197.26.170) > > the call can not be set up because I send reply from my public eth1 > > 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 > > SIP/2.0 *180*Ringing Via: SIP/2.0/UDP > 10.250.242.74:5060;branch=*z9hG4bKqci5ec***Record-Route: > > > Record-Route: > > > From: sip:300940 at domain.com;tag=*2F81324631* > To: > sip:300905 at domain.com:5060;tag=231469dIr894 > Call-ID: > *020A3EA03A8 at SFESIP4-id1-ext*CSeq: 1 INVITE Contact: > > > I?m not sure if I do it right way because the packet (sip5) goes to > 10.250.242.74 with the source ip of public eth0 and not the one it > should pass through to be able to come back. > > What is the right way in my case to get the call through? > > Thank you for all of your help, > > Regards, > > Ehrny > > > > _______________________________________________ > 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: From denis7979 at mail.ru Fri Nov 18 10:43:49 2016 From: denis7979 at mail.ru (Denis) Date: Fri, 18 Nov 2016 12:43:49 +0300 Subject: [OpenSIPS-Users] Memory free problem In-Reply-To: <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> References: <1024256996.20161117101150@ptl.ru> <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> Message-ID: <69131771.20161118124349@ptl.ru> Hello, Bogdan! The log you can find here https://cloud.mail.ru/public/84c1/Fw9VGe2J9 mailto:denis7979 at mail.ru Hi Denis, I do not think they are related. The warnings report some traffic anomalies - a PRACK request for a confirmed dialog (with 200 OK). On the memory part, if the log is correct, it says you have 180M free. What are the ERROR line just after that log ? I want to see which was the module trying to allocate memory. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.11.2016 09:11, Denis wrote: Memory free problem Hello! Today i have a temporary problem with out of free memory (about 4 minutes). Unfortunately, i noticed the problem when everything became fine, so i didn`t make standard procedure of detecting problems with memory which has been described in documentation. In syslog i see such sequence of events. Before the first message about out of free memory "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes left), please increase the "-m" command line parameter!" i see many messages "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c531c95f0 [3855:951170645] with clid '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1' and tags '96x8v2xkj9of92j' '332693C-EF5'" "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c4735d130 [4072:1150064691] with clid 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2' and tags '1czw3nbhw632pzn' '3326728-1DC1'" dialing with two callid. The question is, can such Warning influence on shm. allocation? Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From bogdan at opensips.org Fri Nov 18 15:33:24 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 18 Nov 2016 16:33:24 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> Message-ID: <6117be99-edd6-cb33-d58c-a22469b5ce2f@opensips.org> HI Miha, Sorry, but I'm not able to follow the case you mentioned with Innovaphone PBX - maybe you can post (to see the differences) the sent and returned contact hdrs in the REGISTER request + reply for the 2 cases (OpenSIPS and Innovaphone PBX). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 11:20, Miha wrote: > I do not know if this is the case. But from what I can see what I > register it on some Innovaphone PBX, innovaphone sends back in contact > (200 ok) just ip of IPBX and also when INVITE is send in contact there > is URI of PBX and only and it works. > > i tried this but did not have any luck. > > br > miha > > On 18/11/2016 09:48, Bogdan-Andrei Iancu wrote: >> Hi Miha, >> >> You mean the UAC does not like the multi-URI Contact header in the >> 200 OK ???? If so, that UAC is really broken as 1) breaks the SIP >> syntax (which allows it) and 2) breaks the the SIP Registration as >> per RFC3261. >> >> What about the second contact (the one already existing in usrloc >> when this registration comes) ? can it be discarded ? If YES, you can >> try passing the "c1f" flags to save() : >> http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 >> >> That will make OpenSIPS to accept only 1 contact per AOR/user and any >> new contact will override the existing one. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 18.11.2016 10:15, Miha wrote: >>> Hi Bogdan >>> >>> I did few more test. This contact bothers UAC. Is there anything i >>> can do in this case in OpenSIPS so that it will only reply with one >>> URI in contact? >>> >>> Contact:;expires=1518 >>> ;received="sip:84.41.125.21:5060",; >>> expires=180. >>> >>> >>> tnx so much! >>> MIha >>> >>> On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >>>> Hi Miha, >>>> >>>> yes, that is parallel forking (you may have more than 2 contacts only). >>>> >>>> Are you sure your DB was sync'ed? OpenSIPS is periodically flushing >>>> the memory cache into the location table (see the "state" of the >>>> contact (as per "ul show") if marked as DIRTY). >>>> >>>> In regards to RFC, I think you quote the wrong section (maybe about >>>> callings?) - for REGISTERs, any number of URIs are allowed AFAIK. >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 17.11.2016 12:35, Miha wrote: >>>>> Bodan >>>>> >>>>> so this is dual forking...? >>>>> So if you have one account and you have two phones on it and first >>>>> will try to register, 200 ok will will have contact of both phones? >>>>> In location table I can see only one registration for this user >>>>> but for "opensipsctl ul show" it shows me two contacts, which is >>>>> strange? (When i do trace only one invite is send) and UAC replay >>>>> with Busy all the time due to two contacts (this what i have been >>>>> told). >>>>> >>>>> Ok, but if you look at rfc there is only one URI allowed in >>>>> contact if I understand this right? >>>>> >>>>> >>>>> The Contact header field MUST be present and contain exactly one SIP >>>>> or SIPS URI in any request that can result in the establishment of a >>>>> dialog >>>>> >>>>> Please correct me if I am wrong. tnx so much! Miha >>>>> >>>>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>>>> Hi Miha, >>>>>> >>>>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>>>> registrations for that user (for all the devices the user may have). >>>>>> >>>>>> I guess your user has 2 registrations, so the 200 OK will report >>>>>> back both of them. You can check via "opensipsctl ul show" >>>>>> >>>>>> Regards, >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> On 17.11.2016 12:13, Miha wrote: >>>>>>> Hello Bogdan >>>>>>> >>>>>>> i changed this and it works in all cases, only in one I noticed >>>>>>> today this (Opensips reply only in this case with two URI on >>>>>>> contact): >>>>>>> >>>>>>> UAC:5060 ->OpenSIPS:5060 >>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>>>> Max-Forwards: 70. >>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>> To: 042335040 . >>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>> CSeq: 1804289391 REGISTER. >>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>> PRACK, INFO. >>>>>>> Authorization: Digest >>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>>>> Contact: 042335040 ;ex >>>>>>> pires=3600. >>>>>>> Privacy: none. >>>>>>> Supported: path. >>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>> Content-Length: 0. >>>>>>> >>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>> SIP/2.0 401 Unauthorized. >>>>>>> Via: SIP/2.0/UDP >>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>>>> 5bd7495297c6. >>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>> To: 042335040 ;tag=0c7ff67d927afc274 >>>>>>> b272138ce65100a.ac4d. >>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>> CSeq: 1804289391 REGISTER. >>>>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", >>>>>>> stale=true. >>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>> Content-Length: 0. >>>>>>> >>>>>>> >>>>>>> U UAC:5060 ->OpenSIPS:5060 >>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>>>> Max-Forwards: 70. >>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>> To: 042335040 . >>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>> CSeq: 1804289392 REGISTER. >>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>> PRACK, INFO. >>>>>>> Authorization: Digest >>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>>>> Contact: 042335040 ;ex >>>>>>> pires=3600. >>>>>>> Privacy: none. >>>>>>> Supported: path. >>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>> Content-Length: 0. >>>>>>> . >>>>>>> >>>>>>> >>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>> SIP/2.0 200 OK. >>>>>>> Via: SIP/2.0/UDP >>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>>>> bbf80e346f48. >>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>> To: 042335040 ;tag=766e4f757c55b3450 >>>>>>> c9992a50fb64799-9163. >>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>> CSeq: 1804289392 REGISTER. >>>>>>> Contact: ;expires=3600 >>>>>>> ;received="sip:UAC:5060", >>>>>> > ;expires=119. >>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>> Content-Length: 0. >>>>>>> >>>>>>> Do you see where could be an issue? >>>>>>> >>>>>>> >>>>>>> tnx >>>>>>> miha >>>>>>> >>>>>>> >>>>>>> On 16/11/2016 08:11, Miha wrote: >>>>>>>> Hello Bogdan >>>>>>>> >>>>>>>> yes this was the case... >>>>>>>> >>>>>>>> thank you! >>>>>>>> >>>>>>>> >>>>>>>> br >>>>>>>> miha >>>>>>>> >>>>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>>>> Hi Miha, >>>>>>>>> >>>>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>>>> probably you use fix_nated_contact() instead of >>>>>>>>> fix_nated_register(). >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>> http://www.opensips-solutions.com >>>>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> i need one info. >>>>>>>>>> I have one phone behind NAT and it is registered on OpenSIPS. >>>>>>>>>> IN register packet, which is send to OpenSIPS I can see >>>>>>>>>> contact: "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>>>> >>>>>>>>>> and let says that the public ip for this device is >>>>>>>>>> xxx.xxx.xxx.xxx. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> When opensips sends INVITE it send to right public ip and >>>>>>>>>> right port (source ip and source port generated by router). >>>>>>>>>> The issue is this: >>>>>>>>>> Invite is like: >>>>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and this >>>>>>>>>> request is then fw to this UAC behind router. The UAC replays >>>>>>>>>> to this INVITE with 404 Not found as it is waiting to receive >>>>>>>>>> the same URI which was written in contact (the userpart is >>>>>>>>>> ok, put the ip is public, not private and this is the >>>>>>>>>> issue).From what I can see in RFC this is the case. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Till now Idid not have any issues with this, but now I found >>>>>>>>>> first phone which replays with 404 and from RFC point of view >>>>>>>>>> there should be private ip request :) . So is there anything >>>>>>>>>> I can do :)? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> tnx >>>>>>>>>> miha >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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: From bogdan at opensips.org Fri Nov 18 15:39:23 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 18 Nov 2016 16:39:23 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <6117be99-edd6-cb33-d58c-a22469b5ce2f@opensips.org> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> <6117be99-edd6-cb33-d58c-a22469b5ce2f@opensips.org> Message-ID: <39d25b06-6417-408f-7012-41f993355ed2@opensips.org> I guess your UAC freezes when receiving back in the 200 OK REGISTER the "received" hdr param in Contact ?? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 16:33, Bogdan-Andrei Iancu wrote: > HI Miha, > > Sorry, but I'm not able to follow the case you mentioned with > Innovaphone PBX - maybe you can post (to see the differences) the sent > and returned contact hdrs in the REGISTER request + reply for the 2 > cases (OpenSIPS and Innovaphone PBX). > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 18.11.2016 11:20, Miha wrote: >> I do not know if this is the case. But from what I can see what I >> register it on some Innovaphone PBX, innovaphone sends back in >> contact (200 ok) just ip of IPBX and also when INVITE is send in >> contact there is URI of PBX and only and it works. >> >> i tried this but did not have any luck. >> >> br >> miha >> >> On 18/11/2016 09:48, Bogdan-Andrei Iancu wrote: >>> Hi Miha, >>> >>> You mean the UAC does not like the multi-URI Contact header in the >>> 200 OK ???? If so, that UAC is really broken as 1) breaks the SIP >>> syntax (which allows it) and 2) breaks the the SIP Registration as >>> per RFC3261. >>> >>> What about the second contact (the one already existing in usrloc >>> when this registration comes) ? can it be discarded ? If YES, you >>> can try passing the "c1f" flags to save() : >>> http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 >>> >>> That will make OpenSIPS to accept only 1 contact per AOR/user and >>> any new contact will override the existing one. >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 18.11.2016 10:15, Miha wrote: >>>> Hi Bogdan >>>> >>>> I did few more test. This contact bothers UAC. Is there anything i >>>> can do in this case in OpenSIPS so that it will only reply with one >>>> URI in contact? >>>> >>>> Contact:;expires=1518 >>>> ;received="sip:84.41.125.21:5060",; >>>> expires=180. >>>> >>>> >>>> tnx so much! >>>> MIha >>>> >>>> On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >>>>> Hi Miha, >>>>> >>>>> yes, that is parallel forking (you may have more than 2 contacts >>>>> only). >>>>> >>>>> Are you sure your DB was sync'ed? OpenSIPS is periodically >>>>> flushing the memory cache into the location table (see the "state" >>>>> of the contact (as per "ul show") if marked as DIRTY). >>>>> >>>>> In regards to RFC, I think you quote the wrong section (maybe >>>>> about callings?) - for REGISTERs, any number of URIs are allowed >>>>> AFAIK. >>>>> >>>>> Regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 17.11.2016 12:35, Miha wrote: >>>>>> Bodan >>>>>> >>>>>> so this is dual forking...? >>>>>> So if you have one account and you have two phones on it and >>>>>> first will try to register, 200 ok will will have contact of >>>>>> both phones? >>>>>> In location table I can see only one registration for this user >>>>>> but for "opensipsctl ul show" it shows me two contacts, which is >>>>>> strange? (When i do trace only one invite is send) and UAC replay >>>>>> with Busy all the time due to two contacts (this what i have been >>>>>> told). >>>>>> >>>>>> Ok, but if you look at rfc there is only one URI allowed in >>>>>> contact if I understand this right? >>>>>> >>>>>> >>>>>> The Contact header field MUST be present and contain exactly one SIP >>>>>> or SIPS URI in any request that can result in the establishment of a >>>>>> dialog >>>>>> >>>>>> Please correct me if I am wrong. tnx so much! Miha >>>>>> >>>>>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>>>>> Hi Miha, >>>>>>> >>>>>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>>>>> registrations for that user (for all the devices the user may have). >>>>>>> >>>>>>> I guess your user has 2 registrations, so the 200 OK will report >>>>>>> back both of them. You can check via "opensipsctl ul show" >>>>>>> >>>>>>> Regards, >>>>>>> Bogdan-Andrei Iancu >>>>>>> OpenSIPS Founder and Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> On 17.11.2016 12:13, Miha wrote: >>>>>>>> Hello Bogdan >>>>>>>> >>>>>>>> i changed this and it works in all cases, only in one I noticed >>>>>>>> today this (Opensips reply only in this case with two URI on >>>>>>>> contact): >>>>>>>> >>>>>>>> UAC:5060 ->OpenSIPS:5060 >>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>>>>> Max-Forwards: 70. >>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>> To: 042335040 . >>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>>> PRACK, INFO. >>>>>>>> Authorization: Digest >>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>>>>> Contact: 042335040 ;ex >>>>>>>> pires=3600. >>>>>>>> Privacy: none. >>>>>>>> Supported: path. >>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>> Content-Length: 0. >>>>>>>> >>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>> SIP/2.0 401 Unauthorized. >>>>>>>> Via: SIP/2.0/UDP >>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>>>>> 5bd7495297c6. >>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>> To: 042335040 ;tag=0c7ff67d927afc274 >>>>>>>> b272138ce65100a.ac4d. >>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", >>>>>>>> stale=true. >>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>> Content-Length: 0. >>>>>>>> >>>>>>>> >>>>>>>> U UAC:5060 ->OpenSIPS:5060 >>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>>>>> Max-Forwards: 70. >>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>> To: 042335040 . >>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>>> PRACK, INFO. >>>>>>>> Authorization: Digest >>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>>>>> Contact: 042335040 ;ex >>>>>>>> pires=3600. >>>>>>>> Privacy: none. >>>>>>>> Supported: path. >>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>> Content-Length: 0. >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>> SIP/2.0 200 OK. >>>>>>>> Via: SIP/2.0/UDP >>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>>>>> bbf80e346f48. >>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>> To: 042335040 ;tag=766e4f757c55b3450 >>>>>>>> c9992a50fb64799-9163. >>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>> Contact: ;expires=3600 >>>>>>>> ;received="sip:UAC:5060", >>>>>>> > ;expires=119. >>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>> Content-Length: 0. >>>>>>>> >>>>>>>> Do you see where could be an issue? >>>>>>>> >>>>>>>> >>>>>>>> tnx >>>>>>>> miha >>>>>>>> >>>>>>>> >>>>>>>> On 16/11/2016 08:11, Miha wrote: >>>>>>>>> Hello Bogdan >>>>>>>>> >>>>>>>>> yes this was the case... >>>>>>>>> >>>>>>>>> thank you! >>>>>>>>> >>>>>>>>> >>>>>>>>> br >>>>>>>>> miha >>>>>>>>> >>>>>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>>>>> Hi Miha, >>>>>>>>>> >>>>>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>>>>> probably you use fix_nated_contact() instead of >>>>>>>>>> fix_nated_register(). >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>>> http://www.opensips-solutions.com >>>>>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>>>>> Hello >>>>>>>>>>> >>>>>>>>>>> i need one info. >>>>>>>>>>> I have one phone behind NAT and it is registered on >>>>>>>>>>> OpenSIPS. IN register packet, which is send to OpenSIPS I >>>>>>>>>>> can see contact: >>>>>>>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>>>>> >>>>>>>>>>> and let says that the public ip for this device is >>>>>>>>>>> xxx.xxx.xxx.xxx. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When opensips sends INVITE it send to right public ip and >>>>>>>>>>> right port (source ip and source port generated by router). >>>>>>>>>>> The issue is this: >>>>>>>>>>> Invite is like: >>>>>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and >>>>>>>>>>> this request is then fw to this UAC behind router. The UAC >>>>>>>>>>> replays to this INVITE with 404 Not found as it is waiting >>>>>>>>>>> to receive the same URI which was written in contact (the >>>>>>>>>>> userpart is ok, put the ip is public, not private and this >>>>>>>>>>> is the issue).From what I can see in RFC this is the case. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Till now Idid not have any issues with this, but now I found >>>>>>>>>>> first phone which replays with 404 and from RFC point of >>>>>>>>>>> view there should be private ip request :) . So is there >>>>>>>>>>> anything I can do :)? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> tnx >>>>>>>>>>> miha >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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: From bogdan at opensips.org Fri Nov 18 15:51:49 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 18 Nov 2016 16:51:49 +0200 Subject: [OpenSIPS-Users] Memory free problem In-Reply-To: <69131771.20161118124349@ptl.ru> References: <1024256996.20161117101150@ptl.ru> <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> <69131771.20161118124349@ptl.ru> Message-ID: Hi Denis, It looks to me you have a PRACK request that is looping big time on your OpenSIPS, consuming CPU and memory - see how often the warning with bogus state appears. Check the routing for PRACK. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 11:43, Denis wrote: > Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! > > The log you can find here > https://cloud.mail.ru/public/84c1/Fw9VGe2J9 > > mailto:denis7979 at mail.ru > > > Hi Denis, > > I do not think they are related. The warnings report some traffic > anomalies - a PRACK request for a confirmed dialog (with 200 OK). > > On the memory part, if the log is correct, it says you have 180M free. > What are the ERROR line just after that log ? I want to see which was > the module trying to allocate memory. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 17.11.2016 09:11, Denis wrote: > > Memory free problem Hello! > > Today i have a temporary problem with out of free memory (about 4 > minutes). > Unfortunately, i noticed the problem when everything became fine, so i > didn`t make standard procedure of detecting problems with memory which > has been described in documentation. > > In syslog i see such sequence of events. > > Before the first message about out of free memory > > "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes > left), please increase the "-m" command line parameter!" > > i see many messages > > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c531c95f0 [3855:951170645] with clid > '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1 > ' and tags '96x8v2xkj9of92j' > '332693C-EF5'" > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c4735d130 [4072:1150064691] with clid > 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2 > ' and tags '1czw3nbhw632pzn' > '3326728-1DC1'" > > dialing with two callid. > > The question is, can such Warning influence on shm. allocation? > > Thank you for any help. > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: From mbgatherer at gmail.com Fri Nov 18 18:53:27 2016 From: mbgatherer at gmail.com (Maciej Bylica) Date: Fri, 18 Nov 2016 18:53:27 +0100 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> References: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> Message-ID: Hello As i mentioned before memcached is already installed. I am using innodb_memcache.containers to implement memcached as a plugin. netstat -plnt | grep 9999 tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN 18421/mysqld Everything looks fine i have full transparency, data provided by memcached CLI (telnet) are seen inside innodb table and vise versa. I am using the latest 2.2.2 git opensips rel. and memcached module loaded: loadmodule "cachedb_memcached.so" modparam("cachedb_memcached", "cachedb_url","memcached:default: //localhost:9999,127.0.0.1/") The script i am using is just the basic one, without any additional configuration. Inside the script there is following operation provided: cache_fetch("memcached:default","$tU",$avp(i:601)); Innodb table contains following data: +-------------+-------------+------+------+------+ | id | num | c3 | c4 | c5 | +-------------+-------------+------+------+------+ | 49121112233 | 49121112233 | 0 | 3 | 0 | | 49221112233 | 49221112233 | 0 | 1 | 0 | | 49221112234 | 49221112234 | 0 | 2 | 0 | +-------------+-------------+------+------+------+ Now, i am sending INVITE with tU = 49121112233 and getting proper behavior which means: - no error inside the opensips.log, xlog following cache_fetch returns correct $avp(i:601) - mysqld.log shows <95 get 49121112233 >95 sending key 49121112233 >95 END but really strange is that calling tU = 49221112233 is causing quite opposite results: - following error is shown DBG:core:cachedb_fetch: from script [memcached] - with grp [default] ERROR:cachedb_memcached:wrap_memcached_get: Failed to get: SYSTEM ERROR - no mysqld debug is produced The last one example(tU = 49221112234)is failing with the same error. Memcached is loaded with all those data Connected to localhost. Escape character is '^]'. get 49221112233 VALUE 49221112233 0 11 49221112233 END get 49221112234 VALUE 49221112234 0 11 49221112234 END but because of some reasons memcached module is not utilized. As aforementioned, opensips script does not have any $rU filtering setup, so should query for any data it is asked for. Maybe i am wrong with some of my assumptions or the way memcached is configured, so kindly help me to understand where the problem is located. Thanks Maciej. 2016-11-15 18:09 GMT+01:00 Bogdan-Andrei Iancu : > OK, thank you for the update Maciej, > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 15.11.2016 18:28, Maciej Bylica wrote: > > Hi Bogdan, > > Thanks for reply. > Right, Opensips module was not the source of the problem. > I've managed to solve the issue, memcache is working fine. > > Thanks > Maciej. > > 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu : > >> Hi Maciej, >> >> As I see, you are manually compiling and installing the memcached stuff - >> any special reason for doing that ? (versus using packages) >> >> As the problem seems to be in the lib, not in the OpenSIPS module. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 09.11.2016 18:41, Maciej Bylica wrote: >> >> Hello I am struggling with memcached installation with the latest git >> opensips 2.2.2 and centos 6.8 Here are version releases i am using: >> libmemcached-1.0.18 (./configure, make && make install) memcached-1.4.33 >> (./configure, make && make install) with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH >> memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 does not produce any error >> but what is really puzzling me during the opensips start is the error >> below: DBG:core:load_module: loading module /usr/local/lib64/opensips/modules/cachedb_memcached.so >> ERROR:core:sr_load_module: could not open module >> : >> /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once Can >> someone please guide me how to put memcached up and running ? >> Opensips is compiled with cachedb_memcached module. >> Thanks in advance. >> Maciej >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Fri Nov 18 18:54:37 2016 From: miha at softnet.si (Miha) Date: Fri, 18 Nov 2016 18:54:37 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <39d25b06-6417-408f-7012-41f993355ed2@opensips.org> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> <6117be99-edd6-cb33-d58c-a22469b5ce2f@opensips.org> <39d25b06-6417-408f-7012-41f993355ed2@opensips.org> Message-ID: <0bbecaee-0958-c06c-d9e4-e21ee3815d96@softnet.si> Hello bogdan I guess, but it looks like so. Is it possible to remove it? tnx miha On 18/11/2016 15:39, Bogdan-Andrei Iancu wrote: > I guess your UAC freezes when receiving back in the 200 OK REGISTER > the "received" hdr param in Contact ?? > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 18.11.2016 16:33, Bogdan-Andrei Iancu wrote: >> HI Miha, >> >> Sorry, but I'm not able to follow the case you mentioned with >> Innovaphone PBX - maybe you can post (to see the differences) the >> sent and returned contact hdrs in the REGISTER request + reply for >> the 2 cases (OpenSIPS and Innovaphone PBX). >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 18.11.2016 11:20, Miha wrote: >>> I do not know if this is the case. But from what I can see what I >>> register it on some Innovaphone PBX, innovaphone sends back in >>> contact (200 ok) just ip of IPBX and also when INVITE is send in >>> contact there is URI of PBX and only and it works. >>> >>> i tried this but did not have any luck. >>> >>> br >>> miha >>> >>> On 18/11/2016 09:48, Bogdan-Andrei Iancu wrote: >>>> Hi Miha, >>>> >>>> You mean the UAC does not like the multi-URI Contact header in the >>>> 200 OK ???? If so, that UAC is really broken as 1) breaks the SIP >>>> syntax (which allows it) and 2) breaks the the SIP Registration as >>>> per RFC3261. >>>> >>>> What about the second contact (the one already existing in usrloc >>>> when this registration comes) ? can it be discarded ? If YES, you >>>> can try passing the "c1f" flags to save() : >>>> http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 >>>> >>>> That will make OpenSIPS to accept only 1 contact per AOR/user and >>>> any new contact will override the existing one. >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 18.11.2016 10:15, Miha wrote: >>>>> Hi Bogdan >>>>> >>>>> I did few more test. This contact bothers UAC. Is there anything i >>>>> can do in this case in OpenSIPS so that it will only reply with >>>>> one URI in contact? >>>>> >>>>> Contact:;expires=1518 >>>>> ;received="sip:84.41.125.21:5060",; >>>>> expires=180. >>>>> >>>>> >>>>> tnx so much! >>>>> MIha >>>>> >>>>> On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >>>>>> Hi Miha, >>>>>> >>>>>> yes, that is parallel forking (you may have more than 2 contacts >>>>>> only). >>>>>> >>>>>> Are you sure your DB was sync'ed? OpenSIPS is periodically >>>>>> flushing the memory cache into the location table (see the >>>>>> "state" of the contact (as per "ul show") if marked as DIRTY). >>>>>> >>>>>> In regards to RFC, I think you quote the wrong section (maybe >>>>>> about callings?) - for REGISTERs, any number of URIs are allowed >>>>>> AFAIK. >>>>>> >>>>>> Regards, >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> On 17.11.2016 12:35, Miha wrote: >>>>>>> Bodan >>>>>>> >>>>>>> so this is dual forking...? >>>>>>> So if you have one account and you have two phones on it and >>>>>>> first will try to register, 200 ok will will have contact of >>>>>>> both phones? >>>>>>> In location table I can see only one registration for this user >>>>>>> but for "opensipsctl ul show" it shows me two contacts, which is >>>>>>> strange? (When i do trace only one invite is send) and UAC >>>>>>> replay with Busy all the time due to two contacts (this what i >>>>>>> have been told). >>>>>>> >>>>>>> Ok, but if you look at rfc there is only one URI allowed in >>>>>>> contact if I understand this right? >>>>>>> >>>>>>> >>>>>>> The Contact header field MUST be present and contain exactly one SIP >>>>>>> or SIPS URI in any request that can result in the establishment of a >>>>>>> dialog >>>>>>> >>>>>>> Please correct me if I am wrong. >>>>>>> >>>>>>> >>>>>>> tnx so much! >>>>>>> Miha >>>>>>> >>>>>>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>>>>>> Hi Miha, >>>>>>>> >>>>>>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>>>>>> registrations for that user (for all the devices the user may >>>>>>>> have). >>>>>>>> >>>>>>>> I guess your user has 2 registrations, so the 200 OK will >>>>>>>> report back both of them. You can check via "opensipsctl ul show" >>>>>>>> >>>>>>>> Regards, >>>>>>>> Bogdan-Andrei Iancu >>>>>>>> OpenSIPS Founder and Developer >>>>>>>> http://www.opensips-solutions.com >>>>>>>> On 17.11.2016 12:13, Miha wrote: >>>>>>>>> Hello Bogdan >>>>>>>>> >>>>>>>>> i changed this and it works in all cases, only in one I >>>>>>>>> noticed today this (Opensips reply only in this case with two >>>>>>>>> URI on contact): >>>>>>>>> >>>>>>>>> UAC:5060 ->OpenSIPS:5060 >>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>>>>>> Max-Forwards: 70. >>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>> To: 042335040 . >>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>>>> PRACK, INFO. >>>>>>>>> Authorization: Digest >>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>>>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>>>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>>>>>> Contact: 042335040 >>>>>>>>> ;ex >>>>>>>>> pires=3600. >>>>>>>>> Privacy: none. >>>>>>>>> Supported: path. >>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>>> Content-Length: 0. >>>>>>>>> >>>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>>> SIP/2.0 401 Unauthorized. >>>>>>>>> Via: SIP/2.0/UDP >>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>>>>>> 5bd7495297c6. >>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>> To: 042335040 >>>>>>>>> ;tag=0c7ff67d927afc274 >>>>>>>>> b272138ce65100a.ac4d. >>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>>>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", >>>>>>>>> stale=true. >>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>>> Content-Length: 0. >>>>>>>>> >>>>>>>>> >>>>>>>>> U UAC:5060 ->OpenSIPS:5060 >>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>>>>>> Max-Forwards: 70. >>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>> To: 042335040 . >>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>>>> PRACK, INFO. >>>>>>>>> Authorization: Digest >>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>>>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>>>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>>>>>> Contact: 042335040 >>>>>>>>> ;ex >>>>>>>>> pires=3600. >>>>>>>>> Privacy: none. >>>>>>>>> Supported: path. >>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>>> Content-Length: 0. >>>>>>>>> . >>>>>>>>> >>>>>>>>> >>>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>>> SIP/2.0 200 OK. >>>>>>>>> Via: SIP/2.0/UDP >>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>>>>>> bbf80e346f48. >>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>> To: 042335040 >>>>>>>>> ;tag=766e4f757c55b3450 >>>>>>>>> c9992a50fb64799-9163. >>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>>> Contact: >>>>>>>>> ;expires=3600 >>>>>>>>> ;received="sip:UAC:5060", >>>>>>>> > ;expires=119. >>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>>> Content-Length: 0. >>>>>>>>> >>>>>>>>> Do you see where could be an issue? >>>>>>>>> >>>>>>>>> >>>>>>>>> tnx >>>>>>>>> miha >>>>>>>>> >>>>>>>>> >>>>>>>>> On 16/11/2016 08:11, Miha wrote: >>>>>>>>>> Hello Bogdan >>>>>>>>>> >>>>>>>>>> yes this was the case... >>>>>>>>>> >>>>>>>>>> thank you! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> br >>>>>>>>>> miha >>>>>>>>>> >>>>>>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>>>>>> Hi Miha, >>>>>>>>>>> >>>>>>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>>>>>> probably you use fix_nated_contact() instead of >>>>>>>>>>> fix_nated_register(). >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>>>> http://www.opensips-solutions.com >>>>>>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>>>>>> Hello >>>>>>>>>>>> >>>>>>>>>>>> i need one info. >>>>>>>>>>>> I have one phone behind NAT and it is registered on >>>>>>>>>>>> OpenSIPS. IN register packet, which is send to OpenSIPS I >>>>>>>>>>>> can see contact: >>>>>>>>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>>>>>> >>>>>>>>>>>> and let says that the public ip for this device is >>>>>>>>>>>> xxx.xxx.xxx.xxx. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When opensips sends INVITE it send to right public ip and >>>>>>>>>>>> right port (source ip and source port generated by router). >>>>>>>>>>>> The issue is this: >>>>>>>>>>>> Invite is like: >>>>>>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and >>>>>>>>>>>> this request is then fw to this UAC behind router. The UAC >>>>>>>>>>>> replays to this INVITE with 404 Not found as it is waiting >>>>>>>>>>>> to receive the same URI which was written in contact (the >>>>>>>>>>>> userpart is ok, put the ip is public, not private and this >>>>>>>>>>>> is the issue).From what I can see in RFC this is the case. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Till now Idid not have any issues with this, but now I >>>>>>>>>>>> found first phone which replays with 404 and from RFC point >>>>>>>>>>>> of view there should be private ip request :) . So is there >>>>>>>>>>>> anything I can do :)? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> tnx >>>>>>>>>>>> miha >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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: From pat at voxtelesys.com Fri Nov 18 23:20:55 2016 From: pat at voxtelesys.com (Pat Burke) Date: Fri, 18 Nov 2016 16:20:55 -0600 Subject: [OpenSIPS-Users] Error creating presence tables with MySQL 5.7 Message-ID: <1682b792bb71e134380e59c6a919b5ec@voxtelesys.com> When running "opensipsdbctl create" I get the following error message. Install presence related tables? (y/n): y INFO: creating presence tables into opensips_2_2 ... mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1101 (42000) at line 2: BLOB, TEXT, GEOMETRY or JSON column 'extra_hdrs' can't have a default value ERROR: Failed to create presence tables! Regards, Pat Burke -------------- next part -------------- An HTML attachment was scrubbed... URL: From wasphin at gmail.com Sat Nov 19 09:57:27 2016 From: wasphin at gmail.com (xiaofeng) Date: Sat, 19 Nov 2016 16:57:27 +0800 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> Message-ID: >> I?ve got opensips with two Ethernet adapters, eth1 as a private and another one eth0 as public. Opensips works fine when the call is coming on the public eth0 and leaves opensips through the same public adapter. (All the GWs are behind that public eth0 instead of one ). The problem happens when the call comes in through the private eth1, please see the drawing in attachment. >> This maybe helpful. https://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc72 _______________________________________________ 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: From wasphin at gmail.com Sat Nov 19 11:27:47 2016 From: wasphin at gmail.com (xiaofeng) Date: Sat, 19 Nov 2016 18:27:47 +0800 Subject: [OpenSIPS-Users] Rtpproxy and IPV4 IPV6 interworking In-Reply-To: References: <1779817.2kyhvzfVrv@blacky.mylan> <2780361.W64aQsUSPm@blacky.mylan> <2566829.ExfhvV83KV@blacky.mylan> Message-ID: Hi, Robert, Does rtpproxy _autobridge work? http://www.opensips.org/html/docs/modules/1.11.x/rtpproxy#id293590 Regards, xiaofeng _______________________________________________ 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: From y at jettel.ru Sat Nov 19 12:06:03 2016 From: y at jettel.ru (Ehrny) Date: Sat, 19 Nov 2016 11:06:03 +0000 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> Hi R?zvan, I gues so. I?ve got t_on_reply("1"); in the route and at the end of the script there is: onreply_route[1] { force_send_socket(udp:10.197.26.170:5060); } But it doesn?t seem to change send_socket back to priv IP addr (( Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Friday, November 18, 2016 12:22 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! Did you try setting the private socket on the reply? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/17/2016 01:00 AM, Ehrny wrote: Dear R?zvan, Thanks again for the prompt help. I was able to change the headers as needed but I?m stuck with another problem( I?ve got opensips with two Ethernet adapters, eth1 as a private and another one eth0 as public. Opensips works fine when the call is coming on the public eth0 and leaves opensips through the same public adapter. (All the GWs are behind that public eth0 instead of one ). The problem happens when the call comes in through the private eth1, please see the drawing in attachment. - sip1. After I?ve got invite from provider on the private eth1 , I send it through the public eth0. - sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the call to be able to pass through the opensips and come back from external GW (x.x.82.139). I also change SIP Request's URI and use uac_replace_to () to change these fields as needed. - sip4. Opensips has got 180 Ringing from external GW (x.x.82.139) - sip5. Opensips tries to send it back to originator (10.250.242.74) which is behind private NIC eth0 (10.197.26.170) the call can not be set up because I send reply from my public eth1 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.250.242.74:5060;branch=z9hG4bKqci5ec Record-Route: > Record-Route: > From: sip:300940 at domain.com;tag=2F81324631 To: sip:300905 at domain.com:5060;tag=231469dIr894 Call-ID: 020A3EA03A8 at SFESIP4-id1-ext CSeq: 1 INVITE Contact: I?m not sure if I do it right way because the packet (sip5) goes to 10.250.242.74 with the source ip of public eth0 and not the one it should pass through to be able to come back. What is the right way in my case to get the call through? Thank you for all of your help, Regards, Ehrny _______________________________________________ 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: From y at jettel.ru Sat Nov 19 21:40:48 2016 From: y at jettel.ru (Ehrny) Date: Sat, 19 Nov 2016 20:40:48 +0000 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> Dear R?zvan, ? I?ve tried to add variable to onreply_route[1] $var(upstream0) = $(hdr(Via)[0]{via.param,received}); xlog("upstream0 = $var(upstream0) \n"); and in the log I get critical alert: CRITICAL:tm:tm_pv_context_reply: no picked branch (-1) for a final response From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Ehrny Sent: Saturday, November 19, 2016 2:06 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] $ai transformation Hi R?zvan, I gues so. I?ve got t_on_reply("1"); in the route and at the end of the script there is: onreply_route[1] { force_send_socket(udp:10.197.26.170:5060); } But it doesn?t seem to change send_socket back to priv IP addr (( Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Friday, November 18, 2016 12:22 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! Did you try setting the private socket on the reply? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/17/2016 01:00 AM, Ehrny wrote: Dear R?zvan, Thanks again for the prompt help. I was able to change the headers as needed but I?m stuck with another problem( I?ve got opensips with two Ethernet adapters, eth1 as a private and another one eth0 as public. Opensips works fine when the call is coming on the public eth0 and leaves opensips through the same public adapter. (All the GWs are behind that public eth0 instead of one ). The problem happens when the call comes in through the private eth1, please see the drawing in attachment. - sip1. After I?ve got invite from provider on the private eth1 , I send it through the public eth0. - sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the call to be able to pass through the opensips and come back from external GW (x.x.82.139). I also change SIP Request's URI and use uac_replace_to () to change these fields as needed. - sip4. Opensips has got 180 Ringing from external GW (x.x.82.139) - sip5. Opensips tries to send it back to originator (10.250.242.74) which is behind private NIC eth0 (10.197.26.170) the call can not be set up because I send reply from my public eth1 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.250.242.74:5060;branch=z9hG4bKqci5ec Record-Route: > Record-Route: > From: sip:300940 at domain.com;tag=2F81324631 To: sip:300905 at domain.com:5060;tag=231469dIr894 Call-ID: 020A3EA03A8 at SFESIP4-id1-ext CSeq: 1 INVITE Contact: I?m not sure if I do it right way because the packet (sip5) goes to 10.250.242.74 with the source ip of public eth0 and not the one it should pass through to be able to come back. What is the right way in my case to get the call through? Thank you for all of your help, Regards, Ehrny _______________________________________________ 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: From denis7979 at mail.ru Mon Nov 21 09:24:44 2016 From: denis7979 at mail.ru (Denis) Date: Mon, 21 Nov 2016 11:24:44 +0300 Subject: [OpenSIPS-Users] Memory free problem In-Reply-To: References: <1024256996.20161117101150@ptl.ru> <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> <69131771.20161118124349@ptl.ru> Message-ID: <848316507.20161121112444@ptl.ru> Hello, Bogdan! Yes, the ngrep shows that PRACK has been received, but not sent to dest SIP UA. The question is, why "is looping big time on your OpenSIPS"? Here you can find SIP log of one of the call, mentioned early, with callid '4gk2hpk433lgdt1d6ys7ifkwd' https://cloud.mail.ru/public/BvpZ/SJHLQmqEZ In the log: 1.1.1.1 - Caller 2.2.2.2 - Opensips 3.3.3.3 - Callee Top hiding has been applied for this call. Thank you. mailto:denis7979 at mail.ru Hi Denis, It looks to me you have a PRACK request that is looping big time on your OpenSIPS, consuming CPU and memory - see how often the warning with bogus state appears. Check the routing for PRACK. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 11:43, Denis wrote: Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! The log you can find here https://cloud.mail.ru/public/84c1/Fw9VGe2J9 mailto:denis7979 at mail.ru Hi Denis, I do not think they are related. The warnings report some traffic anomalies - a PRACK request for a confirmed dialog (with 200 OK). On the memory part, if the log is correct, it says you have 180M free. What are the ERROR line just after that log ? I want to see which was the module trying to allocate memory. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.11.2016 09:11, Denis wrote: Memory free problem Hello! Today i have a temporary problem with out of free memory (about 4 minutes). Unfortunately, i noticed the problem when everything became fine, so i didn`t make standard procedure of detecting problems with memory which has been described in documentation. In syslog i see such sequence of events. Before the first message about out of free memory "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes left), please increase the "-m" command line parameter!" i see many messages "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c531c95f0 [3855:951170645] with clid '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1' and tags '96x8v2xkj9of92j' '332693C-EF5'" "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c4735d130 [4072:1150064691] with clid 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2' and tags '1czw3nbhw632pzn' '3326728-1DC1'" dialing with two callid. The question is, can such Warning influence on shm. allocation? Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From razvan at opensips.org Mon Nov 21 09:50:27 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 21 Nov 2016 10:50:27 +0200 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> Message-ID: Hi, Ehrny! You don't need to use contexts in the onreply_route[], because that route is already ran in the context of the reply message. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/19/2016 10:40 PM, Ehrny wrote: > > Dear R?zvan, > > ? I?ve tried to add variable to onreply_route[1] > > $var(upstream0) = $(hdr(Via)[0]{via.param,received}); > > xlog("upstream0 = $var(upstream0) \n"); > > and in the log I get critical alert: > > CRITICAL:tm:tm_pv_context_reply: no picked branch (-1) for a final > response > > *From:*users-bounces at lists.opensips.org > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Ehrny > *Sent:* Saturday, November 19, 2016 2:06 PM > *To:* OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi R?zvan, > > I gues so. > > I?ve got t_on_reply("1"); in the route > > and at the end of the script there is: > > onreply_route[1] { > > force_send_socket(udp:10.197.26.170:5060); > > } > > But it doesn?t seem to change send_socket back to priv IP addr (( > > Kind regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan Crainea > *Sent:* Friday, November 18, 2016 12:22 PM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > Did you try setting the private socket on the reply? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/17/2016 01:00 AM, Ehrny wrote: > > Dear R?zvan, > > Thanks again for the prompt help. I was able to change the headers > as needed but I?m stuck with another problem( > > I?ve got opensips with two Ethernet adapters, eth1 as a private > and another one eth0 as public. Opensips works fine when the call > is coming on the public eth0 and leaves opensips through the same > public adapter. (All the GWs are behind that public eth0 instead > of one ). The problem happens when the call comes in through the > private eth1, please see the drawing in attachment. > > -sip1. After I?ve got invite from provider on the private eth1 , > I send it through the public eth0. > > -sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the call > to be able to pass through the opensips and come back from > external GW (x.x.82.139). I also change SIP Request's URI and use > uac_replace_to () to change these fields as needed. > > -sip4. Opensips has got 180 Ringing from external GW (x.x.82.139) > > -sip5. Opensips tries to send it back to originator > (10.250.242.74) which is behind private NIC eth0 (10.197.26.170) > > the call can not be set up because I send reply from my public eth1 > > 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 > > SIP/2.0 *180* Ringing Via: SIP/2.0/UDP > 10.250.242.74:5060;branch=*z9hG4bKqci5ec *Record-Route: > > > Record-Route: > > > From: sip:300940 at domain.com;tag=*2F81324631* > To: > sip:300905 at domain.com:5060;tag=231469dIr894 > Call-ID: > *020A3EA03A8 at SFESIP4-id1-ext* CSeq: 1 INVITE Contact: > > > I?m not sure if I do it right way because the packet (sip5) goes > to 10.250.242.74 with the source ip of public eth0 and not the one > it should pass through to be able to come back. > > What is the right way in my case to get the call through? > > Thank you for all of your help, > > Regards, > > Ehrny > > > > _______________________________________________ > > 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: From y at jettel.ru Mon Nov 21 11:13:57 2016 From: y at jettel.ru (Ehrny) Date: Mon, 21 Nov 2016 10:13:57 +0000 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> Hello R?zvan, I need to do some routing in onreply_route[] based on destination IP. Tried $rd with no avail , it returns null If I get you right regarding context, the var $var(upstream0) = $(hdr(Via)[0]{via.received}); Is empty also. What is the right way to get an IP address in replies and do further routing? Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 21, 2016 11:50 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! You don't need to use contexts in the onreply_route[], because that route is already ran in the context of the reply message. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/19/2016 10:40 PM, Ehrny wrote: Dear R?zvan, ? I?ve tried to add variable to onreply_route[1] $var(upstream0) = $(hdr(Via)[0]{via.param,received}); xlog("upstream0 = $var(upstream0) \n"); and in the log I get critical alert: CRITICAL:tm:tm_pv_context_reply: no picked branch (-1) for a final response From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Ehrny Sent: Saturday, November 19, 2016 2:06 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] $ai transformation Hi R?zvan, I gues so. I?ve got t_on_reply("1"); in the route and at the end of the script there is: onreply_route[1] { force_send_socket(udp:10.197.26.170:5060); } But it doesn?t seem to change send_socket back to priv IP addr (( Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Friday, November 18, 2016 12:22 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! Did you try setting the private socket on the reply? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/17/2016 01:00 AM, Ehrny wrote: Dear R?zvan, Thanks again for the prompt help. I was able to change the headers as needed but I?m stuck with another problem( I?ve got opensips with two Ethernet adapters, eth1 as a private and another one eth0 as public. Opensips works fine when the call is coming on the public eth0 and leaves opensips through the same public adapter. (All the GWs are behind that public eth0 instead of one ). The problem happens when the call comes in through the private eth1, please see the drawing in attachment. - sip1. After I?ve got invite from provider on the private eth1 , I send it through the public eth0. - sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the call to be able to pass through the opensips and come back from external GW (x.x.82.139). I also change SIP Request's URI and use uac_replace_to () to change these fields as needed. - sip4. Opensips has got 180 Ringing from external GW (x.x.82.139) - sip5. Opensips tries to send it back to originator (10.250.242.74) which is behind private NIC eth0 (10.197.26.170) the call can not be set up because I send reply from my public eth1 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.250.242.74:5060;branch=z9hG4bKqci5ec Record-Route: > Record-Route: > From: sip:300940 at domain.com;tag=2F81324631 To: sip:300905 at domain.com:5060;tag=231469dIr894 Call-ID: 020A3EA03A8 at SFESIP4-id1-ext CSeq: 1 INVITE Contact: I?m not sure if I do it right way because the packet (sip5) goes to 10.250.242.74 with the source ip of public eth0 and not the one it should pass through to be able to come back. What is the right way in my case to get the call through? Thank you for all of your help, Regards, Ehrny _______________________________________________ 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: From bogdan at opensips.org Mon Nov 21 11:13:34 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 21 Nov 2016 12:13:34 +0200 Subject: [OpenSIPS-Users] nat issue In-Reply-To: <0bbecaee-0958-c06c-d9e4-e21ee3815d96@softnet.si> References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> <6117be99-edd6-cb33-d58c-a22469b5ce2f@opensips.org> <39d25b06-6417-408f-7012-41f993355ed2@opensips.org> <0bbecaee-0958-c06c-d9e4-e21ee3815d96@softnet.si> Message-ID: Hi Miha, According the SIP grammar, that parameter is perfectly legitimate. The client is broken as it is not able to cope with it (in the worst case, to simply ignore it). There is no out of the box way to disable it, but I may provide you a patch for that - just to see if that fixes your problem. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 19:54, Miha wrote: > Hello bogdan > > I guess, but it looks like so. Is it possible to remove it? > > > tnx > miha > > On 18/11/2016 15:39, Bogdan-Andrei Iancu wrote: >> I guess your UAC freezes when receiving back in the 200 OK REGISTER >> the "received" hdr param in Contact ?? >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 18.11.2016 16:33, Bogdan-Andrei Iancu wrote: >>> HI Miha, >>> >>> Sorry, but I'm not able to follow the case you mentioned with >>> Innovaphone PBX - maybe you can post (to see the differences) the >>> sent and returned contact hdrs in the REGISTER request + reply for >>> the 2 cases (OpenSIPS and Innovaphone PBX). >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 18.11.2016 11:20, Miha wrote: >>>> I do not know if this is the case. But from what I can see what I >>>> register it on some Innovaphone PBX, innovaphone sends back in >>>> contact (200 ok) just ip of IPBX and also when INVITE is send in >>>> contact there is URI of PBX and only and it works. >>>> >>>> i tried this but did not have any luck. >>>> >>>> br >>>> miha >>>> >>>> On 18/11/2016 09:48, Bogdan-Andrei Iancu wrote: >>>>> Hi Miha, >>>>> >>>>> You mean the UAC does not like the multi-URI Contact header in the >>>>> 200 OK ???? If so, that UAC is really broken as 1) breaks the SIP >>>>> syntax (which allows it) and 2) breaks the the SIP Registration as >>>>> per RFC3261. >>>>> >>>>> What about the second contact (the one already existing in usrloc >>>>> when this registration comes) ? can it be discarded ? If YES, you >>>>> can try passing the "c1f" flags to save() : >>>>> http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 >>>>> >>>>> That will make OpenSIPS to accept only 1 contact per AOR/user and >>>>> any new contact will override the existing one. >>>>> >>>>> Regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 18.11.2016 10:15, Miha wrote: >>>>>> Hi Bogdan >>>>>> >>>>>> I did few more test. This contact bothers UAC. Is there anything >>>>>> i can do in this case in OpenSIPS so that it will only reply with >>>>>> one URI in contact? >>>>>> >>>>>> Contact:;expires=1518 >>>>>> ;received="sip:84.41.125.21:5060",; >>>>>> expires=180. >>>>>> >>>>>> >>>>>> tnx so much! >>>>>> MIha >>>>>> >>>>>> On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >>>>>>> Hi Miha, >>>>>>> >>>>>>> yes, that is parallel forking (you may have more than 2 contacts >>>>>>> only). >>>>>>> >>>>>>> Are you sure your DB was sync'ed? OpenSIPS is periodically >>>>>>> flushing the memory cache into the location table (see the >>>>>>> "state" of the contact (as per "ul show") if marked as DIRTY). >>>>>>> >>>>>>> In regards to RFC, I think you quote the wrong section (maybe >>>>>>> about callings?) - for REGISTERs, any number of URIs are allowed >>>>>>> AFAIK. >>>>>>> >>>>>>> Regards, >>>>>>> Bogdan-Andrei Iancu >>>>>>> OpenSIPS Founder and Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> On 17.11.2016 12:35, Miha wrote: >>>>>>>> Bodan >>>>>>>> >>>>>>>> so this is dual forking...? >>>>>>>> So if you have one account and you have two phones on it and >>>>>>>> first will try to register, 200 ok will will have contact of >>>>>>>> both phones? >>>>>>>> In location table I can see only one registration for this user >>>>>>>> but for "opensipsctl ul show" it shows me two contacts, which >>>>>>>> is strange? (When i do trace only one invite is send) and UAC >>>>>>>> replay with Busy all the time due to two contacts (this what i >>>>>>>> have been told). >>>>>>>> >>>>>>>> Ok, but if you look at rfc there is only one URI allowed in >>>>>>>> contact if I understand this right? >>>>>>>> >>>>>>>> >>>>>>>> The Contact header field MUST be present and contain exactly one SIP >>>>>>>> or SIPS URI in any request that can result in the establishment of a >>>>>>>> dialog >>>>>>>> >>>>>>>> Please correct me if I am wrong. >>>>>>>> >>>>>>>> >>>>>>>> tnx so much! >>>>>>>> Miha >>>>>>>> >>>>>>>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>>>>>>> Hi Miha, >>>>>>>>> >>>>>>>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>>>>>>> registrations for that user (for all the devices the user may >>>>>>>>> have). >>>>>>>>> >>>>>>>>> I guess your user has 2 registrations, so the 200 OK will >>>>>>>>> report back both of them. You can check via "opensipsctl ul show" >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>> http://www.opensips-solutions.com >>>>>>>>> On 17.11.2016 12:13, Miha wrote: >>>>>>>>>> Hello Bogdan >>>>>>>>>> >>>>>>>>>> i changed this and it works in all cases, only in one I >>>>>>>>>> noticed today this (Opensips reply only in this case with two >>>>>>>>>> URI on contact): >>>>>>>>>> >>>>>>>>>> UAC:5060 ->OpenSIPS:5060 >>>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>>>>>>> Max-Forwards: 70. >>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>> To: 042335040 . >>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>>>>> PRACK, INFO. >>>>>>>>>> Authorization: Digest >>>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>>>>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>>>>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>>>>>>> Contact: 042335040 >>>>>>>>>> ;ex >>>>>>>>>> pires=3600. >>>>>>>>>> Privacy: none. >>>>>>>>>> Supported: path. >>>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>>>> Content-Length: 0. >>>>>>>>>> >>>>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>>>> SIP/2.0 401 Unauthorized. >>>>>>>>>> Via: SIP/2.0/UDP >>>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>>>>>>> 5bd7495297c6. >>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>> To: 042335040 >>>>>>>>>> ;tag=0c7ff67d927afc274 >>>>>>>>>> b272138ce65100a.ac4d. >>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>>>>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", >>>>>>>>>> stale=true. >>>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>>>> Content-Length: 0. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> U UAC:5060 ->OpenSIPS:5060 >>>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>>>>>>> Max-Forwards: 70. >>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>> To: 042335040 . >>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, >>>>>>>>>> PRACK, INFO. >>>>>>>>>> Authorization: Digest >>>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>>>>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>>>>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>>>>>>> Contact: 042335040 >>>>>>>>>> ;ex >>>>>>>>>> pires=3600. >>>>>>>>>> Privacy: none. >>>>>>>>>> Supported: path. >>>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>>>> Content-Length: 0. >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>>>> SIP/2.0 200 OK. >>>>>>>>>> Via: SIP/2.0/UDP >>>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>>>>>>> bbf80e346f48. >>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>> To: 042335040 >>>>>>>>>> ;tag=766e4f757c55b3450 >>>>>>>>>> c9992a50fb64799-9163. >>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>>>> Contact: >>>>>>>>>> ;expires=3600 >>>>>>>>>> ;received="sip:UAC:5060", >>>>>>>>> > ;expires=119. >>>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>>>> Content-Length: 0. >>>>>>>>>> >>>>>>>>>> Do you see where could be an issue? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> tnx >>>>>>>>>> miha >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 16/11/2016 08:11, Miha wrote: >>>>>>>>>>> Hello Bogdan >>>>>>>>>>> >>>>>>>>>>> yes this was the case... >>>>>>>>>>> >>>>>>>>>>> thank you! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> br >>>>>>>>>>> miha >>>>>>>>>>> >>>>>>>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>>>>>>> Hi Miha, >>>>>>>>>>>> >>>>>>>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>>>>>>> probably you use fix_nated_contact() instead of >>>>>>>>>>>> fix_nated_register(). >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>>>>> http://www.opensips-solutions.com >>>>>>>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>>>>>>> Hello >>>>>>>>>>>>> >>>>>>>>>>>>> i need one info. >>>>>>>>>>>>> I have one phone behind NAT and it is registered on >>>>>>>>>>>>> OpenSIPS. IN register packet, which is send to OpenSIPS I >>>>>>>>>>>>> can see contact: >>>>>>>>>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>>>>>>> >>>>>>>>>>>>> and let says that the public ip for this device is >>>>>>>>>>>>> xxx.xxx.xxx.xxx. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> When opensips sends INVITE it send to right public ip and >>>>>>>>>>>>> right port (source ip and source port generated by >>>>>>>>>>>>> router). The issue is this: >>>>>>>>>>>>> Invite is like: >>>>>>>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and >>>>>>>>>>>>> this request is then fw to this UAC behind router. The UAC >>>>>>>>>>>>> replays to this INVITE with 404 Not found as it is waiting >>>>>>>>>>>>> to receive the same URI which was written in contact (the >>>>>>>>>>>>> userpart is ok, put the ip is public, not private and this >>>>>>>>>>>>> is the issue).From what I can see in RFC this is the case. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Till now Idid not have any issues with this, but now I >>>>>>>>>>>>> found first phone which replays with 404 and from RFC >>>>>>>>>>>>> point of view there should be private ip request :) . So >>>>>>>>>>>>> is there anything I can do :)? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> tnx >>>>>>>>>>>>> miha >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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: From razvan at opensips.org Mon Nov 21 11:31:40 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 21 Nov 2016 12:31:40 +0200 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> Message-ID: Hi, Ehrny! You need the IP address of whom? Caller? Callee? $rd is null because a reply does not have a R-URI. Perhaps the reply doesn't have a received parameter in the reply either, that's why it is empty. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/21/2016 12:13 PM, Ehrny wrote: > > Hello R?zvan, > > I need to do some routing in onreply_route[] based on destination IP. > > Tried $rd with no avail , it returns null > > If I get you right regarding context, the var $var(upstream0) = > $(hdr(Via)[0]{via.received}); Is empty also. > > What is the right way to get an IP address in replies and do further > routing? > > Kind regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan Crainea > *Sent:* Monday, November 21, 2016 11:50 AM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > You don't need to use contexts in the onreply_route[], because that > route is already ran in the context of the reply message. > > Best regards, > > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/19/2016 10:40 PM, Ehrny wrote: > > Dear R?zvan, > > ? I?ve tried to add variable to onreply_route[1] > > $var(upstream0) = $(hdr(Via)[0]{via.param,received}); > > xlog("upstream0 = $var(upstream0) \n"); > > and in the log I get critical alert: > > CRITICAL:tm:tm_pv_context_reply: no picked branch (-1) for a final > response > > *From:*users-bounces at lists.opensips.org > > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Ehrny > *Sent:* Saturday, November 19, 2016 2:06 PM > *To:* OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi R?zvan, > > I gues so. > > I?ve got t_on_reply("1"); in the route > > and at the end of the script there is: > > onreply_route[1] { > > force_send_socket(udp:10.197.26.170:5060); > > } > > But it doesn?t seem to change send_socket back to priv IP addr (( > > Kind regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan > Crainea > *Sent:* Friday, November 18, 2016 12:22 PM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > Did you try setting the private socket on the reply? > > Best regards, > > > R?zvan Crainea > > OpenSIPS Solutions > > www.opensips-solutions.com > > On 11/17/2016 01:00 AM, Ehrny wrote: > > Dear R?zvan, > > Thanks again for the prompt help. I was able to change the > headers as needed but I?m stuck with another problem( > > I?ve got opensips with two Ethernet adapters, eth1 as a > private and another one eth0 as public. Opensips works fine > when the call is coming on the public eth0 and leaves opensips > through the same public adapter. (All the GWs are behind that > public eth0 instead of one ). The problem happens when the > call comes in through the private eth1, please see the drawing > in attachment. > > -sip1. After I?ve got invite from provider on the private > eth1 , I send it through the public eth0. > > -sip2. I use force_send_socket(udp:PUBLIC_IP:PORT) for the > call to be able to pass through the opensips and come back > from external GW (x.x.82.139). I also change SIP Request's URI > and use uac_replace_to () to change these fields as needed. > > -sip4. Opensips has got 180 Ringing from external GW > (x.x.82.139) > > -sip5. Opensips tries to send it back to originator > (10.250.242.74) which is behind private NIC eth0 (10.197.26.170) > > the call can not be set up because I send reply from my public > eth1 > > 2016-11-16 18:56:14 : x.x.80.43:5060 -> 10.250.242.74:5060 > > SIP/2.0 *180* Ringing Via: SIP/2.0/UDP > 10.250.242.74:5060;branch=*z9hG4bKqci5ec *Record-Route: > > > Record-Route: > > > From: sip:300940 at domain.com;tag=*2F81324631* > To: > sip:300905 at domain.com:5060;tag=231469dIr894 > > Call-ID: *020A3EA03A8 at SFESIP4-id1-ext* CSeq: 1 INVITE Contact: > > > I?m not sure if I do it right way because the packet (sip5) > goes to 10.250.242.74 with the source ip of public eth0 and > not the one it should pass through to be able to come back. > > What is the right way in my case to get the call through? > > Thank you for all of your help, > > Regards, > > Ehrny > > > > > _______________________________________________ > > 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: From bogdan at opensips.org Mon Nov 21 12:02:11 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 21 Nov 2016 13:02:11 +0200 Subject: [OpenSIPS-Users] Memory free problem In-Reply-To: <848316507.20161121112444@ptl.ru> References: <1024256996.20161117101150@ptl.ru> <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> <69131771.20161118124349@ptl.ru> <848316507.20161121112444@ptl.ru> Message-ID: <9254dac1-a043-404e-4834-27ac4c1bc069@opensips.org> Hi Denis, Yes, I see you use Topo Hiding, and as the PRACK is after the 200 OK + ACK, OpenSIPS dialog module does not match the PRACK -> it sticks to the OpenSIPS IP and loops on it. If I send you a small patch (to allow PRACK inside dialog) could you test it ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.11.2016 10:24, Denis wrote: > Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! > > Yes, the ngrep shows that PRACK has been received, but not sent to > dest SIP UA. > The question is, why "is looping big time on your OpenSIPS"? > > Here you can find SIP log of one of the call, mentioned early, with > callid '4gk2hpk433lgdt1d6ys7ifkwd > ' > https://cloud.mail.ru/public/BvpZ/SJHLQmqEZ > > In the log: > 1.1.1.1 - Caller > 2.2.2.2 - Opensips > 3.3.3.3 - Callee > > Top hiding has been applied for this call. > > Thank you. > > mailto:denis7979 at mail.ru > > > Hi Denis, > > It looks to me you have a PRACK request that is looping big time on > your OpenSIPS, consuming CPU and memory - see how often the warning > with bogus state appears. Check the routing for PRACK. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 18.11.2016 11:43, Denis wrote: > > Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! > > The log you can find here > https://cloud.mail.ru/public/84c1/Fw9VGe2J9 > > mailto:denis7979 at mail.ru > > > Hi Denis, > > I do not think they are related. The warnings report some traffic > anomalies - a PRACK request for a confirmed dialog (with 200 OK). > > On the memory part, if the log is correct, it says you have 180M free. > What are the ERROR line just after that log ? I want to see which was > the module trying to allocate memory. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 17.11.2016 09:11, Denis wrote: > > Memory free problem Hello! > > Today i have a temporary problem with out of free memory (about 4 > minutes). > Unfortunately, i noticed the problem when everything became fine, so i > didn`t make standard procedure of detecting problems with memory which > has been described in documentation. > > In syslog i see such sequence of events. > > Before the first message about out of free memory > > "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes > left), please increase the "-m" command line parameter!" > > i see many messages > > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c531c95f0 [3855:951170645] with clid > '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1 > ' and tags '96x8v2xkj9of92j' > '332693C-EF5'" > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c4735d130 [4072:1150064691] with clid > 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2 > ' and tags '1czw3nbhw632pzn' > '3326728-1DC1'" > > dialing with two callid. > > The question is, can such Warning influence on shm. allocation? > > Thank you for any help. > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: From denis7979 at mail.ru Mon Nov 21 12:22:38 2016 From: denis7979 at mail.ru (Denis) Date: Mon, 21 Nov 2016 14:22:38 +0300 Subject: [OpenSIPS-Users] Memory free problem In-Reply-To: <9254dac1-a043-404e-4834-27ac4c1bc069@opensips.org> References: <1024256996.20161117101150@ptl.ru> <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> <69131771.20161118124349@ptl.ru> <848316507.20161121112444@ptl.ru> <9254dac1-a043-404e-4834-27ac4c1bc069@opensips.org> Message-ID: <1728357642.20161121142238@ptl.ru> Hello, Bogdan! Yes, sure, i will test it. Server:: OpenSIPS (2.2.1 (x86_64/linux)) mailto:denis7979 at mail.ru Hi Denis, Yes, I see you use Topo Hiding, and as the PRACK is after the 200 OK + ACK, OpenSIPS dialog module does not match the PRACK -> it sticks to the OpenSIPS IP and loops on it. If I send you a small patch (to allow PRACK inside dialog) could you test it ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.11.2016 10:24, Denis wrote: Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! Yes, the ngrep shows that PRACK has been received, but not sent to dest SIP UA. The question is, why "is looping big time on your OpenSIPS"? Here you can find SIP log of one of the call, mentioned early, with callid '4gk2hpk433lgdt1d6ys7ifkwd' https://cloud.mail.ru/public/BvpZ/SJHLQmqEZ In the log: 1.1.1.1 - Caller 2.2.2.2 - Opensips 3.3.3.3 - Callee Top hiding has been applied for this call. Thank you. mailto:denis7979 at mail.ru Hi Denis, It looks to me you have a PRACK request that is looping big time on your OpenSIPS, consuming CPU and memory - see how often the warning with bogus state appears. Check the routing for PRACK. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 11:43, Denis wrote: Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! The log you can find here https://cloud.mail.ru/public/84c1/Fw9VGe2J9 mailto:denis7979 at mail.ru Hi Denis, I do not think they are related. The warnings report some traffic anomalies - a PRACK request for a confirmed dialog (with 200 OK). On the memory part, if the log is correct, it says you have 180M free. What are the ERROR line just after that log ? I want to see which was the module trying to allocate memory. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.11.2016 09:11, Denis wrote: Memory free problem Hello! Today i have a temporary problem with out of free memory (about 4 minutes). Unfortunately, i noticed the problem when everything became fine, so i didn`t make standard procedure of detecting problems with memory which has been described in documentation. In syslog i see such sequence of events. Before the first message about out of free memory "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes left), please increase the "-m" command line parameter!" i see many messages "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c531c95f0 [3855:951170645] with clid '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1' and tags '96x8v2xkj9of92j' '332693C-EF5'" "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg 0x7f1c4735d130 [4072:1150064691] with clid 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2' and tags '1czw3nbhw632pzn' '3326728-1DC1'" dialing with two callid. The question is, can such Warning influence on shm. allocation? Thank you for any help. mailto:denis7979 at mail.ru _______________________________________________ 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: From bogdan at opensips.org Mon Nov 21 12:25:22 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 21 Nov 2016 13:25:22 +0200 Subject: [OpenSIPS-Users] Memory free problem In-Reply-To: <1728357642.20161121142238@ptl.ru> References: <1024256996.20161117101150@ptl.ru> <39e4f369-bae2-c201-f560-7cdd99175c0d@opensips.org> <69131771.20161118124349@ptl.ru> <848316507.20161121112444@ptl.ru> <9254dac1-a043-404e-4834-27ac4c1bc069@opensips.org> <1728357642.20161121142238@ptl.ru> Message-ID: <58d11048-4648-8c87-ed2f-7d6c245cd7d6@opensips.org> Denis, please try this and see if the PRACK gets routed correctly (and you should also get rid of the warnings and memory issues). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.11.2016 13:22, Denis wrote: > Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! > > Yes, sure, i will test it. > > Server:: OpenSIPS (2.2.1 (x86_64/linux)) > > mailto:denis7979 at mail.ru > > > Hi Denis, > > Yes, I see you use Topo Hiding, and as the PRACK is after the 200 OK + > ACK, OpenSIPS dialog module does not match the PRACK -> it sticks to > the OpenSIPS IP and loops on it. > > If I send you a small patch (to allow PRACK inside dialog) could you > test it ? > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 21.11.2016 10:24, Denis wrote: > > Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! > > Yes, the ngrep shows that PRACK has been received, but not sent to > dest SIP UA. > The question is, why "is looping big time on your OpenSIPS"? > > Here you can find SIP log of one of the call, mentioned early, with > callid '4gk2hpk433lgdt1d6ys7ifkwd > ' > https://cloud.mail.ru/public/BvpZ/SJHLQmqEZ > > In the log: > 1.1.1.1 - Caller > 2.2.2.2 - Opensips > 3.3.3.3 - Callee > > Top hiding has been applied for this call. > > Thank you. > > mailto:denis7979 at mail.ru > > > Hi Denis, > > It looks to me you have a PRACK request that is looping big time on > your OpenSIPS, consuming CPU and memory - see how often the warning > with bogus state appears. Check the routing for PRACK. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 18.11.2016 11:43, Denis wrote: > > Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan! > > The log you can find here > https://cloud.mail.ru/public/84c1/Fw9VGe2J9 > > mailto:denis7979 at mail.ru > > > Hi Denis, > > I do not think they are related. The warnings report some traffic > anomalies - a PRACK request for a confirmed dialog (with 200 OK). > > On the memory part, if the log is correct, it says you have 180M free. > What are the ERROR line just after that log ? I want to see which was > the module trying to allocate memory. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 17.11.2016 09:11, Denis wrote: > > Memory free problem Hello! > > Today i have a temporary problem with out of free memory (about 4 > minutes). > Unfortunately, i noticed the problem when everything became fine, so i > didn`t make standard procedure of detecting problems with memory which > has been described in documentation. > > In syslog i see such sequence of events. > > Before the first message about out of free memory > > "ERROR:core:fm_malloc: not enough free shm memory (180803792 bytes > left), please increase the "-m" command line parameter!" > > i see many messages > > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c531c95f0 [3855:951170645] with clid > '4gk2hpk433lgdt1d6ys7ifkwd at 1.1.1.1 > ' and tags '96x8v2xkj9of92j' > '332693C-EF5'" > "WARNING:dialog:log_next_state_dlg: bogus event 5 in state 4 for dlg > 0x7f1c4735d130 [4072:1150064691] with clid > 'eht08t1eovzlqahle6xhfeiln at 2.2.2.2 > ' and tags '1czw3nbhw632pzn' > '3326728-1DC1'" > > dialing with two callid. > > The question is, can such Warning influence on shm. allocation? > > Thank you for any help. > > mailto:denis7979 at mail.ru > > _______________________________________________ > 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: -------------- next part -------------- diff --git a/modules/dialog/dlg_hash.c b/modules/dialog/dlg_hash.c index d8c8be1..92b9844 100644 --- a/modules/dialog/dlg_hash.c +++ b/modules/dialog/dlg_hash.c @@ -1004,6 +1004,7 @@ void next_state_dlg(struct dlg_cell *dlg, int event, int dir, int *old_state, switch (dlg->state) { case DLG_STATE_EARLY: case DLG_STATE_CONFIRMED_NA: + case DLG_STATE_CONFIRMED: break; default: log_next_state_dlg(event, dlg); From spanda at 3clogic.com Mon Nov 21 12:26:58 2016 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 21 Nov 2016 16:56:58 +0530 Subject: [OpenSIPS-Users] How to configure two different domain in listen . Message-ID: Hi All , I am using opensips-1.11 . I need to configure multiple domains in the listen field and I want the particular domain get exposed to outside depending upon the request . bellow is my config file . listen=10.165.yy.xxx:5507 AS test1.i3clogic.com:5507 listen=10.165.yy.xyy:5507 AS test2.i3clogic.com:5507 alias="test1.i3clogic.com" alias="test1.i3clogic.com:5507" alias="test2.i3clogic.com" alias="test2.i3clogic.com:5507" So what I want is , When an Invite comes with request uri " test2.i3clogic.com" , then it should add the same domain in the Record_route while forwarding the call . But now its adding "test1.i3clogic.com" domain always . I think it giving priority to the listen domain added first . How can i achieve my goal . Is this possible or not . If possible then how can I do this . *Thanks & Regards* *Sasmita Panda* *Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Nov 21 12:59:09 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 21 Nov 2016 13:59:09 +0200 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: References: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> Message-ID: <708d3289-32b5-a56a-520e-1603eb6d8664@opensips.org> Hi Maciej, Thanks for the detailed report. Do you think the error is related to the key you are trying to fetch or is it related to the simply being the second query you perform ? What if you perform from the very beginning a a query on the second key ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.11.2016 19:53, Maciej Bylica wrote: > Hello > > As i mentioned before memcached is already installed. I am using > innodb_memcache.containers to implement memcached as a plugin. > > netstat -plnt | grep 9999 > > tcp 0 0 127.0.0.1:9999 0.0.0.0:* > LISTEN 18421/mysqld > > > Everything looks fine i have full transparency, data provided by > memcached CLI (telnet) are seen inside innodb table and vise versa. > > I am using the latest 2.2.2 git opensips rel. and memcached module loaded: > > loadmodule "cachedb_memcached.so" > > modparam("cachedb_memcached", > "cachedb_url","memcached:default://localhost:9999,127.0.0.1/ > ") > > > The script i am using is just the basic one, without any additional > configuration. > Inside the script there is following operation provided: > > cache_fetch("memcached:default","$tU",$avp(i:601)); > > > Innodb table contains following data: > > +-------------+-------------+------+------+------+ > > | id | num | c3 | c4 | c5 | > > +-------------+-------------+------+------+------+ > > | 49121112233 | 49121112233 | 0 | 3 | 0 | > > | 49221112233 | 49221112233 | 0 | 1 | 0 | > > | 49221112234 | 49221112234 | 0 | 2 | 0 | > > +-------------+-------------+------+------+------+ > > > Now, i am sending INVITE with tU = 49121112233 and getting proper > behavior which means: > - no error inside the opensips.log, xlog followingcache_fetch returns > correct $avp(i:601) > - mysqld.log shows > > <95 get 49121112233 > > >95 sending key 49121112233 > > >95 END > > > but really strange is that calling tU = 49221112233 is causing quite > opposite results: > - following error is shown > > DBG:core:cachedb_fetch: from script [memcached] - with grp [default] > > ERROR:cachedb_memcached:wrap_memcached_get: Failed to get: SYSTEM ERROR > > - no mysqld debug is produced > > > The last one example(tU = 49221112234)is failing with the same error. > > > Memcached is loaded with all those data > > Connected to localhost. > > Escape character is '^]'. > > get 49221112233 > > VALUE 49221112233 0 11 > > 49221112233 > > END > > get 49221112234 > > VALUE 49221112234 0 11 > > 49221112234 > > END > > > but because of some reasons memcached module is not utilized. > As aforementioned, opensips script does not have any $rU filtering > setup, so should query for any data it is asked for. > Maybe i am wrong with some of my assumptions or the way memcached is > configured, so kindly help me to understand where the problem is located. > > Thanks > Maciej. > > > > > > > > 2016-11-15 18:09 GMT+01:00 Bogdan-Andrei Iancu >: > > OK, thank you for the update Maciej, > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 15.11.2016 18:28, Maciej Bylica wrote: >> Hi Bogdan, >> Thanks for reply. >> Right, Opensips module was not the source of the problem. >> I've managed to solve the issue, memcache is working fine. >> Thanks >> Maciej. >> 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu >> >: >> >> Hi Maciej, As I see, you are manually compiling and >> installing the memcached stuff - any special reason for doing >> that ? (versus using packages) As the problem seems to be in >> the lib, not in the OpenSIPS module. Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> >> On 09.11.2016 18:41, Maciej Bylica wrote: >>> Hello I am struggling with memcached installation with the >>> latest git opensips 2.2.2 and centos 6.8 Here are version >>> releases i am using: libmemcached-1.0.18 (./configure, make >>> && make install) memcached-1.4.33 (./configure, make && make >>> install) with >>> LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH memcached -d >>> -u nobody -m 1048 -p 9999 127.0.0.1 does not produce any >>> error but what is really puzzling me during the opensips >>> start is the error below: DBG:core:load_module: loading >>> module >>> /usr/local/lib64/opensips/modules/cachedb_memcached.so >>> ERROR:core:sr_load_module: could not open module >>> : >>> /usr/local/lib/libmemcached.so.11: undefined symbol: >>> pthread_once Can someone please guide me how to put >>> memcached up and running ? >>> Opensips is compiled with cachedb_memcached module. >>> Thanks in advance. >>> Maciej >>> >>> _______________________________________________ >>> 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: From bogdan at opensips.org Mon Nov 21 13:33:36 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 21 Nov 2016 14:33:36 +0200 Subject: [OpenSIPS-Users] How to configure two different domain in listen . In-Reply-To: References: Message-ID: Hi Sasmita, The URI in RR header is dictated by the interfaces / listeners involved in routing the call. In your case, on which interface is the call received ? on .xxx or .xyy ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.11.2016 13:26, Sasmita Panda wrote: > Hi All , > > I am using opensips-1.11 . I need to configure multiple domains > in the listen field and I want the particular domain get exposed to > outside depending upon the request . > > > bellow is my config file . > > listen=10.165.yy.xxx:5507 AS test1.i3clogic.com:5507 > > > listen=10.165.yy.xyy:5507 AS test2.i3clogic.com:5507 > > > alias="test1.i3clogic.com " > alias="test1.i3clogic.com:5507 " > > alias="test2.i3clogic.com " > alias="test2.i3clogic.com:5507 " > > So what I want is , When an Invite comes with request uri > "test2.i3clogic.com " , then it should add > the same domain in the Record_route while forwarding the call . > > But now its adding "test1.i3clogic.com > " domain always . I think it giving > priority to the listen domain added first . > > How can i achieve my goal . Is this possible or not . If possible > then how can I do this . > > > */Thanks & Regards/* > /Sasmita Panda/ > /Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > > _______________________________________________ > 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: From dubeyvishal at yahoo.com Mon Nov 21 13:51:20 2016 From: dubeyvishal at yahoo.com (vishal dubey) Date: Mon, 21 Nov 2016 12:51:20 +0000 (UTC) Subject: [OpenSIPS-Users] Want to create opensips subscriber from restful api or from web application References: <1456921225.1415578.1479732680807.ref@mail.yahoo.com> Message-ID: <1456921225.1415578.1479732680807@mail.yahoo.com> Hi Team, I want to create opensips subscriber from other web application. I think it is possible through pi_httpd or db_httpd. but i am not able to find any example hot to do this. Please help. Thanks,Vishal -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Nov 21 14:01:34 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 21 Nov 2016 15:01:34 +0200 Subject: [OpenSIPS-Users] Possible Memory Leak in rest_client module. In-Reply-To: References: <10fe005ba618cd93d4b9d4abc31f968b@mail.devito.cc> <95a5b0e2-5c81-184d-9fd9-3f0e72886284@opensips.org> Message-ID: <833dfa8a-e962-0b90-e7f6-c2ba9fca2fca@opensips.org> Hi Jim, sorry for the late reply. Unfortunately the memory debugging is not properly enabled. What version of OpenSIPS are you using there ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.11.2016 16:20, Jim DeVito wrote: > Hi Bogdan, > > Took about a week in production for the problem to crop up again so I > was able to get the mem dump. I hope this can provide you some > insight. Let me know if you need anything else. > > http://pastebin.com/WQWqhhiA > > Thanks!! > > --- > Jim DeVito > > On 2016-11-07 12:04, Bogdan-Andrei Iancu wrote: >> Hi Jim, >> >> Please see >> http://www.opensips.org/Documentation/TroubleShooting-OutOfMem - let >> me know if you managed to get the mem dump. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 07.11.2016 21:20, Jim DeVito wrote: >>> Hi All, >>> >>> This happened prior to 2.2.2 and I thought I saw a bug report that >>> was fixed in 2.2.2. However it still seems to be a thing with using >>> the res_curl module. After about a week I get this... >>> >>> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >>> ERROR:core:fm_malloc: not enough free pkg memory (4296 bytes left), >>> please increase the "-M" command line parameter! >>> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >>> INFO:core:fm_malloc: attempting defragmentation... (need 1808 bytes) >>> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >>> INFO:core:fm_malloc: unable to alloc a big enough fragment! >>> Nov 7 13:33:44 sip-proxy01 opensips: Nov 7 13:33:44 [20811] >>> ERROR:rest_client:rest_get_method: curl_easy_perform: Out of memory >>> >>> I reboot and all is well for another week. Like res_client is not >>> releasing the memory it is using. shmem:used_size:: seems to always >>> be going up until it runs out of the memory I allotted with the -M >>> switch. What else can I do to see where this is coming from? >>> >>> Thanks!! >>> From y at jettel.ru Mon Nov 21 17:40:42 2016 From: y at jettel.ru (Ehrny) Date: Mon, 21 Nov 2016 16:40:42 +0000 Subject: [OpenSIPS-Users] $ai transformation References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788AD9EE@JET-EX02.jettel.ru> Hi R?zvan, Thanks for your help. The call needs to be done through multi homed OpenSIPs (I don?t use mhomed flag) Caller -> Carrier1 -> OpenSIPs(eth1)---OpenSIPs(eth0) -> pbx -> Callee $var(upstream1) = $(hdr(Via)[0]{via.host}); returned the IP address I needed OpenSIPs(eth1) has private IP , so on requests I use force_send_socket(udp:OpenSIPs_PUB_IP:5060) to be able to send call to further destinations. When replies are back I need to change send _socket back to privateIP for the answers to Carrier1. I?ve got the IP address of the Carrier1 in the onreply_route . onreply_route[1] { ? if ($(var(upstream1)) == "10.250.242.74") { force_send_socket(udp:10.197.26.170:5060); } ? } It doesn?t seem to change ip address for replies . Would you please advise me how to change send_socket in onreply_route ? Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 21, 2016 1:32 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! You need the IP address of whom? Caller? Callee? $rd is null because a reply does not have a R-URI. Perhaps the reply doesn't have a received parameter in the reply either, that's why it is empty. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/21/2016 12:13 PM, Ehrny wrote: Hello R?zvan, I need to do some routing in onreply_route[] based on destination IP. Tried $rd with no avail , it returns null If I get you right regarding context, the var $var(upstream0) = $(hdr(Via)[0]{via.received}); Is empty also. What is the right way to get an IP address in replies and do further routing? Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 21, 2016 11:50 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! You don't need to use contexts in the onreply_route[], because that route is already ran in the context of the reply message. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon Nov 21 20:55:15 2016 From: miha at softnet.si (Miha) Date: Mon, 21 Nov 2016 20:55:15 +0100 Subject: [OpenSIPS-Users] nat issue In-Reply-To: References: <1f44deec-ac09-9de3-c938-e18a9b4171fa@softnet.si> <1e9cd559-d277-0fb0-6b1d-d4dd54e45059@opensips.org> <17de93ae-ea15-7818-24a3-4dc31342893a@softnet.si> <1a3ae947-f9e7-c5b3-bbbe-4fabe1b648e2@softnet.si> <02477e55-9520-dd33-a8e3-19b49783228e@opensips.org> <2610b8d4-1cb3-804f-2fce-8d24c129ffb5@softnet.si> <3d864dde-2b07-f872-e7bd-181627c3a653@opensips.org> <6117be99-edd6-cb33-d58c-a22469b5ce2f@opensips.org> <39d25b06-6417-408f-7012-41f993355ed2@opensips.org> <0bbecaee-0958-c06c-d9e4-e21ee3815d96@softnet.si> Message-ID: <8b9ac776-7fc3-6f7a-c143-80923939350c@softnet.si> Hello Bogdan i think it is no need to do that if this client is broken. You already doing so much good with opensips ;) Tnx so much with all explanation and all you work! Miha On 21/11/2016 11:13, Bogdan-Andrei Iancu wrote: > Hi Miha, > > According the SIP grammar, that parameter is perfectly legitimate. The > client is broken as it is not able to cope with it (in the worst case, > to simply ignore it). > > There is no out of the box way to disable it, but I may provide you a > patch for that - just to see if that fixes your problem. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 18.11.2016 19:54, Miha wrote: >> Hello bogdan >> >> I guess, but it looks like so. Is it possible to remove it? >> >> >> tnx >> miha >> >> On 18/11/2016 15:39, Bogdan-Andrei Iancu wrote: >>> I guess your UAC freezes when receiving back in the 200 OK REGISTER >>> the "received" hdr param in Contact ?? >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 18.11.2016 16:33, Bogdan-Andrei Iancu wrote: >>>> HI Miha, >>>> >>>> Sorry, but I'm not able to follow the case you mentioned with >>>> Innovaphone PBX - maybe you can post (to see the differences) the >>>> sent and returned contact hdrs in the REGISTER request + reply for >>>> the 2 cases (OpenSIPS and Innovaphone PBX). >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 18.11.2016 11:20, Miha wrote: >>>>> I do not know if this is the case. But from what I can see what I >>>>> register it on some Innovaphone PBX, innovaphone sends back in >>>>> contact (200 ok) just ip of IPBX and also when INVITE is send in >>>>> contact there is URI of PBX and only and it works. >>>>> >>>>> i tried this but did not have any luck. >>>>> >>>>> br >>>>> miha >>>>> >>>>> On 18/11/2016 09:48, Bogdan-Andrei Iancu wrote: >>>>>> Hi Miha, >>>>>> >>>>>> You mean the UAC does not like the multi-URI Contact header in >>>>>> the 200 OK ???? If so, that UAC is really broken as 1) breaks the >>>>>> SIP syntax (which allows it) and 2) breaks the the SIP >>>>>> Registration as per RFC3261. >>>>>> >>>>>> What about the second contact (the one already existing in usrloc >>>>>> when this registration comes) ? can it be discarded ? If YES, you >>>>>> can try passing the "c1f" flags to save() : >>>>>> http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 >>>>>> >>>>>> That will make OpenSIPS to accept only 1 contact per AOR/user and >>>>>> any new contact will override the existing one. >>>>>> >>>>>> Regards, >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> On 18.11.2016 10:15, Miha wrote: >>>>>>> Hi Bogdan >>>>>>> >>>>>>> I did few more test. This contact bothers UAC. Is there anything >>>>>>> i can do in this case in OpenSIPS so that it will only reply >>>>>>> with one URI in contact? >>>>>>> >>>>>>> Contact:;expires=1518 >>>>>>> ;received="sip:84.41.125.21:5060",; >>>>>>> expires=180. >>>>>>> >>>>>>> >>>>>>> tnx so much! >>>>>>> MIha >>>>>>> >>>>>>> On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote: >>>>>>>> Hi Miha, >>>>>>>> >>>>>>>> yes, that is parallel forking (you may have more than 2 >>>>>>>> contacts only). >>>>>>>> >>>>>>>> Are you sure your DB was sync'ed? OpenSIPS is periodically >>>>>>>> flushing the memory cache into the location table (see the >>>>>>>> "state" of the contact (as per "ul show") if marked as DIRTY). >>>>>>>> >>>>>>>> In regards to RFC, I think you quote the wrong section (maybe >>>>>>>> about callings?) - for REGISTERs, any number of URIs are >>>>>>>> allowed AFAIK. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Bogdan-Andrei Iancu >>>>>>>> OpenSIPS Founder and Developer >>>>>>>> http://www.opensips-solutions.com >>>>>>>> On 17.11.2016 12:35, Miha wrote: >>>>>>>>> Bodan >>>>>>>>> >>>>>>>>> so this is dual forking...? >>>>>>>>> So if you have one account and you have two phones on it and >>>>>>>>> first will try to register, 200 ok will will have contact of >>>>>>>>> both phones? >>>>>>>>> In location table I can see only one registration for this >>>>>>>>> user but for "opensipsctl ul show" it shows me two contacts, >>>>>>>>> which is strange? (When i do trace only one invite is send) >>>>>>>>> and UAC replay with Busy all the time due to two contacts >>>>>>>>> (this what i have been told). >>>>>>>>> >>>>>>>>> Ok, but if you look at rfc there is only one URI allowed in >>>>>>>>> contact if I understand this right? >>>>>>>>> >>>>>>>>> >>>>>>>>> The Contact header field MUST be present and contain exactly one SIP >>>>>>>>> or SIPS URI in any request that can result in the establishment of a >>>>>>>>> dialog >>>>>>>>> >>>>>>>>> Please correct me if I am wrong. >>>>>>>>> >>>>>>>>> >>>>>>>>> tnx so much! >>>>>>>>> Miha >>>>>>>>> >>>>>>>>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote: >>>>>>>>>> Hi Miha, >>>>>>>>>> >>>>>>>>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid >>>>>>>>>> registrations for that user (for all the devices the user may >>>>>>>>>> have). >>>>>>>>>> >>>>>>>>>> I guess your user has 2 registrations, so the 200 OK will >>>>>>>>>> report back both of them. You can check via "opensipsctl ul show" >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>>> http://www.opensips-solutions.com >>>>>>>>>> On 17.11.2016 12:13, Miha wrote: >>>>>>>>>>> Hello Bogdan >>>>>>>>>>> >>>>>>>>>>> i changed this and it works in all cases, only in one I >>>>>>>>>>> noticed today this (Opensips reply only in this case with >>>>>>>>>>> two URI on contact): >>>>>>>>>>> >>>>>>>>>>> UAC:5060 ->OpenSIPS:5060 >>>>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6. >>>>>>>>>>> Max-Forwards: 70. >>>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>>> To: 042335040 . >>>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, >>>>>>>>>>> UPDATE, >>>>>>>>>>> PRACK, INFO. >>>>>>>>>>> Authorization: Digest >>>>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b >>>>>>>>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res >>>>>>>>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca". >>>>>>>>>>> Contact: 042335040 >>>>>>>>>>> ;ex >>>>>>>>>>> pires=3600. >>>>>>>>>>> Privacy: none. >>>>>>>>>>> Supported: path. >>>>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>>>>> Content-Length: 0. >>>>>>>>>>> >>>>>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>>>>> SIP/2.0 401 Unauthorized. >>>>>>>>>>> Via: SIP/2.0/UDP >>>>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022 >>>>>>>>>>> 5bd7495297c6. >>>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>>> To: 042335040 >>>>>>>>>>> ;tag=0c7ff67d927afc274 >>>>>>>>>>> b272138ce65100a.ac4d. >>>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>>> CSeq: 1804289391 REGISTER. >>>>>>>>>>> WWW-Authenticate: Digest realm="opsp.test.net", >>>>>>>>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", >>>>>>>>>>> stale=true. >>>>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>>>>> Content-Length: 0. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> U UAC:5060 ->OpenSIPS:5060 >>>>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0. >>>>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48. >>>>>>>>>>> Max-Forwards: 70. >>>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>>> To: 042335040 . >>>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, >>>>>>>>>>> UPDATE, >>>>>>>>>>> PRACK, INFO. >>>>>>>>>>> Authorization: Digest >>>>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8 >>>>>>>>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res >>>>>>>>>>> ponse="9ce3622addeedf74622a23697e6f3728". >>>>>>>>>>> Contact: 042335040 >>>>>>>>>>> ;ex >>>>>>>>>>> pires=3600. >>>>>>>>>>> Privacy: none. >>>>>>>>>>> Supported: path. >>>>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2. >>>>>>>>>>> Content-Length: 0. >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> UOpenSIPS:5060 -> UAC:5060 >>>>>>>>>>> SIP/2.0 200 OK. >>>>>>>>>>> Via: SIP/2.0/UDP >>>>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b >>>>>>>>>>> bbf80e346f48. >>>>>>>>>>> From: 042335040 ;tag=1f62205074. >>>>>>>>>>> To: 042335040 >>>>>>>>>>> ;tag=766e4f757c55b3450 >>>>>>>>>>> c9992a50fb64799-9163. >>>>>>>>>>> Call-ID: 61c67f739bef5a2e. >>>>>>>>>>> CSeq: 1804289392 REGISTER. >>>>>>>>>>> Contact: >>>>>>>>>>> ;expires=3600 >>>>>>>>>>> ;received="sip:UAC:5060", >>>>>>>>>> > ;expires=119. >>>>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)). >>>>>>>>>>> Content-Length: 0. >>>>>>>>>>> >>>>>>>>>>> Do you see where could be an issue? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> tnx >>>>>>>>>>> miha >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 16/11/2016 08:11, Miha wrote: >>>>>>>>>>>> Hello Bogdan >>>>>>>>>>>> >>>>>>>>>>>> yes this was the case... >>>>>>>>>>>> >>>>>>>>>>>> thank you! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> br >>>>>>>>>>>> miha >>>>>>>>>>>> >>>>>>>>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote: >>>>>>>>>>>>> Hi Miha, >>>>>>>>>>>>> >>>>>>>>>>>>> When you handle REGISTER requests (from behind NAT) most >>>>>>>>>>>>> probably you use fix_nated_contact() instead of >>>>>>>>>>>>> fix_nated_register(). >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>>>>>> http://www.opensips-solutions.com >>>>>>>>>>>>> On 15.11.2016 09:11, Miha wrote: >>>>>>>>>>>>>> Hello >>>>>>>>>>>>>> >>>>>>>>>>>>>> i need one info. >>>>>>>>>>>>>> I have one phone behind NAT and it is registered on >>>>>>>>>>>>>> OpenSIPS. IN register packet, which is send to OpenSIPS I >>>>>>>>>>>>>> can see contact: >>>>>>>>>>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP" >>>>>>>>>>>>>> >>>>>>>>>>>>>> and let says that the public ip for this device is >>>>>>>>>>>>>> xxx.xxx.xxx.xxx. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> When opensips sends INVITE it send to right public ip and >>>>>>>>>>>>>> right port (source ip and source port generated by >>>>>>>>>>>>>> router). The issue is this: >>>>>>>>>>>>>> Invite is like: >>>>>>>>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and >>>>>>>>>>>>>> this request is then fw to this UAC behind router. The >>>>>>>>>>>>>> UAC replays to this INVITE with 404 Not found as it is >>>>>>>>>>>>>> waiting to receive the same URI which was written in >>>>>>>>>>>>>> contact (the userpart is ok, put the ip is public, not >>>>>>>>>>>>>> private and this is the issue).From what I can see in RFC >>>>>>>>>>>>>> this is the case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Till now Idid not have any issues with this, but now I >>>>>>>>>>>>>> found first phone which replays with 404 and from RFC >>>>>>>>>>>>>> point of view there should be private ip request :) . So >>>>>>>>>>>>>> is there anything I can do :)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> tnx >>>>>>>>>>>>>> miha >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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: From mbgatherer at gmail.com Mon Nov 21 22:20:15 2016 From: mbgatherer at gmail.com (Maciej Bylica) Date: Mon, 21 Nov 2016 22:20:15 +0100 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: <708d3289-32b5-a56a-520e-1603eb6d8664@opensips.org> References: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> <708d3289-32b5-a56a-520e-1603eb6d8664@opensips.org> Message-ID: Hi Bogdan, Thanks for the reply. It seems it is related to the key, it doesn't matter which query is it. First query on the second key does not change anything. I've just added additional key 49101112233 and it works (query was fired), but 49331112233 does not. Thanks Maciej. 2016-11-21 12:59 GMT+01:00 Bogdan-Andrei Iancu : > Hi Maciej, > > Thanks for the detailed report. > > Do you think the error is related to the key you are trying to fetch or is > it related to the simply being the second query you perform ? What if you > perform from the very beginning a a query on the second key ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 18.11.2016 19:53, Maciej Bylica wrote: > > Hello > > As i mentioned before memcached is already installed. I am using > innodb_memcache.containers to implement memcached as a plugin. > > netstat -plnt | grep 9999 > > tcp 0 0 127.0.0.1:9999 0.0.0.0:* > LISTEN 18421/mysqld > > > Everything looks fine i have full transparency, data provided by memcached > CLI (telnet) are seen inside innodb table and vise versa. > > I am using the latest 2.2.2 git opensips rel. and memcached module loaded: > > loadmodule "cachedb_memcached.so" > > modparam("cachedb_memcached", "cachedb_url","memcached:default: > //localhost:9999,127.0.0.1/") > > The script i am using is just the basic one, without any additional > configuration. > Inside the script there is following operation provided: > > cache_fetch("memcached:default","$tU",$avp(i:601)); > > Innodb table contains following data: > > +-------------+-------------+------+------+------+ > > | id | num | c3 | c4 | c5 | > > +-------------+-------------+------+------+------+ > > | 49121112233 | 49121112233 | 0 | 3 | 0 | > > | 49221112233 | 49221112233 | 0 | 1 | 0 | > > | 49221112234 | 49221112234 | 0 | 2 | 0 | > > +-------------+-------------+------+------+------+ > > Now, i am sending INVITE with tU = 49121112233 and getting proper > behavior which means: > - no error inside the opensips.log, xlog following cache_fetch returns > correct $avp(i:601) > - mysqld.log shows > > <95 get 49121112233 > > >95 sending key 49121112233 > > >95 END > > but really strange is that calling tU = 49221112233 is causing quite > opposite results: > - following error is shown > > DBG:core:cachedb_fetch: from script [memcached] - with grp [default] > > ERROR:cachedb_memcached:wrap_memcached_get: Failed to get: SYSTEM ERROR > > - no mysqld debug is produced > > > The last one example(tU = 49221112234)is failing with the same error. > > > Memcached is loaded with all those data > > Connected to localhost. > > Escape character is '^]'. > > get 49221112233 > > VALUE 49221112233 0 11 > > 49221112233 > > END > > get 49221112234 > > VALUE 49221112234 0 11 > > 49221112234 > > END > > > but because of some reasons memcached module is not utilized. > As aforementioned, opensips script does not have any $rU filtering setup, > so should query for any data it is asked for. > Maybe i am wrong with some of my assumptions or the way memcached is > configured, so kindly help me to understand where the problem is located. > > Thanks > Maciej. > > > > > > > > 2016-11-15 18:09 GMT+01:00 Bogdan-Andrei Iancu : > >> OK, thank you for the update Maciej, >> >> Best regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 15.11.2016 18:28, Maciej Bylica wrote: >> >> Hi Bogdan, >> Thanks for reply. >> Right, Opensips module was not the source of the problem. >> I've managed to solve the issue, memcache is working fine. >> Thanks >> Maciej. >> 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu : >>> >>> Hi Maciej, As I see, you are manually compiling and installing the >>> memcached stuff - any special reason for doing that ? (versus using >>> packages) As the problem seems to be in the lib, not in the OpenSIPS >>> module. Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>> >>> On 09.11.2016 18:41, Maciej Bylica wrote: >>> >>> Hello I am struggling with memcached installation with the latest git >>> opensips 2.2.2 and centos 6.8 Here are version releases i am using: >>> libmemcached-1.0.18 (./configure, make && make install) memcached-1.4.33 >>> (./configure, make && make install) with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH >>> memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 does not produce any error >>> but what is really puzzling me during the opensips start is the error >>> below: DBG:core:load_module: loading module /usr/local/lib64/opensips/modules/cachedb_memcached.so >>> ERROR:core:sr_load_module: could not open module >>> : >>> /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once Can >>> someone please guide me how to put memcached up and running ? >>> Opensips is compiled with cachedb_memcached module. >>> Thanks in advance. >>> Maciej >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbgatherer at gmail.com Mon Nov 21 22:44:41 2016 From: mbgatherer at gmail.com (Maciej Bylica) Date: Mon, 21 Nov 2016 22:44:41 +0100 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: References: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> <708d3289-32b5-a56a-520e-1603eb6d8664@opensips.org> Message-ID: Ok, i figured it out, that the problem relies in port number definition. I am getting no issues with 11211. Thanks Maciej 2016-11-21 22:20 GMT+01:00 Maciej Bylica : > Hi Bogdan, > > Thanks for the reply. > > It seems it is related to the key, it doesn't matter which query is it. > First query on the second key does not change anything. > I've just added additional key 49101112233 and it works (query was fired), > but 49331112233 does not. > > Thanks > Maciej. > > > 2016-11-21 12:59 GMT+01:00 Bogdan-Andrei Iancu : > >> Hi Maciej, >> >> Thanks for the detailed report. >> >> Do you think the error is related to the key you are trying to fetch or >> is it related to the simply being the second query you perform ? What if >> you perform from the very beginning a a query on the second key ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 18.11.2016 19:53, Maciej Bylica wrote: >> >> Hello >> >> As i mentioned before memcached is already installed. I am using >> innodb_memcache.containers to implement memcached as a plugin. >> >> netstat -plnt | grep 9999 >> >> tcp 0 0 127.0.0.1:9999 0.0.0.0:* >> LISTEN 18421/mysqld >> >> >> Everything looks fine i have full transparency, data provided by >> memcached CLI (telnet) are seen inside innodb table and vise versa. >> >> I am using the latest 2.2.2 git opensips rel. and memcached module loaded: >> >> loadmodule "cachedb_memcached.so" >> >> modparam("cachedb_memcached", "cachedb_url","memcached:default: >> //localhost:9999,127.0.0.1/") >> >> The script i am using is just the basic one, without any additional >> configuration. >> Inside the script there is following operation provided: >> >> cache_fetch("memcached:default","$tU",$avp(i:601)); >> >> Innodb table contains following data: >> >> +-------------+-------------+------+------+------+ >> >> | id | num | c3 | c4 | c5 | >> >> +-------------+-------------+------+------+------+ >> >> | 49121112233 | 49121112233 | 0 | 3 | 0 | >> >> | 49221112233 | 49221112233 | 0 | 1 | 0 | >> >> | 49221112234 | 49221112234 | 0 | 2 | 0 | >> >> +-------------+-------------+------+------+------+ >> >> Now, i am sending INVITE with tU = 49121112233 and getting proper >> behavior which means: >> - no error inside the opensips.log, xlog following cache_fetch returns >> correct $avp(i:601) >> - mysqld.log shows >> >> <95 get 49121112233 >> >> >95 sending key 49121112233 >> >> >95 END >> >> but really strange is that calling tU = 49221112233 is causing quite >> opposite results: >> - following error is shown >> >> DBG:core:cachedb_fetch: from script [memcached] - with grp [default] >> >> ERROR:cachedb_memcached:wrap_memcached_get: Failed to get: SYSTEM ERROR >> >> - no mysqld debug is produced >> >> >> The last one example(tU = 49221112234)is failing with the same error. >> >> >> Memcached is loaded with all those data >> >> Connected to localhost. >> >> Escape character is '^]'. >> >> get 49221112233 >> >> VALUE 49221112233 0 11 >> >> 49221112233 >> >> END >> >> get 49221112234 >> >> VALUE 49221112234 0 11 >> >> 49221112234 >> >> END >> >> >> but because of some reasons memcached module is not utilized. >> As aforementioned, opensips script does not have any $rU filtering setup, >> so should query for any data it is asked for. >> Maybe i am wrong with some of my assumptions or the way memcached is >> configured, so kindly help me to understand where the problem is located. >> >> Thanks >> Maciej. >> >> >> >> >> >> >> >> 2016-11-15 18:09 GMT+01:00 Bogdan-Andrei Iancu : >> >>> OK, thank you for the update Maciej, >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>> >>> On 15.11.2016 18:28, Maciej Bylica wrote: >>> >>> Hi Bogdan, >>> Thanks for reply. >>> Right, Opensips module was not the source of the problem. >>> I've managed to solve the issue, memcache is working fine. >>> Thanks >>> Maciej. >>> 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu : >>>> >>>> Hi Maciej, As I see, you are manually compiling and installing the >>>> memcached stuff - any special reason for doing that ? (versus using >>>> packages) As the problem seems to be in the lib, not in the OpenSIPS >>>> module. Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>>> >>>> On 09.11.2016 18:41, Maciej Bylica wrote: >>>> >>>> Hello I am struggling with memcached installation with the latest git >>>> opensips 2.2.2 and centos 6.8 Here are version releases i am using: >>>> libmemcached-1.0.18 (./configure, make && make install) memcached-1.4.33 >>>> (./configure, make && make install) with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH >>>> memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 does not produce any error >>>> but what is really puzzling me during the opensips start is the error >>>> below: DBG:core:load_module: loading module /usr/local/lib64/opensips/modules/cachedb_memcached.so >>>> ERROR:core:sr_load_module: could not open module >>>> : >>>> /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once Can >>>> someone please guide me how to put memcached up and running ? >>>> Opensips is compiled with cachedb_memcached module. >>>> Thanks in advance. >>>> Maciej >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Nov 22 10:26:05 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 22 Nov 2016 11:26:05 +0200 Subject: [OpenSIPS-Users] How to configure two different domain in listen . In-Reply-To: References: Message-ID: Hi Sasmita, You cannot use multiple global advertised_address - it can have only one value; multiple definitions will simply rewrite the previous ones. If you want to keep the same file, maybe you should consider using some defines in combination with text pre-processing. Like have your common/shared opensips.m4 file and for each server keep a local.m4 where the domain macro is defined. And before starting opensips, simply do "m4 local.m4 opensips.m4 > opensips.cfg" Also, what you can do is to use the advertised option in a per interface manner: listen=udp:1.2.3.4:5507 as test1.i3clogic.com see:http://www.opensips.org/Documentation/Script-CoreParameters-2-2#toc65 put in the same file the listeners from multiple servers, and set on your boxes the option to allow binding to non-existing IPs. This is ugly, but it may do the trick. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 22.11.2016 09:08, Sasmita Panda wrote: > Hi , > > Thanks for your reply . I got your point . > > Actually , I have to place my opensips cfg file in a file system > . and wanted to access that file in different machines . In short I > wanted to maintain a single file for all the servers . > > In my case both the domains are mapped to different machine > having their own public and private IP. It wont work for me in this > case . Its giving error while starting opensips , its not able to bind > the address . This is not the right way to do so . > > So , I wanted to combine two different file in a single file . > How I will do this ? Can I add two different "advertised_address" ? > > listen=udp:eth0:5507 > advertised_address=test1.i3clogic.com > advertised_address=test2.i3clogic.com > advertised_port=5507 > > Can I do like this . I have tried to run like this but its not > working . Its always publishing the second address "test2.i3clogic.com > " in record_route . > What I am trying to do is possible or not ? > > > > */Thanks & Regards/* > /Sasmita Panda/ > /Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > On Mon, Nov 21, 2016 at 6:03 PM, Bogdan-Andrei Iancu > > wrote: > > Hi Sasmita, > > The URI in RR header is dictated by the interfaces / listeners > involved in routing the call. > > In your case, on which interface is the call received ? on .xxx or > .xyy ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 21.11.2016 13:26, Sasmita Panda wrote: >> Hi All , >> I am using opensips-1.11 . I need to configure multiple >> domains in the listen field and I want the particular domain get >> exposed to outside depending upon the request . >> bellow is my config file . >> listen=10.165.yy.xxx:5507 AS test1.i3clogic.com:5507 >> >> listen=10.165.yy.xyy:5507 AS test2.i3clogic.com:5507 >> >> alias="test1.i3clogic.com " >> alias="test1.i3clogic.com:5507 " >> alias="test2.i3clogic.com " >> alias="test2.i3clogic.com:5507 " >> So what I want is , When an Invite comes with request uri >> "test2.i3clogic.com " , then it >> should add the same domain in the Record_route while forwarding >> the call . >> But now its adding "test1.i3clogic.com >> " domain always . I think it giving >> priority to the listen domain added first . >> How can i achieve my goal . Is this possible or not . If >> possible then how can I do this . >> */Thanks & Regards/* >> /Sasmita Panda/ >> /Network Testing and Software Engineer/ >> /3CLogic , ph:07827611765/ >> >> _______________________________________________ >> 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: From bogdan at opensips.org Tue Nov 22 10:30:06 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 22 Nov 2016 11:30:06 +0200 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: References: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> <708d3289-32b5-a56a-520e-1603eb6d8664@opensips.org> Message-ID: <69a38c8b-4a6a-c591-4108-ef5e51521441@opensips.org> Hi Maciej, That is weired, but I'm glad you solved it. I mean it is weired (with the wrong port) why it worked for some and did not for other keys :-/ Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.11.2016 23:44, Maciej Bylica wrote: > Ok, i figured it out, that the problem relies in port number definition. > I am getting no issues with 11211. > > Thanks > Maciej > > 2016-11-21 22:20 GMT+01:00 Maciej Bylica >: > > Hi Bogdan, > > Thanks for the reply. > > It seems it is related to the key, it doesn't matter which query > is it. > First query on the second key does not change anything. > I've just added additional key 49101112233 and it works (query was > fired), but 49331112233 does not. > > Thanks > Maciej. > > > 2016-11-21 12:59 GMT+01:00 Bogdan-Andrei Iancu > >: > > Hi Maciej, > > Thanks for the detailed report. > > Do you think the error is related to the key you are trying to > fetch or is it related to the simply being the second query > you perform ? What if you perform from the very beginning a a > query on the second key ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > On 18.11.2016 19:53, Maciej Bylica wrote: >> Hello >> As i mentioned before memcached is already installed. I am >> using innodb_memcache.containers to implement memcached as a >> plugin. >> >> netstat -plnt | grep 9999 >> >> tcp 0 0 127.0.0.1:9999 >> 0.0.0.0:* LISTEN 18421/mysqld >> >> Everything looks fine i have full transparency, data provided >> by memcached CLI (telnet) are seen inside innodb table and >> vise versa. >> I am using the latest 2.2.2 git opensips rel. and memcached >> module loaded: >> >> loadmodule "cachedb_memcached.so" >> >> modparam("cachedb_memcached", >> "cachedb_url","memcached:default://localhost:9999,127.0.0.1/ >> ") >> >> The script i am using is just the basic one, without any >> additional configuration. >> Inside the script there is following operation provided: >> >> cache_fetch("memcached:default","$tU",$avp(i:601)); >> >> Innodb table contains following data: >> >> +-------------+-------------+------+------+------+ >> >> | id | num | c3 | c4 | c5 | >> >> +-------------+-------------+------+------+------+ >> >> | 49121112233 | 49121112233 | 0 | 3 | 0 | >> >> | 49221112233 | 49221112233 | 0 | 1 | 0 | >> >> | 49221112234 | 49221112234 | 0 | 2 | 0 | >> >> +-------------+-------------+------+------+------+ >> >> Now, i am sending INVITE with tU = 49121112233 and getting >> proper behavior which means: >> - no error inside the opensips.log, xlog followingcache_fetch >> returns correct $avp(i:601) - mysqld.log shows >> >> <95 get 49121112233 >> >> >95 sending key 49121112233 >> >> >95 END >> >> but really strange is that calling tU = 49221112233 is >> causing quite opposite results: >> - following error is shown >> >> DBG:core:cachedb_fetch: from script [memcached] - with grp >> [default] >> >> ERROR:cachedb_memcached:wrap_memcached_get: Failed to get: >> SYSTEM ERROR >> >> - no mysqld debug is produced >> >> The last one example(tU = 49221112234)is failing with the >> same error. >> >> Memcached is loaded with all those data >> >> Connected to localhost. >> >> Escape character is '^]'. >> >> get 49221112233 >> >> VALUE 49221112233 0 11 >> >> 49221112233 >> >> END >> >> get 49221112234 >> >> VALUE 49221112234 0 11 >> >> 49221112234 >> >> END >> >> but because of some reasons memcached module is not utilized. >> As aforementioned, opensips script does not have any $rU >> filtering setup, so should query for any data it is asked for. >> Maybe i am wrong with some of my assumptions or the way >> memcached is configured, so kindly help me to understand >> where the problem is located. >> Thanks >> Maciej. >> >> 2016-11-15 18:09 GMT+01:00 Bogdan-Andrei Iancu >> >: >> >> OK, thank you for the update Maciej, Best regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> >> On 15.11.2016 18:28, Maciej Bylica wrote: >>> Hi Bogdan, >>> Thanks for reply. >>> Right, Opensips module was not the source of the problem. >>> I've managed to solve the issue, memcache is working fine. >>> Thanks >>> Maciej. >>> 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu >>> >: >>> >>> Hi Maciej, As I see, you are manually compiling and >>> installing the memcached stuff - any special reason >>> for doing that ? (versus using packages) As the >>> problem seems to be in the lib, not in the OpenSIPS >>> module. Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> >>> On 09.11.2016 18:41, Maciej Bylica wrote: >>>> Hello I am struggling with memcached installation >>>> with the latest git opensips 2.2.2 and centos 6.8 >>>> Here are version releases i am using: >>>> libmemcached-1.0.18 (./configure, make && make >>>> install) memcached-1.4.33 (./configure, make && >>>> make install) with >>>> LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH >>>> memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 >>>> does not produce any error but what is really >>>> puzzling me during the opensips start is the error >>>> below: DBG:core:load_module: loading module >>>> /usr/local/lib64/opensips/modules/cachedb_memcached.so >>>> ERROR:core:sr_load_module: could not open module >>>> : >>>> /usr/local/lib/libmemcached.so.11: undefined >>>> symbol: pthread_once Can someone please guide me >>>> how to put memcached up and running ? >>>> Opensips is compiled with cachedb_memcached module. >>>> Thanks in advance. >>>> Maciej >>>> >>>> _______________________________________________ >>>> 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: From razvan at opensips.org Tue Nov 22 18:32:36 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 22 Nov 2016 19:32:36 +0200 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD9502788AD9EE@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AD9EE@JET-EX02.jettel.ru> Message-ID: <16797e7f-6e6b-7e05-5044-06ae06fdf16d@opensips.org> Hi, Ehrny! If you completely remove the force_send_socket() and any $fs settings in onreply_route, is it doing the same thing? Normally the reply should be automatically routed through the same interface the request came from. Not sure why your reply goes over the other one. I willtry to replicate this and let you know if it works or not. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/21/2016 06:40 PM, Ehrny wrote: > > Hi R?zvan, > > Thanks for your help. > > The call needs to be done through multi homed OpenSIPs (I don?t use > mhomed flag) > > Caller -> Carrier1 -> OpenSIPs(eth1)---OpenSIPs(eth0) -> pbx -> Callee > > $var(upstream1) = $(hdr(Via)[0]{via.host}); returned the IP > address I needed > > OpenSIPs(eth1) has private IP , so on requests I use > force_send_socket(udp:OpenSIPs_PUB_IP:5060) to be able to send call > to further destinations. When replies are back I need to change send > _socket back to privateIP for the answers to Carrier1. > > I?ve got the IP address of the Carrier1 in the onreply_route . > > onreply_route[1] { > > ? > > if ($(var(upstream1)) == "10.250.242.74") { > > force_send_socket(udp:10.197.26.170:5060); > > } > > ? > > } > > It doesn?t seem to change ip address for replies . > > Would you please advise me how to change send_socket in onreply_route ? > > Kind regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan Crainea > *Sent:* Monday, November 21, 2016 1:32 PM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > You need the IP address of whom? Caller? Callee? > $rd is null because a reply does not have a R-URI. Perhaps the reply > doesn't have a received parameter in the reply either, that's why it > is empty. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/21/2016 12:13 PM, Ehrny wrote: > > Hello R?zvan, > > I need to do some routing in onreply_route[] based on destination IP. > > Tried $rd with no avail , it returns null > > If I get you right regarding context, the var > $var(upstream0) = $(hdr(Via)[0]{via.received}); Is empty also. > > What is the right way to get an IP address in replies and do > further routing? > > Kind regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan > Crainea > *Sent:* Monday, November 21, 2016 11:50 AM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > You don't need to use contexts in the onreply_route[], because > that route is already ran in the context of the reply message. > > Best regards, > > > R?zvan Crainea > > OpenSIPS Solutions > > www.opensips-solutions.com > > > > _______________________________________________ > 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: From y at jettel.ru Tue Nov 22 18:45:10 2016 From: y at jettel.ru (Ehrny) Date: Tue, 22 Nov 2016 17:45:10 +0000 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <16797e7f-6e6b-7e05-5044-06ae06fdf16d@opensips.org> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AD9EE@JET-EX02.jettel.ru> <16797e7f-6e6b-7e05-5044-06ae06fdf16d@opensips.org> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788AFEEC@JET-EX02.jettel.ru> Hi R?zvan, I?ve tried both # force_send_socket(udp:10.197.26.170:5060); and $fs="udp:10.197.26.170:5060"; with no luck (( Without any of these lines it doesn?t work either (( Ps.. in the main request routing logic I use force_send_socket(udp:x.x.82.39:5060); Best Regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Tuesday, November 22, 2016 8:33 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! If you completely remove the force_send_socket() and any $fs settings in onreply_route, is it doing the same thing? Normally the reply should be automatically routed through the same interface the request came from. Not sure why your reply goes over the other one. I will try to replicate this and let you know if it works or not. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/21/2016 06:40 PM, Ehrny wrote: Hi R?zvan, Thanks for your help. The call needs to be done through multi homed OpenSIPs (I don?t use mhomed flag) Caller -> Carrier1 -> OpenSIPs(eth1)---OpenSIPs(eth0) -> pbx -> Callee $var(upstream1) = $(hdr(Via)[0]{via.host}); returned the IP address I needed OpenSIPs(eth1) has private IP , so on requests I use force_send_socket(udp:OpenSIPs_PUB_IP:5060) to be able to send call to further destinations. When replies are back I need to change send _socket back to privateIP for the answers to Carrier1. I?ve got the IP address of the Carrier1 in the onreply_route . onreply_route[1] { ? if ($(var(upstream1)) == "10.250.242.74") { force_send_socket(udp:10.197.26.170:5060); } ? } It doesn?t seem to change ip address for replies . Would you please advise me how to change send_socket in onreply_route ? Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 21, 2016 1:32 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! You need the IP address of whom? Caller? Callee? $rd is null because a reply does not have a R-URI. Perhaps the reply doesn't have a received parameter in the reply either, that's why it is empty. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/21/2016 12:13 PM, Ehrny wrote: Hello R?zvan, I need to do some routing in onreply_route[] based on destination IP. Tried $rd with no avail , it returns null If I get you right regarding context, the var $var(upstream0) = $(hdr(Via)[0]{via.received}); Is empty also. What is the right way to get an IP address in replies and do further routing? Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 21, 2016 11:50 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! You don't need to use contexts in the onreply_route[], because that route is already ran in the context of the reply message. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com _______________________________________________ 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: From razvan at opensips.org Wed Nov 23 10:24:57 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 23 Nov 2016 11:24:57 +0200 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD9502788AFEEC@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AD9EE@JET-EX02.jettel.ru> <16797e7f-6e6b-7e05-5044-06ae06fdf16d@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AFEEC@JET-EX02.jettel.ru> Message-ID: <6f0700c2-0007-13ce-4abc-924bc36c041b@opensips.org> Hi, Ehrny! I've just tested, and for me it works as it should - the reply goes through the interface it came from. Is there any chance you could send me your script (privately)? Perhaps I can spot some problemsby looking at it. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/22/2016 07:45 PM, Ehrny wrote: > > Hi R?zvan, > > I?ve tried both > > # force_send_socket(udp:10.197.26.170:5060); > > and > > $fs="udp:10.197.26.170:5060"; > > with no luck (( > > Without any of these lines it doesn?t work either (( > > Ps.. in the main request routing logic I use > > force_send_socket(udp:x.x.82.39:5060); > > Best Regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan Crainea > *Sent:* Tuesday, November 22, 2016 8:33 PM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > If you completely remove the force_send_socket() and any $fs settings > in onreply_route, is it doing the same thing? > Normally the reply should be automatically routed through the same > interface the request came from. Not sure why your reply goes over the > other one. I will try to replicate this and let you know if it works > or not. > > Best regards, > > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 11/21/2016 06:40 PM, Ehrny wrote: > > Hi R?zvan, > > Thanks for your help. > > The call needs to be done through multi homed OpenSIPs (I don?t > use mhomed flag) > > Caller -> Carrier1 -> OpenSIPs(eth1)---OpenSIPs(eth0) -> pbx -> > Callee > > $var(upstream1) = $(hdr(Via)[0]{via.host}); returned the IP > address I needed > > OpenSIPs(eth1) has private IP , so on requests I use > force_send_socket(udp:OpenSIPs_PUB_IP:5060) to be able to send > call to further destinations. When replies are back I need to > change send _socket back to privateIP for the answers to Carrier1. > > I?ve got the IP address of the Carrier1 in the onreply_route . > > onreply_route[1] { > > ? > > if ($(var(upstream1)) == "10.250.242.74") { > > force_send_socket(udp:10.197.26.170:5060); > > } > > ? > > } > > It doesn?t seem to change ip address for replies . > > Would you please advise me how to change send_socket in > onreply_route ? > > Kind regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan > Crainea > *Sent:* Monday, November 21, 2016 1:32 PM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > You need the IP address of whom? Caller? Callee? > $rd is null because a reply does not have a R-URI. Perhaps the > reply doesn't have a received parameter in the reply either, > that's why it is empty. > > Best regards, > > > R?zvan Crainea > > OpenSIPS Solutions > > www.opensips-solutions.com > > On 11/21/2016 12:13 PM, Ehrny wrote: > > Hello R?zvan, > > I need to do some routing in onreply_route[] based on > destination IP. > > Tried $rd with no avail , it returns null > > If I get you right regarding context, the var > $var(upstream0) = $(hdr(Via)[0]{via.received}); Is empty > also. > > What is the right way to get an IP address in replies and do > further routing? > > Kind regards, > > Ehrny > > *From:*users-bounces at lists.opensips.org > > [mailto:users-bounces at lists.opensips.org] *On Behalf Of > *Razvan Crainea > *Sent:* Monday, November 21, 2016 11:50 AM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] $ai transformation > > Hi, Ehrny! > > You don't need to use contexts in the onreply_route[], because > that route is already ran in the context of the reply message. > > Best regards, > > > > R?zvan Crainea > > OpenSIPS Solutions > > www.opensips-solutions.com > > > > > _______________________________________________ > > 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: From y at jettel.ru Wed Nov 23 11:19:55 2016 From: y at jettel.ru (Ehrny) Date: Wed, 23 Nov 2016 10:19:55 +0000 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <6f0700c2-0007-13ce-4abc-924bc36c041b@opensips.org> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AD9EE@JET-EX02.jettel.ru> <16797e7f-6e6b-7e05-5044-06ae06fdf16d@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AFEEC@JET-EX02.jettel.ru> <6f0700c2-0007-13ce-4abc-924bc36c041b@opensips.org> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788B14C4@JET-EX02.jettel.ru> Hi R?zvan, Yes I can. Would you please shoot me e?mail so I?ll be able to send it. Thanks for your kind help, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Wednesday, November 23, 2016 12:25 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! I've just tested, and for me it works as it should - the reply goes through the interface it came from. Is there any chance you could send me your script (privately)? Perhaps I can spot some problems by looking at it. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/22/2016 07:45 PM, Ehrny wrote: Hi R?zvan, I?ve tried both # force_send_socket(udp:10.197.26.170:5060); and $fs="udp:10.197.26.170:5060"; with no luck (( Without any of these lines it doesn?t work either (( Ps.. in the main request routing logic I use force_send_socket(udp:x.x.82.39:5060); Best Regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Tuesday, November 22, 2016 8:33 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! If you completely remove the force_send_socket() and any $fs settings in onreply_route, is it doing the same thing? Normally the reply should be automatically routed through the same interface the request came from. Not sure why your reply goes over the other one. I will try to replicate this and let you know if it works or not. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/21/2016 06:40 PM, Ehrny wrote: Hi R?zvan, Thanks for your help. The call needs to be done through multi homed OpenSIPs (I don?t use mhomed flag) Caller -> Carrier1 -> OpenSIPs(eth1)---OpenSIPs(eth0) -> pbx -> Callee $var(upstream1) = $(hdr(Via)[0]{via.host}); returned the IP address I needed OpenSIPs(eth1) has private IP , so on requests I use force_send_socket(udp:OpenSIPs_PUB_IP:5060) to be able to send call to further destinations. When replies are back I need to change send _socket back to privateIP for the answers to Carrier1. I?ve got the IP address of the Carrier1 in the onreply_route . onreply_route[1] { ? if ($(var(upstream1)) == "10.250.242.74") { force_send_socket(udp:10.197.26.170:5060); } ? } It doesn?t seem to change ip address for replies . Would you please advise me how to change send_socket in onreply_route ? Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 21, 2016 1:32 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! You need the IP address of whom? Caller? Callee? $rd is null because a reply does not have a R-URI. Perhaps the reply doesn't have a received parameter in the reply either, that's why it is empty. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/21/2016 12:13 PM, Ehrny wrote: Hello R?zvan, I need to do some routing in onreply_route[] based on destination IP. Tried $rd with no avail , it returns null If I get you right regarding context, the var $var(upstream0) = $(hdr(Via)[0]{via.received}); Is empty also. What is the right way to get an IP address in replies and do further routing? Kind regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Monday, November 21, 2016 11:50 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! You don't need to use contexts in the onreply_route[], because that route is already ran in the context of the reply message. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com _______________________________________________ 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: From y at jettel.ru Wed Nov 23 11:28:34 2016 From: y at jettel.ru (Ehrny) Date: Wed, 23 Nov 2016 10:28:34 +0000 Subject: [OpenSIPS-Users] $ai transformation In-Reply-To: <8B36F227BD22B041AEA7015FD914CD9502788B14C4@JET-EX02.jettel.ru> References: <8B36F227BD22B041AEA7015FD914CD950278897397@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788A4134@JET-EX02.jettel.ru> <8bfed6fa-f611-9398-985a-2734172f23c8@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AAD40@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AB355@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788ACD07@JET-EX02.jettel.ru> <8B36F227BD22B041AEA7015FD914CD9502788AD9EE@JET-EX02.jettel.ru> <16797e7f-6e6b-7e05-5044-06ae06fdf16d@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788AFEEC@JET-EX02.jettel.ru> <6f0700c2-0007-13ce-4abc-924bc36c041b@opensips.org> <8B36F227BD22B041AEA7015FD914CD9502788B14C4@JET-EX02.jettel.ru> Message-ID: <8B36F227BD22B041AEA7015FD914CD9502788B1552@JET-EX02.jettel.ru> Hi R?zvan, if it?s possible, you can shoot me email to settestset at aol.com Thanks as ever From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Ehrny Sent: Wednesday, November 23, 2016 1:20 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] $ai transformation Hi R?zvan, Yes I can. Would you please shoot me e?mail so I?ll be able to send it. Thanks for your kind help, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Wednesday, November 23, 2016 12:25 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! I've just tested, and for me it works as it should - the reply goes through the interface it came from. Is there any chance you could send me your script (privately)? Perhaps I can spot some problems by looking at it. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/22/2016 07:45 PM, Ehrny wrote: Hi R?zvan, I?ve tried both # force_send_socket(udp:10.197.26.170:5060); and $fs="udp:10.197.26.170:5060"; with no luck (( Without any of these lines it doesn?t work either (( Ps.. in the main request routing logic I use force_send_socket(udp:x.x.82.39:5060); Best Regards, Ehrny From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Tuesday, November 22, 2016 8:33 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] $ai transformation Hi, Ehrny! If you completely remove the force_send_socket() and any $fs settings in onreply_route, is it doing the same thing? Normally the reply should be automatically routed through the same interface the request came from. Not sure why your reply goes over the other one. I will try to replicate this and let you know if it works or not. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pimenta at inatel.br Wed Nov 23 12:34:23 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Wed, 23 Nov 2016 11:34:23 +0000 Subject: [OpenSIPS-Users] Documentation about media relay with OpenSIPS Message-ID: Dear OpenSIPS users, I would like to learn about how to implement a media relay by means of OpenSIPS. I have found the documentation about the mediaproxy module. Is it the right documentation for media relaying with OpenSIPS, isn't it? Could someone here point some more documentations about it, available on Internet, please? Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Wed Nov 23 14:53:19 2016 From: johan at democon.be (Johan De Clercq) Date: Wed, 23 Nov 2016 14:53:19 +0100 Subject: [OpenSIPS-Users] Documentation about media relay with OpenSIPS In-Reply-To: References: Message-ID: I think it's better to use rtpengine. There is a small tutorial on the opensips site (webrtc) and there is extensive documentation on github. 2016-11-23 12:34 GMT+01:00 Rodrigo Pimenta Carvalho : > Dear OpenSIPS users, > > > I would like to learn about how to implement a media relay by means of > OpenSIPS. > > I have found the documentation about the mediaproxy module. Is it the > right documentation for media relaying with OpenSIPS, isn't it? > > > Could someone here point some more documentations about it, available on > Internet, please? > > > Any hint will be very helpful! > > > Best regards. > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > _______________________________________________ > 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: From john.quick at smartvox.co.uk Wed Nov 23 15:22:50 2016 From: john.quick at smartvox.co.uk (John Quick) Date: Wed, 23 Nov 2016 14:22:50 -0000 Subject: [OpenSIPS-Users] v2.2 documentation error Message-ID: <000201d24595$12978810$37c69830$@smartvox.co.uk> Online documentation for Core Parameters v2.2: Section 3.4 alias The examples of usage shown in this section cause a syntax error when you start OpenSIPS. Like this: Nov 23 14:11:00 [14175] CRITICAL:core:yyerror: parse error in config file //etc/opensips/opensips.cfg, line 44, column 21-22: Nov 23 14:11:00 [14175] ERROR:core:main: bad config file (2 errors) The value assigned must specify the transport protocol in front of the hostname or IP address. For example: alias=udp:other.domain.com:5060 John Quick Smartvox Limited From liviu at opensips.org Wed Nov 23 16:45:29 2016 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 23 Nov 2016 17:45:29 +0200 Subject: [OpenSIPS-Users] v2.2 documentation error In-Reply-To: <000201d24595$12978810$37c69830$@smartvox.co.uk> References: <000201d24595$12978810$37c69830$@smartvox.co.uk> Message-ID: <5d1c1d13-5c57-4873-6f97-84397c7739d2@opensips.org> Thank you for the hint, John! It would appear that the v2.3 docs [1] already have this issue corrected. Regards, [1]: http://www.opensips.org/Documentation/Script-CoreParameters-2-3#toc27 Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 23.11.2016 16:22, John Quick wrote: > Online documentation for Core Parameters v2.2: > Section 3.4 alias > The examples of usage shown in this section cause a syntax error when you > start OpenSIPS. Like this: > Nov 23 14:11:00 [14175] CRITICAL:core:yyerror: parse error in config file > //etc/opensips/opensips.cfg, line 44, column 21-22: > Nov 23 14:11:00 [14175] ERROR:core:main: bad config file (2 errors) > > The value assigned must specify the transport protocol in front of the > hostname or IP address. For example: > alias=udp:other.domain.com:5060 > > John Quick > Smartvox Limited > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From mbgatherer at gmail.com Wed Nov 23 17:21:18 2016 From: mbgatherer at gmail.com (Maciej Bylica) Date: Wed, 23 Nov 2016 17:21:18 +0100 Subject: [OpenSIPS-Users] CACHEDB_MEMCACHED Module - libmemcached undefined symbol issue In-Reply-To: <69a38c8b-4a6a-c591-4108-ef5e51521441@opensips.org> References: <115dd573-b73b-e598-eb50-28c70e482921@opensips.org> <708d3289-32b5-a56a-520e-1603eb6d8664@opensips.org> <69a38c8b-4a6a-c591-4108-ef5e51521441@opensips.org> Message-ID: Hi, Don't know there the problem was located. Port 9999 was only utilized by memcached process. Anyway i hope there are no issues within the memcached module code. Thanks Maciej. 2016-11-22 10:30 GMT+01:00 Bogdan-Andrei Iancu : > Hi Maciej, > > That is weired, but I'm glad you solved it. I mean it is weired (with the > wrong port) why it worked for some and did not for other keys :-/ > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 21.11.2016 23:44, Maciej Bylica wrote: > > Ok, i figured it out, that the problem relies in port number definition. > I am getting no issues with 11211. > > Thanks > Maciej > > 2016-11-21 22:20 GMT+01:00 Maciej Bylica : > >> Hi Bogdan, >> >> Thanks for the reply. >> >> It seems it is related to the key, it doesn't matter which query is it. >> First query on the second key does not change anything. >> I've just added additional key 49101112233 and it works (query was >> fired), but 49331112233 does not. >> >> Thanks >> Maciej. >> >> >> 2016-11-21 12:59 GMT+01:00 Bogdan-Andrei Iancu : >> >>> Hi Maciej, >>> >>> Thanks for the detailed report. >>> >>> Do you think the error is related to the key you are trying to fetch or >>> is it related to the simply being the second query you perform ? What if >>> you perform from the very beginning a a query on the second key ? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>> >>> On 18.11.2016 19:53, Maciej Bylica wrote: >>> >>> Hello >>> As i mentioned before memcached is already installed. I am using >>> innodb_memcache.containers to implement memcached as a plugin. >>> >>> netstat -plnt | grep 9999 >>> >>> tcp 0 0 127.0.0.1:9999 0.0.0.0:* >>> LISTEN 18421/mysqld >>> >>> Everything looks fine i have full transparency, data provided by >>> memcached CLI (telnet) are seen inside innodb table and vise versa. >>> I am using the latest 2.2.2 git opensips rel. and memcached module >>> loaded: >>> >>> loadmodule "cachedb_memcached.so" >>> >>> modparam("cachedb_memcached", "cachedb_url","memcached:default: >>> //localhost:9999,127.0.0.1/") >>> The script i am using is just the basic one, without any additional >>> configuration. >>> Inside the script there is following operation provided: >>> >>> cache_fetch("memcached:default","$tU",$avp(i:601)); >>> Innodb table contains following data: >>> >>> +-------------+-------------+------+------+------+ >>> >>> | id | num | c3 | c4 | c5 | >>> >>> +-------------+-------------+------+------+------+ >>> >>> | 49121112233 | 49121112233 | 0 | 3 | 0 | >>> >>> | 49221112233 | 49221112233 | 0 | 1 | 0 | >>> >>> | 49221112234 | 49221112234 | 0 | 2 | 0 | >>> >>> +-------------+-------------+------+------+------+ >>> Now, i am sending INVITE with tU = 49121112233 and getting proper >>> behavior which means: >>> - no error inside the opensips.log, xlog following cache_fetch returns >>> correct $avp(i:601) - mysqld.log shows >>> >>> <95 get 49121112233 >>> >>> >95 sending key 49121112233 >>> >>> >95 END >>> but really strange is that calling tU = 49221112233 is causing quite >>> opposite results: >>> - following error is shown >>> >>> DBG:core:cachedb_fetch: from script [memcached] - with grp [default] >>> >>> ERROR:cachedb_memcached:wrap_memcached_get: Failed to get: SYSTEM ERROR >>> >>> - no mysqld debug is produced >>> >>> The last one example(tU = 49221112234)is failing with the same error. >>> >>> Memcached is loaded with all those data >>> >>> Connected to localhost. >>> >>> Escape character is '^]'. >>> >>> get 49221112233 >>> >>> VALUE 49221112233 0 11 >>> >>> 49221112233 >>> >>> END >>> >>> get 49221112234 >>> >>> VALUE 49221112234 0 11 >>> >>> 49221112234 >>> >>> END >>> >>> but because of some reasons memcached module is not utilized. >>> As aforementioned, opensips script does not have any $rU filtering >>> setup, so should query for any data it is asked for. >>> Maybe i am wrong with some of my assumptions or the way memcached is >>> configured, so kindly help me to understand where the problem is located. >>> Thanks >>> Maciej. >>> >>> 2016-11-15 18:09 GMT+01:00 Bogdan-Andrei Iancu : >>>> >>>> OK, thank you for the update Maciej, Best regards, >>>> >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>>> >>>> On 15.11.2016 18:28, Maciej Bylica wrote: >>>> >>>> Hi Bogdan, >>>> Thanks for reply. >>>> Right, Opensips module was not the source of the problem. >>>> I've managed to solve the issue, memcache is working fine. >>>> Thanks >>>> Maciej. >>>> 2016-11-10 12:56 GMT+01:00 Bogdan-Andrei Iancu : >>>>> >>>>> Hi Maciej, As I see, you are manually compiling and installing the >>>>> memcached stuff - any special reason for doing that ? (versus using >>>>> packages) As the problem seems to be in the lib, not in the OpenSIPS >>>>> module. Regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>>>> >>>>> On 09.11.2016 18:41, Maciej Bylica wrote: >>>>> >>>>> Hello I am struggling with memcached installation with the latest git >>>>> opensips 2.2.2 and centos 6.8 Here are version releases i am using: >>>>> libmemcached-1.0.18 (./configure, make && make install) memcached-1.4.33 >>>>> (./configure, make && make install) with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH >>>>> memcached -d -u nobody -m 1048 -p 9999 127.0.0.1 does not produce any error >>>>> but what is really puzzling me during the opensips start is the error >>>>> below: DBG:core:load_module: loading module /usr/local/lib64/opensips/modules/cachedb_memcached.so >>>>> ERROR:core:sr_load_module: could not open module >>>>> : >>>>> /usr/local/lib/libmemcached.so.11: undefined symbol: pthread_once Can >>>>> someone please guide me how to put memcached up and running ? >>>>> Opensips is compiled with cachedb_memcached module. >>>>> Thanks in advance. >>>>> Maciej >>>>> >>>>> _______________________________________________ >>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Nov 23 18:04:32 2016 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 23 Nov 2016 19:04:32 +0200 Subject: [OpenSIPS-Users] Error creating presence tables with MySQL 5.7 In-Reply-To: <1682b792bb71e134380e59c6a919b5ec@voxtelesys.com> References: <1682b792bb71e134380e59c6a919b5ec@voxtelesys.com> Message-ID: <5cf0e9b8-ffbf-cb11-0c1c-de4f08904482@opensips.org> Hi, Pat! A similar thread regarding this issue can be found here [1] Long story short, you need to make sure your "sql_mode" (mysql> SELECT @@GLOBAL.sql_mode;) does not include STRICT_TRANS_TABLES. Regards, [1]: https://opensips.org/pipermail/users/2013-August/026565.html Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 19.11.2016 00:20, Pat Burke wrote: > When running "opensipsdbctl create" I get the following error message. > > Install presence related tables? (y/n): y > INFO: creating presence tables into opensips_2_2 ... > mysql: [Warning] Using a password on the command line interface can be > insecure. > ERROR 1101 (42000) at line 2: BLOB, TEXT, GEOMETRY or JSON column > 'extra_hdrs' can't have a default value > ERROR: Failed to create presence tables! > > Regards, > *Pat Burke* > > > > > _______________________________________________ > 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: From opensips-list at daork.net Sat Nov 26 05:04:03 2016 From: opensips-list at daork.net (Nathan Ward) Date: Sat, 26 Nov 2016 17:04:03 +1300 Subject: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply" Message-ID: <8DCAE806-CBC7-47B7-9A32-FBB8CB680B52@daork.net> Hi all, I am configuring an SBC with 3 legs - one to the core (i.e. to a registrar and routing server), one towards end users, and one towards a provider. My intent is to make he SBC fairly ?dumb?, and not keep state of registrations etc. The provider requires registration and authentication for calls. I generate registrations from our core towards our provider for each line, through the SBC (forwarding these rather than B2BUA-ing). I also have users registering towards our core. Works great. When we forward an INVITE from our core, the B2BUA creates a new session and forwards it to the provider. The provider challenges (401), which is forwarded back towards the core. The core ACKs this challenge, and forwards the ACK to the provider. Then, the B2BUA deletes the dialog after saying "ACK for a negative reply?. This means that the subsequent authenticated INVITE generates a new instance on the B2BUA, and a new Call-ID - which causes the provider to reject this as the Call-ID is expected to be consistent across auth/unauth INVITEs. Worth noting that before we call b2b_init_request, I call ?force_send_socket?, as we use loopback/virtual addresses for talking with our provider. - Is this expected behaviour? - Is there a way to tweak this so that ACK for a 401/407/etc. does not immediately tear down the B2BUA entity? - Can I avoid this by writing my own B2BUA scenario? We are using the built in ?top hiding? for the moment. If code is required to permit this model I?m happy to work on this, but before I get my hands dirty I thought I?d ask around :-) We have the same behaviour from User->B2BUA->Core - however for the moment our Core doesn?t care about differing Call-ID, which is obviously a problem that I?ll be looking at next..! -- Nathan Ward From adrian.fretwell at topgreen.co.uk Sat Nov 26 11:19:55 2016 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Sat, 26 Nov 2016 10:19:55 +0000 Subject: [OpenSIPS-Users] Actions that apply to all branches Message-ID: <43caffe9-165e-9f6e-2a9a-b99c0376eb45@topgreen.co.uk> Hello, I understand from the documentation that after calling append_branch() any further URI manipulations only apply to the main branch, but I am trying to understand what actions will still apply over all the branches. For example I discovered that rtpproxy_offer() appears to affect all branches, but force_send_socket() only apples to the main branch. Is there a list or rule that will help me work out what I need to apply before branching and what I can leave until later, perhaps until just before t_relay() is called? I hope my question makes sense. Kind regards, Adrian Fretwell The Old School house Top Green Sibthorpe Nottinghamshire NG23 5PN. T: 01636 525360 M: 07850 756603 This electronic message contains information from A-Squared Engineering Services which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email to adrian.fretwell at topgreen.co.uk immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dubeyvishal at yahoo.com Mon Nov 28 05:50:01 2016 From: dubeyvishal at yahoo.com (vishal dubey) Date: Mon, 28 Nov 2016 04:50:01 +0000 (UTC) Subject: [OpenSIPS-Users] Want to create opensips subscriber from restful api or from web application In-Reply-To: <1456921225.1415578.1479732680807@mail.yahoo.com> References: <1456921225.1415578.1479732680807.ref@mail.yahoo.com> <1456921225.1415578.1479732680807@mail.yahoo.com> Message-ID: <424736387.1648153.1480308601268@mail.yahoo.com> Team, Any suggestion on my earlier request ?"Want to create opensips subscriber from restful api or from web application". I want to add?subscribers from other web application. Is there any webservice or other way available to do this? Thanks, in advance.? On Monday, 21 November 2016 6:21 PM, vishal dubey wrote: Hi Team, I want to create opensips subscriber from other web application. I think it is possible through pi_httpd or db_httpd. but i am not able to find any example hot to do this. Please help. Thanks,Vishal -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Nov 28 10:35:23 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 28 Nov 2016 11:35:23 +0200 Subject: [OpenSIPS-Users] Actions that apply to all branches In-Reply-To: <43caffe9-165e-9f6e-2a9a-b99c0376eb45@topgreen.co.uk> References: <43caffe9-165e-9f6e-2a9a-b99c0376eb45@topgreen.co.uk> Message-ID: Hi, Adrian! I don't think you will find such a list. Usually the idea is to do the changes that affect all branches in the main route, and if you want to do per-branch changes, do them in the branch_route. Are you sure that force_send_socket() only applies to the main branch? If you call force_send_socket() in the main route, and then add a second branch, the messages leave on different interfaces? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/26/2016 12:19 PM, Adrian Fretwell wrote: > > Hello, > > I understand from the documentation that after calling append_branch() > any further URI manipulations only apply to the main branch, but I am > trying to understand what actions will still apply over all the > branches. For example I discovered that rtpproxy_offer() appears to > affect all branches, but force_send_socket() only apples to the main > branch. > > Is there a list or rule that will help me work out what I need to > apply before branching and what I can leave until later, perhaps until > just before t_relay() is called? > > I hope my question makes sense. > > Kind regards, > > Adrian Fretwell > The Old School house > Top Green > Sibthorpe > Nottinghamshire > NG23 5PN. > > T: 01636 525360 > M: 07850 756603 > > This electronic message contains information from A-Squared > Engineering Services which may be privileged or confidential. The > information is intended to be for the use of the individual(s) or > entity(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of > this information is prohibited. If you have received this electronic > message in error, please notify us by telephone or email to > adrian.fretwell at topgreen.co.uk immediately. > > > _______________________________________________ > 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: From razvan at opensips.org Mon Nov 28 10:45:57 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 28 Nov 2016 11:45:57 +0200 Subject: [OpenSIPS-Users] Want to create opensips subscriber from restful api or from web application In-Reply-To: <424736387.1648153.1480308601268@mail.yahoo.com> References: <1456921225.1415578.1479732680807.ref@mail.yahoo.com> <1456921225.1415578.1479732680807@mail.yahoo.com> <424736387.1648153.1480308601268@mail.yahoo.com> Message-ID: Hi, Vishal! You could insert directly a subscriber in the database, using something like: insert into subscriber (username, domain, password, ha1, ha1b) values ('100', 'opensips.org', 'password', md5(concat(username, ':', domain, ':', password)), md5(concat(username, '@', domain, ':', domain, ':', password))); You can find more info here: https://www.opensips.org/Documentation/TipsFAQ#toc2 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/28/2016 06:50 AM, vishal dubey wrote: > Team, > > Any suggestion on my earlier request "Want to create opensips > subscriber from restful api or from web application". > > I want to add subscribers from other web application. Is there any > webservice or other way available to do this? > > Thanks, in advance. > > > On Monday, 21 November 2016 6:21 PM, vishal dubey > wrote: > > > Hi Team, > > I want to create opensips subscriber from other web application. I > think it is possible through pi_httpd or db_httpd. but i am not able > to find any example hot to do this. > > Please help. > > Thanks, > Vishal > > > > > _______________________________________________ > 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: From bogdan at opensips.org Mon Nov 28 10:47:22 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 28 Nov 2016 11:47:22 +0200 Subject: [OpenSIPS-Users] Documentation about media relay with OpenSIPS In-Reply-To: References: Message-ID: <3f7f03d9-8512-6202-d24e-02041e7ceb88@opensips.org> Hi, I also recommend rtpproxy - it is a good and powerful (in terms of capabilities) media engine, even if not capable to handle WS. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 23.11.2016 15:53, Johan De Clercq wrote: > I think it's better to use rtpengine. > There is a small tutorial on the opensips site (webrtc) and there is > extensive documentation on github. > > 2016-11-23 12:34 GMT+01:00 Rodrigo Pimenta Carvalho >: > > Dear OpenSIPS users, > > > I would like to learn about how to implement a media relay by > means of OpenSIPS. > > I have found the documentation about the mediaproxy module. Is it > the right documentation for media relaying with OpenSIPS, isn't it? > > > Could someone here point some more documentations about it, > available on Internet, please? > > > Any hint will be very helpful! > > > Best regards. > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > _______________________________________________ > 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: From pimenta at inatel.br Mon Nov 28 11:38:11 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Mon, 28 Nov 2016 10:38:11 +0000 Subject: [OpenSIPS-Users] Documentation about media relay with OpenSIPS In-Reply-To: <3f7f03d9-8512-6202-d24e-02041e7ceb88@opensips.org> References: , <3f7f03d9-8512-6202-d24e-02041e7ceb88@opensips.org> Message-ID: Hi. Thank all of you. Regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: users-bounces at lists.opensips.org em nome de Bogdan-Andrei Iancu Enviado: segunda-feira, 28 de novembro de 2016 07:47 Para: OpenSIPS users mailling list Assunto: Re: [OpenSIPS-Users] Documentation about media relay with OpenSIPS Hi, I also recommend rtpproxy - it is a good and powerful (in terms of capabilities) media engine, even if not capable to handle WS. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com Home - OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 23.11.2016 15:53, Johan De Clercq wrote: I think it's better to use rtpengine. There is a small tutorial on the opensips site (webrtc) and there is extensive documentation on github. 2016-11-23 12:34 GMT+01:00 Rodrigo Pimenta Carvalho >: Dear OpenSIPS users, I would like to learn about how to implement a media relay by means of OpenSIPS. I have found the documentation about the mediaproxy module. Is it the right documentation for media relaying with OpenSIPS, isn't it? Could someone here point some more documentations about it, available on Internet, please? Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 _______________________________________________ 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: From adrian.fretwell at topgreen.co.uk Mon Nov 28 11:57:58 2016 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Mon, 28 Nov 2016 10:57:58 +0000 Subject: [OpenSIPS-Users] handle_timer_job delay in execution Message-ID: Hello, help please. Can anyone give me some direction on how to diagnose what is causing timer job delays in execution? This SIP proxy (2.2.1) has virtually no load, you can see from the timestamps in the log extract and yet there is still a delay. I don't know where to start looking. Nov 28 08:50:37 sip-01 /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: 185.40.4.47 Relay denied. Nov 28 08:51:14 sip-01 /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: WARNING:core:handle_timer_job: timer job has a 70000 us delay in execution Nov 28 08:54:22 sip-01 /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: 185.40.4.198 Relay denied. Kind regards, Adrian Fretwell The Old School house Top Green Sibthorpe Nottinghamshire NG23 5PN. T: 01636 525360 M: 07850 756603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From schoolhouse at a2es.co.uk Mon Nov 28 13:11:32 2016 From: schoolhouse at a2es.co.uk (Schoolhouse Filing) Date: Mon, 28 Nov 2016 12:11:32 +0000 Subject: [OpenSIPS-Users] Actions that apply to all branches In-Reply-To: References: <43caffe9-165e-9f6e-2a9a-b99c0376eb45@topgreen.co.uk> Message-ID: Hi Razvan, What I found was then if I appended branches then called force_send_socket() only the current branch went out on that interface, the other branches went out on a different interface. It's not a problem I will re-structure my script, I was simply appending branches to create a ring group. Kind Regards, Adrian. On 28/11/16 09:35, R?zvan Crainea wrote: > Hi, Adrian! > > I don't think you will find such a list. > Usually the idea is to do the changes that affect all branches in the > main route, and if you want to do per-branch changes, do them in the > branch_route. > Are you sure that force_send_socket() only applies to the main branch? > If you call force_send_socket() in the main route, and then add a > second branch, the messages leave on different interfaces? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/26/2016 12:19 PM, Adrian Fretwell wrote: >> >> Hello, >> >> I understand from the documentation that after calling >> append_branch() any further URI manipulations only apply to the main >> branch, but I am trying to understand what actions will still apply >> over all the branches. For example I discovered that >> rtpproxy_offer() appears to affect all branches, but >> force_send_socket() only apples to the main branch. >> >> Is there a list or rule that will help me work out what I need to >> apply before branching and what I can leave until later, perhaps >> until just before t_relay() is called? >> >> I hope my question makes sense. >> >> Kind regards, >> >> Adrian Fretwell >> The Old School house >> Top Green >> Sibthorpe >> Nottinghamshire >> NG23 5PN. >> >> T: 01636 525360 >> M: 07850 756603 >> >> This electronic message contains information from A-Squared >> Engineering Services which may be privileged or confidential. The >> information is intended to be for the use of the individual(s) or >> entity(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of >> this information is prohibited. If you have received this electronic >> message in error, please notify us by telephone or email to >> adrian.fretwell at topgreen.co.uk immediately. >> >> >> _______________________________________________ >> 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: From razvan at opensips.org Mon Nov 28 14:08:08 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 28 Nov 2016 15:08:08 +0200 Subject: [OpenSIPS-Users] handle_timer_job delay in execution In-Reply-To: References: Message-ID: <215b0748-4f50-1e2d-2481-461a9740c056@opensips.org> Hi, Adrian! Are you still seeing those errors, even if there is no traffic? Can you check if you have any hung transactions? Just run: scripts/opensipsctl fifo get_statistics tm: Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/28/2016 12:57 PM, Adrian Fretwell wrote: > > Hello, help please. > > Can anyone give me some direction on how to diagnose what is causing > timer job delays in execution? This SIP proxy (2.2.1) has virtually > no load, you can see from the timestamps in the log extract and yet > there is still a delay. I don't know where to start looking. > > Nov 28 08:50:37 sip-01 > /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: 185.40.4.47 > Relay denied. > Nov 28 08:51:14 sip-01 > /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: > WARNING:core:handle_timer_job: timer job has a 70000 us > delay in execution > Nov 28 08:54:22 sip-01 > /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: 185.40.4.198 > Relay denied. > > Kind regards, > > Adrian Fretwell > The Old School house > Top Green > Sibthorpe > Nottinghamshire > NG23 5PN. > > T: 01636 525360 > M: 07850 756603 > > > _______________________________________________ > 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: From adrian.fretwell at topgreen.co.uk Mon Nov 28 14:33:34 2016 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Mon, 28 Nov 2016 13:33:34 +0000 Subject: [OpenSIPS-Users] handle_timer_job delay in execution In-Reply-To: <215b0748-4f50-1e2d-2481-461a9740c056@opensips.org> References: <215b0748-4f50-1e2d-2481-461a9740c056@opensips.org> Message-ID: <2f37aac7-4b75-5fa3-284c-9ea16276ec55@topgreen.co.uk> Hi Razvan, I don't see the error regularly, I think that's what is making it hard to track down, they just seem to randomly occur. Anyway here is the output of the fifo command, I will check this as soon as I get the next error. tm:received_replies:: 177 tm:relayed_replies:: 111 tm:local_replies:: 6 tm:UAS_transactions:: 59 tm:UAC_transactions:: 3 tm:2xx_transactions:: 56 tm:3xx_transactions:: 0 tm:4xx_transactions:: 6 tm:5xx_transactions:: 0 tm:6xx_transactions:: 0 tm:inuse_transactions:: 0 Kind regards, Adrian Fretwell The Old School house Top Green Sibthorpe Nottinghamshire NG23 5PN. On 28/11/16 13:08, R?zvan Crainea wrote: > Hi, Adrian! > > Are you still seeing those errors, even if there is no traffic? > Can you check if you have any hung transactions? Just run: > > scripts/opensipsctl fifo get_statistics tm: > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/28/2016 12:57 PM, Adrian Fretwell wrote: >> >> Hello, help please. >> >> Can anyone give me some direction on how to diagnose what is causing >> timer job delays in execution? This SIP proxy (2.2.1) has virtually >> no load, you can see from the timestamps in the log extract and yet >> there is still a delay. I don't know where to start looking. >> >> Nov 28 08:50:37 sip-01 >> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: 185.40.4.47 >> Relay denied. >> Nov 28 08:51:14 sip-01 >> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: >> WARNING:core:handle_timer_job: timer job has a 70000 us >> delay in execution >> Nov 28 08:54:22 sip-01 >> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: >> 185.40.4.198 Relay denied. >> >> Kind regards, >> >> Adrian Fretwell >> The Old School house >> Top Green >> Sibthorpe >> Nottinghamshire >> NG23 5PN. >> >> T: 01636 525360 >> M: 07850 756603 >> >> >> _______________________________________________ >> 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: From razvan at opensips.org Mon Nov 28 14:42:17 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 28 Nov 2016 15:42:17 +0200 Subject: [OpenSIPS-Users] handle_timer_job delay in execution In-Reply-To: <2f37aac7-4b75-5fa3-284c-9ea16276ec55@topgreen.co.uk> References: <215b0748-4f50-1e2d-2481-461a9740c056@opensips.org> <2f37aac7-4b75-5fa3-284c-9ea16276ec55@topgreen.co.uk> Message-ID: Are you doing any DB queries that might take a lot of time? Also, how many children are you using? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/28/2016 03:33 PM, Adrian Fretwell wrote: > > Hi Razvan, > > I don't see the error regularly, I think that's what is making it hard > to track down, they just seem to randomly occur. Anyway here is the > output of the fifo command, I will check this as soon as I get the > next error. > > tm:received_replies:: 177 > tm:relayed_replies:: 111 > tm:local_replies:: 6 > tm:UAS_transactions:: 59 > tm:UAC_transactions:: 3 > tm:2xx_transactions:: 56 > tm:3xx_transactions:: 0 > tm:4xx_transactions:: 6 > tm:5xx_transactions:: 0 > tm:6xx_transactions:: 0 > tm:inuse_transactions:: 0 > > Kind regards, > > Adrian Fretwell > The Old School house > Top Green > Sibthorpe > Nottinghamshire > NG23 5PN. > > On 28/11/16 13:08, R?zvan Crainea wrote: >> Hi, Adrian! >> >> Are you still seeing those errors, even if there is no traffic? >> Can you check if you have any hung transactions? Just run: >> >> scripts/opensipsctl fifo get_statistics tm: >> >> Best regards, >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> On 11/28/2016 12:57 PM, Adrian Fretwell wrote: >>> >>> Hello, help please. >>> >>> Can anyone give me some direction on how to diagnose what is causing >>> timer job delays in execution? This SIP proxy (2.2.1) has virtually >>> no load, you can see from the timestamps in the log extract and yet >>> there is still a delay. I don't know where to start looking. >>> >>> Nov 28 08:50:37 sip-01 >>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: >>> 185.40.4.47 Relay denied. >>> Nov 28 08:51:14 sip-01 >>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: >>> WARNING:core:handle_timer_job: timer job has a 70000 us >>> delay in execution >>> Nov 28 08:54:22 sip-01 >>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: >>> 185.40.4.198 Relay denied. >>> >>> Kind regards, >>> >>> Adrian Fretwell >>> The Old School house >>> Top Green >>> Sibthorpe >>> Nottinghamshire >>> NG23 5PN. >>> >>> T: 01636 525360 >>> M: 07850 756603 >>> >>> >>> _______________________________________________ >>> 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: From adrian.fretwell at topgreen.co.uk Mon Nov 28 15:42:57 2016 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Mon, 28 Nov 2016 14:42:57 +0000 Subject: [OpenSIPS-Users] handle_timer_job delay in execution In-Reply-To: References: <215b0748-4f50-1e2d-2481-461a9740c056@opensips.org> <2f37aac7-4b75-5fa3-284c-9ea16276ec55@topgreen.co.uk> Message-ID: Hi Razvan, No other users of the mysql, everything looks idle. The machine is quite powerful a Dell PowerEdge Server with Dual Intel Xeon CPUs (12 cores/24 threads) and 32Gb Memory and a three disk RAID 5 array. Here is the parameters from config: children=4 dns=no rev_dns=no # for customers listen=udp:XX.XX.XX.X1:5060 # for gateways listen=udp:XX.XX.XX.X2:5060 # for internal media etc. listen=udp:XX.XX.XX.X1:8060 From /etc/defaults # Amount of shared memory to allocate for the running OpenSIPS server (in Mb) S_MEMORY=512 # Amount of pkg memory to allocate for the running OpenSIPS server (in Mb) P_MEMORY=16 Kind regards, Adrian. On 28/11/16 13:42, R?zvan Crainea wrote: > Are you doing any DB queries that might take a lot of time? Also, how > many children are you using? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/28/2016 03:33 PM, Adrian Fretwell wrote: >> >> Hi Razvan, >> >> I don't see the error regularly, I think that's what is making it >> hard to track down, they just seem to randomly occur. Anyway here is >> the output of the fifo command, I will check this as soon as I get >> the next error. >> >> tm:received_replies:: 177 >> tm:relayed_replies:: 111 >> tm:local_replies:: 6 >> tm:UAS_transactions:: 59 >> tm:UAC_transactions:: 3 >> tm:2xx_transactions:: 56 >> tm:3xx_transactions:: 0 >> tm:4xx_transactions:: 6 >> tm:5xx_transactions:: 0 >> tm:6xx_transactions:: 0 >> tm:inuse_transactions:: 0 >> >> Kind regards, >> >> Adrian Fretwell >> The Old School house >> Top Green >> Sibthorpe >> Nottinghamshire >> NG23 5PN. >> >> On 28/11/16 13:08, R?zvan Crainea wrote: >>> Hi, Adrian! >>> >>> Are you still seeing those errors, even if there is no traffic? >>> Can you check if you have any hung transactions? Just run: >>> >>> scripts/opensipsctl fifo get_statistics tm: >>> >>> Best regards, >>> R?zvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> On 11/28/2016 12:57 PM, Adrian Fretwell wrote: >>>> >>>> Hello, help please. >>>> >>>> Can anyone give me some direction on how to diagnose what is >>>> causing timer job delays in execution? This SIP proxy (2.2.1) has >>>> virtually no load, you can see from the timestamps in the log >>>> extract and yet there is still a delay. I don't know where to >>>> start looking. >>>> >>>> Nov 28 08:50:37 sip-01 >>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: >>>> 185.40.4.47 Relay denied. >>>> Nov 28 08:51:14 sip-01 >>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: >>>> WARNING:core:handle_timer_job: timer job has a 70000 us >>>> delay in execution >>>> Nov 28 08:54:22 sip-01 >>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: >>>> 185.40.4.198 Relay denied. >>>> >>>> Kind regards, >>>> >>>> Adrian Fretwell >>>> The Old School house >>>> Top Green >>>> Sibthorpe >>>> Nottinghamshire >>>> NG23 5PN. >>>> >>>> T: 01636 525360 >>>> M: 07850 756603 >>>> >>>> >>>> _______________________________________________ >>>> 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: From razvan at opensips.org Mon Nov 28 17:25:18 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 28 Nov 2016 18:25:18 +0200 Subject: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply" In-Reply-To: <8DCAE806-CBC7-47B7-9A32-FBB8CB680B52@daork.net> References: <8DCAE806-CBC7-47B7-9A32-FBB8CB680B52@daork.net> Message-ID: <51e9e774-b3dc-42fc-6c09-c230a537b77a@opensips.org> Hi, Nathan! Have you tried calling b2b_init_request() with the "a" flag [1]? [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/26/2016 06:04 AM, Nathan Ward wrote: > Hi all, > > I am configuring an SBC with 3 legs - one to the core (i.e. to a registrar and routing server), one towards end users, and one towards a provider. > My intent is to make he SBC fairly ?dumb?, and not keep state of registrations etc. > > The provider requires registration and authentication for calls. I generate registrations from our core towards our provider for each line, through the SBC (forwarding these rather than B2BUA-ing). I also have users registering towards our core. Works great. > > When we forward an INVITE from our core, the B2BUA creates a new session and forwards it to the provider. The provider challenges (401), which is forwarded back towards the core. The core ACKs this challenge, and forwards the ACK to the provider. Then, the B2BUA deletes the dialog after saying "ACK for a negative reply?. > > This means that the subsequent authenticated INVITE generates a new instance on the B2BUA, and a new Call-ID - which causes the provider to reject this as the Call-ID is expected to be consistent across auth/unauth INVITEs. > > Worth noting that before we call b2b_init_request, I call ?force_send_socket?, as we use loopback/virtual addresses for talking with our provider. > > - Is this expected behaviour? > - Is there a way to tweak this so that ACK for a 401/407/etc. does not immediately tear down the B2BUA entity? > - Can I avoid this by writing my own B2BUA scenario? We are using the built in ?top hiding? for the moment. > > If code is required to permit this model I?m happy to work on this, but before I get my hands dirty I thought I?d ask around :-) > > > We have the same behaviour from User->B2BUA->Core - however for the moment our Core doesn?t care about differing Call-ID, which is obviously a problem that I?ll be looking at next..! > > -- > Nathan Ward > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From opensips-list at daork.net Tue Nov 29 03:09:05 2016 From: opensips-list at daork.net (Nathan Ward) Date: Tue, 29 Nov 2016 15:09:05 +1300 Subject: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply" In-Reply-To: <51e9e774-b3dc-42fc-6c09-c230a537b77a@opensips.org> References: <8DCAE806-CBC7-47B7-9A32-FBB8CB680B52@daork.net> <51e9e774-b3dc-42fc-6c09-c230a537b77a@opensips.org> Message-ID: <98FE1CB5-9C14-44A5-B699-E6D7D78C014C@daork.net> > On 29/11/2016, at 5:25 AM, R?zvan Crainea wrote: > > Hi, Nathan! > > Have you tried calling b2b_init_request() with the "a" flag [1]? > > [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 Hi, Yes I have. This passes through the authentication challenge headers in the 401/407, and then any subsequent response headers in the new INVITE. b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message - because it is marked to_del, the ACK that the originator of the INVITE sends in response to the 401/407 deletes the session. I don?t understand how this flag is intended to be used, as there doesn?t seem to be anything in the code to avoid setting to_del if the response is a 401/407 (or anything >=300, actually) with auth challenge headers. All it does is pass through the headers, but as it deletes the session, a new Call-ID is issued by B2BUA when the authenticated invite is generated. -- Nathan Ward From razvan at opensips.org Tue Nov 29 09:26:00 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 29 Nov 2016 10:26:00 +0200 Subject: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply" In-Reply-To: <98FE1CB5-9C14-44A5-B699-E6D7D78C014C@daork.net> References: <8DCAE806-CBC7-47B7-9A32-FBB8CB680B52@daork.net> <51e9e774-b3dc-42fc-6c09-c230a537b77a@opensips.org> <98FE1CB5-9C14-44A5-B699-E6D7D78C014C@daork.net> Message-ID: <95396842-2c30-7be3-1891-a62b2812c360@opensips.org> On 11/29/2016 04:09 AM, Nathan Ward wrote: >> On 29/11/2016, at 5:25 AM, R?zvan Crainea wrote: >> >> Hi, Nathan! >> >> Have you tried calling b2b_init_request() with the "a" flag [1]? >> >> [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 > Hi, > > Yes I have. This passes through the authentication challenge headers in the 401/407, and then any subsequent response headers in the new INVITE. > > b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message - because it is marked to_del, the ACK that the originator of the INVITE sends in response to the 401/407 deletes the session. > > I don?t understand how this flag is intended to be used, as there doesn?t seem to be anything in the code to avoid setting to_del if the response is a 401/407 (or anything >=300, actually) with auth challenge headers. All it does is pass through the headers, but as it deletes the session, a new Call-ID is issued by B2BUA when the authenticated invite is generated. > Hi, Nathan! Yes, you are right, the flag simply passes the auth headers between the two legs. So you were saying that you were only using b2b for topology hiding? If so, why not using directly the topology_hiding module[1]? [1] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com From opensips-list at daork.net Tue Nov 29 09:36:34 2016 From: opensips-list at daork.net (Nathan Ward) Date: Tue, 29 Nov 2016 21:36:34 +1300 Subject: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply" In-Reply-To: <95396842-2c30-7be3-1891-a62b2812c360@opensips.org> References: <8DCAE806-CBC7-47B7-9A32-FBB8CB680B52@daork.net> <51e9e774-b3dc-42fc-6c09-c230a537b77a@opensips.org> <98FE1CB5-9C14-44A5-B699-E6D7D78C014C@daork.net> <95396842-2c30-7be3-1891-a62b2812c360@opensips.org> Message-ID: <028D3361-D85A-4623-AFAC-9DBCC0BA1E95@daork.net> > On 29/11/2016, at 9:26 PM, R?zvan Crainea wrote: > > On 11/29/2016 04:09 AM, Nathan Ward wrote: >>> On 29/11/2016, at 5:25 AM, R?zvan Crainea wrote: >>> >>> Hi, Nathan! >>> >>> Have you tried calling b2b_init_request() with the "a" flag [1]? >>> >>> [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 >> Hi, >> >> Yes I have. This passes through the authentication challenge headers in the 401/407, and then any subsequent response headers in the new INVITE. >> >> b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message - because it is marked to_del, the ACK that the originator of the INVITE sends in response to the 401/407 deletes the session. >> >> I don?t understand how this flag is intended to be used, as there doesn?t seem to be anything in the code to avoid setting to_del if the response is a 401/407 (or anything >=300, actually) with auth challenge headers. All it does is pass through the headers, but as it deletes the session, a new Call-ID is issued by B2BUA when the authenticated invite is generated. >> > Hi, Nathan! > > Yes, you are right, the flag simply passes the auth headers between the two legs. > So you were saying that you were only using b2b for topology hiding? If so, why not using directly the topology_hiding module[1]? Sure that?s an option, however I would like to understand the B2BUA module better. What is the use case for passing authentication headers if the B2BUA instance is shut down when a challenge (401/407) passes through? -- Nathan Ward From razvan at opensips.org Tue Nov 29 13:10:12 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 29 Nov 2016 14:10:12 +0200 Subject: [OpenSIPS-Users] handle_timer_job delay in execution In-Reply-To: References: <215b0748-4f50-1e2d-2481-461a9740c056@opensips.org> <2f37aac7-4b75-5fa3-284c-9ea16276ec55@topgreen.co.uk> Message-ID: <4427caf4-7862-01dd-a4a4-80cfd0b18098@opensips.org> Hi, Adrian! What version of OpenSIPS are you using? Can you update to the latest version? Can you also run an "opensipsctl ps" and send the output back? Also, can you send the list of the modules you are using? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/28/2016 04:42 PM, Adrian Fretwell wrote: > > Hi Razvan, > > No other users of the mysql, everything looks idle. The machine is > quite powerful a Dell PowerEdge Server with Dual Intel Xeon CPUs (12 > cores/24 threads) and 32Gb Memory and a three disk RAID 5 array. Here > is the parameters from config: > > children=4 > dns=no > rev_dns=no > > # for customers > listen=udp:XX.XX.XX.X1:5060 > > # for gateways > listen=udp:XX.XX.XX.X2:5060 > > # for internal media etc. > listen=udp:XX.XX.XX.X1:8060 > > From /etc/defaults > > # Amount of shared memory to allocate for the running OpenSIPS server > (in Mb) > S_MEMORY=512 > > # Amount of pkg memory to allocate for the running OpenSIPS server (in Mb) > P_MEMORY=16 > > Kind regards, > > Adrian. > > > On 28/11/16 13:42, R?zvan Crainea wrote: >> Are you doing any DB queries that might take a lot of time? Also, how >> many children are you using? >> >> Best regards, >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> On 11/28/2016 03:33 PM, Adrian Fretwell wrote: >>> >>> Hi Razvan, >>> >>> I don't see the error regularly, I think that's what is making it >>> hard to track down, they just seem to randomly occur. Anyway here >>> is the output of the fifo command, I will check this as soon as I >>> get the next error. >>> >>> tm:received_replies:: 177 >>> tm:relayed_replies:: 111 >>> tm:local_replies:: 6 >>> tm:UAS_transactions:: 59 >>> tm:UAC_transactions:: 3 >>> tm:2xx_transactions:: 56 >>> tm:3xx_transactions:: 0 >>> tm:4xx_transactions:: 6 >>> tm:5xx_transactions:: 0 >>> tm:6xx_transactions:: 0 >>> tm:inuse_transactions:: 0 >>> >>> Kind regards, >>> >>> Adrian Fretwell >>> The Old School house >>> Top Green >>> Sibthorpe >>> Nottinghamshire >>> NG23 5PN. >>> >>> On 28/11/16 13:08, R?zvan Crainea wrote: >>>> Hi, Adrian! >>>> >>>> Are you still seeing those errors, even if there is no traffic? >>>> Can you check if you have any hung transactions? Just run: >>>> >>>> scripts/opensipsctl fifo get_statistics tm: >>>> >>>> Best regards, >>>> R?zvan Crainea >>>> OpenSIPS Solutions >>>> www.opensips-solutions.com >>>> On 11/28/2016 12:57 PM, Adrian Fretwell wrote: >>>>> >>>>> Hello, help please. >>>>> >>>>> Can anyone give me some direction on how to diagnose what is >>>>> causing timer job delays in execution? This SIP proxy (2.2.1) has >>>>> virtually no load, you can see from the timestamps in the log >>>>> extract and yet there is still a delay. I don't know where to >>>>> start looking. >>>>> >>>>> Nov 28 08:50:37 sip-01 >>>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: >>>>> 185.40.4.47 Relay denied. >>>>> Nov 28 08:51:14 sip-01 >>>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: >>>>> WARNING:core:handle_timer_job: timer job has a 70000 us >>>>> delay in execution >>>>> Nov 28 08:54:22 sip-01 >>>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: >>>>> 185.40.4.198 Relay denied. >>>>> >>>>> Kind regards, >>>>> >>>>> Adrian Fretwell >>>>> The Old School house >>>>> Top Green >>>>> Sibthorpe >>>>> Nottinghamshire >>>>> NG23 5PN. >>>>> >>>>> T: 01636 525360 >>>>> M: 07850 756603 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > > > _______________________________________________ > 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: From bogdan at opensips.org Tue Nov 29 13:14:43 2016 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 29 Nov 2016 14:14:43 +0200 Subject: [OpenSIPS-Users] Actions that apply to all branches In-Reply-To: References: <43caffe9-165e-9f6e-2a9a-b99c0376eb45@topgreen.co.uk> Message-ID: Hi, The per-branch data is : * R-URI * DST-URI (outbound proxy) * PATH header * q value (priority) * send_socket * branch flags Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 28.11.2016 14:11, Schoolhouse Filing wrote: > > Hi Razvan, > > What I found was then if I appended branches then called > force_send_socket() only the current branch went out on that > interface, the other branches went out on a different interface. It's > not a problem I will re-structure my script, I was simply appending > branches to create a ring group. > > Kind Regards, > > Adrian. > > > On 28/11/16 09:35, R?zvan Crainea wrote: >> Hi, Adrian! >> >> I don't think you will find such a list. >> Usually the idea is to do the changes that affect all branches in the >> main route, and if you want to do per-branch changes, do them in the >> branch_route. >> Are you sure that force_send_socket() only applies to the main >> branch? If you call force_send_socket() in the main route, and then >> add a second branch, the messages leave on different interfaces? >> >> Best regards, >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> On 11/26/2016 12:19 PM, Adrian Fretwell wrote: >>> >>> Hello, >>> >>> I understand from the documentation that after calling >>> append_branch() any further URI manipulations only apply to the main >>> branch, but I am trying to understand what actions will still apply >>> over all the branches. For example I discovered that >>> rtpproxy_offer() appears to affect all branches, but >>> force_send_socket() only apples to the main branch. >>> >>> Is there a list or rule that will help me work out what I need to >>> apply before branching and what I can leave until later, perhaps >>> until just before t_relay() is called? >>> >>> I hope my question makes sense. >>> >>> Kind regards, >>> >>> Adrian Fretwell >>> The Old School house >>> Top Green >>> Sibthorpe >>> Nottinghamshire >>> NG23 5PN. >>> >>> T: 01636 525360 >>> M: 07850 756603 >>> >>> This electronic message contains information from A-Squared >>> Engineering Services which may be privileged or confidential. The >>> information is intended to be for the use of the individual(s) or >>> entity(s) named above. If you are not the intended recipient be >>> aware that any disclosure, copying, distribution or use of the >>> contents of this information is prohibited. If you have received >>> this electronic message in error, please notify us by telephone or >>> email to adrian.fretwell at topgreen.co.uk immediately. >>> >>> >>> _______________________________________________ >>> 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: From razvan at opensips.org Tue Nov 29 13:51:15 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 29 Nov 2016 14:51:15 +0200 Subject: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply" In-Reply-To: <028D3361-D85A-4623-AFAC-9DBCC0BA1E95@daork.net> References: <8DCAE806-CBC7-47B7-9A32-FBB8CB680B52@daork.net> <51e9e774-b3dc-42fc-6c09-c230a537b77a@opensips.org> <98FE1CB5-9C14-44A5-B699-E6D7D78C014C@daork.net> <95396842-2c30-7be3-1891-a62b2812c360@opensips.org> <028D3361-D85A-4623-AFAC-9DBCC0BA1E95@daork.net> Message-ID: <6062e454-3fca-db29-7c89-b963f9d71b74@opensips.org> On 11/29/2016 10:36 AM, Nathan Ward wrote: >> On 29/11/2016, at 9:26 PM, R?zvan Crainea wrote: >> >> On 11/29/2016 04:09 AM, Nathan Ward wrote: >>>> On 29/11/2016, at 5:25 AM, R?zvan Crainea wrote: >>>> >>>> Hi, Nathan! >>>> >>>> Have you tried calling b2b_init_request() with the "a" flag [1]? >>>> >>>> [1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010 >>> Hi, >>> >>> Yes I have. This passes through the authentication challenge headers in the 401/407, and then any subsequent response headers in the new INVITE. >>> >>> b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message - because it is marked to_del, the ACK that the originator of the INVITE sends in response to the 401/407 deletes the session. >>> >>> I don?t understand how this flag is intended to be used, as there doesn?t seem to be anything in the code to avoid setting to_del if the response is a 401/407 (or anything >=300, actually) with auth challenge headers. All it does is pass through the headers, but as it deletes the session, a new Call-ID is issued by B2BUA when the authenticated invite is generated. >>> >> Hi, Nathan! >> >> Yes, you are right, the flag simply passes the auth headers between the two legs. >> So you were saying that you were only using b2b for topology hiding? If so, why not using directly the topology_hiding module[1]? > Sure that?s an option, however I would like to understand the B2BUA module better. > What is the use case for passing authentication headers if the B2BUA instance is shut down when a challenge (401/407) passes through? Hi, Nathan! From SIP perspective, the authentication mechanism is completely independent from the message/call. That's why you can even use the same credentials for different calls, as long as the nonce does not change. So the auth server, does not have to map the credentials with a call-id. Some servers might enforce this requirement - however, unfortunately those will not work with opensips B2B. From OpenSIPS perspective, when it receives the 401/407, the transaction will be terminated, and the B2B will destroy the associated entities. When the new INVITE comes in, it will create a completly new entity, that will contain a different Callid (and will be seen as a new leg). These two entities are not corelated at all in the current code. That's why for now the current B2B implementation does not support your scenario. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com From pimenta at inatel.br Tue Nov 29 21:33:52 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Tue, 29 Nov 2016 20:33:52 +0000 Subject: [OpenSIPS-Users] Conflicting information from commands 'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '. Message-ID: Hi. I have peer A and peer B online on my OpenSIPS. After removing peer A from table location and reseting peer A, I have: Connection:: ID=29 Type=tcp State=0 Source=127.0.0.1:52887 Destination=127.0.0.1:5060 Lifetime=1970-01-01 08:44:41 It means that peer A is online on OpenSIPS via TCP socket with port 52887. This is the result of command ' opensipsctl fifo list_tcp_conns '. However, the commad 'opensipsctl ul show' gives me: AOR:: intercomA_5dtUWgwgqzR6 Contact:: sip:intercomA_5dtUWgwgqzR6 at 127.0.0.1:48694;transport=TCP;ob Q= Expires:: 479 Callid:: 5694778c-6178-4e80-bf2e-7a4dc0deb5d1 Cseq:: 37504 User-agent:: n/a State:: CS_SYNC Flags:: 0 Cflags:: Socket:: tcp:127.0.0.1:5060 Methods:: 8063 Attr:: in_same_network SIP_instance:: It means that peer A is online on OpenSIPS via TCP socket with port 48694. So, I have a kind of conflict here. How can it be possible? So, if peer A calls peer B, when B answers I can see the following log: Jan 1 08:36:14 [435] ERROR:core:tcpconn_async_connect: failed to retrieve SO_ERROR [server=127.0.0.1:48694] (111) Connection refused Why such behavior does exist in OpenSIPS? How to avoid it? And after a while a new TCP connection appered in port 52887. Like this: Contact:: sip:intercomA_5dtUWgwgqzR6 at 127.0.0.1:52887;transport=TCP;ob Q= Expires:: 236 Callid:: 96672dc5-a98c-468e-a07a-aca27748791a Cseq:: 25094 User-agent:: n/a State:: CS_SYNC Flags:: 0 Cflags:: Socket:: tcp:127.0.0.1:5060 Methods:: 8063 Attr:: in_same_network SIP_instance:: Could it be a problem in OpenSIPS? Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.fretwell at topgreen.co.uk Wed Nov 30 10:43:46 2016 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Wed, 30 Nov 2016 09:43:46 +0000 Subject: [OpenSIPS-Users] Actions that apply to all branches In-Reply-To: References: <43caffe9-165e-9f6e-2a9a-b99c0376eb45@topgreen.co.uk> Message-ID: <76b52f4b-5b0a-5b0a-3254-512b384d4d7a@topgreen.co.uk> Bogdan, thank you that is very helpful. Kind regards, Adrian Fretwell On 29/11/16 12:14, Bogdan-Andrei Iancu wrote: > Hi, > > The per-branch data is : > * R-URI > * DST-URI (outbound proxy) > * PATH header > * q value (priority) > * send_socket > * branch flags > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 28.11.2016 14:11, Schoolhouse Filing wrote: >> >> Hi Razvan, >> >> What I found was then if I appended branches then called >> force_send_socket() only the current branch went out on that >> interface, the other branches went out on a different interface. >> It's not a problem I will re-structure my script, I was simply >> appending branches to create a ring group. >> >> Kind Regards, >> >> Adrian. >> >> >> On 28/11/16 09:35, R?zvan Crainea wrote: >>> Hi, Adrian! >>> >>> I don't think you will find such a list. >>> Usually the idea is to do the changes that affect all branches in >>> the main route, and if you want to do per-branch changes, do them in >>> the branch_route. >>> Are you sure that force_send_socket() only applies to the main >>> branch? If you call force_send_socket() in the main route, and then >>> add a second branch, the messages leave on different interfaces? >>> >>> Best regards, >>> R?zvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> On 11/26/2016 12:19 PM, Adrian Fretwell wrote: >>>> >>>> Hello, >>>> >>>> I understand from the documentation that after calling >>>> append_branch() any further URI manipulations only apply to the >>>> main branch, but I am trying to understand what actions will still >>>> apply over all the branches. For example I discovered that >>>> rtpproxy_offer() appears to affect all branches, but >>>> force_send_socket() only apples to the main branch. >>>> >>>> Is there a list or rule that will help me work out what I need to >>>> apply before branching and what I can leave until later, perhaps >>>> until just before t_relay() is called? >>>> >>>> I hope my question makes sense. >>>> >>>> Kind regards, >>>> >>>> Adrian Fretwell >>>> The Old School house >>>> Top Green >>>> Sibthorpe >>>> Nottinghamshire >>>> NG23 5PN. >>>> >>>> T: 01636 525360 >>>> M: 07850 756603 >>>> >>>> This electronic message contains information from A-Squared >>>> Engineering Services which may be privileged or confidential. The >>>> information is intended to be for the use of the individual(s) or >>>> entity(s) named above. If you are not the intended recipient be >>>> aware that any disclosure, copying, distribution or use of the >>>> contents of this information is prohibited. If you have received >>>> this electronic message in error, please notify us by telephone or >>>> email to adrian.fretwell at topgreen.co.uk immediately. >>>> >>>> >>>> _______________________________________________ >>>> 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: From razvan at opensips.org Wed Nov 30 11:47:17 2016 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 30 Nov 2016 12:47:17 +0200 Subject: [OpenSIPS-Users] Conflicting information from commands 'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '. In-Reply-To: References: Message-ID: Hi, Rodrigo! Before removing A from the user location, did you do an opensips ul show to see what registrations OpenSIPS knows? Are there multiple registrations? Are you deleting all of them? Opening a TCP connection to opensips doesn't necessarily mean that the client also sent a REGISTER message, and therefore the client is not yet registered from SIP perspective. What you might see there (with port 48695) might be an old (bogus) registration. After a while, when the client registers, you see the correct info. Best regards, R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 11/29/2016 10:33 PM, Rodrigo Pimenta Carvalho wrote: > Hi. > > > I have peer A and peer B online on my OpenSIPS. > > After removing peer A from table location and reseting peer A, I have: > > > Connection:: ID=29 Type=tcp State=0 Source=127.0.0.1:*52887* > Destination=127.0.0.1:5060 Lifetime=1970-01-01 08:44:41 > > It means that peer A is online on OpenSIPS via TCP socket with port > 52887. This is the result of command '/opensipsctl fifo list_tcp_conns/'. > > > However, the commad '/opensipsctl ul show/' gives me: > > > AOR:: intercomA_5dtUWgwgqzR6 > Contact:: > sip:intercomA_5dtUWgwgqzR6 at 127.0.0.1:*48694*;transport=TCP;ob Q= > Expires:: 479 > Callid:: 5694778c-6178-4e80-bf2e-7a4dc0deb5d1 > Cseq:: 37504 > User-agent:: n/a > State:: CS_SYNC > Flags:: 0 > Cflags:: > Socket:: tcp:127.0.0.1:5060 > Methods:: 8063 > Attr:: in_same_network > SIP_instance:: > > It means that peer A is online on OpenSIPS via TCP socket with port > 48694. So, I have a kind of conflict here. How can it be possible? > > So, if peer A calls peer B, when B answers I can see the following log: > > > Jan 1 08:36:14 [435] ERROR:core:tcpconn_async_connect: failed to > retrieve SO_ERROR [server=127.0.0.1:*48694*] (111) Connection refused > > > Why such behavior does exist in OpenSIPS? How to avoid it? > > And after a while a new TCP connection appered in port 52887. Like this: > > > Contact:: > sip:intercomA_5dtUWgwgqzR6 at 127.0.0.1:52887;transport=TCP;ob Q= > Expires:: 236 > Callid:: 96672dc5-a98c-468e-a07a-aca27748791a > Cseq:: 25094 > User-agent:: n/a > State:: CS_SYNC > Flags:: 0 > Cflags:: > Socket:: tcp:127.0.0.1:5060 > Methods:: 8063 > Attr:: in_same_network > SIP_instance:: > > Could it be a problem in OpenSIPS? > > > > Any hint will be very helpful! > > > Best regards. > > > > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From pimenta at inatel.br Wed Nov 30 12:07:45 2016 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Wed, 30 Nov 2016 11:07:45 +0000 Subject: [OpenSIPS-Users] Conflicting information from commands 'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '. In-Reply-To: References: , Message-ID: Hi. Razvan. Thank you very much! If I remember, I guess that I had removed all records from table location, of user A. But I will pay more attention on it next time. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: users-bounces at lists.opensips.org em nome de R?zvan Crainea Enviado: quarta-feira, 30 de novembro de 2016 08:47 Para: users at lists.opensips.org Assunto: Re: [OpenSIPS-Users] Conflicting information from commands 'opensipsctl ul show' and ' opensipsctl fifo list_tcp_conns '. Hi, Rodrigo! Before removing A from the user location, did you do an opensips ul show to see what registrations OpenSIPS knows? Are there multiple registrations? Are you deleting all of them? Opening a TCP connection to opensips doesn't necessarily mean that the client also sent a REGISTER message, and therefore the client is not yet registered from SIP perspective. What you might see there (with port 48695) might be an old (bogus) registration. After a while, when the client registers, you see the correct info. Best regards, R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com Home ? OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 11/29/2016 10:33 PM, Rodrigo Pimenta Carvalho wrote: > Hi. > > > I have peer A and peer B online on my OpenSIPS. > > After removing peer A from table location and reseting peer A, I have: > > > Connection:: ID=29 Type=tcp State=0 Source=127.0.0.1:*52887* > Destination=127.0.0.1:5060 Lifetime=1970-01-01 08:44:41 > > It means that peer A is online on OpenSIPS via TCP socket with port > 52887. This is the result of command '/opensipsctl fifo list_tcp_conns/'. > > > However, the commad '/opensipsctl ul show/' gives me: > > > AOR:: intercomA_5dtUWgwgqzR6 > Contact:: > sip:intercomA_5dtUWgwgqzR6 at 127.0.0.1:*48694*;transport=TCP;ob Q= > Expires:: 479 > Callid:: 5694778c-6178-4e80-bf2e-7a4dc0deb5d1 > Cseq:: 37504 > User-agent:: n/a > State:: CS_SYNC > Flags:: 0 > Cflags:: > Socket:: tcp:127.0.0.1:5060 > Methods:: 8063 > Attr:: in_same_network > SIP_instance:: > > It means that peer A is online on OpenSIPS via TCP socket with port > 48694. So, I have a kind of conflict here. How can it be possible? > > So, if peer A calls peer B, when B answers I can see the following log: > > > Jan 1 08:36:14 [435] ERROR:core:tcpconn_async_connect: failed to > retrieve SO_ERROR [server=127.0.0.1:*48694*] (111) Connection refused > > > Why such behavior does exist in OpenSIPS? How to avoid it? > > And after a while a new TCP connection appered in port 52887. Like this: > > > Contact:: > sip:intercomA_5dtUWgwgqzR6 at 127.0.0.1:52887;transport=TCP;ob Q= > Expires:: 236 > Callid:: 96672dc5-a98c-468e-a07a-aca27748791a > Cseq:: 25094 > User-agent:: n/a > State:: CS_SYNC > Flags:: 0 > Cflags:: > Socket:: tcp:127.0.0.1:5060 > Methods:: 8063 > Attr:: in_same_network > SIP_instance:: > > Could it be a problem in OpenSIPS? > > > > Any hint will be very helpful! > > > Best regards. > > > > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users Users Info Page - OpenSIPS lists.opensips.org Discussions about how to use OpenSIPS (non-business). To see the collection of prior postings to the list, visit the Users Archives. > _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Users Info Page - OpenSIPS lists.opensips.org Discussions about how to use OpenSIPS (non-business). To see the collection of prior postings to the list, visit the Users Archives. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.fretwell at topgreen.co.uk Wed Nov 30 10:41:20 2016 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Wed, 30 Nov 2016 09:41:20 +0000 Subject: [OpenSIPS-Users] handle_timer_job delay in execution In-Reply-To: <4427caf4-7862-01dd-a4a4-80cfd0b18098@opensips.org> References: <215b0748-4f50-1e2d-2481-461a9740c056@opensips.org> <2f37aac7-4b75-5fa3-284c-9ea16276ec55@topgreen.co.uk> <4427caf4-7862-01dd-a4a4-80cfd0b18098@opensips.org> Message-ID: Hi Razvan, I am using Opensips 2.2.1 Which I believe is the latest stable version. PS output: Process:: ID=0 PID=22168 Type=attendant Process:: ID=1 PID=22169 Type=RTPP timeout receiver Process:: ID=2 PID=22170 Type=MI Datagram Process:: ID=3 PID=22171 Type=MI Datagram Process:: ID=4 PID=22172 Type=MI FIFO Process:: ID=5 PID=22173 Type=Stun loop Process:: ID=6 PID=22174 Type=time_keeper Process:: ID=7 PID=22175 Type=timer Process:: ID=8 PID=22176 Type=SIP receiver udp:xxx.xxx.xxx.71:5060 Process:: ID=9 PID=22177 Type=SIP receiver udp:xxx.xxx.xxx.71:5060 Process:: ID=10 PID=22178 Type=SIP receiver udp:xxx.xxx.xxx.71:5060 Process:: ID=11 PID=22179 Type=SIP receiver udp:xxx.xxx.xxx.71:5060 Process:: ID=12 PID=22180 Type=SIP receiver udp:xxx.xxx.xxx.72:5060 Process:: ID=13 PID=22181 Type=SIP receiver udp:xxx.xxx.xxx.72:5060 Process:: ID=14 PID=22183 Type=SIP receiver udp:xxx.xxx.xxx.72:5060 Process:: ID=15 PID=22185 Type=SIP receiver udp:xxx.xxx.xxx.72:5060 Process:: ID=16 PID=22187 Type=SIP receiver udp:xxx.xxx.xxx.71:8060 Process:: ID=17 PID=22189 Type=SIP receiver udp:xxx.xxx.xxx.71:8060 Process:: ID=18 PID=22191 Type=SIP receiver udp:xxx.xxx.xxx.71:8060 Process:: ID=19 PID=22193 Type=SIP receiver udp:xxx.xxx.xxx.71:8060 Here is the modules section from my config, you will be able to see the modules loaded and all their parameters. # ------------------ Modules Section ---------------------------------- # # Loading modules and their parameters # --------------------------------------------------------------------- #set module path mpath="/usr/local/opensips-pxy-2.2.1/lib64/opensips/modules/" /* --- Module STUN -------------------- ------------------------------------*/ loadmodule "stun.so" modparam("stun", "primary_ip", "xxx.xxx.xxx.71") modparam("stun", "alternate_ip", "xxx.xxx.xxx.72") modparam("stun", "primary_port", "5060") modparam("stun","alternate_port","3478") /* --- Module SIGNALING --------------- ------------------------------------*/ loadmodule "signaling.so" /* --- Module STATELESS --------------- ------------------------------------*/ loadmodule "sl.so" /* --- Module TRANSACTION ------------- ------------------------------------*/ loadmodule "tm.so" modparam("tm", "fr_timeout", 25) modparam("tm", "fr_inv_timeout", 120) modparam("tm", "restart_fr_on_each_reply", 1) modparam("tm", "onreply_avp_mode", 1) modparam("tm", "auto_100trying", 0) /* --- Module RECORD ROUTE ------------ ------------------------------------*/ loadmodule "rr.so" modparam("rr", "append_fromtag", 1) /* --- Module MAX FORWARD ------------- ------------------------------------*/ loadmodule "maxfwd.so" modparam("maxfwd", "max_limit", 80) /* --- Module SIPMSGOPS --------------- ------------------------------------*/ loadmodule "sipmsgops.so" /* --- Module TEXTOPS ----------------- ------------------------------------*/ loadmodule "textops.so" /* --- Module MI_FIFO ----------------- ------------------------------------*/ loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips-pxy_fifo") modparam("mi_fifo", "fifo_mode", 0666) modparam("mi_fifo", "fifo_group", "a2ipx") /* --- Module MI_DATAGRAM ----------------- ------------------------------------*/ loadmodule "mi_datagram.so" modparam("mi_datagram", "socket_name", "udp:xxx.xxx.xxx.71:9061") modparam("mi_datagram", "children_count", 2) /* --- Module URI --------------------- ------------------------------------*/ loadmodule "uri.so" modparam("uri", "use_uri_table", 0) /* --- Module MYSQL ------------------- ------------------------------------*/ loadmodule "db_mysql.so" /* --- Module USRLOC ------------------ ------------------------------------*/ loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url","mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") /* --- Module REGISTRAR --------------- ------------------------------------*/ loadmodule "registrar.so" modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") modparam("registrar", "default_expires", 1800) modparam("registrar", "min_expires", 300) modparam("registrar", "max_expires", 3600) modparam("registrar", "received_avp", "$avp(received_nh)") modparam("registrar", "max_contacts", 10) /* --- Module ACC --------------------- ------------------------------------*/ loadmodule "acc.so" modparam("acc", "early_media", 0) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") modparam("acc", "db_extra", "src_ip=$si; caller_id=$avp(cdr_auth_user); callee_id=$tu; call_type=$avp(cdr_call_type); direction=$avp(cdr_direction); txfr_call_id=$avp(txfr_call_id)") modparam("acc", "multi_leg_info", "leg_src=$avp(src); leg_dst=$avp(dst)") /* --- Module AUTH -------------------- ------------------------------------*/ loadmodule "auth.so" #modparam("auth", "disable_nonce_check", 1) /* --- Module AUTH_DB ----------------- ------------------------------------*/ loadmodule "auth_db.so" modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db|uri", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") modparam("auth_db", "load_credentials", "$avp(rpid)=rpid; $avp(pres)=presentation; $avp(og_acl)=acl_string; $avp(std_code)=std_code; $avp(og_con_calls)=con_calls; $avp(og_centrex)=centrex; $avp(og_centr ex_cli)=centrex_cli; $avp(default_cps)=default_cps; $avp(allowed_cps)=allowed_cps") /* --- Module ALIAS_DB ---------------- ------------------------------------*/ loadmodule "alias_db.so" modparam("alias_db", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") /* --- Module CACHEDB_LOCAL------------ ------------------------------------*/ loadmodule "cachedb_local.so" modparam("cachedb_local", "cache_table_size", 20) modparam("cachedb_local", "exec_threshold", 100000) modparam("cachedb_local", "cache_clean_period", 1800) /* --- Module DIALOG ------------------ ------------------------------------*/ loadmodule "dialog.so" modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "default_timeout", 21600) # 6 hours timeout modparam("dialog", "db_mode", 2) modparam("dialog", "db_update_period", 45) modparam("dialog", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") modparam("dialog", "profiles_with_value", "concalls; gwcalls; inbound; outbound") modparam("dialog", "profiles_no_value", "local; facility") modparam("dialog", "rr_param", "lts") modparam("dialog", "options_ping_interval", 60) modparam("dialog", "reinvite_ping_interval", 900) # 15 minute timeout /* --- Module NATHELPER --------------- ------------------------------------*/ loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 40) modparam("nathelper", "ping_nated_only", 0) modparam("nathelper", "force_socket", "xxx.xxx.xxx.71:5060") modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG") modparam("nathelper", "sipping_from", "sip:pinger at vox1.a2ipx.co.uk") modparam("nathelper", "received_avp", "$avp(received_nh)") modparam("nathelper", "ping_threshold", 5) modparam("nathelper", "max_pings_lost", 3) modparam("nathelper", "natping_partitions", 4) /* --- Module UAC --------------------- ------------------------------------*/ loadmodule "uac.so" modparam("uac","restore_mode","auto") modparam("uac","restore_passwd","qh3gd63rs") modparam("uac","rr_from_store_param","AF-vsf") modparam("uac","rr_to_store_param","AF-vst") /* --- Module UAC AUTH ---------------- ------------------------------------*/ loadmodule "uac_auth.so" /* --- Module RTPPROXY ---------------- ------------------------------------*/ loadmodule "rtpproxy.so" #modparam("rtpproxy", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") modparam("rtpproxy", "rtpproxy_sock", "udp:xxx.xxx.xxx.77:12221 udp:xxx.xxx.xxx.78:12221") modparam("rtpproxy", "rtpp_notify_socket", "tcp:xxx.xxx.xxx.71:19991") /* --- Module DIALPLAN ---------------- ------------------------------------*/ loadmodule "dialplan.so" modparam("dialplan", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") /* --- Module DROUTING ---------------- ------------------------------------*/ loadmodule "drouting.so" modparam("drouting", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") modparam("drouting", "define_blacklist", 'gws= 2') modparam("drouting", "use_partitions", 0) modparam("drouting", "probing_from", "sip:pinger at xxx.xxx.xxx.72") /* --- Module PERMISSIONS ------------- ------------------------------------*/ loadmodule "permissions.so" modparam("permissions", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") modparam("permissions", "address_table", "address") /* --- Module DOMAIN ------------------ ------------------------------------*/ loadmodule "domain.so" modparam("domain", "db_mode", 1) # Use caching modparam("domain", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") /* --- Module SST -------------------- ------------------------------------*/ #loadmodule "sst.so" #modparam("sst", "sst_flag", "SST_FLAG") #modparam("sst", "min_se", 1800) # 30 min as described in RFC 4028 #modparam("sst", "sst_interval", 0) #modparam("sst", "enable_stats", 0) # no stats required /* --- Module AVPOPS ------------------ ------------------------------------*/ loadmodule "avpops.so" modparam("avpops", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") modparam("avpops","avp_table","usr_preferences") /* --- Module EXEC -------------------- ------------------------------------*/ loadmodule "exec.so" /* --- Module FRAUD DETECTION---------- ------------------------------------*/ loadmodule "fraud_detection.so" modparam("fraud_detection", "db_url", "mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221") /* --- Module SIPTRACE ---------------- ------------------------------------*/ loadmodule "siptrace.so" modparam("siptrace", "trace_id", "[tid]uri=mysql://opensips221:xxxxxxxxxxxx at localhost/opensips221; table=sip_trace;") #modparam("siptrace", "trace_local_ip", "xxx.xxx.xxx.71") modparam("siptrace", "trace_on", 0) /* --- Module OPTIONS ----------------- ------------------------------------*/ loadmodule "options.so" /* --- Module TOPOLOGY HIDING---------- ------------------------------------*/ loadmodule "topology_hiding.so" modparam("topology_hiding", "th_callid_passwd", "xxxxxxxxxxx") modparam("topology_hiding", "th_callid_prefix", "JPCJ09_") modparam("topology_hiding", "force_dialog", 0) modparam("topology_hiding", "th_contact_encode_passwd", "qkwehg34r3kq4bkq4h444") modparam("topology_hiding", "th_contact_encode_param", "A2Xinc") /* --- Module PROTO_UDP --------------- ------------------------------------*/ loadmodule "proto_udp.so" Kind regards, Adrian Fretwell A? Engineering Services The Old School house Top Green Sibthorpe Nottinghamshire NG23 5PN. On 29/11/16 12:10, R?zvan Crainea wrote: > Hi, Adrian! > > What version of OpenSIPS are you using? Can you update to the latest > version? > Can you also run an "opensipsctl ps" and send the output back? Also, > can you send the list of the modules you are using? > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 11/28/2016 04:42 PM, Adrian Fretwell wrote: >> >> Hi Razvan, >> >> No other users of the mysql, everything looks idle. The machine is >> quite powerful a Dell PowerEdge Server with Dual Intel Xeon CPUs (12 >> cores/24 threads) and 32Gb Memory and a three disk RAID 5 array. >> Here is the parameters from config: >> >> children=4 >> dns=no >> rev_dns=no >> >> # for customers >> listen=udp:XX.XX.XX.X1:5060 >> >> # for gateways >> listen=udp:XX.XX.XX.X2:5060 >> >> # for internal media etc. >> listen=udp:XX.XX.XX.X1:8060 >> >> From /etc/defaults >> >> # Amount of shared memory to allocate for the running OpenSIPS server >> (in Mb) >> S_MEMORY=512 >> >> # Amount of pkg memory to allocate for the running OpenSIPS server >> (in Mb) >> P_MEMORY=16 >> >> Kind regards, >> >> Adrian. >> >> >> On 28/11/16 13:42, R?zvan Crainea wrote: >>> Are you doing any DB queries that might take a lot of time? Also, >>> how many children are you using? >>> >>> Best regards, >>> R?zvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> On 11/28/2016 03:33 PM, Adrian Fretwell wrote: >>>> >>>> Hi Razvan, >>>> >>>> I don't see the error regularly, I think that's what is making it >>>> hard to track down, they just seem to randomly occur. Anyway here >>>> is the output of the fifo command, I will check this as soon as I >>>> get the next error. >>>> >>>> tm:received_replies:: 177 >>>> tm:relayed_replies:: 111 >>>> tm:local_replies:: 6 >>>> tm:UAS_transactions:: 59 >>>> tm:UAC_transactions:: 3 >>>> tm:2xx_transactions:: 56 >>>> tm:3xx_transactions:: 0 >>>> tm:4xx_transactions:: 6 >>>> tm:5xx_transactions:: 0 >>>> tm:6xx_transactions:: 0 >>>> tm:inuse_transactions:: 0 >>>> >>>> Kind regards, >>>> >>>> Adrian Fretwell >>>> The Old School house >>>> Top Green >>>> Sibthorpe >>>> Nottinghamshire >>>> NG23 5PN. >>>> >>>> On 28/11/16 13:08, R?zvan Crainea wrote: >>>>> Hi, Adrian! >>>>> >>>>> Are you still seeing those errors, even if there is no traffic? >>>>> Can you check if you have any hung transactions? Just run: >>>>> >>>>> scripts/opensipsctl fifo get_statistics tm: >>>>> >>>>> Best regards, >>>>> R?zvan Crainea >>>>> OpenSIPS Solutions >>>>> www.opensips-solutions.com >>>>> On 11/28/2016 12:57 PM, Adrian Fretwell wrote: >>>>>> >>>>>> Hello, help please. >>>>>> >>>>>> Can anyone give me some direction on how to diagnose what is >>>>>> causing timer job delays in execution? This SIP proxy (2.2.1) >>>>>> has virtually no load, you can see from the timestamps in the log >>>>>> extract and yet there is still a delay. I don't know where to >>>>>> start looking. >>>>>> >>>>>> Nov 28 08:50:37 sip-01 >>>>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22176]: main: >>>>>> 185.40.4.47 Relay denied. >>>>>> Nov 28 08:51:14 sip-01 >>>>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22193]: >>>>>> WARNING:core:handle_timer_job: timer job has a 70000 >>>>>> us delay in execution >>>>>> Nov 28 08:54:22 sip-01 >>>>>> /usr/local/opensips-pxy-2.2.1/sbin/opensips[22178]: main: >>>>>> 185.40.4.198 Relay denied. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Adrian Fretwell >>>>>> The Old School house >>>>>> Top Green >>>>>> Sibthorpe >>>>>> Nottinghamshire >>>>>> NG23 5PN. >>>>>> >>>>>> T: 01636 525360 >>>>>> M: 07850 756603 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> >> _______________________________________________ >> 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: