From shahzad at voip-demos.com Sun Mar 1 03:25:14 2015 From: shahzad at voip-demos.com (shahzad at voip-demos.com) Date: Sun, 01 Mar 2015 03:25:14 +0100 Subject: [OpenSIPS-Users] =?utf-8?q?No_support_for_TCP_in_OpenSIPS_v2=2E1?= =?utf-8?q?=3F?= Message-ID: <209109c1aa320341ee032be1b3b58d2a@voip-demos.com> OK, so i have successfully compiled opensip v2.1 trunk and tried to start it with minimal configuration, it fails and gives error on global TCP parameters. It does not even accepts "disable_tcp=no". I do not understand what is wrong here, i rechecked every option in "make menuconfig" and didn't find anything related to TCP anywhere. Please help, i need TCP support to test opensips capability to interconnect with webrtc endpoints and rtpengine service. Here is the output of opensips -V command, -- version: opensips 2.1.1dev (x86_64/linux) flags: STATS: On, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-FUTEX-ADAPTIVE_WAIT, USE_PTHREAD_MUTEX 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: 2dd472a main.c compiled on 03:10:21 Mar 1 2015 with gcc 4.7 -- Thank you. From bogdan at opensips.org Sun Mar 1 12:51:36 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sun, 01 Mar 2015 12:51:36 +0100 Subject: [OpenSIPS-Users] Error compiling opensips v2.1 trunk Message-ID: <0g5wwu8bpnbc1qsbg4ajp5oj.1425210696564@email.android.com> Thank you too for reporting. Regards, Bogdan Sent from Samsung Mobile -------- Original message -------- From: shahzad at voip-demos.com Date:28/02/2015 20:26 (GMT+01:00) To: Bogdan-Andrei Iancu Cc: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Error compiling opensips v2.1 trunk Thanks. This seems to have solved the problem. Thank you. On 2015-02-28 09:18, Bogdan-Andrei Iancu wrote: > Hi, > > Please update the whole tree from GIT and try again. > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 28.02.2015 00:57, shahzad at voip-demos.com wrote: >> Hi, >> >> I am trying to compile opensips v2.1 trunk and getting this error, >> >> -- make[2]: Entering directory >> `/usr/src/svn-src/opensips/modules/tlsops' tls_select.c:32:30: fatal >> error: ../../tcp_server.h: No such file or directory >> compilation terminated. >> tlsops.c:42:59: fatal error: ../../tcp_conn.h: No such file or >> directory >> compilation terminated. >> Compiling tlsops.c >> Compiling tls_select.c >> tls_select.c:32:30: fatal error: ../../tcp_server.h: No such file or >> directory >> compilation terminated. >> tlsops.c:42:59: fatal error: ../../tcp_conn.h: No such file or >> directory >> compilation terminated. >> make[2]: *** [tls_select.o] Error 1 >> make[2]: *** Waiting for unfinished jobs.... >> make[2]: *** [tlsops.o] Error 1 >> make[2]: Leaving directory >> `/usr/src/svn-src/opensips/modules/tlsops' make[1]: *** [modules] >> Error 2 >> make[1]: Leaving directory `/usr/src/svn-src/opensips' -- >> >> This may be a missing library but i couldn't figure out the lib name >> to install it. >> >> I am using Debian Wheezy 64-bit inside a LXC container. >> >> Thank you. >> >> >> _______________________________________________ >> 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 Sun Mar 1 13:03:14 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sun, 01 Mar 2015 13:03:14 +0100 Subject: [OpenSIPS-Users] No support for TCP in OpenSIPS v2.1? Message-ID: Hi, In 2.1 the protocols are loaded as modules and there is no disable param at all. So just set the tcp listener and do loadmodule "proto_tcp.so" . Note many parameters related to protocols were changed or moved and the docs were not yet updated. Regards, Bogdan Sent from Samsung Mobile -------- Original message -------- From: shahzad at voip-demos.com Date:01/03/2015 03:25 (GMT+01:00) To: users at lists.opensips.org Subject: [OpenSIPS-Users] No support for TCP in OpenSIPS v2.1? OK, so i have successfully compiled opensip v2.1 trunk and tried to start it with minimal configuration, it fails and gives error on global TCP parameters. It does not even accepts "disable_tcp=no". I do not understand what is wrong here, i rechecked every option in "make menuconfig" and didn't find anything related to TCP anywhere. Please help, i need TCP support to test opensips capability to interconnect with webrtc endpoints and rtpengine service. Here is the output of opensips -V command, -- version: opensips 2.1.1dev (x86_64/linux) flags: STATS: On, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-FUTEX-ADAPTIVE_WAIT, USE_PTHREAD_MUTEX 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: 2dd472a main.c compiled on 03:10:21 Mar? 1 2015 with gcc 4.7 -- Thank you. _______________________________________________ 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 Sun Mar 1 18:29:11 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sun, 01 Mar 2015 19:29:11 +0200 Subject: [OpenSIPS-Users] X-Lite presence In-Reply-To: <54F0CB83.7080002@gmail.com> References: <54EFC728.7080505@gmail.com> <54F0C151.9010204@opensips.org> <54F0CB83.7080002@gmail.com> Message-ID: <54F34C67.1000201@opensips.org> The key log is: Feb 27 14:27:58 sip1 /sbin/opensips[31967]: DBG:pua:send_publish_int: request for a publish with expires 0 and no record found But this is harmless - it says it does not want to send an un-PUBLISH for a presentity already terminated . The question for you is - is the presence status of that device correctly visible ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 27.02.2015 21:54, campusvtv wrote: > Hello, > > i'm using UDP for the end point and on debug 4 for key PUA (during > X-Lite REGISTER): > > http://pastebin.com/9A7fjNxv > > Thank you > > Regards > > El 27/02/2015 a las 14:11, Bogdan-Andrei Iancu escribi?: >> Hi, >> >> Do you use TCP for the end point ? No other error in place ? >> >> Can you run in debug=4 to get more logs ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 27.02.2015 03:23, campusvtv wrote: >>> Hello, >>> >>> I'm trying to implement presence for X-Lite with pua y pua_usrloc >>> modules. >>> >>> My modules configuration is: >>> [....] >>> >>> Feb 26 18:39:26 sip1 /sbin/opensips[27330]: Usuario 44444 Registrado >>> Feb 26 18:39:26 sip1 /sbin/opensips[27327]: User-Agent es X-Lite >>> Feb 26 18:39:26 sip1 /sbin/opensips[27327]: >>> ERROR:pua_usrloc:ul_publish: failed to send publish >>> >>> Any hint? >>> >>> Regards >>> >>> _______________________________________________ >>> 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 campusvtv at gmail.com Sun Mar 1 20:18:47 2015 From: campusvtv at gmail.com (campusvtv) Date: Sun, 01 Mar 2015 14:18:47 -0500 Subject: [OpenSIPS-Users] X-Lite presence In-Reply-To: <54F34C67.1000201@opensips.org> References: <54EFC728.7080505@gmail.com> <54F0C151.9010204@opensips.org> <54F0CB83.7080002@gmail.com> <54F34C67.1000201@opensips.org> Message-ID: <54F36617.7080901@gmail.com> Hello, how or where can i check this? Thank you Regards El 01/03/2015 a las 12:29, Bogdan-Andrei Iancu escribi?: > is the presence status of that device correctly visible From shahzad at voip-demos.com Mon Mar 2 04:42:51 2015 From: shahzad at voip-demos.com (shahzad at voip-demos.com) Date: Mon, 02 Mar 2015 04:42:51 +0100 Subject: [OpenSIPS-Users] =?utf-8?q?No_support_for_TCP_in_OpenSIPS_v2=2E1?= =?utf-8?q?=3F?= In-Reply-To: References: Message-ID: <3356d0257103a389f8ba5324dace186f@voip-demos.com> OK, in the source tree, i only see proto_tls and proto_sctp directors under modules. Searching proto_tcp lead me to net directory which indeed has proto_tcp and proto_udp directories however, there is no "so" file, so i guess these protos not compiled by default, however interestingly they also do not have any Makefile, so i can't even try to manually compile them (i.e. without relying on "make menuconfig"). Should i continue my attempt to compile and run v2.1 tunk or is it too early to test it? Please advise. Thank you. On 2015-03-01 13:03, Bogdan-Andrei Iancu wrote: > Hi, > > In 2.1 the protocols are loaded as modules and there is no disable param at all. > So just set the tcp listener and do loadmodule "proto_tcp.so" . > Note many parameters related to protocols were changed or moved and the docs were not yet updated. > > Regards, > Bogdan > > Sent from Samsung Mobile > > -------- Original message -------- > From: shahzad at voip-demos.com > Date:01/03/2015 03:25 (GMT+01:00) > To: users at lists.opensips.org > Subject: [OpenSIPS-Users] No support for TCP in OpenSIPS v2.1? > > OK, so i have successfully compiled opensip v2.1 trunk and tried to > start it with minimal configuration, it fails and gives error on global > TCP parameters. It does not even accepts "disable_tcp=no". > > I do not understand what is wrong here, i rechecked every option in > "make menuconfig" and didn't find anything related to TCP anywhere. > Please help, i need TCP support to test opensips capability to > interconnect with webrtc endpoints and rtpengine service. > > Here is the output of opensips -V command, > > -- > version: opensips 2.1.1dev (x86_64/linux) > flags: STATS: On, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, > FAST_LOCK-FUTEX-ADAPTIVE_WAIT, USE_PTHREAD_MUTEX > 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: 2dd472a > main.c compiled on 03:10:21 Mar 1 2015 with gcc 4.7 > -- > > Thank you. > > _______________________________________________ > 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 merlin.li at tsingch.com Mon Mar 2 06:13:23 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Mon, 2 Mar 2015 13:13:23 +0800 Subject: [OpenSIPS-Users] how to relay failure signling to FreeSwitch? Message-ID: <2015030213132206208217@tsingch.com> Hi all, My opensips working with FS. What i want is when the callee decline a call, FS will play a recording to the caller. Since t_relay() can not be used in onreply route, i add the following in the failure_route. failure_route[failure] { if( t_check_status("603")){ prefix("Busy_"); t_relay("192.168.1.2:5080"); exit; } } And i got the following error: Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled/6xx transaction Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:w_t_relay: t_forward_nonack failed Any help will be appreciated. merlin.li at tsingch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlin.li at tsingch.com Mon Mar 2 06:30:31 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Mon, 2 Mar 2015 13:30:31 +0800 Subject: [OpenSIPS-Users] how to relay failure signling to FreeSwitch? References: <2015030213132206208217@tsingch.com> Message-ID: <2015030213303096370521@tsingch.com> Hi all, I noticed that someone alreay asked same question, what he got is : because it is against RFC3261 - 6xx reply means global failure and no further forking is allowed. http://lists.sip-router.org/pipermail/sr-users/2008-May/017415.html But i still want to know how others handle this situation? i mean how to play a recording to the caller when opensips received a "603" Thanks in advanced. merlin.li at tsingch.com From: merlin.li at tsingch.com Date: 2015-03-02 13:13 To: users CC: clare.bao Subject: how to relay failure signling to FreeSwitch? Hi all, My opensips working with FS. What i want is when the callee decline a call, FS will play a recording to the caller. Since t_relay() can not be used in onreply route, i add the following in the failure_route. failure_route[failure] { if( t_check_status("603")){ prefix("Busy_"); t_relay("192.168.1.2:5080"); exit; } } And i got the following error: Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled/6xx transaction Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:w_t_relay: t_forward_nonack failed Any help will be appreciated. merlin.li at tsingch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dani.popa at gmail.com Mon Mar 2 07:28:57 2015 From: dani.popa at gmail.com (Dani Popa) Date: Mon, 2 Mar 2015 00:28:57 -0600 Subject: [OpenSIPS-Users] t_uac_dlg and tcp socket In-Reply-To: <54F17B89.8050302@opensips.org> References: <54F17B89.8050302@opensips.org> Message-ID: Hi, It works like a charm! Thanks, Dani On Sat, Feb 28, 2015 at 2:25 AM, Bogdan-Andrei Iancu wrote: > Hi Dani, > > The socket you set may be ignore if not compatible from proto perspective > with the protocol required by the SIP destination (RURI or DU). If the RURI > requires UDP (has no ";transport=tcp" in it) and the socket is TCP, the > socket info will be discarded and a new sock will be searched. > > So, try to put the "transport=tcp" in your next hop URI. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 27.02.2015 23:18, Dani Popa wrote: > > Hi, > > t_uac_dlg with socket 'tcp:x.x.x.x' should work ? > > When i try to use t_uac_dlg with socket 'tcp:x.x.x.x' i see that the > SIP message is sent over udp. > > Thanks > -- > Dani Popa > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- Dani Popa -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 2 11:40:05 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 02 Mar 2015 12:40:05 +0200 Subject: [OpenSIPS-Users] No support for TCP in OpenSIPS v2.1? In-Reply-To: <3356d0257103a389f8ba5324dace186f@voip-demos.com> References: <3356d0257103a389f8ba5324dace186f@voip-demos.com> Message-ID: <54F43E05.4020600@opensips.org> The TCP-plain and UDP-plain protocols are modules directly in code (see net/ directory ). These module are automatically compiled, you do not have to do anything more than placing that loadmodule in the script. It should automagically do the work for you ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 02.03.2015 05:42, shahzad at voip-demos.com wrote: > > OK, in the source tree, i only see proto_tls and proto_sctp directors > under modules. Searching proto_tcp lead me to net directory which > indeed has proto_tcp and proto_udp directories however, there is no > "so" file, so i guess these protos not compiled by default, however > interestingly they also do not have any Makefile, so i can't even try > to manually compile them (i.e. without relying on "make menuconfig"). > > Should i continue my attempt to compile and run v2.1 tunk or is it too > early to test it? Please advise. > > Thank you. > > On 2015-03-01 13:03, Bogdan-Andrei Iancu wrote: > >> Hi, >> In 2.1 the protocols are loaded as modules and there is no disable >> param at all. >> So just set the tcp listener and do loadmodule "proto_tcp.so" . >> Note many parameters related to protocols were changed or moved and >> the docs were not yet updated. >> Regards, >> Bogdan >> Sent from Samsung Mobile >> >> >> -------- Original message -------- >> From: shahzad at voip-demos.com >> Date:01/03/2015 03:25 (GMT+01:00) >> To: users at lists.opensips.org >> Subject: [OpenSIPS-Users] No support for TCP in OpenSIPS v2.1? >> >> OK, so i have successfully compiled opensip v2.1 trunk and tried to >> start it with minimal configuration, it fails and gives error on global >> TCP parameters. It does not even accepts "disable_tcp=no". >> >> I do not understand what is wrong here, i rechecked every option in >> "make menuconfig" and didn't find anything related to TCP anywhere. >> Please help, i need TCP support to test opensips capability to >> interconnect with webrtc endpoints and rtpengine service. >> >> Here is the output of opensips -V command, >> >> -- >> version: opensips 2.1.1dev (x86_64/linux) >> flags: STATS: On, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, >> FAST_LOCK-FUTEX-ADAPTIVE_WAIT, USE_PTHREAD_MUTEX >> 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: 2dd472a >> main.c compiled on 03:10:21 Mar 1 2015 with gcc 4.7 >> -- >> >> >> Thank you. >> >> _______________________________________________ >> 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 Mar 2 11:44:28 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 02 Mar 2015 12:44:28 +0200 Subject: [OpenSIPS-Users] how to relay failure signling to FreeSwitch? In-Reply-To: <2015030213303096370521@tsingch.com> References: <2015030213132206208217@tsingch.com> <2015030213303096370521@tsingch.com> Message-ID: <54F43F0C.6050609@opensips.org> Hi, See the disable_6xx_block : http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id294347 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 02.03.2015 07:30, merlin.li at tsingch.com wrote: > Hi all, > I noticed that someone alreay asked same question, what he got is : > because it is against RFC3261 - 6xx reply means global failure and no > further forking is allowed. > http://lists.sip-router.org/pipermail/sr-users/2008-May/017415.html > > > But i still want to know how others handle this situation? i mean how > to play a recording to the caller when opensips received a "603" > > Thanks in advanced. > > ------------------------------------------------------------------------ > merlin.li at tsingch.com > > *From:* merlin.li at tsingch.com > *Date:* 2015-03-02 13:13 > *To:* users > *CC:* clare.bao > *Subject:* how to relay failure signling to FreeSwitch? > Hi all, > > My opensips working with FS. > What i want is when the callee decline a call, FS will play a > recording to the caller. > Since t_relay() can not be used in onreply route, i add the > following in the failure_route. > > failure_route[failure] { > if( t_check_status("603")){ > prefix("Busy_"); > t_relay("192.168.1.2:5080"); > exit; > } > } > > And i got the following error: > Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled/6xx transaction > Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:w_t_relay: t_forward_nonack failed > > Any help will be appreciated. > ------------------------------------------------------------------------ > merlin.li at tsingch.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 merlin.li at tsingch.com Mon Mar 2 11:52:09 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Mon, 2 Mar 2015 18:52:09 +0800 Subject: [OpenSIPS-Users] how to relay failure signling to FreeSwitch? References: <2015030213132206208217@tsingch.com>, <2015030213303096370521@tsingch.com>, <54F43F0C.6050609@opensips.org> Message-ID: <2015030218520876873123@tsingch.com> Hi Iancu, Thanks! Tt works like a charm! merlin.li at tsingch.com From: Bogdan-Andrei Iancu Date: 2015-03-02 18:44 To: OpenSIPS users mailling list CC: ???; merlin.li Subject: Re: [OpenSIPS-Users] how to relay failure signling to FreeSwitch? Hi, See the disable_6xx_block : http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id294347 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.comOn 02.03.2015 07:30, merlin.li at tsingch.com wrote: Hi all, I noticed that someone alreay asked same question, what he got is : because it is against RFC3261 - 6xx reply means global failure and no further forking is allowed. http://lists.sip-router.org/pipermail/sr-users/2008-May/017415.html But i still want to know how others handle this situation? i mean how to play a recording to the caller when opensips received a "603" Thanks in advanced. merlin.li at tsingch.com From: merlin.li at tsingch.com Date: 2015-03-02 13:13 To: users CC: clare.bao Subject: how to relay failure signling to FreeSwitch? Hi all, My opensips working with FS. What i want is when the callee decline a call, FS will play a recording to the caller. Since t_relay() can not be used in onreply route, i add the following in the failure_route. failure_route[failure] { if( t_check_status("603")){ prefix("Busy_"); t_relay("192.168.1.2:5080"); exit; } } And i got the following error: Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled/6xx transaction Mar 2 11:48:03 VS /usr/bin/opensips[38986]: ERROR:tm:w_t_relay: t_forward_nonack failed Any help will be appreciated. merlin.li at tsingch.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 efes9999 at hotmail.com Mon Mar 2 16:59:02 2015 From: efes9999 at hotmail.com (Mert Yazgart) Date: Mon, 2 Mar 2015 10:59:02 -0500 Subject: [OpenSIPS-Users] chaining multiple Opensips instances Message-ID: We would like to have some of the sip clients connect to a "middleman" opensips instance which will relay the SIP requests to our "main" opensips server (after some security related filtering) and relay the responses from the "main" server back to the clients. There will be no NAT involved. RTP doesn't need to be relayed, just the SIP. What is the simplest way of achieving this on the opensips instance in the middle? t_relay with an IP specified? Other options? Does this need to be stateful? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlin.li at tsingch.com Tue Mar 3 09:14:19 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Tue, 3 Mar 2015 16:14:19 +0800 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? Message-ID: <2015030316141824085315@tsingch.com> Hi all, Let me describe my scenario first. if the callee is not online, opensips will wait for 30s. During the 30s, if the callee be online, opensips will send the invite to it. $avp(timeout) = 30 ; while( !lookup("location","m") ){ if( $avp(timeout)==0 ){ send_reply("420","Can not find the callee!"); exit; } sleep("1"); $avp(timeout) = $avp(timeout)-1; } This works well, the only problem is the caller can not cancel it during that 30s t_cancel_branch() only can be used in onreply_route, but at that time, callee is offline. My question is : Is it possible that terminate a request in route block? merlin.li at tsingch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlin.li at tsingch.com Tue Mar 3 09:45:15 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Tue, 3 Mar 2015 16:45:15 +0800 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? References: <2015030316141824085315@tsingch.com> Message-ID: <2015030316451426487717@tsingch.com> Hi, Or is there a way i can break the while loop in the route block when i receive the CANCEL request? merlin.li at tsingch.com From: merlin.li at tsingch.com Date: 2015-03-03 16:14 To: users Subject: how to cancel an INVITE before the callee receive it? Hi all, Let me describe my scenario first. if the callee is not online, opensips will wait for 30s. During the 30s, if the callee be online, opensips will send the invite to it. $avp(timeout) = 30 ; while( !lookup("location","m") ){ if( $avp(timeout)==0 ){ send_reply("420","Can not find the callee!"); exit; } sleep("1"); $avp(timeout) = $avp(timeout)-1; } This works well, the only problem is the caller can not cancel it during that 30s t_cancel_branch() only can be used in onreply_route, but at that time, callee is offline. My question is : Is it possible that terminate a request in route block? merlin.li at tsingch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adriavidal at gmail.com Tue Mar 3 10:44:23 2015 From: adriavidal at gmail.com (=?UTF-8?B?QWRyacOgIFZpZGFs?=) Date: Tue, 3 Mar 2015 10:44:23 +0100 Subject: [OpenSIPS-Users] CDRtool 9.3 web interface Message-ID: I'm facing a problem with CDRTool 9.3, on the web interface i can't select the date or time, i try to click the icons but nothing happen. I've located the problem at cdr_generic.php $f->show_element("begin_date",""); print " "; p.d. I've tried with different browsers/systems too -- -- Adri? Vidal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tijmen at ag-projects.com Tue Mar 3 11:30:40 2015 From: tijmen at ag-projects.com (Tijmen de Mes) Date: Tue, 3 Mar 2015 11:30:40 +0100 Subject: [OpenSIPS-Users] CDRtool 9.3 web interface In-Reply-To: References: Message-ID: <63C8E021-55E5-44E0-8BD8-FDD986579B05@ag-projects.com> Hi, Clicking on the icons does not work. If you click on the input field you should get a date picker. If you don?t get it please take a look at the webbrowsers console if get any error or exception. Best regards, Tijmen de Mes ? AG-Projects > On 3 mrt. 2015, at 10:44, Adri? Vidal wrote: > > I'm facing a problem with CDRTool 9.3, > on the web interface i can't select the date or time, i try to click the icons but nothing happen. > > I've located the problem at > > cdr_generic.php > > $f->show_element("begin_date",""); > > print " > > "; > > p.d. I've tried with different browsers/systems too > -- > -- > Adri? Vidal > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From liviu at opensips.org Tue Mar 3 13:57:32 2015 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 03 Mar 2015 14:57:32 +0200 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? In-Reply-To: <2015030316451426487717@tsingch.com> References: <2015030316141824085315@tsingch.com> <2015030316451426487717@tsingch.com> Message-ID: <54F5AFBC.1000200@opensips.org> Hello merlin, First of all, from a user's perspective, a Post-Dial Delay of up to 30 seconds should be quite annoying. Your SIP logic will also increase the amount of traffic received by your platform, due to lots of retransmissions for all failed calls. That being said, here is what you should add in order to make it work: t_newtran(); ... while (...) { if (t_was_cancelled()) { t_reply("487", "Request Cancelled"); exit; } ... } Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 03.03.2015 10:45, merlin.li at tsingch.com wrote: > Hi, > > Or is there a way i can break the while loop in the route block when i > receive the CANCEL request? > > ------------------------------------------------------------------------ > merlin.li at tsingch.com > > *From:* merlin.li at tsingch.com > *Date:* 2015-03-03 16:14 > *To:* users > *Subject:* how to cancel an INVITE before the callee receive it? > Hi all, > > Let me describe my scenario first. > > if the callee is not online, opensips will wait for 30s. > During the 30s, if the callee be online, opensips will send the > invite to it. > > $avp(timeout) = 30 ; > while( !lookup("location","m") ){ > if( $avp(timeout)==0 ){ > send_reply("420","Can not find the callee!"); > exit; > } > sleep("1"); > $avp(timeout) = $avp(timeout)-1; > } > > This works well, the only problem is the caller can not cancel it > during that 30s > t_cancel_branch() only can be used in onreply_route, but at that > time, callee is offline. > > My question is : > Is it possible that terminate a request in route block? > > > ------------------------------------------------------------------------ > merlin.li at tsingch.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 liviu at opensips.org Tue Mar 3 14:15:23 2015 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 03 Mar 2015 15:15:23 +0200 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? In-Reply-To: <54F5AFBC.1000200@opensips.org> References: <2015030316141824085315@tsingch.com> <2015030316451426487717@tsingch.com> <54F5AFBC.1000200@opensips.org> Message-ID: <54F5B3EB.9050808@opensips.org> The previous solution won't work because you can't call t_was_cancelled() in the main route... You should: 1) set $T_fr_timeout and $T_fr_inv_timeout to 1 2) t_on_failure(...) [1] 3) t_relay() to a bogus gateway [2] 4) catch the 408 timeout in the failure route. Using an $avp counter, go back to step 1) until 30 tries have been done. In this failure route, you may now also use t_was_cancelled(). [1] : http://www.opensips.org/Documentation/Script-Routes-2-1#toc3 [2] : http://www.opensips.org/html/docs/modules/2.1.x/tm.html#trelay-1 On 03.03.2015 14:57, Liviu Chircu wrote: > Hello merlin, > > First of all, from a user's perspective, a Post-Dial Delay of up to 30 > seconds should be quite annoying. Your SIP logic will also increase > the amount of traffic received by your platform, due to lots of > retransmissions for all failed calls. > > That being said, here is what you should add in order to make it work: > > t_newtran(); > ... > while (...) { > if (t_was_cancelled()) { > t_reply("487", "Request Cancelled"); > exit; > } > ... > } > > Best regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 03.03.2015 10:45, merlin.li at tsingch.com wrote: >> Hi, >> >> Or is there a way i can break the while loop in the route block when >> i receive the CANCEL request? >> >> ------------------------------------------------------------------------ >> merlin.li at tsingch.com >> >> *From:* merlin.li at tsingch.com >> *Date:* 2015-03-03 16:14 >> *To:* users >> *Subject:* how to cancel an INVITE before the callee receive it? >> Hi all, >> >> Let me describe my scenario first. >> >> if the callee is not online, opensips will wait for 30s. >> During the 30s, if the callee be online, opensips will send the >> invite to it. >> >> $avp(timeout) = 30 ; >> while( !lookup("location","m") ){ >> if( $avp(timeout)==0 ){ >> send_reply("420","Can not find the callee!"); >> exit; >> } >> sleep("1"); >> $avp(timeout) = $avp(timeout)-1; >> } >> >> This works well, the only problem is the caller can not cancel it >> during that 30s >> t_cancel_branch() only can be used in onreply_route, but at that >> time, callee is offline. >> >> My question is : >> Is it possible that terminate a request in route block? >> >> >> ------------------------------------------------------------------------ >> merlin.li at tsingch.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 adriavidal at gmail.com Tue Mar 3 17:02:44 2015 From: adriavidal at gmail.com (=?UTF-8?B?QWRyacOgIFZpZGFs?=) Date: Tue, 3 Mar 2015 17:02:44 +0100 Subject: [OpenSIPS-Users] CDRtool 9.3 web interface In-Reply-To: <63C8E021-55E5-44E0-8BD8-FDD986579B05@ag-projects.com> References: <63C8E021-55E5-44E0-8BD8-FDD986579B05@ag-projects.com> Message-ID: 2015-03-03 11:30 GMT+01:00 Tijmen de Mes : > Hi, > > Clicking on the icons does not work. If you click on the input field you > should get a date picker. > > If you don?t get it please take a look at the webbrowsers console if get > any error or exception. > > Best regards, > > Tijmen de Mes > I see no input field to click on https://www.dropbox.com/s/w55ynwrc1kbps6d/Captura%20de%20pantalla%202015-03-03%2017.02.14.png?dl=0 -- -- Adri? Vidal T. 93 150 31 80 | M 607 28 89 56 @ adria at gmail.com www www.xpreme.net | centralitaip.xpreme.net twitter xpreme_it -------------- next part -------------- An HTML attachment was scrubbed... URL: From tijmen at ag-projects.com Tue Mar 3 17:49:12 2015 From: tijmen at ag-projects.com (Tijmen de Mes) Date: Tue, 3 Mar 2015 17:49:12 +0100 Subject: [OpenSIPS-Users] CDRtool 9.3 web interface In-Reply-To: References: <63C8E021-55E5-44E0-8BD8-FDD986579B05@ag-projects.com> Message-ID: Hi, I see the problem now. I will send a patch to you private email which you can apply to CDRTool. Hopefully it will fix this problem. Best regards, Tijmen de Mes ? AG Projects > On 3 mrt. 2015, at 17:02, Adri? Vidal wrote: > > > 2015-03-03 11:30 GMT+01:00 Tijmen de Mes >: > Hi, > > Clicking on the icons does not work. If you click on the input field you should get a date picker. > > If you don?t get it please take a look at the webbrowsers console if get any error or exception. > > Best regards, > > Tijmen de Mes > > I see no input field to click on > > https://www.dropbox.com/s/w55ynwrc1kbps6d/Captura%20de%20pantalla%202015-03-03%2017.02.14.png?dl=0 > > > > > -- > -- > Adri? Vidal > > T. 93 150 31 80 | M 607 28 89 56 > @ adria at gmail.com > www www.xpreme.net | centralitaip.xpreme.net > twitter xpreme_it _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pkelly at gmail.com Wed Mar 4 10:19:37 2015 From: pkelly at gmail.com (Pete Kelly) Date: Wed, 4 Mar 2015 09:19:37 +0000 Subject: [OpenSIPS-Users] Presence over TCP with NAT, possible bug In-Reply-To: <54F0C250.5060203@opensips.org> References: <54DBB756.6020203@opensips.org> <54DCFAF7.5000702@opensips.org> <54EAF6A0.7060500@opensips.org> <54F0C250.5060203@opensips.org> Message-ID: Hi Bogdan... even in debug 6 with EXTRA_DEBUG there is nothing like that, I have put the logs in pastebin here: http://pastebin.com/PaM2Rxy5 On 27 February 2015 at 19:15, Bogdan-Andrei Iancu wrote: > Pete, > > You should look for logs from "_tcpconn_find" when the NOTIFY is about to > be sent out. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 26.02.2015 17:37, Pete Kelly wrote: > > Hi > > Yes I did that, and also with EXTRA_DEBUG too - I should be able to grab > the logs from the time it happened. > > Is there any particular item you want me to look for? > > On 23 February 2015 at 09:45, Bogdan-Andrei Iancu > wrote: > >> Hi Pete, >> >> Do you have any chance to run in debug mode to get some extra info ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 23.02.2015 10:49, Pete Kelly wrote: >> >> Hi Bogdan >> >> As I said in my original post, I tried that already with no success. >> >> On 12 February 2015 at 19:11, Bogdan-Andrei Iancu >> wrote: >> >>> Hi Pete, >>> >>> Try setting the tcp_accept_aliases global param to 1: >>> tcp_accept_aliases = 1 >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>> >>> On 12.02.2015 11:24, Pete Kelly wrote: >>> >>> Bogdan >>> >>> In fact the TCP connection stays open (I checked with netstat on port >>> 28733 being open on the remote host). >>> >>> I think the problem is opensips is opening (or is supposed to open) >>> 5060 on the remote and this is failing? I think it may be looking for an >>> already existing connection to 5060? >>> >>> Pete >>> >>> On 11 February 2015 at 20:11, Bogdan-Andrei Iancu >>> wrote: >>> >>>> Hi Pete, >>>> >>>> If the TCP connection (the one used to received the SUBSCRIBE from end >>>> user) went down, when sending an in-dialog NOTIFY, OpenSIPS will refuse to >>>> open a new TCP connection (the policy is to accept connection, not to open >>>> connections towards end-users). >>>> >>>> Can you check if this is your case ? >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>>> >>>> On 11.02.2015 12:50, Pete Kelly wrote: >>>> >>>> I have been experimenting recently with Presence over TCP and >>>> noticed sometimes OpenSIPS fails to send a NOTIFY for a recent SUBSCRIBE, >>>> with a tcp_send error in the logs. >>>> >>>> I did some research and found an old issue which seems to be similar >>>> to this as the inbound SUBSCRIBE TCP connection is on a high port, yet the >>>> NOTIFY is to go to port 5060. >>>> >>>> http://lists.opensips.org/pipermail/users/2013-May/025922.html >>>> >>>> The fix here is to set tcp_accept_aliases =1 >>>> >>>> I tried this fix and it did not resolve the issue. Looking in the >>>> source code it seems OpenSIPS may be trying to reuse an old/existing TCP >>>> connection and is failing to find one - it does seem to be slightly >>>> intermittent too. Sometimes (very rarely) it will work, and it seems to be >>>> related to how many other TCP connections are open at the moment but I have >>>> found it very very difficult to pin down. In the end I got round it by >>>> looping the TCP SUBSCRIBE back to UDP and the OpenSIPS then produces a >>>> NOTIFY/UDP no problem. This solution is a bodge and I would be interested >>>> to know if the failure to tcp_send is a bug or something I can detect and >>>> handle in the config somehow? >>>> >>>> Using OpenSIPS 1.11 latest, in EXTRA_DEBUG mode this is the error >>>> that is produced: >>>> >>>> [19361]: ERROR:tm:msg_send: tcp_send failed >>>> [19361]: ERROR:tm:t_uac: attempt to send to 'sip:111.111.8.146:5060;transport=tcp;lr' >>>> failed >>>> >>>> This is the inbound SUBSCRIBE and 200OK... I am simply dealing with >>>> this by calling handle_subscribe('1'); >>>> >>>> T 2015/02/10 12:52:09.324134 111.111.8.146:28733 -> 192.168.0.113:5060 >>>> [AP] >>>> SUBSCRIBE sip:user203 at test-domain.com SIP/2.0. >>>> Via: SIP/2.0/TCP 111.111.8.146:5060 >>>> ;egress-zone=DNS;branch=z9hG4bK5c628151ab895c5f2f45ed8bdafeda0d24504147.1569b0b8efc74f7daf3767cc97d0b38e;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a;rport. >>>> Via: SIP/2.0/TLS 10.15.20.113:54999 >>>> ;branch=z9hG4bKfd5e7b1424014fc8de23205f0de3873e.1;received=188.39.51.2;rport=54999;ingress-zone=DefaultSubZone. >>>> Call-ID: a1922a193e1b6057 at 10.15.20.113. >>>> CSeq: 303 SUBSCRIBE. >>>> Contact: >>> ;gr=urn:uuid:683f87a0-e026-5f0a-b86b-58139361c7a4>. >>>> From: ;tag=359dbb1cb104d434. >>>> To: . >>>> Max-Forwards: 15. >>>> Record-Route: . >>>> Record-Route: . >>>> Record-Route: >>> ;transport=tls;apparent=remove;ds;lr;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a>. >>>> User-Agent: Test. >>>> Expires: 3600. >>>> Event: presence. >>>> Accept: application/pidf+xml. >>>> P-Asserted-Identity: . >>>> X-TAATag: 6ed63f01-3191-4a1f-b2a2-4121fb834f07. >>>> Content-Length: 0. >>>> . >>>> >>>> >>>> T 2015/02/10 12:52:09.326218 192.168.0.113:5060 -> 111.111.8.146:28733 >>>> [AP] >>>> SIP/2.0 200 OK. >>>> Via: SIP/2.0/TCP 111.111.8.146:5060 >>>> ;received=111.111.8.146;egress-zone=DNS;branch=z9hG4bK5c628151ab895c5f2f45ed8bdafeda0d24504147.1569b0b8efc74f7daf3767cc97d0b38e;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a;rport=28733. >>>> Via: SIP/2.0/TLS 10.15.20.113:54999 >>>> ;branch=z9hG4bKfd5e7b1424014fc8de23205f0de3873e.1;received=188.39.51.2;rport=54999;ingress-zone=DefaultSubZone. >>>> Call-ID: a1922a193e1b6057 at 10.15.20.113. >>>> CSeq: 303 SUBSCRIBE. >>>> From: ;tag=359dbb1cb104d434. >>>> To: >>> >;tag=e3eb1f19b04f8e78afd28f643f416b5f-9be8. >>>> Record-Route: . >>>> Record-Route: . >>>> Record-Route: >>> ;transport=tls;apparent=remove;ds;lr;proxy-call-id=345dee99-7aca-44b4-bf5f-fb1f2e57774a>. >>>> Expires: 3600. >>>> Contact: >>>> . >>>> Server: Test. >>>> Content-Length: 0. >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at ag-projects.com Wed Mar 4 10:35:06 2015 From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=) Date: Wed, 4 Mar 2015 10:35:06 +0100 Subject: [OpenSIPS-Users] SIP to WebRTC Proxy / Gateway In-Reply-To: References: Message-ID: <402A87DA-2C2C-4B68-AAC6-DB64327985A2@ag-projects.com> IIRC OpenSIPS hasn?t landed WebSocket support yet, but you could use OverSIP for translating SIP over UDP/TCP/TLS to WebSocket, acting as an outbound proxy, for example. Nevertheless, if you are connecting to a WebRTC gateway thing, signalling is likely the least of your worries, because your soft phone probably doesn?t support the media capabilities mandated by WebRTC. Cheers, On 28 Feb 2015, at 22:00, Rion Carter wrote: > I'm pretty new to SIP, RTP and WebRTC. I am in need of a gateway or proxy that can let me use an existing SIP Soft-phone to connect to a WebRTC/SIP-over-websockets server (the WebRTC/SIP-over-websockets server does not provide a way for regular SIP softphones to connect). > > Would OpenSIPS be able to proxy my requests from my softphone to the WebRTC endpoint? I have examined the documentation and if I've missed something I apologize. Most everything I read emphasizes connecting webrtc clients to a server, and my need is different than that. > > Any examples, tutorials or documentation would be appreciated. > > Thanks! > _______________________________________________ > 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 pkelly at gmail.com Wed Mar 4 11:21:59 2015 From: pkelly at gmail.com (Pete Kelly) Date: Wed, 4 Mar 2015 10:21:59 +0000 Subject: [OpenSIPS-Users] chaining multiple Opensips instances In-Reply-To: References: Message-ID: Easiest way to achieve this is simply to change the request URI as the SIP travels through the "middleman" instance: e.g. $ru = "sip:"+$rU+"@main-opensips.server:5060"; t_relay(); If you want to keep the request uri unchanged, you can change the destination instead: $du = "sip:main-opensips-server:5060"; t_relay(); And to do it in a more managed fashion, you could use the dispatcher module which lets you change the IP of the "main" server on the fly should you wish to. On 2 March 2015 at 15:59, Mert Yazgart wrote: > We would like to have some of the sip clients connect to a "middleman" > opensips instance which will relay the SIP requests to our "main" opensips > server (after some security related filtering) and relay the responses from > the "main" server back to the clients. > > There will be no NAT involved. RTP doesn't need to be relayed, just the > SIP. > > What is the simplest way of achieving this on the opensips instance in the > middle? t_relay with an IP specified? Other options? Does this need to be > stateful? > > 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 adriavidal at gmail.com Wed Mar 4 12:14:39 2015 From: adriavidal at gmail.com (=?UTF-8?B?QWRyacOgIFZpZGFs?=) Date: Wed, 4 Mar 2015 12:14:39 +0100 Subject: [OpenSIPS-Users] CDRtool 9.3 web interface In-Reply-To: References: <63C8E021-55E5-44E0-8BD8-FDD986579B05@ag-projects.com> Message-ID: Yes it solves the problem, thanks! 2015-03-03 17:49 GMT+01:00 Tijmen de Mes : > Hi, > > I see the problem now. I will send a patch to you private email which you > can apply to CDRTool. Hopefully it will fix this problem. > > Best regards, > > Tijmen de Mes > ? > AG Projects > > > On 3 mrt. 2015, at 17:02, Adri? Vidal wrote: > > > 2015-03-03 11:30 GMT+01:00 Tijmen de Mes : > >> Hi, >> >> Clicking on the icons does not work. If you click on the input field you >> should get a date picker. >> >> If you don?t get it please take a look at the webbrowsers console if get >> any error or exception. >> >> Best regards, >> >> Tijmen de Mes >> > > I see no input field to click on > > > https://www.dropbox.com/s/w55ynwrc1kbps6d/Captura%20de%20pantalla%202015-03-03%2017.02.14.png?dl=0 > > > > > -- > -- > Adri? Vidal > > T. 93 150 31 80 | M 607 28 89 56 > > @ adria at gmail.com > > www www.xpreme.net | centralitaip.xpreme.net > > twitter xpreme_it > _______________________________________________ > 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 > > -- -- Adri? Vidal T. 93 150 31 80 | M 607 28 89 56 @ adria at gmail.com www www.xpreme.net | centralitaip.xpreme.net twitter xpreme_it -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlin.li at tsingch.com Wed Mar 4 12:30:19 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Wed, 4 Mar 2015 19:30:19 +0800 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? References: Message-ID: <201503041930185190809@tsingch.com> Hi Chircu, Thanks for your reply. The 30s just my test value. And maybe i didn't discribe my problem clearly. I can understand that t_newtran() can create the transaction first , and i already did it before i send the first email. But as i said, the caller still can not cancel it, because i don't know how to do it. t_cancel_branch() only can be used in onreply_route but at that time, callee is offline. Here is my cancel processing in the route , would you please tell me how can i cancel the invite which still in the while loop? # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()){ t_relay(); exit; } } merlin.li at tsingch.com Message: 1 Date: Tue, 03 Mar 2015 14:57:32 +0200 From: Liviu Chircu Subject: Re: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? To: users at lists.opensips.org Message-ID: <54F5AFBC.1000200 at opensips.org> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Hello merlin, First of all, from a user's perspective, a Post-Dial Delay of up to 30 seconds should be quite annoying. Your SIP logic will also increase the amount of traffic received by your platform, due to lots of retransmissions for all failed calls. That being said, here is what you should add in order to make it work: t_newtran(); ... while (...) { if (t_was_cancelled()) { t_reply("487", "Request Cancelled"); exit; } ... } Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 03.03.2015 10:45, merlin.li at tsingch.com wrote: > Hi, > > Or is there a way i can break the while loop in the route block when i > receive the CANCEL request? > > ------------------------------------------------------------------------ > merlin.li at tsingch.com > > *From:* merlin.li at tsingch.com > *Date:* 2015-03-03 16:14 > *To:* users > *Subject:* how to cancel an INVITE before the callee receive it? > Hi all, > > Let me describe my scenario first. > > if the callee is not online, opensips will wait for 30s. > During the 30s, if the callee be online, opensips will send the > invite to it. > > $avp(timeout) = 30 ; > while( !lookup("location","m") ){ > if( $avp(timeout)==0 ){ > send_reply("420","Can not find the callee!"); > exit; > } > sleep("1"); > $avp(timeout) = $avp(timeout)-1; > } > > This works well, the only problem is the caller can not cancel it > during that 30s > t_cancel_branch() only can be used in onreply_route, but at that > time, callee is offline. > > My question is : > Is it possible that terminate a request in route block? > > > ------------------------------------------------------------------------ > merlin.li at tsingch.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: ------------------------------ Message: 2 Date: Tue, 03 Mar 2015 15:15:23 +0200 From: Liviu Chircu Subject: Re: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? To: users at lists.opensips.org Message-ID: <54F5B3EB.9050808 at opensips.org> Content-Type: text/plain; charset="windows-1252"; Format="flowed" The previous solution won't work because you can't call t_was_cancelled() in the main route... You should: 1) set $T_fr_timeout and $T_fr_inv_timeout to 1 2) t_on_failure(...) [1] 3) t_relay() to a bogus gateway [2] 4) catch the 408 timeout in the failure route. Using an $avp counter, go back to step 1) until 30 tries have been done. In this failure route, you may now also use t_was_cancelled(). [1] : http://www.opensips.org/Documentation/Script-Routes-2-1#toc3 [2] : http://www.opensips.org/html/docs/modules/2.1.x/tm.html#trelay-1 On 03.03.2015 14:57, Liviu Chircu wrote: > Hello merlin, > > First of all, from a user's perspective, a Post-Dial Delay of up to 30 > seconds should be quite annoying. Your SIP logic will also increase > the amount of traffic received by your platform, due to lots of > retransmissions for all failed calls. > > That being said, here is what you should add in order to make it work: > > t_newtran(); > ... > while (...) { > if (t_was_cancelled()) { > t_reply("487", "Request Cancelled"); > exit; > } > ... > } > > Best regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 03.03.2015 10:45, merlin.li at tsingch.com wrote: >> Hi, >> >> Or is there a way i can break the while loop in the route block when >> i receive the CANCEL request? >> >> ------------------------------------------------------------------------ >> merlin.li at tsingch.com >> >> *From:* merlin.li at tsingch.com >> *Date:* 2015-03-03 16:14 >> *To:* users >> *Subject:* how to cancel an INVITE before the callee receive it? >> Hi all, >> >> Let me describe my scenario first. >> >> if the callee is not online, opensips will wait for 30s. >> During the 30s, if the callee be online, opensips will send the >> invite to it. >> >> $avp(timeout) = 30 ; >> while( !lookup("location","m") ){ >> if( $avp(timeout)==0 ){ >> send_reply("420","Can not find the callee!"); >> exit; >> } >> sleep("1"); >> $avp(timeout) = $avp(timeout)-1; >> } >> >> This works well, the only problem is the caller can not cancel it >> during that 30s >> t_cancel_branch() only can be used in onreply_route, but at that >> time, callee is offline. >> >> My question is : >> Is it possible that terminate a request in route block? >> >> >> ------------------------------------------------------------------------ >> merlin.li at tsingch.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: ------------------------------ Message: 3 Date: Tue, 3 Mar 2015 17:02:44 +0100 From: Adri? Vidal Subject: Re: [OpenSIPS-Users] CDRtool 9.3 web interface To: OpenSIPS users mailling list Message-ID: Content-Type: text/plain; charset="utf-8" 2015-03-03 11:30 GMT+01:00 Tijmen de Mes : > Hi, > > Clicking on the icons does not work. If you click on the input field you > should get a date picker. > > If you don?t get it please take a look at the webbrowsers console if get > any error or exception. > > Best regards, > > Tijmen de Mes > I see no input field to click on https://www.dropbox.com/s/w55ynwrc1kbps6d/Captura%20de%20pantalla%202015-03-03%2017.02.14.png?dl=0 -- -- Adri? Vidal T. 93 150 31 80 | M 607 28 89 56 @ adria at gmail.com www www.xpreme.net | centralitaip.xpreme.net twitter xpreme_it -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users End of Users Digest, Vol 80, Issue 6 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 4 12:57:45 2015 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 04 Mar 2015 13:57:45 +0200 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? In-Reply-To: <201503041930185190809@tsingch.com> References: <201503041930185190809@tsingch.com> Message-ID: <54F6F339.8080109@opensips.org> merlin, The SIP CANCEL must be sent by the caller, since "he wants to undo his INVITE request", not by the proxy. In order to break the call on the UAC side, have your proxy send him a generic "404 - Not Found" SIP reply, after your have done enough lookup() tries: ... t_reply("404", "Not Found"); exit; ... Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 04.03.2015 13:30, merlin.li at tsingch.com wrote: > Hi Chircu, > > Thanks for your reply. > The 30s just my test value. > And maybe i didn't discribe my problem clearly. > I can understand that t_newtran() can create the transaction first , > and i already did it before i send the first email. > But as i said, the caller still can not cancel it, because i don't > know how to do it. > t_cancel_branch() only can be used in onreply_route but at that time, > callee is offline. > > Here is my cancel processing in the route , would you please tell me > how can i cancel the invite which still in the while loop? > > # CANCEL processing > if (is_method("CANCEL")) > { > if (t_check_trans()){ > t_relay(); > exit; > } > > } > > ------------------------------------------------------------------------ > merlin.li at tsingch.com > > > Message: 1 > Date: Tue, 03 Mar 2015 14:57:32 +0200 > From: Liviu Chircu > Subject: Re: [OpenSIPS-Users] how to cancel an INVITE before the > callee receive it? > To: users at lists.opensips.org > Message-ID: <54F5AFBC.1000200 at opensips.org> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > Hello merlin, > First of all, from a user's perspective, a Post-Dial Delay of up > to 30 > seconds should be quite annoying. Your SIP logic will also > increase the > amount of traffic received by your platform, due to lots of > retransmissions for all failed calls. > That being said, here is what you should add in order to make it work: > t_newtran(); > ... > while (...) { > if (t_was_cancelled()) { > t_reply("487", "Request Cancelled"); > exit; > } > ... > } > Best regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 03.03.2015 10:45, merlin.li at tsingch.com wrote: > > Hi, > > > > Or is there a way i can break the while loop in the route block > when i > > receive the CANCEL request? > > > > > ------------------------------------------------------------------------ > > merlin.li at tsingch.com > > > > *From:* merlin.li at tsingch.com > > *Date:* 2015-03-03 16:14 > > *To:* users > > *Subject:* how to cancel an INVITE before the callee receive it? > > Hi all, > > > > Let me describe my scenario first. > > > > if the callee is not online, opensips will wait for 30s. > > During the 30s, if the callee be online, opensips will send the > > invite to it. > > > > $avp(timeout) = 30 ; > > while( !lookup("location","m") ){ > > if( $avp(timeout)==0 ){ > > send_reply("420","Can not find the callee!"); > > exit; > > } > > sleep("1"); > > $avp(timeout) = $avp(timeout)-1; > > } > > > > This works well, the only problem is the caller can not > cancel it > > during that 30s > > t_cancel_branch() only can be used in onreply_route, but at that > > time, callee is offline. > > > > My question is : > > Is it possible that terminate a request in route block? > > > > > > > ------------------------------------------------------------------------ > > merlin.li at tsingch.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: > > ------------------------------ > Message: 2 > Date: Tue, 03 Mar 2015 15:15:23 +0200 > From: Liviu Chircu > Subject: Re: [OpenSIPS-Users] how to cancel an INVITE before the > callee receive it? > To: users at lists.opensips.org > Message-ID: <54F5B3EB.9050808 at opensips.org> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > The previous solution won't work because you can't call > t_was_cancelled() in the main route... You should: > 1) set $T_fr_timeout and $T_fr_inv_timeout to 1 > 2) t_on_failure(...) [1] > 3) t_relay() to a bogus gateway [2] > 4) catch the 408 timeout in the failure route. Using an $avp > counter, go > back to step 1) until 30 tries have been done. In this failure route, > you may now also use t_was_cancelled(). > [1] : http://www.opensips.org/Documentation/Script-Routes-2-1#toc3 > [2] : http://www.opensips.org/html/docs/modules/2.1.x/tm.html#trelay-1 > On 03.03.2015 14:57, Liviu Chircu wrote: > > Hello merlin, > > > > First of all, from a user's perspective, a Post-Dial Delay of up > to 30 > > seconds should be quite annoying. Your SIP logic will also increase > > the amount of traffic received by your platform, due to lots of > > retransmissions for all failed calls. > > > > That being said, here is what you should add in order to make it > work: > > > > t_newtran(); > > ... > > while (...) { > > if (t_was_cancelled()) { > > t_reply("487", "Request Cancelled"); > > exit; > > } > > ... > > } > > > > Best regards, > > Liviu Chircu > > OpenSIPS Developer > > http://www.opensips-solutions.com > > On 03.03.2015 10:45, merlin.li at tsingch.com wrote: > >> Hi, > >> > >> Or is there a way i can break the while loop in the route block > when > >> i receive the CANCEL request? > >> > >> > ------------------------------------------------------------------------ > >> merlin.li at tsingch.com > >> > >> *From:* merlin.li at tsingch.com > >> *Date:* 2015-03-03 16:14 > >> *To:* users > >> *Subject:* how to cancel an INVITE before the callee > receive it? > >> Hi all, > >> > >> Let me describe my scenario first. > >> > >> if the callee is not online, opensips will wait for 30s. > >> During the 30s, if the callee be online, opensips will send the > >> invite to it. > >> > >> $avp(timeout) = 30 ; > >> while( !lookup("location","m") ){ > >> if( $avp(timeout)==0 ){ > >> send_reply("420","Can not find the callee!"); > >> exit; > >> } > >> sleep("1"); > >> $avp(timeout) = $avp(timeout)-1; > >> } > >> > >> This works well, the only problem is the caller can not > cancel it > >> during that 30s > >> t_cancel_branch() only can be used in onreply_route, but at > that > >> time, callee is offline. > >> > >> My question is : > >> Is it possible that terminate a request in route block? > >> > >> > >> > ------------------------------------------------------------------------ > >> merlin.li at tsingch.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: > > ------------------------------ > Message: 3 > Date: Tue, 3 Mar 2015 17:02:44 +0100 > From: Adri? Vidal > Subject: Re: [OpenSIPS-Users] CDRtool 9.3 web interface > To: OpenSIPS users mailling list > Message-ID: > > Content-Type: text/plain; charset="utf-8" > 2015-03-03 11:30 GMT+01:00 Tijmen de Mes : > > Hi, > > > > Clicking on the icons does not work. If you click on the input > field you > > should get a date picker. > > > > If you don?t get it please take a look at the webbrowsers > console if get > > any error or exception. > > > > Best regards, > > > > Tijmen de Mes > > > I see no input field to click on > https://www.dropbox.com/s/w55ynwrc1kbps6d/Captura%20de%20pantalla%202015-03-03%2017.02.14.png?dl=0 > -- > -- > Adri? Vidal > T. 93 150 31 80 | M 607 28 89 56 > @ adria at gmail.com > www www.xpreme.net | centralitaip.xpreme.net > twitter xpreme_it > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > End of Users Digest, Vol 80, Issue 6 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.pinassi at unisi.it Wed Mar 4 14:31:15 2015 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Wed, 04 Mar 2015 14:31:15 +0100 Subject: [OpenSIPS-Users] Again BLF and Presence with Snom 7xx phones and OpenSips In-Reply-To: <54EF180A.4030405@opensips.org> References: <54EC4C92.8040204@unisi.it> <54EF180A.4030405@opensips.org> Message-ID: <54F70923.1070708@unisi.it> Hi Bodgan, thanks for your kind reply. I follow your advices and i saw that NOTIFY message was sent but looks strange: NOTIFY sip:5007 at 172.20.1.25:32768 SIP/2.0. Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bK2aa9.80ebc992.0. To: ;tag=3gc7nus1ce. From: ;tag=f315b2d58ae8829149b784764c5a40e3-6e8f. CSeq: 7 NOTIFY. Call-ID: 54f6d4095b93-fjqtyt2odvk0. Max-Forwards: 70. Content-Length: 147. User-Agent: OpenSIPS (1.11.3-tls (i386/linux)). Event: dialog. Contact: . Subscription-State: active;expires=3600. Content-Type: application/dialog-info+xml. . Is that correct ? Thanks, Michele Il 26/02/2015 13:56, Bogdan-Andrei Iancu ha scritto: > Hi Michele, > > The problem in your script is that you do not handle the sequential > (in-dialog) SUBSCRIBE requests (as you have the second one in your > trace, ending with 404 and terminating the subscription). > > In the " if ( has_totag() ) " block, you have: > } else { > if (is_method("SUBSCRIBE") && $rd == "127.0.0.1:5060") { # > CUSTOMIZE ME > > The $rd detection does not cover all your cases, as you configure the > presence module to advertise as SIP contact > "sip:presence at voip.unisi.it:5060". So, the test fails. > > You can adapt the test like: > if (is_method("SUBSCRIBE") && $rd == "voip.unisi.it") { # > CUSTOMIZE ME > > Or set the contact in presence with the real IP: > modparam("presence", "server_address", > "sip:presence at 127.0.0.1:5060") > > Best regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 24.02.2015 12:04, Michele Pinassi wrote: >> Hi all, >> >> I'm still stuck on this issue: BLF not working. For example, on my >> SNOM 760 (ext 5002) i activated BLF for some ext, like 5020. Using >> SIPGREP i saw: >> * >> **SUBSCRIBE sip:5020 at voip.unisi.it;user=phone SIP/2.0.* >> Via: SIP/2.0/UDP 172.20.1.10:57286;branch=z9hG4bK-nprg3gvnk4q1;rport. >> From: ;tag=nyux2omhly. >> To: . >> Call-ID: 3944ec54dc20-pfzjpjhrpm6p. >> CSeq: 2 SUBSCRIBE. >> Max-Forwards: 70. >> Contact: ;reg-id=1. >> Event: dialog. >> Accept: application/dialog-info+xml. >> User-Agent: snom760/8.7.3.25.9. >> Proxy-Authorization: Digest >> Expires: 3600. >> Content-Length: 0. >> >> *SIP/2.0 200 OK.* >> Via: SIP/2.0/UDP >> 172.20.1.10:57286;received=172.20.1.10;branch=z9hG4bK-nprg3gvnk4q1;rport=57286. >> From: ;tag=nyux2omhly. >> To: >> ;tag=f315b2d58ae8829149b784764c5a40e3-163d. >> Call-ID: 3944ec54dc20-pfzjpjhrpm6p. >> CSeq: 2 SUBSCRIBE. >> Expires: 3600. >> Contact: . >> Server: OpenSIPS (1.11.3-tls (i386/linux)). >> Content-Length: 0. >> >> *NOTIFY sip:5002 at 172.20.1.10:57286 SIP/2.0.* >> Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdb02.83d58916.0. >> To: ;tag=nyux2omhly. >> From: ;tag=f315b2d58ae8829149b784764c5a40e3-163d. >> CSeq: 1 NOTIFY. >> Call-ID: 3944ec54dc20-pfzjpjhrpm6p. >> Max-Forwards: 70. >> Content-Length: 147. >> User-Agent: OpenSIPS (1.11.3-tls (i386/linux)). >> Event: dialog. >> Contact: . >> Subscription-State: active;expires=3600. >> Content-Type: application/dialog-info+xml. >> . >> >> > state="full" entity="sip:5020 at voip.unisi.it"/> >> * >> **SIP/2.0 200 Ok.* >> Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdb02.83d58916.0. >> From: ;tag=f315b2d58ae8829149b784764c5a40e3-163d. >> To: ;tag=nyux2omhly. >> Call-ID: 3944ec54dc20-pfzjpjhrpm6p. >> CSeq: 1 NOTIFY. >> Content-Length: 0. >> >> *SUBSCRIBE sip:presence at voip.unisi.it:5060 SIP/2.0.* >> Via: SIP/2.0/UDP 172.20.1.25:32768;branch=z9hG4bK-lbgnea3kuorq;rport. >> From: ;tag=w8vp9q5iyn. >> To: >> ;tag=f315b2d58ae8829149b784764c5a40e3-29cc. >> Call-ID: 54ec3a578c9e-klgn0s3i32zo. >> CSeq: 75 SUBSCRIBE. >> Max-Forwards: 70. >> Contact: ;reg-id=1. >> Event: dialog. >> Accept: application/dialog-info+xml. >> User-Agent: snom710/8.7.3.25.9. >> Expires: 3600. >> Content-Length: 0. >> * >> **SIP/2.0 404 Not here.* >> Via: SIP/2.0/UDP >> 172.20.1.25:32768;received=172.20.1.25;branch=z9hG4bK-lbgnea3kuorq;rport=32768. >> From: ;tag=w8vp9q5iyn. >> To: >> ;tag=f315b2d58ae8829149b784764c5a40e3-29cc. >> Call-ID: 54ec3a578c9e-klgn0s3i32zo. >> CSeq: 75 SUBSCRIBE. >> Server: OpenSIPS (1.11.3-tls (i386/linux)). >> Content-Length: 0. >> >> *NOTIFY sip:5002 at 172.20.1.10:57286 SIP/2.0.* >> Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdbe9.7966c706.0. >> To: ;tag=iklb1qjh1v. >> From: ;tag=f315b2d58ae8829149b784764c5a40e3-b571. >> CSeq: 2 NOTIFY. >> Call-ID: ee35ec54a72b-draf1nwo4qn7. >> Max-Forwards: 70. >> Content-Length: 0. >> User-Agent: OpenSIPS (1.11.3-tls (i386/linux)). >> Event: dialog. >> Contact: . >> *Subscription-State: terminated;reason=timeout.* >> * >> **SIP/2.0 200 Ok.* >> Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdbe9.7966c706.0. >> From: ;tag=f315b2d58ae8829149b784764c5a40e3-b571. >> To: ;tag=iklb1qjh1v. >> Call-ID: ee35ec54a72b-draf1nwo4qn7. >> CSeq: 2 NOTIFY. >> Content-Length: 0. >> >> The line 5020 was active but no lamp was powered. Also no NOTIFY or >> other event was sent by Opensips server when i try to call (from >> another phone) 5020. >> >> The full opensips.cfg is available here: http://pastebin.com/e6SfbFfq >> >> Thanks for any help. >> >> Michele >> >> -- >> Michele Pinassi >> Responsabile Telefonia di Ateneo >> Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena >> tel: 0577.(23)5000 - fax: 0577.(23)2053 >> >> Per trovare una soluzione rapida ai tuoi problemi tecnici >> consulta le FAQ di Ateneo, http://www.faq.unisi.it >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)5000 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From eric at uphreak.com Wed Mar 4 15:07:05 2015 From: eric at uphreak.com (Eric Tamme) Date: Wed, 04 Mar 2015 07:07:05 -0700 Subject: [OpenSIPS-Users] SIP to WebRTC Proxy / Gateway In-Reply-To: <402A87DA-2C2C-4B68-AAC6-DB64327985A2@ag-projects.com> References: <402A87DA-2C2C-4B68-AAC6-DB64327985A2@ag-projects.com> Message-ID: <54F71189.9060203@uphreak.com> Re: DTLS-SRTP + ICE -> plain RTP, this can be done using opensips with rtpengine, I have tested it using oversip -> opensips + rtpengine -> legacy sip. But generally speaking if you are "pretty new to SIP, RTP and WebRTC" you are likely going to run into a lot of head aches with WebRTC and "legacy" SIP device interop. I don't mean to be a downer ... thats just the way things are really. On 03/04/2015 02:35 AM, Sa?l Ibarra Corretg? wrote: > IIRC OpenSIPS hasn?t landed WebSocket support yet, but you could use OverSIP for translating SIP over UDP/TCP/TLS to WebSocket, acting as an outbound proxy, for example. > > Nevertheless, if you are connecting to a WebRTC gateway thing, signalling is likely the least of your worries, because your soft phone probably doesn?t support the media capabilities mandated by WebRTC. > > > Cheers, > > On 28 Feb 2015, at 22:00, Rion Carter wrote: > >> I'm pretty new to SIP, RTP and WebRTC. I am in need of a gateway or proxy that can let me use an existing SIP Soft-phone to connect to a WebRTC/SIP-over-websockets server (the WebRTC/SIP-over-websockets server does not provide a way for regular SIP softphones to connect). >> >> Would OpenSIPS be able to proxy my requests from my softphone to the WebRTC endpoint? I have examined the documentation and if I've missed something I apologize. Most everything I read emphasizes connecting webrtc clients to a server, and my need is different than that. >> >> Any examples, tutorials or documentation would be appreciated. >> >> Thanks! >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- > 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 mail at sathees.co.uk Wed Mar 4 16:02:00 2015 From: mail at sathees.co.uk (mahan77) Date: Wed, 4 Mar 2015 08:02:00 -0700 (MST) Subject: [OpenSIPS-Users] Problem Forward DDI/DID To asterisk Message-ID: <1425481320458-7595597.post@n2.nabble.com> Hi, I?m trying to setup OpenSIPS as a proxy to asterisk. I just want to pass the sip related activates to asterisk box. OpenSIPS running on ? 192.168.1.150 Asterisk running on ? 192.168.1.85 OpenSIPS UA using asterisk sippers. I will able to register UA via soft phone to ? 192.168.1.150 then OpenSIPS passing the sip packet to asterisk ? 192.168.1.85. With out any problem. I want to receive all DDI/DID calls into OpenSIPS and then have them forwarded to Asterisk. If UA registered with asterisk via OpenSIPS DDI/DID Calls stopping at OpenSIPS. If UA not registered DDI/DID calls will be forwarded to asterisk without any problem. I have attach ngrep on both servers. I can?t figure out what?s wrong, any help will be nice. This is my basic OpenSIPS script. route{ if(is_method("REGISTER")){ rewritehostport("192.168.1.85:5060"); route(1); } if (is_method("INVITE")) { if ( uri=~"^sip:[1-9][0-9]{10,15}@user.ddns.com") { rewritehostport("192.168.1.85:5060"); route(1); exit; }; } } ============================================================== 192.168.1.150 ? UA OFF LINE ============================================================== interface: eth0 (192.168.1.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) U 87.117.XX.XX:5060 -> 192.168.1.150:5060 INVITE sip:442030009999 at user.ddns.com SIP/2.0. Via: SIP/2.0/UDP 87.117.XX.XX:5060;rport;branch=z9hG4bK9Qy772eQ8ac0N. Max-Forwards: 68. From: "07720000999" ;tag=v0jKH9Se1Bmrr. To: . Call-ID: 89807087-3d1b-1233-4c90-aba651435a79. CSeq: 72403154 INVITE.87.117.XX.XX Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720000999" . . v=0. o=FreeSWITCH 1425447790 1425447791 IN IP4 87.117.XX.XX. s=FreeSWITCH. c=IN IP4 87.117.XX.XX. t=0 0. m=audio 30646 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.150:5060 -> 87.117.XX.XX:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK9Qy772eQ8ac0N. From: "07720000999" ;tag=v0jKH9Se1Bmrr. To: . Call-ID: 89807087-3d1b-1233-4c90-aba651435a79. CSeq: 72403154 INVITE. Server: OpenSIPS (1.11.3-tls (x86_64/linux)). Content-Length: 0. . U 192.168.1.150:5060 -> 192.168.1.85:5060 INVITE sip:442030009999 at 192.168.1.85:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK7209.7f9cedf1.0. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK9Qy772eQ8ac0N. Max-Forwards: 68. From: "07720000999" ;tag=v0jKH9Se1Bmrr. To: . Call-ID: 89807087-3d1b-1233-4c90-aba651435a79. CSeq: 72403154 INVITE. Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720000999" . . v=0. o=FreeSWITCH 1425447790 1425447791 IN IP4 87.117.XX.XX. s=FreeSWITCH. c=IN IP4 87.117.XX.XX. t=0 0. m=audio 30646 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK7209.7f9cedf1.0;received=192.168.1.150. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK9Qy772eQ8ac0N. From: "07720000999" ;tag=v0jKH9Se1Bmrr. To: . Call-ID: 89807087-3d1b-1233-4c90-aba651435a79. CSeq: 72403154 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Session-Expires: 1800;refresher=uac. Contact: . Content-Length: 0. . U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK7209.7f9cedf1.0;received=192.168.1.150. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK9Qy772eQ8ac0N. From: "07720000999" ;tag=v0jKH9Se1Bmrr. To: ;tag=as7e1c9b7e. Call-ID: 89807087-3d1b-1233-4c90-aba651435a79. CSeq: 72403154 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Session-Expires: 1800;refresher=uac. Contact: . Content-Type: application/sdp. Require: timer. Content-Length: 299. . v=0. o=root 394092194 394092194 IN IP4 192.168.1.85. s=Asterisk PBX SVN-branch-13-r432059. c=IN IP4 192.168.1.85. t=0 0. m=audio 17244 RTP/AVP 0 8 3 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=maxptime:150. a=sendrecv. U 192.168.1.150:5060 -> 87.117.XX.XX:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK9Qy772eQ8ac0N. From: "07720000999" ;tag=v0jKH9Se1Bmrr. To: ;tag=as7e1c9b7e. Call-ID: 89807087-3d1b-1233-4c90-aba651435a79. CSeq: 72403154 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Session-Expires: 1800;refresher=uac. Contact: . Content-Type: application/sdp. Require: timer. Content-Length: 299. . v=0. o=root 394092194 394092194 IN IP4 192.168.1.85. s=Asterisk PBX SVN-branch-13-r432059. c=IN IP4 192.168.1.85. t=0 0. m=audio 17244 RTP/AVP 0 8 3 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=maxptime:150. a=sendrecv. ================================================================== 192.168.1.150 ? UA ON LINE ================================================================== interface: eth0 (192.168.1.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) U 192.168.1.64:5060 -> 192.168.1.150:5060 . A.... .A..... 3. U 87.117.XX.XX:5060 -> 192.168.1.150:5060 INVITE sip:442030009999 at user.ddns.com SIP/2.0. Via: SIP/2.0/UDP 87.117.XX.XX:5060;rport;branch=z9hG4bK1XU79Det4BUjF. Max-Forwards: 68. From: "07720000999" ;tag=tjQeQjgc9Z5Km. To: . Call-ID: bde6f09c-3d1c-1233-f6a1-49f9ef1a62b7. CSeq: 72403413 INVITE. Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720000999" . . v=0. o=FreeSWITCH 1425449900 1425449901 IN IP4 87.117.XX.XX. s=FreeSWITCH. c=IN IP4 87.117.XX.XX. t=0 0. m=audio 29054 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.150:5060 -> 87.117.XX.XX:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK1XU79Det4BUjF. From: "07720000999" ;tag=tjQeQjgc9Z5Km. To: . Call-ID: bde6f09c-3d1c-1233-f6a1-49f9ef1a62b7. CSeq: 72403413 INVITE. Server: OpenSIPS (1.11.3-tls (x86_64/linux)). Content-Length: 0. . U 192.168.1.150:5060 -> 192.168.1.85:5060 INVITE sip:442030009999 at 192.168.1.85:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK0b39.642fa4b4.0. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK1XU79Det4BUjF. Max-Forwards: 68. From: "07720000999" ;tag=tjQeQjgc9Z5Km. To: . Call-ID: bde6f09c-3d1c-1233-f6a1-49f9ef1a62b7. CSeq: 72403413 INVITE. Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720000999" . . v=0. o=FreeSWITCH 1425449900 1425449901 IN IP4 87.117.XX.XX. s=FreeSWITCH. c=IN IP4 87.117.XX.XX. t=0 0. m=audio 29054 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK0b39.642fa4b4.0;received=192.168.1.150;rport=5060. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bK1XU79Det4BUjF. From: "07720000999" ;tag=tjQeQjgc9Z5Km. To: ;tag=as24e1cd09. Call-ID: bde6f09c-3d1c-1233-f6a1-49f9ef1a62b7. CSeq: 72403413 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="311b4438". Content-Length: 0. . U 192.168.1.150:5060 -> 192.168.1.85:5060 ACK sip:442030009999 at 192.168.1.85:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK0b39.642fa4b4.0. From: "07720000999" ================================================================== 192.168.1.85 ? UA OFF LINE ================================================================== interface: eth0 (192.168.1.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) U 192.168.1.150:5060 -> 192.168.1.85:5060 INVITE sip:442030009999 at 192.168.1.85:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bKb2b5.d24a1697.0. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bKjQ9BZ0KmrjjKB. Max-Forwards: 68. From: "07720000999" ;tag=mUK4yajK9HvNg. To: . Call-ID: aa32065b-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 72403181 INVITE. Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720000999" . . v=0. o=FreeSWITCH 1425458969 1425458970 IN IP4 87.117.XX.XX. s=FreeSWITCH. c=IN IP4 87.117.XX.XX. t=0 0. m=audio 19522 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bKb2b5.d24a1697.0;received=192.168.1.150. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bKjQ9BZ0KmrjjKB. From: "07720000999" ;tag=mUK4yajK9HvNg. To: . Call-ID: aa32065b-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 72403181 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Session-Expires: 1800;refresher=uac. Contact: . Content-Length: 0. . U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bKb2b5.d24a1697.0;received=192.168.1.150. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bKjQ9BZ0KmrjjKB. From: "07720000999" ;tag=mUK4yajK9HvNg. To: ;tag=as4c83514c. Call-ID: aa32065b-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 72403181 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Session-Expires: 1800;refresher=uac. Contact: . Content-Type: application/sdp. Require: timer. Content-Length: 299. . v=0. o=root 324691673 324691673 IN IP4 192.168.1.85. s=Asterisk PBX SVN-branch-13-r432059. c=IN IP4 192.168.1.85. t=0 0. m=audio 17328 RTP/AVP 0 8 3 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=maxptime:150. a=sendrecv. U 87.117.XX.XX:5060 -> 192.168.1.85:5060 ACK sip:442030009999 at 192.168.1.85:5060 SIP/2.0. Via: SIP/2.0/UDP 87.117.XX.XX:5060;rport;branch=z9hG4bKNjNp4H6yFDNBe. Max-Forwards: 70. From: "07720000999" ;tag=mUK4yajK9HvNg. To: ;tag=as4c83514c. Call-ID: aa32065b-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 72403181 ACK. Contact: . Content-Length: 0. . U 192.168.1.85:5060 -> 87.117.XX.XX:5060 BYE sip:mod_sofia at 87.117.XX.XX:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.85:5060;branch=z9hG4bK6cf09995. Max-Forwards: 70. From: ;tag=as4c83514c. To: "07720000999" ;tag=mUK4yajK9HvNg. Call-ID: aa32065b-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 102 BYE. User-Agent: Asterisk PBX SVN-branch-13-r432059. X-Asterisk-HangupCause: Normal Clearing. X-Asterisk-HangupCauseCode: 16. Content-Length: 0. . U 87.117.XX.XX:5060 -> 192.168.1.85:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.85:5060;branch=z9hG4bK6cf09995. From: ;tag=as4c83514c. To: "07720000999" ;tag=mUK4yajK9HvNg. Call-ID: aa32065b-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 102 BYE. User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Content-Length: 0. . =================================================================== 192.168.1.85 ? UA ON LINE =================================================================== interface: eth0 (192.168.1.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) U 192.168.1.150:5060 -> 192.168.1.85:5060 INVITE sip:442030009999 at 192.168.1.85:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK5ce6.17ba0501.0. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bKZ1gary8yDDc3g. Max-Forwards: 68. From: "07720000999" ;tag=pQ24c45r8DvBF. To: . Call-ID: bc26acf3-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 72403196 INVITE. Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720000999" . . v=0. o=FreeSWITCH 1425451221 1425451222 IN IP4 87.117.XX.XX. s=FreeSWITCH. c=IN IP4 87.117.XX.XX. t=0 0. m=audio 27300 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK5ce6.17ba0501.0;received=192.168.1.150;rport=5060. Via: SIP/2.0/UDP 87.117.XX.XX:5060;received=87.117.XX.XX;rport=5060;branch=z9hG4bKZ1gary8yDDc3g. From: "07720000999" ;tag=pQ24c45r8DvBF. To: ;tag=as163a4dd4. Call-ID: bc26acf3-3d1b-1233-f6a1-49f9ef1a62b7. CSeq: 72403196 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="145be05c". Content-Length: 0. . U 192.168.1.150:5060 -> 192.168.1.85:5060 ACK sip:442030009999 at 192.168.1.85:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK5ce6.17ba0501.0. From: "07720000999" ;tag=pQ24c45r8DvBF. Call-ID: bc26acf3-3d1b-1233-f6a1-49f9ef1a62b7. To: ;tag=as163a4dd4. CSeq: 72403196 ACK. Max-Forwards: 70. User-Agent: OpenSIPS (1.11.3-tls (x86_64/linux)). Content-Length: 0. . -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Problem-Forward-DDI-DID-To-asterisk-tp7595597.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From uzcudunl at yahoo.it Wed Mar 4 17:45:59 2015 From: uzcudunl at yahoo.it (leo) Date: Wed, 4 Mar 2015 09:45:59 -0700 (MST) Subject: [OpenSIPS-Users] OpenSIPS and Apple Push Notification In-Reply-To: <1402325945452-7591783.post@n2.nabble.com> References: <1402325945452-7591783.post@n2.nabble.com> Message-ID: <1425487559413-7595598.post@n2.nabble.com> I just need the last help: - considering that the UAC has an unlimited expiry (so the lookup will return 1) - my actual configuration is trying to send the INVITE to the contact in the DB but it will timeout (because the UAC is not connected anymore but it has unlimited expiry). - after this time out i should send the PN and wait for the UAC to re-register and then establish a new INVITE with this new info. Could you give me a couple of ideas on how to implement this? Thanks a lot! Leo -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-and-Apple-Push-Notification-tp7591783p7595598.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From eric at uphreak.com Wed Mar 4 17:55:32 2015 From: eric at uphreak.com (Eric Tamme) Date: Wed, 04 Mar 2015 09:55:32 -0700 Subject: [OpenSIPS-Users] OpenSIPS and Apple Push Notification In-Reply-To: <1425487559413-7595598.post@n2.nabble.com> References: <1402325945452-7591783.post@n2.nabble.com> <1425487559413-7595598.post@n2.nabble.com> Message-ID: <54F73904.9070207@uphreak.com> I would forget about push notifications. Just set a short expiration so that the device will renew its registration frequently. If you are using tcp then you should look at RFC5626 for SIP outbound information. On 03/04/2015 09:45 AM, leo wrote: > I just need the last help: > - considering that the UAC has an unlimited expiry (so the lookup will > return 1) > - my actual configuration is trying to send the INVITE to the contact in the > DB but it will timeout (because the UAC is not connected anymore but it has > unlimited expiry). > - after this time out i should send the PN and wait for the UAC to > re-register and then establish a new INVITE with this new info. > > Could you give me a couple of ideas on how to implement this? > > Thanks a lot! > > Leo > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-and-Apple-Push-Notification-tp7591783p7595598.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 merlin.li at tsingch.com Thu Mar 5 11:16:09 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Thu, 5 Mar 2015 18:16:09 +0800 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? References: , <201503041930185190809@tsingch.com>, <54F6F339.8080109@opensips.org>, <2015030514400333584418@tsingch.com> Message-ID: <201503051816083912131@tsingch.com> Hi Chircu, Thanks again. Yes, i totally agree with you that the CANCEL must be sent by the caller. The problem is the caller sent the cancel request, and the opensips also can receive it, but it can not break the while loop in the route block. The process flow is : 1. caller send invite to openips 2. opensips start a thread 1 to porcess the invite(i don't know whether the opensips start a new thread, just a guess ), into the while loop if the callee is offline 3. caller send the cancel request 4. opensips received the cancel request in the thread 2, but thread 1 still in the while loop My question is how can i terminate the while loop in the thread 1(or terminate the whole transation) when opensips receive the CANCEL request? Note: the callee is still offline at this moment , so i can not send 404 to it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlin.li at tsingch.com Thu Mar 5 11:16:42 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Thu, 5 Mar 2015 18:16:42 +0800 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? References: , <201503041930185190809@tsingch.com>, <54F6F339.8080109@opensips.org>, <2015030514400333584418@tsingch.com>, <2015030515101166802129@tsingch.com> Message-ID: <201503051816424658682@tsingch.com> Hi Chircu, I got an idea, and tested it, but the result confuse me. In the CANCEL processing block, i use set_dlg_flag("1") to set a dialog flag, if (is_method("CANCEL")) # in the route block { if (t_check_trans()){ if(!is_dlg_flag_set("1")){ set_dlg_flag("1"); t_relay(); exit; } } } and in the while loop: while( !lookup("location","m") ){ if(is_dlg_flag_set("1")){ t_reply("404","cancel the request!"); exit; } ..... } Sometimes , it works well, but sometimes, the CANCEL process is not executed until the loop finished. What i said is i got two result, and i don't know why. result 1: when opensips received the CANCEL request , the dialog flag is set, then break the while loop. result 2: Caller issue a CANCEL request, but opensips didn't entering the CANCEL process until the while loop is finished. merlin.li at tsingch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Mar 5 11:47:13 2015 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 05 Mar 2015 12:47:13 +0200 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? In-Reply-To: <201503051816424658682@tsingch.com> References: , <201503041930185190809@tsingch.com>, <54F6F339.8080109@opensips.org>, <2015030514400333584418@tsingch.com>, <2015030515101166802129@tsingch.com> <201503051816424658682@tsingch.com> Message-ID: <54F83431.2000808@opensips.org> Hello merlin, I have already given you the solution [1], but you did not read the email. It is also A LOT more efficient than your while+sleep loop, since it does not block the OpenSIPS workers at all - they are free to process all incoming traffic. Please implement it, send "404 Not Found" to the _caller_ when you decide to stop the call, and let me know if there are any problems :) [1] : http://lists.opensips.org/pipermail/users/2015-March/031022.html Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 05.03.2015 12:16, merlin.li at tsingch.com wrote: > > Hi Chircu, > > I got an idea, and tested it, but the result confuse me. > In the CANCEL processing block, i use set_dlg_flag("1") to set a > dialog flag, > > if (is_method("CANCEL")) # in the route block > { > if (t_check_trans()){ > if(!is_dlg_flag_set("1")){ > * set_dlg_flag("1");* > t_relay(); > exit; > } > } > } > > and in the while loop: > while( !lookup("location","m") ){ > if(is_dlg_flag_set("1")){ > t_reply("404","cancel the request!"); > exit; > } > ..... > } > > Sometimes , it works well, but sometimes, the CANCEL process is > not executed until the loop finished. > What i said is i got two result, and i don't know why. > result 1: > when opensips received the CANCEL request , the dialog flag is > set, then break the while loop. > > result 2: > Caller issue a CANCEL request, but opensips didn't entering the > CANCEL process until the while loop is finished. > > > ------------------------------------------------------------------------ > merlin.li at tsingch.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merlin.li at tsingch.com Thu Mar 5 11:56:37 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Thu, 5 Mar 2015 18:56:37 +0800 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? References: , <201503041930185190809@tsingch.com>, <54F6F339.8080109@opensips.org>, <2015030514400333584418@tsingch.com>, <2015030515101166802129@tsingch.com>, <201503051816424658682@tsingch.com>, <54F83431.2000808@opensips.org> Message-ID: <201503051856371144442@tsingch.com> Hi Chircu, Thanks I didn't received your mail which contain the solution, because i'm in China, we have fucking GFW, so sometimes we always miss something. I will test it , and let you know the result. Thanks again. merlin.li at tsingch.com From: Liviu Chircu Date: 2015-03-05 18:47 To: merlin.li at tsingch.com; users Subject: Re: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? Hello merlin, I have already given you the solution [1], but you did not read the email. It is also A LOT more efficient than your while+sleep loop, since it does not block the OpenSIPS workers at all - they are free to process all incoming traffic. Please implement it, send "404 Not Found" to the _caller_ when you decide to stop the call, and let me know if there are any problems :) [1] : http://lists.opensips.org/pipermail/users/2015-March/031022.html Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 05.03.2015 12:16, merlin.li at tsingch.com wrote: Hi Chircu, I got an idea, and tested it, but the result confuse me. In the CANCEL processing block, i use set_dlg_flag("1") to set a dialog flag, if (is_method("CANCEL")) # in the route block { if (t_check_trans()){ if(!is_dlg_flag_set("1")){ set_dlg_flag("1"); t_relay(); exit; } } } and in the while loop: while( !lookup("location","m") ){ if(is_dlg_flag_set("1")){ t_reply("404","cancel the request!"); exit; } ..... } Sometimes , it works well, but sometimes, the CANCEL process is not executed until the loop finished. What i said is i got two result, and i don't know why. result 1: when opensips received the CANCEL request , the dialog flag is set, then break the while loop. result 2: Caller issue a CANCEL request, but opensips didn't entering the CANCEL process until the while loop is finished. merlin.li at tsingch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From achalkov at ya.ru Thu Mar 5 12:44:56 2015 From: achalkov at ya.ru (=?koi8-r?B?/sHMy8/XIOHS1KPN?=) Date: Thu, 05 Mar 2015 14:44:56 +0300 Subject: [OpenSIPS-Users] TLS handling Message-ID: <272051425555896@web6j.yandex.ru> Hi all! Can someone help us?. I cannot understand how TLS in opensips 1.11 works. The problem is when we use TLS, i cannot handle connection problems. When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? From vladpaiu at opensips.org Thu Mar 5 13:38:48 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Thu, 05 Mar 2015 14:38:48 +0200 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: <272051425555896@web6j.yandex.ru> References: <272051425555896@web6j.yandex.ru> Message-ID: <54F84E58.4080706@opensips.org> Hello, Since TLS doesn't support async in 1.11, you should get an error straight out of t_relay() Can you please post the full debug logs here ? Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 05.03.2015 13:44, ?????? ????? wrote: > Hi all! > > Can someone help us?. I cannot understand how TLS in opensips 1.11 works. > The problem is when we use TLS, i cannot handle connection problems. > > When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From achalkov at ya.ru Thu Mar 5 14:22:11 2015 From: achalkov at ya.ru (=?koi8-r?B?/sHMy8/XIOHS1KPN?=) Date: Thu, 05 Mar 2015 16:22:11 +0300 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: <54F84E58.4080706@opensips.org> References: <272051425555896@web6j.yandex.ru> <54F84E58.4080706@opensips.org> Message-ID: <768261425561731@web7o.yandex.ru> debug=4 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_read_req: We're releasing the connection in state 3 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: releasing con 0x7f2be91663a8, state 0, fd=36, id=1 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: extra_data (nil) Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: SIP Request: Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: method: Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_tcp_child: reader response= 7f2be91663a8, 0 from 0 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: uri: Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7f2be91663a8,1), fd_no=38 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: version: Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 232, = ; state=6 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 235, = ; state=17 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via: end of header reached, state=5 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: via found, flags=2 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: this is the first via Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: After parse_msg... Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: preparing to run routing scripts... Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=8000000 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=10 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: to body [#015#012] Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: cseq : <3> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:maxfwd:is_maxfwd_present: value = 70 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: content_length=3 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: found end of header Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to_param: tag=b2b91161 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=29 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_methods: methods 0x173F Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:uri:has_totag: no totag Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=200 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:find_first_route: No Route headers found Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:loose_route: There is no Route HF Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_nonce: comparing [54f85536be0ae02858c2001d58774c222d958f86] and [54f85536be0ae02858c2001d58774c222d958f86] Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f2bef4e28b0 (tail=139826675195936) MC=0x7f2bef4e2080 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4f5968 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7f2bef4f6368 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6378)[0]=[ha1] Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6388)[1]=[mediaproxy] Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7f2bef4f6a48 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_str2val: converting STRING [659cc07a1ab8ccbbc3b5ec2172bc6473] Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: our result = '06223b730875bf2c01ad98448dd08438' Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: authorization is OK Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4f6368 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing 1 rows Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_row: freeing row values at 0x7f2bef4f6a58 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing rows at 0x7f2bef4f6a48 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_result: freeing result set at 0x7f2bef4f5968 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:comp_scriptvar: str 29 : 83.149.9.184 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_newtran: transaction on entrance=(nil) Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 1 entered Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 0 entered Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:_shm_resize: resize(0) called Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:mk_proxy: doing DNS lookup... Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2000 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:build_req_buf_from_sip_req: id added: <;i=1>, rcv proto=2 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_send: no open tcp connection found, opening new one Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 32768 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 65536 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 131072 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 262144 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting buf has no effect Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 133120 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=133120,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 135168 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=135168,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 137216 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=137216,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 139264 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=139264,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 141312 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=141312,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 143360 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=143360,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 145408 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=145408,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 147456 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=147456,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 149504 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=149504,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 151552 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=151552,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 153600 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=153600,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 155648 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=155648,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 157696 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=157696,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 159744 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=159744,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 161792 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=161792,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 163840 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=163840,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 165888 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=165888,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 167936 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=167936,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 169984 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=169984,verify=262142 Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_ser_child: read response= 7f2be91663a8, 1, fd -1 from 17 (19012) Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4e3aa8 Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f2bef4e3af0 Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4e3af8)[0]=[username] Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_query_avp: no result after query Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_close_query: close avp query Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4e3af0 Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_rows: freeing 0 rows Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_result: freeing result set at 0x7f2bef4e3aa8 Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:destroy_avp_list: destroying list (nil) Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:timer_routine: timer routine:2,tl=0x7f2be9166a20 next=(nil), timeout=36 Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: removing 0x7f2be91669a0 from table Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:delete_cell: delete transaction 0x7f2be91669a0 Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: done debug=3 with check if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); t_relay("0x01"); $var(retcode) = $retcode; xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode)"); Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [MAIN] Incoming request (MESSAGE) Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:probe_max_sock_buff: using snd buffer of 255 kb Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: poll error: flags 24 - 4 8 16 32 Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR [server=x.x.x.x:65106] (111) Connection refused Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_send: connect failed Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:msg_send: tcp_send failed Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:t_forward_nonack: sending request failed Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [!!!MESSAGE_DEBUG!!!] t_relay returns 1 05.03.2015, 15:39, "Vlad Paiu" : > Hello, > > Since TLS doesn't support async in 1.11, you should get an error > straight out of t_relay() > Can you please post the full debug logs here ? > > Best Regards, > > Vlad Paiu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 05.03.2015 13:44, ?????? ????? wrote: >> ?Hi all! >> >> ?Can someone help us?. I cannot understand how TLS in opensips 1.11 works. >> ?The problem is when we use TLS, i cannot handle connection problems. >> >> ?When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? >> >> ?_______________________________________________ >> ?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 danilo.sm at tin.it Thu Mar 5 17:10:59 2015 From: danilo.sm at tin.it (danilo.sm at tin.it) Date: Thu, 5 Mar 2015 17:10:59 +0100 (CET) Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL Message-ID: <14beab44bf6.danilo.sm@tin.it> Hi there, I'm working on this scenario to manage some toll free call features Caller =>OpenSips => Asterisk(IVR) => OpenSips => Called A Caller dials a number(A) configured on OpenSips, the call is forwarded to Asterisk where is active an IVR which let caller to choose which extension would like to reach. After Caller select through DTMF the extension, the call have to be sent back to OpenSips which can manage the choise and go on with the call to Called(B). As per my script, i Can reach Asterisk and make choice, but cannot give back to OpenSips the call control to go on Hope I've explained my needs Thx for your reply or to point me back to an existing scenario Danilo -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Mar 5 17:27:46 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 5 Mar 2015 11:27:46 -0500 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx Message-ID: Hello, How do i add customer info in opensipsctl fifo dlg_list_ctx output? I want to add custom field ( customer name) in dlg_list_ctx output -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Mar 5 17:32:36 2015 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 05 Mar 2015 18:32:36 +0200 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: References: Message-ID: <54F88524.4030105@opensips.org> Hello Satish, You can use dialog-persistent variables [1]. For example, $dlg_var(customer_name) = $var(name); [1] : http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 05.03.2015 18:27, Satish Patel wrote: > Hello, > > How do i add customer info in opensipsctl fifo dlg_list_ctx output? > > I want to add custom field ( customer name) in dlg_list_ctx output > > > _______________________________________________ > 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 satish.txt at gmail.com Thu Mar 5 17:39:34 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 5 Mar 2015 11:39:34 -0500 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: <54F88524.4030105@opensips.org> References: <54F88524.4030105@opensips.org> Message-ID: Thanks Liviu, Where should i put this variable in script? I have following code, should i before it create dialog? if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route() || match_dialog()) { if ($DLG_status!=NULL && !validate_dialog() ) { #xlog(" in-dialog bogus request \n"); fix_route_dialog(); } else { #xlog(" in-dialog valid request - $DLG_dir !\n"); fix_route_dialog(); } On Thu, Mar 5, 2015 at 11:32 AM, Liviu Chircu wrote: > Hello Satish, > > You can use dialog-persistent variables [1]. For example, > $dlg_var(customer_name) = $var(name); > > [1] : http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 > > Best regards, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 05.03.2015 18:27, Satish Patel wrote: > > Hello, > > How do i add customer info in opensipsctl fifo dlg_list_ctx output? > > I want to add custom field ( customer name) in dlg_list_ctx output > > > _______________________________________________ > 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 liviu at opensips.org Thu Mar 5 17:46:29 2015 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 05 Mar 2015 18:46:29 +0200 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: References: <54F88524.4030105@opensips.org> Message-ID: <54F88865.5060509@opensips.org> The dialog must be created, otherwise setting your $dlg_val will fail (check for "ERROR:core:do_assign: setting PV failed") The code you posted is for sequential request handling. Normally, the dialog should have been created by the time this block is reached. On 05.03.2015 18:39, Satish Patel wrote: > Thanks Liviu, > > Where should i put this variable in script? I have following code, > should i before it create dialog? > > > if (has_totag()) { > # sequential request withing a dialog should > # take the path determined by record-routing > if (loose_route() || match_dialog()) { > if ($DLG_status!=NULL && !validate_dialog() ) { > #xlog(" in-dialog bogus request \n"); > fix_route_dialog(); > } else { > #xlog(" in-dialog valid request - > $DLG_dir !\n"); > fix_route_dialog(); > } > > > On Thu, Mar 5, 2015 at 11:32 AM, Liviu Chircu > wrote: > > Hello Satish, > > You can use dialog-persistent variables [1]. For example, > $dlg_var(customer_name) = $var(name); > > [1] : > http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 > > Best regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 05.03.2015 18:27, Satish Patel wrote: >> Hello, >> >> How do i add customer info in opensipsctl fifo dlg_list_ctx output? >> >> I want to add custom field ( customer name) in dlg_list_ctx output >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Thu Mar 5 17:56:04 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 5 Mar 2015 11:56:04 -0500 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: <54F88865.5060509@opensips.org> References: <54F88524.4030105@opensips.org> <54F88865.5060509@opensips.org> Message-ID: You means say i just need to add following in in top of config? route { ... ... create_dialog(); $dlg_val(customer_name) = $var(name); On Thu, Mar 5, 2015 at 11:46 AM, Liviu Chircu wrote: > The dialog must be created, otherwise setting your $dlg_val will fail > (check for "ERROR:core:do_assign: setting PV failed") > > The code you posted is for sequential request handling. Normally, the > dialog should have been created by the time this block is reached. > > > On 05.03.2015 18:39, Satish Patel wrote: > > Thanks Liviu, > > Where should i put this variable in script? I have following code, > should i before it create dialog? > > > if (has_totag()) { > # sequential request withing a dialog should > # take the path determined by record-routing > if (loose_route() || match_dialog()) { > if ($DLG_status!=NULL && !validate_dialog() ) { > #xlog(" in-dialog bogus request \n"); > fix_route_dialog(); > } else { > #xlog(" in-dialog valid request - > $DLG_dir !\n"); > fix_route_dialog(); > } > > > On Thu, Mar 5, 2015 at 11:32 AM, Liviu Chircu wrote: > >> Hello Satish, >> >> You can use dialog-persistent variables [1]. For example, >> $dlg_var(customer_name) = $var(name); >> >> [1] : >> http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 >> >> Best regards, >> >> Liviu Chircu >> OpenSIPS Developerhttp://www.opensips-solutions.com >> >> On 05.03.2015 18:27, Satish Patel wrote: >> >> Hello, >> >> How do i add customer info in opensipsctl fifo dlg_list_ctx output? >> >> I want to add custom field ( customer name) in dlg_list_ctx output >> >> >> _______________________________________________ >> 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 liviu at opensips.org Thu Mar 5 18:04:00 2015 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 05 Mar 2015 19:04:00 +0200 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: References: <54F88524.4030105@opensips.org> <54F88865.5060509@opensips.org> Message-ID: <54F88C80.402@opensips.org> Yes. You should see that value in the dlg_list_ctx MI command. On 05.03.2015 18:56, Satish Patel wrote: > You means say i just need to add following in in top of config? > > route { > > ... > ... > create_dialog(); > $dlg_val(customer_name) = $var(name); > > > On Thu, Mar 5, 2015 at 11:46 AM, Liviu Chircu > wrote: > > The dialog must be created, otherwise setting your $dlg_val will > fail (check for "ERROR:core:do_assign: setting PV failed") > > The code you posted is for sequential request handling. Normally, > the dialog should have been created by the time this block is > reached. > > > On 05.03.2015 18:39, Satish Patel wrote: >> Thanks Liviu, >> >> Where should i put this variable in script? I have following >> code, should i before it create dialog? >> >> >> if (has_totag()) { >> # sequential request withing a dialog should >> # take the path determined by record-routing >> if (loose_route() || match_dialog()) { >> if ($DLG_status!=NULL && >> !validate_dialog() ) { >> #xlog(" in-dialog bogus request \n"); >> fix_route_dialog(); >> } else { >> #xlog(" in-dialog valid request >> - $DLG_dir !\n"); >> fix_route_dialog(); >> } >> >> >> On Thu, Mar 5, 2015 at 11:32 AM, Liviu Chircu > > wrote: >> >> Hello Satish, >> >> You can use dialog-persistent variables [1]. For example, >> $dlg_var(customer_name) = $var(name); >> >> [1] : >> http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 >> >> Best regards, >> >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> >> On 05.03.2015 18:27, Satish Patel wrote: >>> Hello, >>> >>> How do i add customer info in opensipsctl fifo dlg_list_ctx >>> output? >>> >>> I want to add custom field ( customer name) in dlg_list_ctx >>> output >>> >>> >>> _______________________________________________ >>> 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 govoiper at gmail.com Thu Mar 5 18:04:41 2015 From: govoiper at gmail.com (SamyGo) Date: Thu, 5 Mar 2015 12:04:41 -0500 Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL In-Reply-To: <14beab44bf6.danilo.sm@tin.it> References: <14beab44bf6.danilo.sm@tin.it> Message-ID: Hi Danilo, Can you just use application *Dial(SIP/OpenSips/${EXTEN})* at the IVR to send call back to the opensips server.Thats how I'd do to send call back to OpenSIPS. BR, Sammy On Thu, Mar 5, 2015 at 11:10 AM, danilo.sm at tin.it wrote: > Hi there, > I'm working on this scenario to manage some toll free call features > > Caller =>OpenSips => Asterisk(IVR) => OpenSips => Called > > A Caller dials a number(A) configured on OpenSips, the call is forwarded > to Asterisk where is active an IVR which let caller to choose which > extension would like to reach. After Caller select through DTMF the > extension, the call have to be sent back to OpenSips which can manage the > choise and go on with the call to Called(B). > As per my script, i Can reach Asterisk and make choice, but cannot give > back to OpenSips the call control to go on > > Hope I've explained my needs > > Thx for your reply or to point me back to an existing scenario > > Danilo > _______________________________________________ > 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 satish.txt at gmail.com Thu Mar 5 18:15:44 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 5 Mar 2015 12:15:44 -0500 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: <54F88C80.402@opensips.org> References: <54F88524.4030105@opensips.org> <54F88865.5060509@opensips.org> <54F88C80.402@opensips.org> Message-ID: I am not seeing my custom variable in MI output also i got this error in logs ERROR:core:do_assign: setting PV failed On Thu, Mar 5, 2015 at 12:04 PM, Liviu Chircu wrote: > Yes. You should see that value in the dlg_list_ctx MI command. > > > On 05.03.2015 18:56, Satish Patel wrote: > > You means say i just need to add following in in top of config? > > route { > > ... > ... > create_dialog(); > $dlg_val(customer_name) = $var(name); > > > On Thu, Mar 5, 2015 at 11:46 AM, Liviu Chircu wrote: > >> The dialog must be created, otherwise setting your $dlg_val will fail >> (check for "ERROR:core:do_assign: setting PV failed") >> >> The code you posted is for sequential request handling. Normally, the >> dialog should have been created by the time this block is reached. >> >> >> On 05.03.2015 18:39, Satish Patel wrote: >> >> Thanks Liviu, >> >> Where should i put this variable in script? I have following code, >> should i before it create dialog? >> >> >> if (has_totag()) { >> # sequential request withing a dialog should >> # take the path determined by record-routing >> if (loose_route() || match_dialog()) { >> if ($DLG_status!=NULL && !validate_dialog() ) { >> #xlog(" in-dialog bogus request \n"); >> fix_route_dialog(); >> } else { >> #xlog(" in-dialog valid request - >> $DLG_dir !\n"); >> fix_route_dialog(); >> } >> >> >> On Thu, Mar 5, 2015 at 11:32 AM, Liviu Chircu wrote: >> >>> Hello Satish, >>> >>> You can use dialog-persistent variables [1]. For example, >>> $dlg_var(customer_name) = $var(name); >>> >>> [1] : >>> http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 >>> >>> Best regards, >>> >>> Liviu Chircu >>> OpenSIPS Developerhttp://www.opensips-solutions.com >>> >>> On 05.03.2015 18:27, Satish Patel wrote: >>> >>> Hello, >>> >>> How do i add customer info in opensipsctl fifo dlg_list_ctx output? >>> >>> I want to add custom field ( customer name) in dlg_list_ctx output >>> >>> >>> _______________________________________________ >>> 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 danilo.sm at tin.it Thu Mar 5 18:18:38 2015 From: danilo.sm at tin.it (danilo.sm at tin.it) Date: Thu, 5 Mar 2015 18:18:38 +0100 (CET) Subject: [OpenSIPS-Users] R: Re: OPENSIPS + IVR CALL CONTROL Message-ID: <14beaf23ce6.danilo.sm@tin.it> Yes Sammy, it's what I was thinking about, but i thought there was another way to retain call control I have to generate 2 CDR and manage these Many thanks to everybody ----Messaggio originale---- Da: govoiper at gmail.com Data: 5-mar-2015 18.04 A: "danilo.sm at tin.it", "OpenSIPS users mailling list" Ogg: Re: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL Hi Danilo,Can you just use application Dial(SIP/OpenSips/${EXTEN}) at the IVR to send call back to the opensips server.Thats how I'd do to send call back to OpenSIPS. BR,Sammy On Thu, Mar 5, 2015 at 11:10 AM, danilo.sm at tin.it wrote: Hi there, I'm working on this scenario to manage some toll free call features Caller =>OpenSips => Asterisk(IVR) => OpenSips => Called A Caller dials a number(A) configured on OpenSips, the call is forwarded to Asterisk where is active an IVR which let caller to choose which extension would like to reach. After Caller select through DTMF the extension, the call have to be sent back to OpenSips which can manage the choise and go on with the call to Called(B). As per my script, i Can reach Asterisk and make choice, but cannot give back to OpenSips the call control to go on Hope I've explained my needs Thx for your reply or to point me back to an existing scenario Danilo _______________________________________________ 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 satish.txt at gmail.com Thu Mar 5 18:22:11 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 5 Mar 2015 12:22:11 -0500 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: References: <54F88524.4030105@opensips.org> <54F88865.5060509@opensips.org> <54F88C80.402@opensips.org> Message-ID: ignore last email, it was my variable issue. I got it work now :) Thanks you very much! On Thu, Mar 5, 2015 at 12:15 PM, Satish Patel wrote: > I am not seeing my custom variable in MI output also i got this error in > logs > > ERROR:core:do_assign: setting PV failed > > On Thu, Mar 5, 2015 at 12:04 PM, Liviu Chircu wrote: > >> Yes. You should see that value in the dlg_list_ctx MI command. >> >> >> On 05.03.2015 18:56, Satish Patel wrote: >> >> You means say i just need to add following in in top of config? >> >> route { >> >> ... >> ... >> create_dialog(); >> $dlg_val(customer_name) = $var(name); >> >> >> On Thu, Mar 5, 2015 at 11:46 AM, Liviu Chircu wrote: >> >>> The dialog must be created, otherwise setting your $dlg_val will fail >>> (check for "ERROR:core:do_assign: setting PV failed") >>> >>> The code you posted is for sequential request handling. Normally, the >>> dialog should have been created by the time this block is reached. >>> >>> >>> On 05.03.2015 18:39, Satish Patel wrote: >>> >>> Thanks Liviu, >>> >>> Where should i put this variable in script? I have following code, >>> should i before it create dialog? >>> >>> >>> if (has_totag()) { >>> # sequential request withing a dialog should >>> # take the path determined by record-routing >>> if (loose_route() || match_dialog()) { >>> if ($DLG_status!=NULL && !validate_dialog() ) { >>> #xlog(" in-dialog bogus request \n"); >>> fix_route_dialog(); >>> } else { >>> #xlog(" in-dialog valid request - >>> $DLG_dir !\n"); >>> fix_route_dialog(); >>> } >>> >>> >>> On Thu, Mar 5, 2015 at 11:32 AM, Liviu Chircu >>> wrote: >>> >>>> Hello Satish, >>>> >>>> You can use dialog-persistent variables [1]. For example, >>>> $dlg_var(customer_name) = $var(name); >>>> >>>> [1] : >>>> http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 >>>> >>>> Best regards, >>>> >>>> Liviu Chircu >>>> OpenSIPS Developerhttp://www.opensips-solutions.com >>>> >>>> On 05.03.2015 18:27, Satish Patel wrote: >>>> >>>> Hello, >>>> >>>> How do i add customer info in opensipsctl fifo dlg_list_ctx output? >>>> >>>> I want to add custom field ( customer name) in dlg_list_ctx output >>>> >>>> >>>> _______________________________________________ >>>> 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 satish.txt at gmail.com Thu Mar 5 18:24:43 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 5 Mar 2015 12:24:43 -0500 Subject: [OpenSIPS-Users] variable info in dlg_list_ctx In-Reply-To: References: <54F88524.4030105@opensips.org> <54F88865.5060509@opensips.org> <54F88C80.402@opensips.org> Message-ID: After i added create_dialog(); on top of the file then it allowed me to set variable, Just wondering what it does? is it going to harm if i am using it? because i never use before and everything seems working so what is the advantage of having create_dialog(); On Thu, Mar 5, 2015 at 12:22 PM, Satish Patel wrote: > ignore last email, it was my variable issue. I got it work now :) > > Thanks you very much! > > On Thu, Mar 5, 2015 at 12:15 PM, Satish Patel > wrote: > >> I am not seeing my custom variable in MI output also i got this error in >> logs >> >> ERROR:core:do_assign: setting PV failed >> >> On Thu, Mar 5, 2015 at 12:04 PM, Liviu Chircu wrote: >> >>> Yes. You should see that value in the dlg_list_ctx MI command. >>> >>> >>> On 05.03.2015 18:56, Satish Patel wrote: >>> >>> You means say i just need to add following in in top of config? >>> >>> route { >>> >>> ... >>> ... >>> create_dialog(); >>> $dlg_val(customer_name) = $var(name); >>> >>> >>> On Thu, Mar 5, 2015 at 11:46 AM, Liviu Chircu >>> wrote: >>> >>>> The dialog must be created, otherwise setting your $dlg_val will fail >>>> (check for "ERROR:core:do_assign: setting PV failed") >>>> >>>> The code you posted is for sequential request handling. Normally, the >>>> dialog should have been created by the time this block is reached. >>>> >>>> >>>> On 05.03.2015 18:39, Satish Patel wrote: >>>> >>>> Thanks Liviu, >>>> >>>> Where should i put this variable in script? I have following code, >>>> should i before it create dialog? >>>> >>>> >>>> if (has_totag()) { >>>> # sequential request withing a dialog should >>>> # take the path determined by record-routing >>>> if (loose_route() || match_dialog()) { >>>> if ($DLG_status!=NULL && !validate_dialog() ) { >>>> #xlog(" in-dialog bogus request \n"); >>>> fix_route_dialog(); >>>> } else { >>>> #xlog(" in-dialog valid request - >>>> $DLG_dir !\n"); >>>> fix_route_dialog(); >>>> } >>>> >>>> >>>> On Thu, Mar 5, 2015 at 11:32 AM, Liviu Chircu >>>> wrote: >>>> >>>>> Hello Satish, >>>>> >>>>> You can use dialog-persistent variables [1]. For example, >>>>> $dlg_var(customer_name) = $var(name); >>>>> >>>>> [1] : >>>>> http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297182 >>>>> >>>>> Best regards, >>>>> >>>>> Liviu Chircu >>>>> OpenSIPS Developerhttp://www.opensips-solutions.com >>>>> >>>>> On 05.03.2015 18:27, Satish Patel wrote: >>>>> >>>>> Hello, >>>>> >>>>> How do i add customer info in opensipsctl fifo dlg_list_ctx output? >>>>> >>>>> I want to add custom field ( customer name) in dlg_list_ctx output >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 merlin.li at tsingch.com Fri Mar 6 09:52:25 2015 From: merlin.li at tsingch.com (merlin.li at tsingch.com) Date: Fri, 6 Mar 2015 16:52:25 +0800 Subject: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? References: , <201503041930185190809@tsingch.com>, <54F6F339.8080109@opensips.org>, <2015030514400333584418@tsingch.com>, <2015030515101166802129@tsingch.com>, <201503051816424658682@tsingch.com>, <54F83431.2000808@opensips.org> Message-ID: <201503061652249273343@tsingch.com> Hi Chircu, one more question, Your solution: 1) set $T_fr_timeout and $T_fr_inv_timeout to 1 2) t_on_failure(...) [1] 3) t_relay() to a bogus gateway [2] 4) catch the 408 timeout in the failure route. Using an $avp counter, go back to step 1) until 30 tries have been done. In this failure route, you may now also use t_was_cancelled(). How can i let the opensips from step 4 to step 1?And what i want to use is t_cancel_branch(), not t_was_cancelled() merlin.li at tsingch.com From: Liviu Chircu Date: 2015-03-05 18:47 To: merlin.li at tsingch.com; users Subject: Re: [OpenSIPS-Users] how to cancel an INVITE before the callee receive it? Hello merlin, I have already given you the solution [1], but you did not read the email. It is also A LOT more efficient than your while+sleep loop, since it does not block the OpenSIPS workers at all - they are free to process all incoming traffic. Please implement it, send "404 Not Found" to the _caller_ when you decide to stop the call, and let me know if there are any problems :) [1] : http://lists.opensips.org/pipermail/users/2015-March/031022.html Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 05.03.2015 12:16, merlin.li at tsingch.com wrote: Hi Chircu, I got an idea, and tested it, but the result confuse me. In the CANCEL processing block, i use set_dlg_flag("1") to set a dialog flag, if (is_method("CANCEL")) # in the route block { if (t_check_trans()){ if(!is_dlg_flag_set("1")){ set_dlg_flag("1"); t_relay(); exit; } } } and in the while loop: while( !lookup("location","m") ){ if(is_dlg_flag_set("1")){ t_reply("404","cancel the request!"); exit; } ..... } Sometimes , it works well, but sometimes, the CANCEL process is not executed until the loop finished. What i said is i got two result, and i don't know why. result 1: when opensips received the CANCEL request , the dialog flag is set, then break the while loop. result 2: Caller issue a CANCEL request, but opensips didn't entering the CANCEL process until the while loop is finished. merlin.li at tsingch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From achalkov at ya.ru Fri Mar 6 10:06:04 2015 From: achalkov at ya.ru (=?koi8-r?B?/sHMy8/XIOHS1KPN?=) Date: Fri, 06 Mar 2015 12:06:04 +0300 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: <768261425561731@web7o.yandex.ru> References: <272051425555896@web6j.yandex.ru> <54F84E58.4080706@opensips.org> <768261425561731@web7o.yandex.ru> Message-ID: <2539131425632764@web1m.yandex.ru> do anyone have any idea about how to handle that? 05.03.2015, 16:22, "?????? ?????" : > debug=4 > > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_read_req: We're releasing the connection in state 3 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?releasing con 0x7f2be91663a8, state 0, fd=36, id=1 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?extra_data (nil) > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: SIP Request: > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?method: ? > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_tcp_child: reader response= 7f2be91663a8, 0 from 0 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?uri: ???? > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7f2be91663a8,1), fd_no=38 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?version: > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 232, = ; state=6 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 235, = ; state=17 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via: end of header reached, state=5 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: via found, flags=2 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: this is the first via > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: After parse_msg... > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: preparing to run routing scripts... > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=8000000 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=10 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: to body [#015#012] > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: cseq : <3> > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:maxfwd:is_maxfwd_present: value = 70 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: content_length=3 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: found end of header > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to_param: tag=b2b91161 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=29 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_methods: methods 0x173F > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:uri:has_totag: no totag > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=200 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:find_first_route: No Route headers found > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:loose_route: There is no Route HF > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_nonce: comparing [54f85536be0ae02858c2001d58774c222d958f86] and [54f85536be0ae02858c2001d58774c222d958f86] > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f2bef4e28b0 (tail=139826675195936) MC=0x7f2bef4e2080 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4f5968 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7f2bef4f6368 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6378)[0]=[ha1] > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6388)[1]=[mediaproxy] > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7f2bef4f6a48 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_str2val: converting STRING [659cc07a1ab8ccbbc3b5ec2172bc6473] > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: our result = '06223b730875bf2c01ad98448dd08438' > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: authorization is OK > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4f6368 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing 1 rows > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_row: freeing row values at 0x7f2bef4f6a58 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing rows at 0x7f2bef4f6a48 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_result: freeing result set at 0x7f2bef4f5968 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:comp_scriptvar: str 29 : 83.149.9.184 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_newtran: transaction on entrance=(nil) > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 1 entered > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 0 entered > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:_shm_resize: resize(0) called > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:mk_proxy: doing DNS lookup... > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2000 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:build_req_buf_from_sip_req: id added: <;i=1>, rcv proto=2 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_send: no open tcp connection found, opening new one > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 32768 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 65536 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 131072 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 262144 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting buf has no effect > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 133120 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=133120,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 135168 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=135168,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 137216 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=137216,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 139264 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=139264,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 141312 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=141312,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 143360 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=143360,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 145408 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=145408,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 147456 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=147456,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 149504 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=149504,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 151552 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=151552,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 153600 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=153600,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 155648 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=155648,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 157696 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=157696,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 159744 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=159744,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 161792 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=161792,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 163840 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=163840,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 165888 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=165888,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 167936 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=167936,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 169984 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=169984,verify=262142 > Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_ser_child: read response= 7f2be91663a8, 1, fd -1 from 17 (19012) > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4e3aa8 > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f2bef4e3af0 > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4e3af8)[0]=[username] > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_query_avp: no result after query > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_close_query: close avp query > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4e3af0 > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_rows: freeing 0 rows > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_result: freeing result set at 0x7f2bef4e3aa8 > Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:destroy_avp_list: destroying list (nil) > Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:timer_routine: timer routine:2,tl=0x7f2be9166a20 next=(nil), timeout=36 > Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: removing 0x7f2be91669a0 from table > Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:delete_cell: delete transaction 0x7f2be91669a0 > Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: done > > debug=3 with check > > ????????????????if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); > ????????????????t_relay("0x01"); > ????????????????$var(retcode) = $retcode; > ????????????????xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode)"); > > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [MAIN] Incoming request (MESSAGE) > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:probe_max_sock_buff: using snd buffer of 255 kb > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: poll error: flags 24 - 4 8 16 32 > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR [server=x.x.x.x:65106] (111) Connection refused > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_send: connect failed > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:msg_send: tcp_send failed > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:t_forward_nonack: sending request failed > Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [!!!MESSAGE_DEBUG!!!] t_relay returns 1 > > 05.03.2015, 15:39, "Vlad Paiu" : >> ?Hello, >> >> ?Since TLS doesn't support async in 1.11, you should get an error >> ?straight out of t_relay() >> ?Can you please post the full debug logs here ? >> >> ?Best Regards, >> >> ?Vlad Paiu >> ?OpenSIPS Developer >> ?http://www.opensips-solutions.com >> >> ?On 05.03.2015 13:44, ?????? ????? wrote: >>> ??Hi all! >>> >>> ??Can someone help us?. I cannot understand how TLS in opensips 1.11 works. >>> ??The problem is when we use TLS, i cannot handle connection problems. >>> >>> ??When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? >>> >>> ??_______________________________________________ >>> ??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 vladpaiu at opensips.org Fri Mar 6 10:42:49 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Fri, 06 Mar 2015 11:42:49 +0200 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: <2539131425632764@web1m.yandex.ru> References: <272051425555896@web6j.yandex.ru> <54F84E58.4080706@opensips.org> <768261425561731@web7o.yandex.ru> <2539131425632764@web1m.yandex.ru> Message-ID: <54F97699.9070802@opensips.org> Hello, OpenSIPS complains that there is an error when connecting via TCP to that endpoint. Now, are you sure you do not have multple branches when relaying that SIP MESSAGE,out of which only one fails ? In t_relay(), if you have multiple branches and at least one succceeds, you will get a 1 return code. Please post the complete debug=4 logs for the processing. In the previous email, you've truncated the logs to the moment OpenSIPS gets blocked in trying to connect to the endpoint - what happens afterwards ( after connet timeout ) would also be helpfull. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 06.03.2015 11:06, ?????? ????? wrote: > do anyone have any idea about how to handle that? > > 05.03.2015, 16:22, "?????? ?????" : >> debug=4 >> >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_read_req: We're releasing the connection in state 3 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: releasing con 0x7f2be91663a8, state 0, fd=36, id=1 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: extra_data (nil) >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: SIP Request: >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: method: >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_tcp_child: reader response= 7f2be91663a8, 0 from 0 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: uri: >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7f2be91663a8,1), fd_no=38 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: version: >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 232, = ; state=6 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 235, = ; state=17 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via: end of header reached, state=5 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: via found, flags=2 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: this is the first via >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: After parse_msg... >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: preparing to run routing scripts... >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=8000000 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=10 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: to body [#015#012] >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: cseq : <3> >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:maxfwd:is_maxfwd_present: value = 70 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: content_length=3 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: found end of header >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to_param: tag=b2b91161 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=29 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_methods: methods 0x173F >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:uri:has_totag: no totag >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=200 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:find_first_route: No Route headers found >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:loose_route: There is no Route HF >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_nonce: comparing [54f85536be0ae02858c2001d58774c222d958f86] and [54f85536be0ae02858c2001d58774c222d958f86] >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f2bef4e28b0 (tail=139826675195936) MC=0x7f2bef4e2080 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4f5968 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7f2bef4f6368 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6378)[0]=[ha1] >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6388)[1]=[mediaproxy] >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7f2bef4f6a48 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_str2val: converting STRING [659cc07a1ab8ccbbc3b5ec2172bc6473] >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: our result = '06223b730875bf2c01ad98448dd08438' >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: authorization is OK >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4f6368 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing 1 rows >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_row: freeing row values at 0x7f2bef4f6a58 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing rows at 0x7f2bef4f6a48 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_result: freeing result set at 0x7f2bef4f5968 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:comp_scriptvar: str 29 : 83.149.9.184 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_newtran: transaction on entrance=(nil) >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 1 entered >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 0 entered >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:_shm_resize: resize(0) called >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:mk_proxy: doing DNS lookup... >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2000 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:build_req_buf_from_sip_req: id added: <;i=1>, rcv proto=2 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_send: no open tcp connection found, opening new one >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 32768 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 65536 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 131072 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 262144 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting buf has no effect >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 133120 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=133120,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 135168 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=135168,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 137216 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=137216,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 139264 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=139264,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 141312 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=141312,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 143360 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=143360,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 145408 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=145408,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 147456 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=147456,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 149504 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=149504,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 151552 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=151552,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 153600 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=153600,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 155648 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=155648,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 157696 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=157696,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 159744 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=159744,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 161792 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=161792,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 163840 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=163840,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 165888 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=165888,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 167936 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=167936,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 169984 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=169984,verify=262142 >> Mar 5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_ser_child: read response= 7f2be91663a8, 1, fd -1 from 17 (19012) >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4e3aa8 >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f2bef4e3af0 >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4e3af8)[0]=[username] >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_query_avp: no result after query >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_close_query: close avp query >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4e3af0 >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_rows: freeing 0 rows >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_result: freeing result set at 0x7f2bef4e3aa8 >> Mar 5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:destroy_avp_list: destroying list (nil) >> Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:timer_routine: timer routine:2,tl=0x7f2be9166a20 next=(nil), timeout=36 >> Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: removing 0x7f2be91669a0 from table >> Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:delete_cell: delete transaction 0x7f2be91669a0 >> Mar 5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: done >> >> debug=3 with check >> >> if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); >> t_relay("0x01"); >> $var(retcode) = $retcode; >> xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode)"); >> >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [MAIN] Incoming request (MESSAGE) >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:probe_max_sock_buff: using snd buffer of 255 kb >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: poll error: flags 24 - 4 8 16 32 >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR [server=x.x.x.x:65106] (111) Connection refused >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_send: connect failed >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:msg_send: tcp_send failed >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:t_forward_nonack: sending request failed >> Mar 5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [!!!MESSAGE_DEBUG!!!] t_relay returns 1 >> >> 05.03.2015, 15:39, "Vlad Paiu" : >>> Hello, >>> >>> Since TLS doesn't support async in 1.11, you should get an error >>> straight out of t_relay() >>> Can you please post the full debug logs here ? >>> >>> Best Regards, >>> >>> Vlad Paiu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> >>> On 05.03.2015 13:44, ?????? ????? wrote: >>>> Hi all! >>>> >>>> Can someone help us?. I cannot understand how TLS in opensips 1.11 works. >>>> The problem is when we use TLS, i cannot handle connection problems. >>>> >>>> When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? >>>> >>>> _______________________________________________ >>>> 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 From achalkov at ya.ru Fri Mar 6 12:12:59 2015 From: achalkov at ya.ru (=?koi8-r?B?/sHMy8/XIOHS1KPN?=) Date: Fri, 06 Mar 2015 14:12:59 +0300 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: <54F97699.9070802@opensips.org> References: <272051425555896@web6j.yandex.ru> <54F84E58.4080706@opensips.org> <768261425561731@web7o.yandex.ru> <2539131425632764@web1m.yandex.ru> <54F97699.9070802@opensips.org> Message-ID: <3238271425640379@web13m.yandex.ru> Yes, i sure. I have only 1 branch because i have only one instance to receive sent MESSAGE and i dont add branches manually. Actually, that is all MESSAGE routing: ... if (is_method("MESSAGE")) route(MESSAGE); ... route[MESSAGE] { ... if (!lookup("location")) { ... } else { t_on_reply("ON_REPLY"); if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); t_relay("0x01"); $var(retcode) = $retcode; xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode) LOGHDR"); ifdef(`LOGS', `xlog("L_INFO", "[MESSAGE] Request is leaving server LOGHDR");') exit; } } I have sent to your e-mail (vladpaiu at opensips.org) debug=4 log from moment, when i killed softphone (destination of MESSAGE) without sip unregistering, but with removing tcp/tls connection. 06.03.2015, 12:43, "Vlad Paiu" : > Hello, > > OpenSIPS complains that there is an error when connecting via TCP to > that endpoint. > Now, are you sure you do not have multple branches when relaying that > SIP MESSAGE,out of which only one fails ? In t_relay(), if you have > multiple branches and at least one succceeds, you will get a 1 return code. > > Please post the complete debug=4 logs for the processing. In the > previous email, you've truncated the logs to the moment OpenSIPS gets > blocked in trying to connect to the endpoint - what happens afterwards ( > after connet timeout ) would also be helpfull. > > Best Regards, > > Vlad Paiu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 06.03.2015 11:06, ?????? ????? wrote: >> ?do anyone have any idea about how to handle that? >> >> ?05.03.2015, 16:22, "?????? ?????" : >>> ?debug=4 >>> >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_read_req: We're releasing the connection in state 3 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?releasing con 0x7f2be91663a8, state 0, fd=36, id=1 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?extra_data (nil) >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: SIP Request: >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?method: ? >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_tcp_child: reader response= 7f2be91663a8, 0 from 0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?uri: ???? >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7f2be91663a8,1), fd_no=38 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?version: >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 232, = ; state=6 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 235, = ; state=17 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via: end of header reached, state=5 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: via found, flags=2 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: this is the first via >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: After parse_msg... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: preparing to run routing scripts... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=8000000 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=10 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: to body [#015#012] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: cseq : <3> >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:maxfwd:is_maxfwd_present: value = 70 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: content_length=3 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: found end of header >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to_param: tag=b2b91161 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=29 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_methods: methods 0x173F >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:uri:has_totag: no totag >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=200 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:find_first_route: No Route headers found >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:loose_route: There is no Route HF >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_nonce: comparing [54f85536be0ae02858c2001d58774c222d958f86] and [54f85536be0ae02858c2001d58774c222d958f86] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f2bef4e28b0 (tail=139826675195936) MC=0x7f2bef4e2080 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4f5968 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7f2bef4f6368 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6378)[0]=[ha1] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6388)[1]=[mediaproxy] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7f2bef4f6a48 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_str2val: converting STRING [659cc07a1ab8ccbbc3b5ec2172bc6473] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: our result = '06223b730875bf2c01ad98448dd08438' >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: authorization is OK >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4f6368 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing 1 rows >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_row: freeing row values at 0x7f2bef4f6a58 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing rows at 0x7f2bef4f6a48 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_result: freeing result set at 0x7f2bef4f5968 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:comp_scriptvar: str 29 : 83.149.9.184 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_newtran: transaction on entrance=(nil) >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 1 entered >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 0 entered >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:_shm_resize: resize(0) called >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:mk_proxy: doing DNS lookup... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2000 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:build_req_buf_from_sip_req: id added: <;i=1>, rcv proto=2 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_send: no open tcp connection found, opening new one >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 32768 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 65536 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 131072 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 262144 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting buf has no effect >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 133120 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=133120,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 135168 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=135168,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 137216 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=137216,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 139264 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=139264,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 141312 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=141312,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 143360 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=143360,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 145408 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=145408,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 147456 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=147456,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 149504 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=149504,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 151552 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=151552,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 153600 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=153600,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 155648 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=155648,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 157696 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=157696,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 159744 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=159744,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 161792 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=161792,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 163840 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=163840,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 165888 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=165888,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 167936 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=167936,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 169984 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=169984,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_ser_child: read response= 7f2be91663a8, 1, fd -1 from 17 (19012) >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4e3aa8 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f2bef4e3af0 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4e3af8)[0]=[username] >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_query_avp: no result after query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_close_query: close avp query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4e3af0 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_rows: freeing 0 rows >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_result: freeing result set at 0x7f2bef4e3aa8 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:destroy_avp_list: destroying list (nil) >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:timer_routine: timer routine:2,tl=0x7f2be9166a20 next=(nil), timeout=36 >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: removing 0x7f2be91669a0 from table >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:delete_cell: delete transaction 0x7f2be91669a0 >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: done >>> >>> ?debug=3 with check >>> >>> ??????????????????if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); >>> ??????????????????t_relay("0x01"); >>> ??????????????????$var(retcode) = $retcode; >>> ??????????????????xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode)"); >>> >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [MAIN] Incoming request (MESSAGE) >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:probe_max_sock_buff: using snd buffer of 255 kb >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: poll error: flags 24 - 4 8 16 32 >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR [server=x.x.x.x:65106] (111) Connection refused >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_send: connect failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:msg_send: tcp_send failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:t_forward_nonack: sending request failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [!!!MESSAGE_DEBUG!!!] t_relay returns 1 >>> >>> ?05.03.2015, 15:39, "Vlad Paiu" : >>>> ???Hello, >>>> >>>> ???Since TLS doesn't support async in 1.11, you should get an error >>>> ???straight out of t_relay() >>>> ???Can you please post the full debug logs here ? >>>> >>>> ???Best Regards, >>>> >>>> ???Vlad Paiu >>>> ???OpenSIPS Developer >>>> ???http://www.opensips-solutions.com >>>> >>>> ???On 05.03.2015 13:44, ?????? ????? wrote: >>>>> ????Hi all! >>>>> >>>>> ????Can someone help us?. I cannot understand how TLS in opensips 1.11 works. >>>>> ????The problem is when we use TLS, i cannot handle connection problems. >>>>> >>>>> ????When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? >>>>> >>>>> ????_______________________________________________ >>>>> ????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 From govoiper at gmail.com Fri Mar 6 22:04:54 2015 From: govoiper at gmail.com (SamyGo) Date: Fri, 6 Mar 2015 16:04:54 -0500 Subject: [OpenSIPS-Users] Installing OpenSIPS 2.1.0 gives error Message-ID: Hi All, Im trying to install new OpenSIPS 2.1.0 from git. Im getting compilation errors; something like this. Compiling net/proto_tcp/proto_tcp.c Compiling net/proto_udp/proto_udp.c Compiling lex.yy.c lex.yy.c:4142:12: warning: redundant redeclaration of ?isatty? [-Wredundant-decls] /usr/include/unistd.h:802:12: note: previous declaration of ?isatty? was here Compiling cfg.tab.c Linking opensips cfg.tab.o: In function `yyparse': /usr/src/opensips/cfg.y:648: undefined reference to `mem_warming_percentage' /usr/src/opensips/cfg.y:646: undefined reference to `mem_warming_pattern_file' /usr/src/opensips/cfg.y:644: undefined reference to `mem_warming_enabled' collect2: ld returned 1 exit status make: *** [opensips] Error 1 I've downloaded it from git git clone https://github.com/OpenSIPS/opensips.git -b 2.1.0 Am I missing something, or need some external package installed to have this resolved ? Thanks, Sammy -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Fri Mar 6 23:39:39 2015 From: liviu at opensips.org (Liviu Chircu) Date: Sat, 07 Mar 2015 00:39:39 +0200 Subject: [OpenSIPS-Users] Installing OpenSIPS 2.1.0 gives error In-Reply-To: References: Message-ID: <54FA2CAB.4010301@opensips.org> Hello Samy, I moved some allocator-specific global variables in their own file, however the cfg.y file was referencing them regardless of the allocator you compile with. Fixed, and thanks for reporting! Cheers, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 06.03.2015 23:04, SamyGo wrote: > Hi All, > > Im trying to install new OpenSIPS 2.1.0 from git. Im getting > compilation errors; something like this. > > Compiling net/proto_tcp/proto_tcp.c > Compiling net/proto_udp/proto_udp.c > Compiling lex.yy.c > lex.yy.c:4142:12: warning: redundant redeclaration of ?isatty? > [-Wredundant-decls] > /usr/include/unistd.h:802:12: note: previous declaration of ?isatty? > was here > Compiling cfg.tab.c > Linking opensips > cfg.tab.o: In function `yyparse': > /usr/src/opensips/cfg.y:648: undefined reference to > `mem_warming_percentage' > /usr/src/opensips/cfg.y:646: undefined reference to > `mem_warming_pattern_file' > /usr/src/opensips/cfg.y:644: undefined reference to `mem_warming_enabled' > collect2: ld returned 1 exit status > make: *** [opensips] Error 1 > > > I've downloaded it from git > git clone https://github.com/OpenSIPS/opensips.git -b 2.1.0 > > Am I missing something, or need some external package installed to > have this resolved ? > > > 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 govoiper at gmail.com Sat Mar 7 01:21:09 2015 From: govoiper at gmail.com (SamyGo) Date: Fri, 6 Mar 2015 19:21:09 -0500 Subject: [OpenSIPS-Users] Installing OpenSIPS 2.1.0 gives error In-Reply-To: <54FA2CAB.4010301@opensips.org> References: <54FA2CAB.4010301@opensips.org> Message-ID: Thanks for the fix, will test it now. On Fri, Mar 6, 2015 at 5:39 PM, Liviu Chircu wrote: > Hello Samy, > > I moved some allocator-specific global variables in their own file, > however the cfg.y file was referencing them regardless of the allocator you > compile with. Fixed, and thanks for reporting! > > Cheers, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 06.03.2015 23:04, SamyGo wrote: > > Hi All, > > Im trying to install new OpenSIPS 2.1.0 from git. Im getting compilation > errors; something like this. > > Compiling net/proto_tcp/proto_tcp.c > Compiling net/proto_udp/proto_udp.c > Compiling lex.yy.c > lex.yy.c:4142:12: warning: redundant redeclaration of ?isatty? > [-Wredundant-decls] > /usr/include/unistd.h:802:12: note: previous declaration of ?isatty? was > here > Compiling cfg.tab.c > Linking opensips > cfg.tab.o: In function `yyparse': > /usr/src/opensips/cfg.y:648: undefined reference to > `mem_warming_percentage' > /usr/src/opensips/cfg.y:646: undefined reference to > `mem_warming_pattern_file' > /usr/src/opensips/cfg.y:644: undefined reference to `mem_warming_enabled' > collect2: ld returned 1 exit status > make: *** [opensips] Error 1 > > > I've downloaded it from git > git clone https://github.com/OpenSIPS/opensips.git -b 2.1.0 > > Am I missing something, or need some external package installed to have > this resolved ? > > > 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 govoiper at gmail.com Sat Mar 7 04:53:19 2015 From: govoiper at gmail.com (SamyGo) Date: Fri, 6 Mar 2015 22:53:19 -0500 Subject: [OpenSIPS-Users] Installing OpenSIPS 2.1.0 gives error In-Reply-To: References: <54FA2CAB.4010301@opensips.org> Message-ID: Thanks again worked this time. (Y) On Fri, Mar 6, 2015 at 7:21 PM, SamyGo wrote: > Thanks for the fix, will test it now. > > On Fri, Mar 6, 2015 at 5:39 PM, Liviu Chircu wrote: > >> Hello Samy, >> >> I moved some allocator-specific global variables in their own file, >> however the cfg.y file was referencing them regardless of the allocator you >> compile with. Fixed, and thanks for reporting! >> >> Cheers, >> >> Liviu Chircu >> OpenSIPS Developerhttp://www.opensips-solutions.com >> >> On 06.03.2015 23:04, SamyGo wrote: >> >> Hi All, >> >> Im trying to install new OpenSIPS 2.1.0 from git. Im getting >> compilation errors; something like this. >> >> Compiling net/proto_tcp/proto_tcp.c >> Compiling net/proto_udp/proto_udp.c >> Compiling lex.yy.c >> lex.yy.c:4142:12: warning: redundant redeclaration of ?isatty? >> [-Wredundant-decls] >> /usr/include/unistd.h:802:12: note: previous declaration of ?isatty? was >> here >> Compiling cfg.tab.c >> Linking opensips >> cfg.tab.o: In function `yyparse': >> /usr/src/opensips/cfg.y:648: undefined reference to >> `mem_warming_percentage' >> /usr/src/opensips/cfg.y:646: undefined reference to >> `mem_warming_pattern_file' >> /usr/src/opensips/cfg.y:644: undefined reference to `mem_warming_enabled' >> collect2: ld returned 1 exit status >> make: *** [opensips] Error 1 >> >> >> I've downloaded it from git >> git clone https://github.com/OpenSIPS/opensips.git -b 2.1.0 >> >> Am I missing something, or need some external package installed to have >> this resolved ? >> >> >> 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 ter.devor at gmail.com Sat Mar 7 07:32:21 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Sat, 7 Mar 2015 01:32:21 -0500 Subject: [OpenSIPS-Users] Safe Place/Method to Fix Contact Message-ID: Hello Everyone, Our environment is in an EC2 instance, and would like to fix the Contact when signalling internally (ie, private IP), and externally (ie, public IP). I have added the following code: In branch: if(!isflagset(5)) { remove_hf("Contact:"); append_hf("Contact: >\r\n"); } In on reply: if(!isflagset(5)) { remove_hf("Contact:"); append_hf("Contact: :5060>\r\n"); } Code works fine and changes the contact as needed however, OpenSIPS stops 200OK on OK. We have the following error message: Failed to match the sequential request to a known dialog Attempt to route with preloaded Route's [sip:5147398047@/sip:5193403221@/sip:;lr;did=2ad.791c28e4/74f3fb2e-3f34-1233-8f94-000c29d9b8bf] Your help is greatly appreciated, Terrance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Sun Mar 8 02:25:42 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Sat, 7 Mar 2015 20:25:42 -0500 Subject: [OpenSIPS-Users] Destination IP in the Branch and Reply Routes Message-ID: Hello Everyone, Our opensips is in a nat'ed environment , and we need a way to test if the destination ip (ie, where the next message is going to be sent) is public or private. Is there a variable, or even better a function that can test for this. Kind Regards, Terrance -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Mar 8 07:32:55 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Mar 2015 01:32:55 -0500 Subject: [OpenSIPS-Users] Opensips 2.1.x siptrace not sending packet to homer Message-ID: I have setup 2.1.x opensips and configure Homer on other box which is running on Kamailio somehow my Opensips siptrace not sending packet to sipcapture server, both are on same LAN. what i am doing wrong? I ran tcpdump on capture server but get nothing. ####### Capture Server ######## modparam("sipcapture", "db_url", "mysql://homer:XXXXXX at localhost/homer_db") modparam("sipcapture", "capture_on", 1) /* My node name*/ modparam("sipcapture", "capture_node", "node1") /* My table name*/ modparam("sipcapture", "table_name", "sip_capture") /* children for raw socket */ modparam("sipcapture", "raw_sock_children", 6) /* IP and port for HEP capturing) */ listen=udp:192.168.1.100:9060 /* activate HEP capturing */ modparam("sipcapture", "hep_capture_on", 1) ######## SIP Trace opensips 2.1 ##### #### SIP Capture agent loadmodule "siptrace.so" modparam("siptrace", "duplicate_uri", "sip:192.168.1.100:9060") modparam("siptrace", "duplicate_with_hep", 1) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_flag", 22) modparam("siptrace", "trace_on", 1) #HEPv2 == timestamp will be included to HEP header modparam("siptrace", "hep_version", 2) modparam("siptrace", "db_url", "mysql://opensips:XXXXXX at localhost/opensips") -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Mar 8 14:57:15 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Mar 2015 09:57:15 -0400 Subject: [OpenSIPS-Users] dispatcher wired behavior Message-ID: I have two Freeswitch in dispatcher, everything works great but i have notice in sip trace if FS1 receive 404 SIP code then it sending it to next FS2, i think it should stop there instead of forwarding next FS2 Following is my config #### Dispatcher loadmodule "dispatcher.so" modparam("dispatcher", "dst_avp", "$avp(271)") modparam("dispatcher", "grp_avp", "$avp(272)") modparam("dispatcher", "cnt_avp", "$avp(273)") modparam("dispatcher", "ds_ping_interval", 5) modparam("dispatcher", "ds_probing_threshhold", 5) modparam("dispatcher", "ds_probing_mode", 0) modparam("dispatcher", "options_reply_codes", "501, 403, 200") modparam("dispatcher", "db_url", "mysql://opensips:xxxxxxxx at localhost /opensips") ... ... route[to_dispatcher] { # Dispatch to FS if ( !ds_select_dst("1", "4", "FM10")) { send_reply("500","Unable to dispatch call to Freeswitch"); exit; } else { xlog("L_WARN", "dispatcher: Attempting to dispatch call to $du\n"); } t_on_failure("dispatcher_rollover"); t_relay(); } failure_route[dispatcher_rollover] { if (t_was_cancelled()) { exit; } if (t_check_status("408") && t_local_replied("all")) { xlog("L_NOTICE", "dispatcher: connection timeout: $rd\n"); ds_mark_dst("p"); } if(!ds_next_dst()) { xlog("L_ERR", "dispatcher: No more dispatcher in route set\n"); t_reply("500", "Temporary failure"); exit; } xlog("L_INFO", "dispatcher: attempting relay to new dispatcher: $du\n"); t_on_failure("dispatcher_rollover"); t_relay(); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Sun Mar 8 16:59:37 2015 From: john.nash778 at gmail.com (John Nash) Date: Sun, 8 Mar 2015 21:29:37 +0530 Subject: [OpenSIPS-Users] Version question Message-ID: I had started testing 1.X series taken from github master branch couple of months ago (It shows version as Server:: OpenSIPS (1.12.0dev-notls (x86_64/linux)) Now I need to install it in one of the production server and before I do that I want to update to the latest version of 1.X series. Which branch should I use to use most upto date 1.X opensips (As master branch now is 2.1) -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Sun Mar 8 17:22:24 2015 From: liviu at opensips.org (Liviu Chircu) Date: Sun, 08 Mar 2015 18:22:24 +0200 Subject: [OpenSIPS-Users] Version question In-Reply-To: References: Message-ID: <54FC7740.4030408@opensips.org> Hello John, 1.11.3 LTS seems to be what you're looking for [1]. You can get it with: git clone https://github.com/OpenSIPS/opensips.git -b 1.11 [1] http://www.opensips.org/About/AvailableVersions Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 08.03.2015 17:59, John Nash wrote: > I had started testing 1.X series taken from github master branch > couple of months ago (It shows version as Server:: OpenSIPS > (1.12.0dev-notls (x86_64/linux)) > > Now I need to install it in one of the production server and before I > do that I want to update to the latest version of 1.X series. Which > branch should I use to use most upto date 1.X opensips (As master > branch now is 2.1) > > > _______________________________________________ > 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.nash778 at gmail.com Sun Mar 8 17:43:42 2015 From: john.nash778 at gmail.com (John Nash) Date: Sun, 8 Mar 2015 22:13:42 +0530 Subject: [OpenSIPS-Users] Version question In-Reply-To: <54FC7740.4030408@opensips.org> References: <54FC7740.4030408@opensips.org> Message-ID: OK. Thank you. I have one more related question. If I use 2.1 version (I understand there may be some bugs) and use it with 1.X scripts (I mean without using async features in script for now) should it all work in general?...Like all modules? On Sun, Mar 8, 2015 at 9:52 PM, Liviu Chircu wrote: > Hello John, > > 1.11.3 LTS seems to be what you're looking for [1]. You can get it with: > git clone https://github.com/OpenSIPS/opensips.git -b 1.11 > > [1] http://www.opensips.org/About/AvailableVersions > > Best regards, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 08.03.2015 17:59, John Nash wrote: > > I had started testing 1.X series taken from github master branch couple > of months ago (It shows version as Server:: OpenSIPS (1.12.0dev-notls > (x86_64/linux)) > > Now I need to install it in one of the production server and before I do > that I want to update to the latest version of 1.X series. Which branch > should I use to use most upto date 1.X opensips (As master branch now is > 2.1) > > > _______________________________________________ > 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 liviu at opensips.org Sun Mar 8 18:12:18 2015 From: liviu at opensips.org (Liviu Chircu) Date: Sun, 08 Mar 2015 19:12:18 +0200 Subject: [OpenSIPS-Users] Version question In-Reply-To: References: <54FC7740.4030408@opensips.org> Message-ID: <54FC82F2.9020800@opensips.org> Syntax-wise, these are the only major changes in 2.1: * for udp/tcp/sctp/tls listeners, you must also do a `loadmodule "proto_xxx.so"` command after setting your mpath. * the global tcp_xxx and tls_xxx params must now be rewritten as modparam("proto_", "_xxxx", ...) Now, from a stability point of view, the network layer has been completely re-organized in order to easily support the addition of new transport protocols. This code is currently in a beta phase - it needs testing. But modules are unchanged and should behave exactly the same. So yes, "it should all work in general" :) Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 08.03.2015 18:43, John Nash wrote: > OK. Thank you. I have one more related question. If I use 2.1 version > (I understand there may be some bugs) and use it with 1.X scripts (I > mean without using async features in script for now) should it all > work in general?...Like all modules? > > On Sun, Mar 8, 2015 at 9:52 PM, Liviu Chircu > wrote: > > Hello John, > > 1.11.3 LTS seems to be what you're looking for [1]. You can get it > with: > git clone https://github.com/OpenSIPS/opensips.git -b 1.11 > > [1] http://www.opensips.org/About/AvailableVersions > > Best regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 08.03.2015 17:59, John Nash wrote: >> I had started testing 1.X series taken from github master branch >> couple of months ago (It shows version as Server:: OpenSIPS >> (1.12.0dev-notls (x86_64/linux)) >> >> Now I need to install it in one of the production server and >> before I do that I want to update to the latest version of 1.X >> series. Which branch should I use to use most upto date 1.X >> opensips (As master branch now is 2.1) >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Sun Mar 8 18:55:15 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Mar 2015 13:55:15 -0400 Subject: [OpenSIPS-Users] Version question In-Reply-To: <54FC82F2.9020800@opensips.org> References: <54FC7740.4030408@opensips.org> <54FC82F2.9020800@opensips.org> Message-ID: We have upgraded 1.12.x to 2.1.x and its been 5 month no issue so far, everything works! i am waiting for 2.1.x stable release so i can push it out but i would say so far its good and stable. Just question to Liviu, How do i use latest 2.1.x feature? currently i am using 1.x config. but i would like to use latest feature of 2.1.x On Sun, Mar 8, 2015 at 1:12 PM, Liviu Chircu wrote: > Syntax-wise, these are the only major changes in 2.1: > > * for udp/tcp/sctp/tls listeners, you must also do a `loadmodule > "proto_xxx.so"` command after setting your mpath. > * the global tcp_xxx and tls_xxx params must now be rewritten as > modparam("proto_", "_xxxx", ...) > > Now, from a stability point of view, the network layer has been completely > re-organized in order to easily support the addition of new transport > protocols. This code is currently in a beta phase - it needs testing. But > modules are unchanged and should behave exactly the same. So yes, "it > should all work in general" :) > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 08.03.2015 18:43, John Nash wrote: > > OK. Thank you. I have one more related question. If I use 2.1 version (I > understand there may be some bugs) and use it with 1.X scripts (I mean > without using async features in script for now) should it all work in > general?...Like all modules? > > On Sun, Mar 8, 2015 at 9:52 PM, Liviu Chircu wrote: > >> Hello John, >> >> 1.11.3 LTS seems to be what you're looking for [1]. You can get it with: >> git clone https://github.com/OpenSIPS/opensips.git -b 1.11 >> >> [1] http://www.opensips.org/About/AvailableVersions >> >> Best regards, >> >> Liviu Chircu >> OpenSIPS Developerhttp://www.opensips-solutions.com >> >> On 08.03.2015 17:59, John Nash wrote: >> >> I had started testing 1.X series taken from github master branch couple >> of months ago (It shows version as Server:: OpenSIPS (1.12.0dev-notls >> (x86_64/linux)) >> >> Now I need to install it in one of the production server and before I do >> that I want to update to the latest version of 1.X series. Which branch >> should I use to use most upto date 1.X opensips (As master branch now is >> 2.1) >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Sun Mar 8 19:04:26 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Mar 2015 14:04:26 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp Message-ID: sorry for push but it wired error! I have configure siptrace to send packet to "Homer" but getting following error in logs ERROR:siptrace:pipport2su: bad protocol udp ERROR:siptrace:pipport2su: bad protocol udp ERROR:siptrace:pipport2su: bad protocol udp Opensips 2.1.x #### SIP Capture agent loadmodule "siptrace.so" modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") modparam("siptrace", "duplicate_with_hep", 1) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_flag", 22) modparam("siptrace", "trace_on", 1) #HEPv2 == timestamp will be included to HEP header modparam("siptrace", "hep_version", 1) modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost/opensips") ... ... route{ setflag(22); sip_trace(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Mar 8 19:52:19 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Mar 2015 14:52:19 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: References: Message-ID: I tried same configuration on 1.11 version and it works! so look like something wrong in 2.1.x version please fix that bug as soon as possible On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel wrote: > sorry for push but it wired error! > > I have configure siptrace to send packet to "Homer" but getting following > error in logs > > ERROR:siptrace:pipport2su: bad protocol udp > ERROR:siptrace:pipport2su: bad protocol udp > ERROR:siptrace:pipport2su: bad protocol udp > > Opensips 2.1.x > > #### SIP Capture agent > loadmodule "siptrace.so" > modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") > modparam("siptrace", "duplicate_with_hep", 1) > modparam("siptrace", "trace_to_database", 0) > modparam("siptrace", "trace_flag", 22) > modparam("siptrace", "trace_on", 1) > #HEPv2 == timestamp will be included to HEP header > modparam("siptrace", "hep_version", 1) > modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost > /opensips") > > ... > ... > route{ > > setflag(22); > > sip_trace(); > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shahzad at voip-demos.com Sun Mar 8 20:20:21 2015 From: shahzad at voip-demos.com (shahzad at voip-demos.com) Date: Sun, 08 Mar 2015 20:20:21 +0100 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: References: Message-ID: OpenSIPS v2.x is much different then v1.x. So, if you are not familiar with it, you should better use 1.x Thank you. On 2015-03-08 19:52, Satish Patel wrote: > I tried same configuration on 1.11 version and it works! so look like something wrong in 2.1.x version please fix that bug as soon as possible > > On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel wrote: > >> sorry for push but it wired error! >> I have configure siptrace to send packet to "Homer" but getting following error in logs >> >> ERROR:siptrace:pipport2su: bad protocol udp >> ERROR:siptrace:pipport2su: bad protocol udp >> ERROR:siptrace:pipport2su: bad protocol udp >> >> Opensips 2.1.x >> >> #### SIP Capture agent >> loadmodule "siptrace.so" >> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060 [1]") >> modparam("siptrace", "duplicate_with_hep", 1) >> modparam("siptrace", "trace_to_database", 0) >> modparam("siptrace", "trace_flag", 22) >> modparam("siptrace", "trace_on", 1) >> #HEPv2 == timestamp will be included to HEP header >> modparam("siptrace", "hep_version", 1) >> modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost/opensips") >> >> ... >> ... >> >> route{ >> >> setflag(22); >> >> sip_trace(); Links: ------ [1] http://192.168.1.200:9060 [2] mailto:satish.txt at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Mar 8 20:31:23 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Mar 2015 15:31:23 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: References: Message-ID: I got your point, but our plan is to use 2.1.x and we are already using it since last 6 month without issue. But it should work in 2.1.x right? On Sun, Mar 8, 2015 at 3:20 PM, wrote: > OpenSIPS v2.x is much different then v1.x. So, if you are not familiar > with it, you should better use 1.x > > Thank you. > > > > On 2015-03-08 19:52, Satish Patel wrote: > > I tried same configuration on 1.11 version and it works! so look like > something wrong in 2.1.x version please fix that bug as soon as possible > > On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel wrote: > >> sorry for push but it wired error! >> >> I have configure siptrace to send packet to "Homer" but getting following >> error in logs >> >> ERROR:siptrace:pipport2su: bad protocol udp >> ERROR:siptrace:pipport2su: bad protocol udp >> ERROR:siptrace:pipport2su: bad protocol udp >> >> Opensips 2.1.x >> >> #### SIP Capture agent >> loadmodule "siptrace.so" >> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") >> modparam("siptrace", "duplicate_with_hep", 1) >> modparam("siptrace", "trace_to_database", 0) >> modparam("siptrace", "trace_flag", 22) >> modparam("siptrace", "trace_on", 1) >> #HEPv2 == timestamp will be included to HEP header >> modparam("siptrace", "hep_version", 1) >> modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost >> /opensips") >> >> ... >> ... >> route{ >> >> setflag(22); >> >> sip_trace(); >> >> >> > > > _______________________________________________ > 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 ter.devor at gmail.com Mon Mar 9 00:02:38 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Sun, 8 Mar 2015 19:02:38 -0400 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: <4fda8f6d562934872688560256868ff7@voip-demos.com> References: <54EC8943.2070308@opensips.org> <4fda8f6d562934872688560256868ff7@voip-demos.com> Message-ID: Good news, What is rtpengine support. Will the proxy manage RTP directly? Or will we still have to use RTP/Media Proxy Terrance ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Mon Mar 9 01:28:42 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Mar 2015 20:28:42 -0400 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: References: <54EC8943.2070308@opensips.org> <4fda8f6d562934872688560256868ff7@voip-demos.com> Message-ID: <412370C2-D775-420C-8E2A-704D3A12BD01@gmail.com> Bogdan, I am running 2.1.x and so far great, I had issue with sipteace with homer which I already reported. So please look into it before release. -- Sent from my iPhone > On Mar 8, 2015, at 7:02 PM, Terrance Devor wrote: > > Good news, > > What is rtpengine support. Will the proxy manage RTP directly? Or will > we still have to use RTP/Media Proxy > > > Terrance > ? > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From acmicrox at gmail.com Mon Mar 9 05:12:04 2015 From: acmicrox at gmail.com (microx) Date: Sun, 8 Mar 2015 21:12:04 -0700 (MST) Subject: [OpenSIPS-Users] CSeq and automatic call termination issue Message-ID: <1425874324382-7595684.post@n2.nabble.com> Hi all, In my testing environment, there are one SIP outbound proxy and one SIP server. The message flow of call setup is like caller->SIP outbound proxy->SIP server->SIP outbound proxy->callee. When the SIP outbound proxy receives an INVITE request from the SIP server, it calls create_dialog("B"). The automatic call termination timer is set to 30 minutes (modparam("dialog", "default_timeout", 1800)). This feature works well when no REFER/PRACK requests are sent during a dialog. If some REFER/PRACK are sent in the same dialog (CSeq increase), the BYE sent from SIP outbound proxy will be *reject by the client due to 500 (lower Cseq)*. I call match_dialog() in the SIP outbound proxy/SIP server when receiving REFER/PRACK. Can someone share how to address this issue? Any comment is greatly appreciated. Best regards, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/CSeq-and-automatic-call-termination-issue-tp7595684.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Mon Mar 9 09:00:34 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 09 Mar 2015 10:00:34 +0200 Subject: [OpenSIPS-Users] Safe Place/Method to Fix Contact In-Reply-To: References: Message-ID: <54FD5322.5030207@opensips.org> Hi, Terrance! Can you make a trace and check whether the Contact header is correct in the 200OK? Also, make sure that all the URI parameters are preserved over this change. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/07/2015 08:32 AM, Terrance Devor wrote: > Hello Everyone, > > Our environment is in an EC2 instance, and would like to fix the > Contact when > signalling internally (ie, private IP), and externally (ie, public > IP). I have added > the following code: > > In branch: > > if(!isflagset(5)) { > remove_hf("Contact:"); > append_hf("Contact: >\r\n"); > } > > > In on reply: > > if(!isflagset(5)) { > remove_hf("Contact:"); > append_hf("Contact: :5060>\r\n"); > } > > Code works fine and changes the contact as needed however, OpenSIPS > stops 200OK on OK. > We have the following error message: > > Failed to match the sequential request to a known dialog > Attempt to route with preloaded Route's [sip:5147398047@ carrier ip>/sip:5193403221@/sip: ip>;lr;did=2ad.791c28e4/74f3fb2e-3f34-1233-8f94-000c29d9b8bf] > > > Your help is greatly appreciated, > > Terrance. > > > > _______________________________________________ > 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 Mar 9 09:09:25 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 09 Mar 2015 10:09:25 +0200 Subject: [OpenSIPS-Users] Destination IP in the Branch and Reply Routes In-Reply-To: References: Message-ID: <54FD5535.9080509@opensips.org> Hi, Terrance! No, OpenSIPS does not provide such function or variable afaik. However, probably you need to test against a limited range of private addresses, so you can simply check a subclass, something like $dd =~ "192\.168\." Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/08/2015 03:25 AM, Terrance Devor wrote: > Hello Everyone, > > Our opensips is in a nat'ed environment , and we need a way to test if the > destination ip (ie, where the next message is going to be sent) is > public or > private. Is there a variable, or even better a function that can test > for this. > > Kind Regards, > > Terrance > > > _______________________________________________ > 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 Mar 9 09:11:42 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 09 Mar 2015 10:11:42 +0200 Subject: [OpenSIPS-Users] dispatcher wired behavior In-Reply-To: References: Message-ID: <54FD55BE.3010205@opensips.org> Hi, Satish! If you want to stop OpenSIPS from failing over to next FS2, you should not call t_relay() in failure_route for the 404 status. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/08/2015 03:57 PM, Satish Patel wrote: > I have two Freeswitch in dispatcher, everything works great but i have > notice in sip trace if FS1 receive 404 SIP code then it sending it to > next FS2, i think it should stop there instead of forwarding next FS2 > > Following is my config > > #### Dispatcher > loadmodule "dispatcher.so" > modparam("dispatcher", "dst_avp", "$avp(271)") > modparam("dispatcher", "grp_avp", "$avp(272)") > modparam("dispatcher", "cnt_avp", "$avp(273)") > modparam("dispatcher", "ds_ping_interval", 5) > modparam("dispatcher", "ds_probing_threshhold", 5) > modparam("dispatcher", "ds_probing_mode", 0) > modparam("dispatcher", "options_reply_codes", "501, 403, 200") > modparam("dispatcher", "db_url", > "mysql://opensips:xxxxxxxx at localhost/opensips") > > > ... > ... > > route[to_dispatcher] { > > # Dispatch to FS > if ( !ds_select_dst("1", "4", "FM10")) { > send_reply("500","Unable to dispatch call to Freeswitch"); > exit; > } else { > xlog("L_WARN", "dispatcher: Attempting to dispatch call to > $du\n"); > } > t_on_failure("dispatcher_rollover"); > t_relay(); > } > > failure_route[dispatcher_rollover] { > if (t_was_cancelled()) { > exit; > } > if (t_check_status("408") && t_local_replied("all")) { > xlog("L_NOTICE", "dispatcher: connection timeout: $rd\n"); > ds_mark_dst("p"); > } > if(!ds_next_dst()) { > xlog("L_ERR", "dispatcher: No more dispatcher in route > set\n"); > t_reply("500", "Temporary failure"); > exit; > } > xlog("L_INFO", "dispatcher: attempting relay to new > dispatcher: $du\n"); > t_on_failure("dispatcher_rollover"); > t_relay(); > } > > > > > _______________________________________________ > 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 Mar 9 10:03:33 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 09 Mar 2015 11:03:33 +0200 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: References: Message-ID: <54FD61E5.9020307@opensips.org> Hi, Satish! Indeed, there was an issue with the protocol check. I fixed it in the master branch. Please give it another try and let me know if you still have problems. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/08/2015 09:31 PM, Satish Patel wrote: > I got your point, but our plan is to use 2.1.x and we are already > using it since last 6 month without issue. > > But it should work in 2.1.x right? > > On Sun, Mar 8, 2015 at 3:20 PM, > wrote: > > OpenSIPS v2.x is much different then v1.x. So, if you are not > familiar with it, you should better use 1.x > > Thank you. > > On 2015-03-08 19:52, Satish Patel wrote: > >> I tried same configuration on 1.11 version and it works! so look >> like something wrong in 2.1.x version please fix that bug as soon >> as possible >> >> On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel >> > wrote: >> >> sorry for push but it wired error! >> I have configure siptrace to send packet to "Homer" but >> getting following error in logs >> ERROR:siptrace:pipport2su: bad protocol udp >> ERROR:siptrace:pipport2su: bad protocol udp >> ERROR:siptrace:pipport2su: bad protocol udp >> Opensips 2.1.x >> #### SIP Capture agent >> loadmodule "siptrace.so" >> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060 >> ") >> modparam("siptrace", "duplicate_with_hep", 1) >> modparam("siptrace", "trace_to_database", 0) >> modparam("siptrace", "trace_flag", 22) >> modparam("siptrace", "trace_on", 1) >> #HEPv2 == timestamp will be included to HEP header >> modparam("siptrace", "hep_version", 1) >> modparam("siptrace", "db_url", >> "mysql://opensips:xxxxxx at localhost/opensips") >> ... >> ... >> route{ >> setflag(22); >> sip_trace(); >> > > _______________________________________________ > 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 karlkarpfen79 at gmail.com Mon Mar 9 10:10:03 2015 From: karlkarpfen79 at gmail.com (Karl Karpfen) Date: Mon, 9 Mar 2015 10:10:03 +0100 Subject: [OpenSIPS-Users] Logwatch-rules for OpenSIPS? Message-ID: Hi, I'm using version 1.11 from git - are there some predefined logwatch rules available I can use on Ubuntu 12.04? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Mar 9 10:21:47 2015 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 09 Mar 2015 11:21:47 +0200 Subject: [OpenSIPS-Users] Logwatch-rules for OpenSIPS? In-Reply-To: References: Message-ID: <54FD662B.3070207@opensips.org> Hello Karl, We haven't added any logwatch files/scripts yet, but this looks like an excellent suggestion for a Feature Request on GitHub [1] [1] https://github.com/OpenSIPS/opensips/issues?q=is%3Aopen+is%3Aissue+label%3A%22feature+request%22 Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 09.03.2015 11:10, Karl Karpfen wrote: > Hi, > > I'm using version 1.11 from git - are there some predefined logwatch > rules available I can use on Ubuntu 12.04? > > 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 mail at sathees.co.uk Mon Mar 9 11:13:53 2015 From: mail at sathees.co.uk (mahan77) Date: Mon, 9 Mar 2015 03:13:53 -0700 (MST) Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk Message-ID: <1425896033806-7595694.post@n2.nabble.com> Hi, I need some help please. I?m trying to pass all sip packets to asterisk via dispatcher module. The problem I?m having if UA signed in the incoming DID will not pass to asterisk. The error message was ?SIP/2.0 401 Unauthorized? How can I solve this problem? preshiead Sathees This is my scripts. route{ if ( !mf_process_maxfwd_header("10") ) { sl_send_reply("483","To Many Hops"); drop(); } ds_select_dst("1", "0"); forward(); #t_relay(); } -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/incoming-DID-will-not-pass-to-asterisk-tp7595694.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From karlkarpfen79 at gmail.com Mon Mar 9 12:36:50 2015 From: karlkarpfen79 at gmail.com (Karl Karpfen) Date: Mon, 9 Mar 2015 12:36:50 +0100 Subject: [OpenSIPS-Users] Logwatch-rules for OpenSIPS? In-Reply-To: <54FD662B.3070207@opensips.org> References: <54FD662B.3070207@opensips.org> Message-ID: Done - thanks :-) 2015-03-09 10:21 GMT+01:00 Liviu Chircu : > Hello Karl, > > We haven't added any logwatch files/scripts yet, but this looks like an > excellent suggestion for a Feature Request on GitHub [1] > > [1] > https://github.com/OpenSIPS/opensips/issues?q=is%3Aopen+is%3Aissue+label%3A%22feature+request%22 > > Best regards, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 09.03.2015 11:10, Karl Karpfen wrote: > > Hi, > > I'm using version 1.11 from git - are there some predefined logwatch > rules available I can use on Ubuntu 12.04? > > Thanks! > > > > _______________________________________________ > 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 karlkarpfen79 at gmail.com Mon Mar 9 12:40:22 2015 From: karlkarpfen79 at gmail.com (Karl Karpfen) Date: Mon, 9 Mar 2015 12:40:22 +0100 Subject: [OpenSIPS-Users] Hangup does not work Message-ID: Hi, I'm using OpenSIPS 1.11 together with CSipSimple clients on Android. There option "ICE" but not "STUN" is enabled. Now I noticed that disconnecting (hang up) after a phone call does not work. Also when pressing the red "hang up"-button in the App, connection is still alive and both sides can communicate with each other. Then after some time (10..20 seconds?) a timeout error is shown on both sides and connection is closed. Any idea if this could be a problem of OpenSIPS and how to solve it? It doesn't matters if I use TLS or not. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Mon Mar 9 14:12:45 2015 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 9 Mar 2015 09:12:45 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: <54FD61E5.9020307@opensips.org> References: <54FD61E5.9020307@opensips.org> Message-ID: <6E13DF8A-03BC-48F0-B9E6-812EEDEF69D5@gmail.com> Superb, definitely going to give a try, I have a silly question. Can I apply that patch manually on my beach because if I try new master then fires it require any change in mysql? Reason we have couple of box running 2.1.x so want to keep it same. But any way let me test code first. And get back to you. -- Sent from my iPhone > On Mar 9, 2015, at 5:03 AM, R?zvan Crainea wrote: > > Hi, Satish! > > Indeed, there was an issue with the protocol check. I fixed it in the master branch. Please give it another try and let me know if you still have problems. > > Best regards, > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com >> On 03/08/2015 09:31 PM, Satish Patel wrote: >> I got your point, but our plan is to use 2.1.x and we are already using it since last 6 month without issue. >> >> But it should work in 2.1.x right? >> >> On Sun, Mar 8, 2015 at 3:20 PM, wrote: >>> OpenSIPS v2.x is much different then v1.x. So, if you are not familiar with it, you should better use 1.x >>> >>> Thank you. >>> >>> >>> >>>> On 2015-03-08 19:52, Satish Patel wrote: >>>> >>>> I tried same configuration on 1.11 version and it works! so look like something wrong in 2.1.x version please fix that bug as soon as possible >>>> >>>>> On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel wrote: >>>>> sorry for push but it wired error! >>>>> >>>>> I have configure siptrace to send packet to "Homer" but getting following error in logs >>>>> >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> >>>>> Opensips 2.1.x >>>>> >>>>> #### SIP Capture agent >>>>> loadmodule "siptrace.so" >>>>> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") >>>>> modparam("siptrace", "duplicate_with_hep", 1) >>>>> modparam("siptrace", "trace_to_database", 0) >>>>> modparam("siptrace", "trace_flag", 22) >>>>> modparam("siptrace", "trace_on", 1) >>>>> #HEPv2 == timestamp will be included to HEP header >>>>> modparam("siptrace", "hep_version", 1) >>>>> modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost/opensips") >>>>> >>>>> ... >>>>> ... >>>>> route{ >>>>> >>>>> setflag(22); >>>>> >>>>> sip_trace(); >>> >>> >>> _______________________________________________ >>> 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 eahaselhoff at gmail.com Mon Mar 9 14:22:47 2015 From: eahaselhoff at gmail.com (Edwin) Date: Mon, 9 Mar 2015 06:22:47 -0700 (MST) Subject: [OpenSIPS-Users] strange behavior use_next_gw Message-ID: <1425907367686-7595700.post@n2.nabble.com> I see a strange behaviour using the route_to_carrier and use_next_gw function: If I use a sip client whichs adds :5060 to the ruri and I receive a 503 Service unavailable from the first gateway, then the ruri sent to the next gateway (using the use_next_gw() function) is mixed up. The first prefix is still there preceded by the prefix from the next gateway with the original number four digets short. Let me explain: The way it works ok (note, no :5060) INVITE sip:31206655443 at mysipserver.org SIP/2.0 -> INVITE sip:123431206655443 at 10.20.30.40 SIP/2.0 <- 503 Service unavailable -> INVITE sip:876531206655443 at 20.30.40.50 SIP/2.0 The problem i see (note, :5060) INVITE sip:31206655443 at mysipserver.org SIP/2.0 -> INVITE sip:123431206655443 at 10.20.30.40 SIP/2.0 <- 503 Service unavailable -> INVITE sip:876512343120665 at 20.30.40.50 SIP/2.0 So I notice the first prefix is still there: 8765 1234 3120665 I can reproduce this by using a 3CX soft client (then it goes wrong). Here below the output of 'opensipsctl dr show' dr gateways +----+------+------+---------------+-------+------------+-------+------------+-------+--------+-------------+ | id | gwid | type | address | strip | pri_prefix | attrs | probe_mode | state | socket | description | +----+------+------+---------------+-------+------------+-------+------------+-------+--------+-------------+ | 1 | 1 | 1 | 10.20.30.40 | 0 | 1234 | NULL | 0 | 0 | NULL | Gateway A | | 2 | 2 | 2 | 20.30.40.50 | 0 | 8765 | NULL | 0 | 0 | NULL | Gateway B | +----+------+------+---------------+-------+------------+-------+------------+-------+--------+-------------+ dr groups +----+----------+--------+---------+-------------+ | id | username | domain | groupid | description | +----+----------+--------+---------+-------------+ | 1 | .* | .* | 1 | Inbound | | 2 | .* | .* | 2 | Outbound | +----+----------+--------+---------+-------------+ dr carriers +----+-----------+--------+-------+-------+-------+---------------------------+ | id | carrierid | gwlist | flags | state | attrs | description | +----+-----------+--------+-------+-------+-------+---------------------------+ | 1 | 1 | 1,2 | 0 | 0 | NULL | Carrier A | | 2 | 2 | 2,1 | 0 | 0 | NULL | Carrier B | +----+-----------+--------+-------+-------+-------+---------------------------+ dr rules +--------+---------+------------+---------+----------+---------+--------+-------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | attrs | description | +--------+---------+------------+---------+----------+---------+--------+-------+-------------+ | 1 | 1 | 4165555555 | | 0 | NULL | 1 | NULL | Inbound | | 2 | 2 | 4165555555 | | 0 | NULL | 1 | NULL | Outbound | +--------+---------+------------+---------+----------+---------+--------+-------+-------------+ Is this a bug? I can give more info if wanted... -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/strange-behavior-use-next-gw-tp7595700.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From eahaselhoff at gmail.com Mon Mar 9 14:38:54 2015 From: eahaselhoff at gmail.com (Edwin) Date: Mon, 9 Mar 2015 06:38:54 -0700 (MST) Subject: [OpenSIPS-Users] strange behavior use_next_gw In-Reply-To: <1425907367686-7595700.post@n2.nabble.com> References: <1425907367686-7595700.post@n2.nabble.com> Message-ID: <1425908334709-7595702.post@n2.nabble.com> I tested a quick 'fix' which works: $ru = "sip:" + $rU + "@" + $rd; if(route_to_carrier("$avp(droute)")) { -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/strange-behavior-use-next-gw-tp7595700p7595702.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From satish.txt at gmail.com Mon Mar 9 14:43:58 2015 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 9 Mar 2015 09:43:58 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: <6E13DF8A-03BC-48F0-B9E6-812EEDEF69D5@gmail.com> References: <54FD61E5.9020307@opensips.org> <6E13DF8A-03BC-48F0-B9E6-812EEDEF69D5@gmail.com> Message-ID: Sorry It was "branch" My iPhone is over smart :( -- Sent from my iPhone > On Mar 9, 2015, at 9:12 AM, Satish Patel wrote: > > Superb, definitely going to give a try, I have a silly question. Can I apply that patch manually on my beach because if I try new master then fires it require any change in mysql? > > Reason we have couple of box running 2.1.x so want to keep it same. But any way let me test code first. And get back to you. > > -- > Sent from my iPhone > >> On Mar 9, 2015, at 5:03 AM, R?zvan Crainea wrote: >> >> Hi, Satish! >> >> Indeed, there was an issue with the protocol check. I fixed it in the master branch. Please give it another try and let me know if you still have problems. >> >> Best regards, >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >>> On 03/08/2015 09:31 PM, Satish Patel wrote: >>> I got your point, but our plan is to use 2.1.x and we are already using it since last 6 month without issue. >>> >>> But it should work in 2.1.x right? >>> >>> On Sun, Mar 8, 2015 at 3:20 PM, wrote: >>>> OpenSIPS v2.x is much different then v1.x. So, if you are not familiar with it, you should better use 1.x >>>> >>>> Thank you. >>>> >>>> >>>> >>>>> On 2015-03-08 19:52, Satish Patel wrote: >>>>> >>>>> I tried same configuration on 1.11 version and it works! so look like something wrong in 2.1.x version please fix that bug as soon as possible >>>>> >>>>>> On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel wrote: >>>>>> sorry for push but it wired error! >>>>>> >>>>>> I have configure siptrace to send packet to "Homer" but getting following error in logs >>>>>> >>>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>>> >>>>>> Opensips 2.1.x >>>>>> >>>>>> #### SIP Capture agent >>>>>> loadmodule "siptrace.so" >>>>>> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") >>>>>> modparam("siptrace", "duplicate_with_hep", 1) >>>>>> modparam("siptrace", "trace_to_database", 0) >>>>>> modparam("siptrace", "trace_flag", 22) >>>>>> modparam("siptrace", "trace_on", 1) >>>>>> #HEPv2 == timestamp will be included to HEP header >>>>>> modparam("siptrace", "hep_version", 1) >>>>>> modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost/opensips") >>>>>> >>>>>> ... >>>>>> ... >>>>>> route{ >>>>>> >>>>>> setflag(22); >>>>>> >>>>>> sip_trace(); >>>> >>>> >>>> _______________________________________________ >>>> 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 frank21118 at yahoo.com Mon Mar 9 15:08:49 2015 From: frank21118 at yahoo.com (bluerain) Date: Mon, 9 Mar 2015 07:08:49 -0700 (MST) Subject: [OpenSIPS-Users] execute lb_status remotely to disable a node Message-ID: <1425910129249-7595707.post@n2.nabble.com> Is there a way to execute lb_status remotely to disable a node from load balancer? So I have an inbound Opensips that takes all the calls and load balance to multiple asterisk. And then I have another obound opensips that will terminate call from the asterisk server. The call flow goes: Inbound Opensips --> multiple Asterisk --> outbound Opensips. Inbound opensips send the calls across multiple asterisk and each asterisk send call (1 to 1) to an outbound opensips. When the outbound opensips goes down, inbound opensips will keep on sending call to the asterisk not know it can no longer terminate call (since the outbound opensips is down). Thus I want to be able to have asterisk send the opensipsctl fifo lb_status x,0 to the inbound opensip so that it will not keep sending call to it. Is that possible? Thx! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/execute-lb-status-remotely-to-disable-a-node-tp7595707.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From satish.txt at gmail.com Mon Mar 9 15:39:22 2015 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 9 Mar 2015 10:39:22 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: References: <54FD61E5.9020307@opensips.org> <6E13DF8A-03BC-48F0-B9E6-812EEDEF69D5@gmail.com> Message-ID: Thanks Razvan, It is working great!! you guys are awesome! On Mon, Mar 9, 2015 at 9:43 AM, Satish Patel wrote: > Sorry It was "branch" > > My iPhone is over smart :( > > -- > Sent from my iPhone > > On Mar 9, 2015, at 9:12 AM, Satish Patel wrote: > > Superb, definitely going to give a try, I have a silly question. Can I > apply that patch manually on my beach because if I try new master then > fires it require any change in mysql? > > Reason we have couple of box running 2.1.x so want to keep it same. But > any way let me test code first. And get back to you. > > -- > Sent from my iPhone > > On Mar 9, 2015, at 5:03 AM, R?zvan Crainea wrote: > > Hi, Satish! > > Indeed, there was an issue with the protocol check. I fixed it in the > master branch. Please give it another try and let me know if you still have > problems. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/08/2015 09:31 PM, Satish Patel wrote: > > I got your point, but our plan is to use 2.1.x and we are already using > it since last 6 month without issue. > > But it should work in 2.1.x right? > > On Sun, Mar 8, 2015 at 3:20 PM, wrote: > >> OpenSIPS v2.x is much different then v1.x. So, if you are not familiar >> with it, you should better use 1.x >> >> Thank you. >> >> >> >> On 2015-03-08 19:52, Satish Patel wrote: >> >> I tried same configuration on 1.11 version and it works! so look like >> something wrong in 2.1.x version please fix that bug as soon as possible >> >> On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel >> wrote: >> >>> sorry for push but it wired error! >>> >>> I have configure siptrace to send packet to "Homer" but getting >>> following error in logs >>> >>> ERROR:siptrace:pipport2su: bad protocol udp >>> ERROR:siptrace:pipport2su: bad protocol udp >>> ERROR:siptrace:pipport2su: bad protocol udp >>> >>> Opensips 2.1.x >>> >>> #### SIP Capture agent >>> loadmodule "siptrace.so" >>> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") >>> modparam("siptrace", "duplicate_with_hep", 1) >>> modparam("siptrace", "trace_to_database", 0) >>> modparam("siptrace", "trace_flag", 22) >>> modparam("siptrace", "trace_on", 1) >>> #HEPv2 == timestamp will be included to HEP header >>> modparam("siptrace", "hep_version", 1) >>> modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost >>> /opensips") >>> >>> ... >>> ... >>> route{ >>> >>> setflag(22); >>> >>> sip_trace(); >>> >>> >>> >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Mon Mar 9 16:43:17 2015 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 9 Mar 2015 11:43:17 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: References: <54FD61E5.9020307@opensips.org> <6E13DF8A-03BC-48F0-B9E6-812EEDEF69D5@gmail.com> Message-ID: Hey Razvan, Can i take following patch and directly apply to my existing install branch instead of downloading new Master? https://github.com/OpenSIPS/opensips/commit/178b0cc26b05a81947de150fe1c2df36d600ccaa Currently i am running: [root at sip ]# opensips -V version: opensips 2.1.1dev-tls (x86_64/linux) flags: STATS: On, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, 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: b3beb20 main.c compiled on 11:44:56 Dec 31 2014 with gcc 4.4.7 On Mon, Mar 9, 2015 at 10:39 AM, Satish Patel wrote: > Thanks Razvan, > > It is working great!! you guys are awesome! > > > On Mon, Mar 9, 2015 at 9:43 AM, Satish Patel wrote: > >> Sorry It was "branch" >> >> My iPhone is over smart :( >> >> -- >> Sent from my iPhone >> >> On Mar 9, 2015, at 9:12 AM, Satish Patel wrote: >> >> Superb, definitely going to give a try, I have a silly question. Can I >> apply that patch manually on my beach because if I try new master then >> fires it require any change in mysql? >> >> Reason we have couple of box running 2.1.x so want to keep it same. But >> any way let me test code first. And get back to you. >> >> -- >> Sent from my iPhone >> >> On Mar 9, 2015, at 5:03 AM, R?zvan Crainea wrote: >> >> Hi, Satish! >> >> Indeed, there was an issue with the protocol check. I fixed it in the >> master branch. Please give it another try and let me know if you still have >> problems. >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/08/2015 09:31 PM, Satish Patel wrote: >> >> I got your point, but our plan is to use 2.1.x and we are already using >> it since last 6 month without issue. >> >> But it should work in 2.1.x right? >> >> On Sun, Mar 8, 2015 at 3:20 PM, wrote: >> >>> OpenSIPS v2.x is much different then v1.x. So, if you are not familiar >>> with it, you should better use 1.x >>> >>> Thank you. >>> >>> >>> >>> On 2015-03-08 19:52, Satish Patel wrote: >>> >>> I tried same configuration on 1.11 version and it works! so look like >>> something wrong in 2.1.x version please fix that bug as soon as possible >>> >>> On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel >>> wrote: >>> >>>> sorry for push but it wired error! >>>> >>>> I have configure siptrace to send packet to "Homer" but getting >>>> following error in logs >>>> >>>> ERROR:siptrace:pipport2su: bad protocol udp >>>> ERROR:siptrace:pipport2su: bad protocol udp >>>> ERROR:siptrace:pipport2su: bad protocol udp >>>> >>>> Opensips 2.1.x >>>> >>>> #### SIP Capture agent >>>> loadmodule "siptrace.so" >>>> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") >>>> modparam("siptrace", "duplicate_with_hep", 1) >>>> modparam("siptrace", "trace_to_database", 0) >>>> modparam("siptrace", "trace_flag", 22) >>>> modparam("siptrace", "trace_on", 1) >>>> #HEPv2 == timestamp will be included to HEP header >>>> modparam("siptrace", "hep_version", 1) >>>> modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost >>>> /opensips") >>>> >>>> ... >>>> ... >>>> route{ >>>> >>>> setflag(22); >>>> >>>> sip_trace(); >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 frank21118 at yahoo.com Mon Mar 9 17:11:17 2015 From: frank21118 at yahoo.com (bluerain) Date: Mon, 9 Mar 2015 09:11:17 -0700 (MST) Subject: [OpenSIPS-Users] execute lb_status remotely to disable a node In-Reply-To: <1425910129249-7595707.post@n2.nabble.com> References: <1425910129249-7595707.post@n2.nabble.com> Message-ID: <1425917477619-7595711.post@n2.nabble.com> I guess further searching I need to install xmlrpc module, but I read on doc that it needs 0.9.10 but I tried to do apt-get install libxmlrpc-c3=0.9.10 it says it can not find that version. If I simply install, it will install version 1.16, will that be ok? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/execute-lb-status-remotely-to-disable-a-node-tp7595707p7595711.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From frank21118 at yahoo.com Mon Mar 9 17:32:16 2015 From: frank21118 at yahoo.com (bluerain) Date: Mon, 9 Mar 2015 09:32:16 -0700 (MST) Subject: [OpenSIPS-Users] opensips 1.9 missing mi_xmlrpc.so file Message-ID: <1425918736260-7595712.post@n2.nabble.com> Is there a place I can download the mi_xmlrpc.so? I looked under my /usr/local/lib64/opensips/modules directory, the file is not there. Thx! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/opensips-1-9-missing-mi-xmlrpc-so-file-tp7595712.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Mon Mar 9 18:04:01 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 09 Mar 2015 19:04:01 +0200 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: References: <54FD61E5.9020307@opensips.org> <6E13DF8A-03BC-48F0-B9E6-812EEDEF69D5@gmail.com> Message-ID: <54FDD281.3000300@opensips.org> Hi, Satish! Not sure what's the order of your messages, but yes, you can apply the patch directly on your branch, without cloning the entire Master. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/09/2015 05:43 PM, Satish Patel wrote: > Hey Razvan, > > Can i take following patch and directly apply to my existing install > branch instead of downloading new Master? > > https://github.com/OpenSIPS/opensips/commit/178b0cc26b05a81947de150fe1c2df36d600ccaa > > > Currently i am running: > > [root at sip ]# opensips -V > version: opensips 2.1.1dev-tls (x86_64/linux) > flags: STATS: On, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, > USE_MCAST, SHM_MEM, 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: b3beb20 > main.c compiled on 11:44:56 Dec 31 2014 with gcc 4.4.7 > > > > On Mon, Mar 9, 2015 at 10:39 AM, Satish Patel > wrote: > > Thanks Razvan, > > It is working great!! you guys are awesome! > > > On Mon, Mar 9, 2015 at 9:43 AM, Satish Patel > wrote: > > Sorry It was "branch" > > My iPhone is over smart :( > > -- > Sent from my iPhone > > On Mar 9, 2015, at 9:12 AM, Satish Patel > wrote: > >> Superb, definitely going to give a try, I have a silly >> question. Can I apply that patch manually on my beach because >> if I try new master then fires it require any change in mysql? >> >> Reason we have couple of box running 2.1.x so want to keep it >> same. But any way let me test code first. And get back to you. >> >> -- >> Sent from my iPhone >> >> On Mar 9, 2015, at 5:03 AM, R?zvan Crainea >> > wrote: >> >>> Hi, Satish! >>> >>> Indeed, there was an issue with the protocol check. I fixed >>> it in the master branch. Please give it another try and let >>> me know if you still have problems. >>> >>> Best regards, >>> R?zvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> On 03/08/2015 09:31 PM, Satish Patel wrote: >>>> I got your point, but our plan is to use 2.1.x and we are >>>> already using it since last 6 month without issue. >>>> >>>> But it should work in 2.1.x right? >>>> >>>> On Sun, Mar 8, 2015 at 3:20 PM, >>> > wrote: >>>> >>>> OpenSIPS v2.x is much different then v1.x. So, if you >>>> are not familiar with it, you should better use 1.x >>>> >>>> Thank you. >>>> >>>> On 2015-03-08 19:52, Satish Patel wrote: >>>> >>>>> I tried same configuration on 1.11 version and it >>>>> works! so look like something wrong in 2.1.x version >>>>> please fix that bug as soon as possible >>>>> >>>>> On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel >>>>> > >>>>> wrote: >>>>> >>>>> sorry for push but it wired error! >>>>> I have configure siptrace to send packet to >>>>> "Homer" but getting following error in logs >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> Opensips 2.1.x >>>>> #### SIP Capture agent >>>>> loadmodule "siptrace.so" >>>>> modparam("siptrace", "duplicate_uri", >>>>> "sip:192.168.1.200:9060 ") >>>>> modparam("siptrace", "duplicate_with_hep", 1) >>>>> modparam("siptrace", "trace_to_database", 0) >>>>> modparam("siptrace", "trace_flag", 22) >>>>> modparam("siptrace", "trace_on", 1) >>>>> #HEPv2 == timestamp will be included to HEP header >>>>> modparam("siptrace", "hep_version", 1) >>>>> modparam("siptrace", "db_url", >>>>> "mysql://opensips:xxxxxx at localhost/opensips") >>>>> ... >>>>> ... >>>>> route{ >>>>> setflag(22); >>>>> sip_trace(); >>>>> >>>> >>>> _______________________________________________ >>>> 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 ter.devor at gmail.com Mon Mar 9 18:44:42 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Mon, 9 Mar 2015 13:44:42 -0400 Subject: [OpenSIPS-Users] Destination IP in the Branch and Reply Routes In-Reply-To: <54FD5535.9080509@opensips.org> References: <54FD5535.9080509@opensips.org> Message-ID: Hello R?zvan, Thank you for your response. Testing against the $dd and local ip would work perfectly however, I have attempted to place some test messages `xlog("L_INFO","Destiantion IP1: $dd\n");` in the main,branch,relay and $dd is always null. I am not sure how this is possible? Do I need to add a modparam for the variable to be populated? Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Mon Mar 9 19:09:29 2015 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 9 Mar 2015 14:09:29 -0400 Subject: [OpenSIPS-Users] URGENT: ERROR:siptrace:pipport2su: bad protocol udp In-Reply-To: <54FDD281.3000300@opensips.org> References: <54FD61E5.9020307@opensips.org> <6E13DF8A-03BC-48F0-B9E6-812EEDEF69D5@gmail.com> <54FDD281.3000300@opensips.org> Message-ID: Thanks, I did exactly whatever you told me, i just patch 5 line in siptrace.c file in my current branch (2.1.1dev-tls git revision: b3beb20) Now it is working but still i am getting following error in logs. ( it is not saying "UDP" this time) ERROR:siptrace:pipport2su: bad protocol ERROR:siptrace:pipport2su: bad protocol And Interesting thing, I have Homer running on other box it is getting following error. Look like it is related to above issue. could you please take a look ERROR: sipcapture [hep.c:139]: hepv2_received(): ERROR: sipcapture:hep_msg_received: unknow protocol [1] ERROR: sipcapture [hep.c:139]: hepv2_received(): ERROR: sipcapture:hep_msg_received: unknow protocol [1] On Mon, Mar 9, 2015 at 1:04 PM, R?zvan Crainea wrote: > Hi, Satish! > > Not sure what's the order of your messages, but yes, you can apply the > patch directly on your branch, without cloning the entire Master. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/09/2015 05:43 PM, Satish Patel wrote: > > Hey Razvan, > > Can i take following patch and directly apply to my existing install > branch instead of downloading new Master? > > > https://github.com/OpenSIPS/opensips/commit/178b0cc26b05a81947de150fe1c2df36d600ccaa > > > Currently i am running: > > [root at sip ]# opensips -V > version: opensips 2.1.1dev-tls (x86_64/linux) > flags: STATS: On, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, > SHM_MEM, 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: b3beb20 > main.c compiled on 11:44:56 Dec 31 2014 with gcc 4.4.7 > > > > On Mon, Mar 9, 2015 at 10:39 AM, Satish Patel > wrote: > >> Thanks Razvan, >> >> It is working great!! you guys are awesome! >> >> >> On Mon, Mar 9, 2015 at 9:43 AM, Satish Patel >> wrote: >> >>> Sorry It was "branch" >>> >>> My iPhone is over smart :( >>> >>> -- >>> Sent from my iPhone >>> >>> On Mar 9, 2015, at 9:12 AM, Satish Patel wrote: >>> >>> Superb, definitely going to give a try, I have a silly question. Can >>> I apply that patch manually on my beach because if I try new master then >>> fires it require any change in mysql? >>> >>> Reason we have couple of box running 2.1.x so want to keep it same. >>> But any way let me test code first. And get back to you. >>> >>> -- >>> Sent from my iPhone >>> >>> On Mar 9, 2015, at 5:03 AM, R?zvan Crainea wrote: >>> >>> Hi, Satish! >>> >>> Indeed, there was an issue with the protocol check. I fixed it in the >>> master branch. Please give it another try and let me know if you still have >>> problems. >>> >>> Best regards, >>> >>> R?zvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/08/2015 09:31 PM, Satish Patel wrote: >>> >>> I got your point, but our plan is to use 2.1.x and we are already using >>> it since last 6 month without issue. >>> >>> But it should work in 2.1.x right? >>> >>> On Sun, Mar 8, 2015 at 3:20 PM, wrote: >>> >>>> OpenSIPS v2.x is much different then v1.x. So, if you are not >>>> familiar with it, you should better use 1.x >>>> >>>> Thank you. >>>> >>>> >>>> >>>> On 2015-03-08 19:52, Satish Patel wrote: >>>> >>>> I tried same configuration on 1.11 version and it works! so look like >>>> something wrong in 2.1.x version please fix that bug as soon as possible >>>> >>>> On Sun, Mar 8, 2015 at 2:04 PM, Satish Patel >>>> wrote: >>>> >>>>> sorry for push but it wired error! >>>>> >>>>> I have configure siptrace to send packet to "Homer" but getting >>>>> following error in logs >>>>> >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> ERROR:siptrace:pipport2su: bad protocol udp >>>>> >>>>> Opensips 2.1.x >>>>> >>>>> #### SIP Capture agent >>>>> loadmodule "siptrace.so" >>>>> modparam("siptrace", "duplicate_uri", "sip:192.168.1.200:9060") >>>>> modparam("siptrace", "duplicate_with_hep", 1) >>>>> modparam("siptrace", "trace_to_database", 0) >>>>> modparam("siptrace", "trace_flag", 22) >>>>> modparam("siptrace", "trace_on", 1) >>>>> #HEPv2 == timestamp will be included to HEP header >>>>> modparam("siptrace", "hep_version", 1) >>>>> modparam("siptrace", "db_url", "mysql://opensips:xxxxxx at localhost >>>>> /opensips") >>>>> >>>>> ... >>>>> ... >>>>> route{ >>>>> >>>>> setflag(22); >>>>> >>>>> sip_trace(); >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 rosenberg11219 at gmail.com Mon Mar 9 19:40:33 2015 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Mon, 9 Mar 2015 20:40:33 +0200 Subject: [OpenSIPS-Users] Call transfer problem Message-ID: I have a OpenSIPS server that acts as a load balancing server for a couple of asterisk servers, and lately I'm having a issue with asterisk responding with a 488 Not acceptable here for transfer requests when it comes to port 5060 on the Opensips server, but if I send it to another port it works fine, I realized that when using port 5060 the sdp has port 0 ie (m=audio 0 RTP/AVP 0 8 101.) but when using another port it does have a port number (ie m=audio 16422 RTP/AVP 0 8 101.) Im attaching both traces, I changed ips for security 212.212.212.212. is the opensips server, 212.212.212.213 is the asterisk server, and 91.176.221.245 is the end user. Can anyone please help me make this work on port 5060 too, and can you please explain why it would act differently, the NAT is also handeled differently as can be seen in the VIA header (maybe router is trying to use some ALG?) Here is the trace using port 5060 U 91.176.221.245:49242 -> 212.212.212.212:5060 INVITE sip:19174250000 at 212.212.212.213:5060;nat=yes SIP/2.0. Via: SIP/2.0/UDP 91.176.221.245:32781;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 70. Route: . Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f468a5000180cd88bd6cead37ab9d1920cc4c54a0ecdd3",uri="sip:19174250000 at 212.212. 212.213:5060",algorithm=MD5,response="0a5a118e2b318621f32b5d60b600229c". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 226. Content-Type: application/sdp. . v=0. o=- 33523926 33523927 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 0 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.212:5060 -> 91.176.221.245:49242 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 91.176.221.245:32781 ;received=91.176.221.245;rport=49242;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Server: OpenSIPS (1.7.2-notls (x86_64/linux)). Content-Length: 0. . U 212.212.212.212:5060 -> 212.212.212.213:5060 INVITE sip:19174250000 at 212.212.212.213:5060 SIP/2.0. Record-Route: . Via: SIP/2.0/UDP 212.212.212.212;branch=z9hG4bKe66e.0702ec92.0. Via: SIP/2.0/UDP 91.176.221.245:32781 ;rport=49242;received=91.176.221.245;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 69. Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f468a5000180cd88bd6cead37ab9d1920cc4c54a0ecdd3",uri="sip:19174250000 at 212.212. 212.213:5060",algorithm=MD5,response="0a5a118e2b318621f32b5d60b600229c". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 226. Content-Type: application/sdp. . v=0. o=- 33523926 33523927 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 0 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.213:5060 -> 212.212.212.212:5060 SIP/2.0 488 Not acceptable here. Via: SIP/2.0/UDP 212.212.212.212;branch=z9hG4bKe66e.0702ec92.0;received=212.212.212.212;rport=5060. Via: SIP/2.0/UDP 91.176.221.245:32781 ;rport=49242;received=91.176.221.245;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Server: SIP Server 9.21/CS. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH. Supported: replaces, timer. X-Asterisk-HangupCause: Normal Clearing. X-Asterisk-HangupCauseCode: 16. Content-Length: 0. . here is the trace using port 5744 U 91.176.221.245:63719 -> 212.212.212.212:5744 INVITE sip:19174250000 at 212.212.212.213:5060;nat=yes SIP/2.0. Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-6f0161f0. From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 70. Route: . Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f46d7a0000081272baa39f9e34a0ee81f471dec7b034ba",uri=" sip:19174250000 at 212.212.212.213:5060 ",algorithm=MD5,response="4096f485853bf6a209424c36dac2342b". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 224. Content-Type: application/sdp. . v=0. o=- 30981 30982 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 16422 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.212:5744 -> 91.176.221.245:63719 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.0.101:5060 ;received=91.176.221.245;rport=63719;branch=z9hG4bK-6f0161f0. From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Server: OpenSIPS (1.7.2-notls (x86_64/linux)). Content-Length: 0. . U 212.212.212.212:5744 -> 212.212.212.213:5060 INVITE sip:19174250000 at 212.212.212.213:5060 SIP/2.0. Record-Route: . Via: SIP/2.0/UDP 212.212.212.212:5744;branch=z9hG4bKa7d5.c5b6d177.0. Via: SIP/2.0/UDP 192.168.0.101:5060 ;rport=63719;received=91.176.221.245;branch=z9hG4bK-6f0161f0. From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 69. Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f46d7a0000081272baa39f9e34a0ee81f471dec7b034ba",uri=" sip:19174250000 at 212.212.212.213:5060 ",algorithm=MD5,response="4096f485853bf6a209424c36dac2342b". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 224. Content-Type: application/sdp. . v=0. o=- 30981 30982 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 16422 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.213:5060 -> 212.212.212.212:5744 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 212.212.212.212:5744 ;branch=z9hG4bKa7d5.c5b6d177.0;received=212.212.212.212;rport=5744. Via: SIP/2.0/UDP 192.168.0.101:5060 ;rport=63719;received=91.176.221.245;branch=z9hG4bK-6f0161f0. Record-Route: . From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Server: SIP Server 9.21/CS. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Contact: . Content-Length: 0. . -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank21118 at yahoo.com Mon Mar 9 20:49:19 2015 From: frank21118 at yahoo.com (bluerain) Date: Mon, 9 Mar 2015 12:49:19 -0700 (MST) Subject: [OpenSIPS-Users] calling opensipsctl fifo lb_status 2 1 by xmlrpc Message-ID: <1425930559821-7595718.post@n2.nabble.com> Ok, so I figured that you can use xmlrpc to call fifo function remotely, but the issue is I am no linux expert, so I've been reading things here and there. I guess the thing I need to do is to write a xxx.php file on Asterisk and then use the php -h xxx.php to execute it to send a command to opensips server? If that is the case can someone provide me with a simple php script to just call "lbl_status 2 1" with php script? I would greatly appreciate any help I can get. thank you! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/calling-opensipsctl-fifo-lb-status-2-1-by-xmlrpc-tp7595718.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From frank21118 at yahoo.com Mon Mar 9 23:28:53 2015 From: frank21118 at yahoo.com (bluerain) Date: Mon, 9 Mar 2015 15:28:53 -0700 (MST) Subject: [OpenSIPS-Users] calling opensipsctl fifo lb_status 2 1 by xmlrpc In-Reply-To: <1425930559821-7595718.post@n2.nabble.com> References: <1425930559821-7595718.post@n2.nabble.com> Message-ID: <1425940133787-7595722.post@n2.nabble.com> Nevermind, I finally get it. So is NOT PHP, I know I may sound stupid, but to linux rookie, is very hard. So just for future reference, or anybody would like to know: 1. Install make sure you have python install in your OS 2. Make a file with extension of .py (e.g. the following): #!/usr/bin/python import xmlrpclib opensips = xmlrpclib.ServerProxy('http://192.168.1.1:8000/RPC2') print opensips.lb_status(1,0); and then on the CLI of the OS which the compute you would like to send the command to opensips, just type "python test.py" lb_status(1,0) will turn off node #1 where lb_status(1,1) will turn on node #1 This maybe simple for linux guru, but is hard to figure out for rookie... hope this is of use to someone! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/calling-opensipsctl-fifo-lb-status-2-1-by-xmlrpc-tp7595718p7595722.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From mail at sathees.co.uk Mon Mar 9 23:51:30 2015 From: mail at sathees.co.uk (mahan77) Date: Mon, 9 Mar 2015 15:51:30 -0700 (MST) Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: <1425896033806-7595694.post@n2.nabble.com> References: <1425896033806-7595694.post@n2.nabble.com> Message-ID: <1425941490713-7595723.post@n2.nabble.com> Is it wrong question to ask in this mailing list? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/incoming-DID-will-not-pass-to-asterisk-tp7595694p7595723.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From ter.devor at gmail.com Tue Mar 10 02:49:32 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Mon, 9 Mar 2015 21:49:32 -0400 Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: <1425941490713-7595723.post@n2.nabble.com> References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> Message-ID: Hello Sathees, It is the appropriate place. I myself would need some more information such as SIP trace, and maybe more of the config? Terrance ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 10 03:15:38 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Mon, 9 Mar 2015 22:15:38 -0400 Subject: [OpenSIPS-Users] Destination IP in the Branch and Reply Routes In-Reply-To: References: <54FD5535.9080509@opensips.org> Message-ID: I tried to test for $dd everywhere, including right after loose_route etc.., and I get null's everywhere. I have a hair raising scenario where I need to know where the next message (ie, destination) will be in the branch and relay routes. This also includes re-invites, session progresses, failures etc... Your help is greatly appreciated, Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From achalkov at ya.ru Tue Mar 10 05:48:54 2015 From: achalkov at ya.ru (=?koi8-r?B?/sHMy8/XIOHS1KPN?=) Date: Tue, 10 Mar 2015 07:48:54 +0300 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: <3238271425640379@web13m.yandex.ru> References: <272051425555896@web6j.yandex.ru> <54F84E58.4080706@opensips.org> <768261425561731@web7o.yandex.ru> <2539131425632764@web1m.yandex.ru> <54F97699.9070802@opensips.org> <3238271425640379@web13m.yandex.ru> Message-ID: <941251425962934@web16g.yandex.ru> Vlad, community, still no idea about that? I really need your advice with that. 06.03.2015, 14:14, "?????? ?????" : > Yes, i sure. I have only 1 branch because i have only one instance to receive sent MESSAGE and i dont add branches manually. Actually, that is all MESSAGE routing: > > ... > ?if (is_method("MESSAGE")) route(MESSAGE); > ... > route[MESSAGE] { > ... > ????????if (!lookup("location")) { > ??... > ???} else { > ????????????????t_on_reply("ON_REPLY"); > ????????????????if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); > ????????????????t_relay("0x01"); > ????????????????$var(retcode) = $retcode; > ????????????????xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode) LOGHDR"); > ????????????????ifdef(`LOGS', `xlog("L_INFO", "[MESSAGE] Request is leaving server LOGHDR");') > ????????????????exit; > ???} > } > > I have sent to your e-mail (vladpaiu at opensips.org) debug=4 log from moment, when i killed softphone (destination of MESSAGE) without sip unregistering, but with removing tcp/tls connection. > > 06.03.2015, 12:43, "Vlad Paiu" : >> ?Hello, >> >> ?OpenSIPS complains that there is an error when connecting via TCP to >> ?that endpoint. >> ?Now, are you sure you do not have multple branches when relaying that >> ?SIP MESSAGE,out of which only one fails ? In t_relay(), if you have >> ?multiple branches and at least one succceeds, you will get a 1 return code. >> >> ?Please post the complete debug=4 logs for the processing. In the >> ?previous email, you've truncated the logs to the moment OpenSIPS gets >> ?blocked in trying to connect to the endpoint - what happens afterwards ( >> ?after connet timeout ) would also be helpfull. >> >> ?Best Regards, >> >> ?Vlad Paiu >> ?OpenSIPS Developer >> ?http://www.opensips-solutions.com >> >> ?On 06.03.2015 11:06, ?????? ????? wrote: >>> ??do anyone have any idea about how to handle that? >>> >>> ??05.03.2015, 16:22, "?????? ?????" : >>>> ??debug=4 >>>> >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_read_req: We're releasing the connection in state 3 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?releasing con 0x7f2be91663a8, state 0, fd=36, id=1 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?extra_data (nil) >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: SIP Request: >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?method: ? >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_tcp_child: reader response= 7f2be91663a8, 0 from 0 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?uri: ???? >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7f2be91663a8,1), fd_no=38 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?version: >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 232, = ; state=6 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 235, = ; state=17 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via: end of header reached, state=5 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: via found, flags=2 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: this is the first via >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: After parse_msg... >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: preparing to run routing scripts... >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=8000000 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=10 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: to body [#015#012] >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: cseq : <3> >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:maxfwd:is_maxfwd_present: value = 70 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: content_length=3 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: found end of header >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to_param: tag=b2b91161 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=29 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_methods: methods 0x173F >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:uri:has_totag: no totag >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=200 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:find_first_route: No Route headers found >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:loose_route: There is no Route HF >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_nonce: comparing [54f85536be0ae02858c2001d58774c222d958f86] and [54f85536be0ae02858c2001d58774c222d958f86] >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f2bef4e28b0 (tail=139826675195936) MC=0x7f2bef4e2080 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4f5968 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7f2bef4f6368 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6378)[0]=[ha1] >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6388)[1]=[mediaproxy] >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7f2bef4f6a48 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_str2val: converting STRING [659cc07a1ab8ccbbc3b5ec2172bc6473] >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: our result = '06223b730875bf2c01ad98448dd08438' >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: authorization is OK >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4f6368 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing 1 rows >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_row: freeing row values at 0x7f2bef4f6a58 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing rows at 0x7f2bef4f6a48 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_result: freeing result set at 0x7f2bef4f5968 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:comp_scriptvar: str 29 : 83.149.9.184 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_newtran: transaction on entrance=(nil) >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 1 entered >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 0 entered >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:_shm_resize: resize(0) called >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:mk_proxy: doing DNS lookup... >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2000 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:build_req_buf_from_sip_req: id added: <;i=1>, rcv proto=2 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_send: no open tcp connection found, opening new one >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 32768 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 65536 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 131072 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 262144 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting buf has no effect >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 133120 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=133120,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 135168 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=135168,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 137216 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=137216,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 139264 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=139264,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 141312 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=141312,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 143360 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=143360,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 145408 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=145408,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 147456 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=147456,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 149504 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=149504,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 151552 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=151552,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 153600 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=153600,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 155648 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=155648,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 157696 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=157696,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 159744 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=159744,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 161792 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=161792,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 163840 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=163840,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 165888 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=165888,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 167936 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=167936,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 169984 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=169984,verify=262142 >>>> ??Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_ser_child: read response= 7f2be91663a8, 1, fd -1 from 17 (19012) >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4e3aa8 >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f2bef4e3af0 >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4e3af8)[0]=[username] >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_query_avp: no result after query >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_close_query: close avp query >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4e3af0 >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_rows: freeing 0 rows >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_result: freeing result set at 0x7f2bef4e3aa8 >>>> ??Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:destroy_avp_list: destroying list (nil) >>>> ??Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:timer_routine: timer routine:2,tl=0x7f2be9166a20 next=(nil), timeout=36 >>>> ??Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: removing 0x7f2be91669a0 from table >>>> ??Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:delete_cell: delete transaction 0x7f2be91669a0 >>>> ??Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: done >>>> >>>> ??debug=3 with check >>>> >>>> ???????????????????if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); >>>> ???????????????????t_relay("0x01"); >>>> ???????????????????$var(retcode) = $retcode; >>>> ???????????????????xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode)"); >>>> >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [MAIN] Incoming request (MESSAGE) >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:probe_max_sock_buff: using snd buffer of 255 kb >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: poll error: flags 24 - 4 8 16 32 >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR [server=x.x.x.x:65106] (111) Connection refused >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_send: connect failed >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:msg_send: tcp_send failed >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:t_forward_nonack: sending request failed >>>> ??Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [!!!MESSAGE_DEBUG!!!] t_relay returns 1 >>>> >>>> ??05.03.2015, 15:39, "Vlad Paiu" : >>>>> ????Hello, >>>>> >>>>> ????Since TLS doesn't support async in 1.11, you should get an error >>>>> ????straight out of t_relay() >>>>> ????Can you please post the full debug logs here ? >>>>> >>>>> ????Best Regards, >>>>> >>>>> ????Vlad Paiu >>>>> ????OpenSIPS Developer >>>>> ????http://www.opensips-solutions.com >>>>> >>>>> ????On 05.03.2015 13:44, ?????? ????? wrote: >>>>>> ?????Hi all! >>>>>> >>>>>> ?????Can someone help us?. I cannot understand how TLS in opensips 1.11 works. >>>>>> ?????The problem is when we use TLS, i cannot handle connection problems. >>>>>> >>>>>> ?????When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? >>>>>> >>>>>> ?????_______________________________________________ >>>>>> ?????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 From mail at sathees.co.uk Tue Mar 10 11:06:24 2015 From: mail at sathees.co.uk (mahan77) Date: Tue, 10 Mar 2015 03:06:24 -0700 (MST) Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> Message-ID: <1425981984139-7595727.post@n2.nabble.com> Hello Terrance, Thank you for your time to replay back. It was basic dispatcher Config file and posted in the first place. This is my sip trace. interface: eth0 (192.168.1.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) U 192.168.1.64:5060 -> 192.168.1.150:5060 . Gb.."........ ?. U 87.117.75.1:5060 -> 192.168.1.150:5060 INVITE sip:442032912345 at 192.168.1.150:5060 SIP/2.0. Via: SIP/2.0/UDP 87.117.75.1:5060;rport;branch=z9hG4bK9gZ0vUKSc0Q3m. Max-Forwards: 68. From: "07720212345" ;tag=1Z1Z5983N78ZN. To: . Call-ID: fe855718-40e4-1233-4c90-aba651435a79. CSeq: 72611343 INVITE. Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720212345" . . v=0. o=FreeSWITCH 1425866039 1425866040 IN IP4 87.117.75.1. s=FreeSWITCH. c=IN IP4 87.117.75.1. t=0 0. m=audio 28776 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.150:5060 -> 192.168.1.85:5060 INVITE sip:442032912345 at 192.168.1.150:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK9gZ0vUKSc0Q3m. Via: SIP/2.0/UDP 87.117.75.1:5060;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. Max-Forwards: 67. From: "07720212345" ;tag=1Z1Z5983N78ZN. To: . Call-ID: fe855718-40e4-1233-4c90-aba651435a79. CSeq: 72611343 INVITE. Contact: . User-Agent: TelNG GW. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Session-Expires: 1800;refresher=uac. Min-SE: 120. Privacy: none. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 225. X-3C-ACCOUNT: 8166. X-3C-DIRECTION: in. X-FS-Support: update_display,send_info. P-Asserted-Identity: "07720212345" . . v=0. o=FreeSWITCH 1425866039 1425866040 IN IP4 87.117.75.1. s=FreeSWITCH. c=IN IP4 87.117.75.1. t=0 0. m=audio 28776 RTP/AVP 8 0 18 101 13. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 192.168.1.85:5060 -> 192.168.1.150:5060 OPTIONS sip:2001 at 192.168.1.64:5060;ob SIP/2.0. Via: SIP/2.0/UDP 192.168.1.85:5060;branch=z9hG4bK2460f825;rport. Max-Forwards: 70. From: "asterisk" ;tag=as2b561864. To: . Contact: . Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. CSeq: 102 OPTIONS. User-Agent: Asterisk PBX SVN-branch-13-r432059. Date: Mon, 09 Mar 2015 09:53:35 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Content-Length: 0. . U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK9gZ0vUKSc0Q3m;received=192.168.1.150;rport=5060. Via: SIP/2.0/UDP 87.117.75.1:5060;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. From: "07720212345" ;tag=1Z1Z5983N78ZN. To: ;tag=as63edc664. Call-ID: fe855718-40e4-1233-4c90-aba651435a79. CSeq: 72611343 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4c8254d0". Content-Length: 0. . U 192.168.1.150:5060 -> 192.168.1.85:5060 OPTIONS sip:2001 at 192.168.1.64:5060;ob SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK2460f825. Via: SIP/2.0/UDP 192.168.1.85:5060;received=192.168.1.85;branch=z9hG4bK2460f825;rport=5060. Max-Forwards: 69. From: "asterisk" ;tag=as2b561864. To: . Contact: . Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. CSeq: 102 OPTIONS. User-Agent: Asterisk PBX SVN-branch-13-r432059. Date: Mon, 09 Mar 2015 09:53:35 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Content-Length: 0. . U 192.168.1.150:5060 -> 87.117.75.1:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 87.117.75.1:5060;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. From: "07720212345" ;tag=1Z1Z5983N78ZN. To: ;tag=as63edc664. Call-ID: fe855718-40e4-1233-4c90-aba651435a79. CSeq: 72611343 INVITE. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4c8254d0". Content-Length: 0. . U 192.168.1.85:5060 -> 192.168.1.150:5060 SIP/2.0 404 Not Found. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK2460f825;received=192.168.1.150. Via: SIP/2.0/UDP 192.168.1.85:5060;received=192.168.1.85;branch=z9hG4bK2460f825;rport=5060. From: "asterisk" ;tag=as2b561864. To: ;tag=as2ed4c72b. Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. CSeq: 102 OPTIONS. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Accept: application/sdp. Content-Length: 0. . U 192.168.1.150:5060 -> 192.168.1.85:5060 SIP/2.0 404 Not Found. Via: SIP/2.0/UDP 192.168.1.85:5060;received=192.168.1.85;branch=z9hG4bK2460f825;rport=5060. From: "asterisk" ;tag=as2b561864. To: ;tag=as2ed4c72b. Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. CSeq: 102 OPTIONS. Server: Asterisk PBX SVN-branch-13-r432059. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Accept: application/sdp. Content-Length: 0. . U 87.117.75.1:5060 -> 192.168.1.150:5060 ACK sip:442032912345 at 192.168.1.150:5060 SIP/2.0. Via: SIP/2.0/UDP 87.117.75.1:5060;rport;branch=z9hG4bK9gZ0vUKSc0Q3m. Max-Forwards: 68. From: "07720212345" ;tag=1Z1Z5983N78ZN. To: ;tag=as63edc664. Call-ID: fe855718-40e4-1233-4c90-aba651435a79. CSeq: 72611343 ACK. Content-Length: 0. . U 192.168.1.150:5060 -> 192.168.1.85:5060 ACK sip:442032912345 at 192.168.1.150:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK9gZ0vUKSc0Q3m. Via: SIP/2.0/UDP 87.117.75.1:5060;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. Max-Forwards: 67. From: "07720212345" ;tag=1Z1Z5983N78ZN. To: ;tag=as63edc664. Call-ID: fe855718-40e4-1233-4c90-aba651435a79. CSeq: 72611343 ACK. Content-Length: 0. . U 192.168.1.64:5060 -> 192.168.1.150:5060 . ................ many thanks sathees -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/incoming-DID-will-not-pass-to-asterisk-tp7595694p7595727.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From eahaselhoff at gmail.com Tue Mar 10 12:54:01 2015 From: eahaselhoff at gmail.com (Edwin) Date: Tue, 10 Mar 2015 04:54:01 -0700 (MST) Subject: [OpenSIPS-Users] dialog errors Message-ID: <1425988441475-7595730.post@n2.nabble.com> A few times a day I see dialog warnings in my logging: Mar 9 08:00:04 [18379]: WARNING:dialog:w_unset_dlg_profile: cannot get string for value Mar 9 08:00:05 [18385]: WARNING:dialog:w_unset_dlg_profile: cannot get string for value Mar 9 08:00:07 [18391]: WARNING:dialog:w_unset_dlg_profile: cannot get string for value Mar 9 08:05:18 [18374]: WARNING:dialog:w_unset_dlg_profile: cannot get string for value Mar 9 08:05:19 [18391]: WARNING:dialog:w_unset_dlg_profile: cannot get string for value Mar 9 08:05:21 [18390]: WARNING:dialog:w_unset_dlg_profile: cannot get string for value I can not find more information about this errors in the opensips documentation or on the mailing lists. Can anyone give me a hint what could be wrong or where to look? (I can give more info about database or config). -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/dialog-errors-tp7595730.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From varadhan.work at gmail.com Tue Mar 10 13:10:56 2015 From: varadhan.work at gmail.com (Varadhan Work) Date: Tue, 10 Mar 2015 17:40:56 +0530 Subject: [OpenSIPS-Users] Blox SBC Message-ID: Hello, I'm Varadhan, We have come up with an idea to build opensource SBC with opensips as core SIP session route, thanks to opensips and its community. Now we have launched beta version of Blox (www.blox.org) Blox is a Session Border Controller(SBC) used to control VoIP signaling and media streams. SBC is responsible for setting up, conducting, and tearing down calls. SBC allows owners to control the types of call that can be placed through the networks and also overcome some of the problems caused by firewalls and NAT for VoIP calls. A common location for a stand-alone SBC is a connection point, called a border, between a private local area network (LAN) and the Internet. SBC polices real-time voice traffic between IP network borders ensuring your private network is robustly secure and fully manageable. You can download and install Blox via www.blox.org, please post your valuable feedback. Thanks & Regards, Varadhan M -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamid2kviii at hotmail.com Tue Mar 10 13:43:15 2015 From: hamid2kviii at hotmail.com (Hamid Hashmi) Date: Tue, 10 Mar 2015 17:43:15 +0500 Subject: [OpenSIPS-Users] How to remove/update dialog Message-ID: route[sip]{... t_on_failure("1"); $DLG_timeout = 120; create_dialog("B"); t_relay();} failure_route[1]{... if(t_check_status("some reasson")){ route(pstn); }...} route[pstn]{... t_on_failure("2"); $DLG_timeout = 60; create_dialog("B"); t_relay();} How to remove previous dialog from table "dialog" ? OR is there any method to update the timeout value in dialog without calling create_dialog("B") ? RegardsHamid R. Hashmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 10 15:03:38 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 10 Mar 2015 10:03:38 -0400 Subject: [OpenSIPS-Users] Blox SBC In-Reply-To: References: Message-ID: Hello, Just visited your site and say that you can only download the .iso. Do you make the full source available? ? Terrance -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenberg11219 at gmail.com Tue Mar 10 15:53:52 2015 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Tue, 10 Mar 2015 16:53:52 +0200 Subject: [OpenSIPS-Users] Problem with placing call on hold Message-ID: I have a OpenSIPS server that acts as a load balancing server for a couple of asterisk servers, and lately I'm having a issue with asterisk responding with a 488 Not acceptable here for hold requests when it comes to port 5060 on the Opensips server, but if I send it to another port it works fine, I realized that when using port 5060 the sdp has port 0 ie (m=audio 0 RTP/AVP 0 8 101.) but when using another port it does have a port number (ie m=audio 16422 RTP/AVP 0 8 101.) Im attaching both traces, I changed ips for security 212.212.212.212. is the opensips server, 212.212.212.213 is the asterisk server, and 91.176.221.245 is the end user. Can anyone please help me make this work on port 5060 too, and can you please explain why it would act differently, the NAT is also handeled differently as can be seen in the VIA header (maybe router is trying to use some ALG?) Here is the trace using port 5060 U 91.176.221.245:49242 -> 212.212.212.212:5060 INVITE sip:19174250000 at 212.212.212.213:5060;nat=yes SIP/2.0. Via: SIP/2.0/UDP 91.176.221.245:32781;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 70. Route: . Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f468a5000180cd88bd6cead37ab9d1920cc4c54a0ecdd3",uri="sip:19174250000 at 212.212. 212.213:5060",algorithm=MD5,response="0a5a118e2b318621f32b5d60b600229c". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 226. Content-Type: application/sdp. . v=0. o=- 33523926 33523927 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 0 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.212:5060 -> 91.176.221.245:49242 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 91.176.221.245:32781 ;received=91.176.221.245;rport=49242;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Server: OpenSIPS (1.7.2-notls (x86_64/linux)). Content-Length: 0. . U 212.212.212.212:5060 -> 212.212.212.213:5060 INVITE sip:19174250000 at 212.212.212.213:5060 SIP/2.0. Record-Route: . Via: SIP/2.0/UDP 212.212.212.212;branch=z9hG4bKe66e.0702ec92.0. Via: SIP/2.0/UDP 91.176.221.245:32781 ;rport=49242;received=91.176.221.245;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 69. Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f468a5000180cd88bd6cead37ab9d1920cc4c54a0ecdd3",uri="sip:19174250000 at 212.212. 212.213:5060",algorithm=MD5,response="0a5a118e2b318621f32b5d60b600229c". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 226. Content-Type: application/sdp. . v=0. o=- 33523926 33523927 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 0 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.213:5060 -> 212.212.212.212:5060 SIP/2.0 488 Not acceptable here. Via: SIP/2.0/UDP 212.212.212.212;branch=z9hG4bKe66e.0702ec92.0;received=212.212.212.212;rport=5060. Via: SIP/2.0/UDP 91.176.221.245:32781 ;rport=49242;received=91.176.221.245;branch=z9hG4bK-a6635dda. From: "EXT 101" ;tag=3189bbd5cf53a984o0. To: ;tag=as7f636018. Call-ID: f8a392e9-f1139d80 at 192.168.0.101. CSeq: 103 INVITE. Server: SIP Server 9.21/CS. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH. Supported: replaces, timer. X-Asterisk-HangupCause: Normal Clearing. X-Asterisk-HangupCauseCode: 16. Content-Length: 0. . here is the trace using port 5744 U 91.176.221.245:63719 -> 212.212.212.212:5744 INVITE sip:19174250000 at 212.212.212.213:5060;nat=yes SIP/2.0. Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-6f0161f0. From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 70. Route: . Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f46d7a0000081272baa39f9e34a0ee81f471dec7b034ba",uri=" sip:19174250000 at 212.212.212.213:5060 ",algorithm=MD5,response="4096f485853bf6a209424c36dac2342b". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 224. Content-Type: application/sdp. . v=0. o=- 30981 30982 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 16422 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.212:5744 -> 91.176.221.245:63719 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.0.101:5060 ;received=91.176.221.245;rport=63719;branch=z9hG4bK-6f0161f0. From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Server: OpenSIPS (1.7.2-notls (x86_64/linux)). Content-Length: 0. . U 212.212.212.212:5744 -> 212.212.212.213:5060 INVITE sip:19174250000 at 212.212.212.213:5060 SIP/2.0. Record-Route: . Via: SIP/2.0/UDP 212.212.212.212:5744;branch=z9hG4bKa7d5.c5b6d177.0. Via: SIP/2.0/UDP 192.168.0.101:5060 ;rport=63719;received=91.176.221.245;branch=z9hG4bK-6f0161f0. From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Max-Forwards: 69. Proxy-Authorization: Digest username="WindowP1",realm="myserver",nonce="54f46d7a0000081272baa39f9e34a0ee81f471dec7b034ba",uri=" sip:19174250000 at 212.212.212.213:5060 ",algorithm=MD5,response="4096f485853bf6a209424c36dac2342b". Contact: "EXT 101" . Expires: 30. User-Agent: Cisco/SPA525G2-7.5.6. Content-Length: 224. Content-Type: application/sdp. . v=0. o=- 30981 30982 IN IP4 192.168.0.101. s=-. c=IN IP4 0.0.0.0. t=0 0. m=audio 16422 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendonly. U 212.212.212.213:5060 -> 212.212.212.212:5744 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 212.212.212.212:5744 ;branch=z9hG4bKa7d5.c5b6d177.0;received=212.212.212.212;rport=5744. Via: SIP/2.0/UDP 192.168.0.101:5060 ;rport=63719;received=91.176.221.245;branch=z9hG4bK-6f0161f0. Record-Route: . From: "EXT 101" ;tag=f8c2b14a55549ac2o0. To: ;tag=as1fcb82f4. Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. CSeq: 103 INVITE. Server: SIP Server 9.21/CS. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Contact: . Content-Length: 0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenberg11219 at gmail.com Tue Mar 10 15:54:29 2015 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Tue, 10 Mar 2015 16:54:29 +0200 Subject: [OpenSIPS-Users] Call transfer problem In-Reply-To: References: Message-ID: Sorry I meant to place call on hold, not transfer On Mon, Mar 9, 2015 at 8:40 PM, Schneur Rosenberg wrote: > I have a OpenSIPS server that acts as a load balancing server for a couple > of asterisk servers, and lately I'm having a issue with asterisk responding > with a 488 Not acceptable here for transfer requests when it comes to port > 5060 on the Opensips server, but if I send it to another port it works > fine, I realized that when using port 5060 the sdp has port 0 ie (m=audio > 0 RTP/AVP 0 8 101.) but when using another port it does have a port number > (ie m=audio 16422 RTP/AVP 0 8 101.) > > Im attaching both traces, I changed ips for security 212.212.212.212. is > the opensips server, 212.212.212.213 is the asterisk server, > and 91.176.221.245 is the end user. > > Can anyone please help me make this work on port 5060 too, and can you > please explain why it would act differently, the NAT is also handeled > differently as can be seen in the VIA header (maybe router is trying to use > some ALG?) > > Here is the trace using port 5060 > > U 91.176.221.245:49242 -> 212.212.212.212:5060 > INVITE sip:19174250000 at 212.212.212.213:5060;nat=yes SIP/2.0. > Via: SIP/2.0/UDP 91.176.221.245:32781;branch=z9hG4bK-a6635dda. > From: "EXT 101" ;tag=3189bbd5cf53a984o0. > To: ;tag=as7f636018. > Call-ID: f8a392e9-f1139d80 at 192.168.0.101. > CSeq: 103 INVITE. > Max-Forwards: 70. > Route: ;lr;ftag=3189bbd5cf53a984o0;did=d97.6c4d2422>. > Proxy-Authorization: Digest > > > username="WindowP1",realm="myserver",nonce="54f468a5000180cd88bd6cead37ab9d1920cc4c54a0ecdd3",uri="sip:19174250000 at 212.212. > > 212.213:5060",algorithm=MD5,response="0a5a118e2b318621f32b5d60b600229c". > Contact: "EXT 101" . > Expires: 30. > User-Agent: Cisco/SPA525G2-7.5.6. > Content-Length: 226. > Content-Type: application/sdp. > . > v=0. > o=- 33523926 33523927 IN IP4 192.168.0.101. > s=-. > c=IN IP4 0.0.0.0. > t=0 0. > m=audio 0 RTP/AVP 0 8 101. > a=rtpmap:0 PCMU/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > a=ptime:30. > a=sendonly. > > U 212.212.212.212:5060 -> 91.176.221.245:49242 > SIP/2.0 100 Giving a try. > Via: SIP/2.0/UDP 91.176.221.245:32781 > ;received=91.176.221.245;rport=49242;branch=z9hG4bK-a6635dda. > From: "EXT 101" ;tag=3189bbd5cf53a984o0. > To: ;tag=as7f636018. > Call-ID: f8a392e9-f1139d80 at 192.168.0.101. > CSeq: 103 INVITE. > Server: OpenSIPS (1.7.2-notls (x86_64/linux)). > Content-Length: 0. > . > > U 212.212.212.212:5060 -> 212.212.212.213:5060 > INVITE sip:19174250000 at 212.212.212.213:5060 SIP/2.0. > Record-Route: . > Via: SIP/2.0/UDP 212.212.212.212;branch=z9hG4bKe66e.0702ec92.0. > Via: SIP/2.0/UDP 91.176.221.245:32781 > ;rport=49242;received=91.176.221.245;branch=z9hG4bK-a6635dda. > From: "EXT 101" ;tag=3189bbd5cf53a984o0. > To: ;tag=as7f636018. > Call-ID: f8a392e9-f1139d80 at 192.168.0.101. > CSeq: 103 INVITE. > Max-Forwards: 69. > Proxy-Authorization: Digest > > > username="WindowP1",realm="myserver",nonce="54f468a5000180cd88bd6cead37ab9d1920cc4c54a0ecdd3",uri="sip:19174250000 at 212.212. > > 212.213:5060",algorithm=MD5,response="0a5a118e2b318621f32b5d60b600229c". > Contact: "EXT 101" . > Expires: 30. > User-Agent: Cisco/SPA525G2-7.5.6. > Content-Length: 226. > Content-Type: application/sdp. > . > v=0. > o=- 33523926 33523927 IN IP4 192.168.0.101. > s=-. > c=IN IP4 0.0.0.0. > t=0 0. > m=audio 0 RTP/AVP 0 8 101. > a=rtpmap:0 PCMU/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > a=ptime:30. > a=sendonly. > > U 212.212.212.213:5060 -> 212.212.212.212:5060 > SIP/2.0 488 Not acceptable here. > Via: SIP/2.0/UDP > 212.212.212.212;branch=z9hG4bKe66e.0702ec92.0;received=212.212.212.212;rport=5060. > Via: SIP/2.0/UDP 91.176.221.245:32781 > ;rport=49242;received=91.176.221.245;branch=z9hG4bK-a6635dda. > From: "EXT 101" ;tag=3189bbd5cf53a984o0. > To: ;tag=as7f636018. > Call-ID: f8a392e9-f1139d80 at 192.168.0.101. > CSeq: 103 INVITE. > Server: SIP Server 9.21/CS. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH. > Supported: replaces, timer. > X-Asterisk-HangupCause: Normal Clearing. > X-Asterisk-HangupCauseCode: 16. > Content-Length: 0. > . > here is the trace using port 5744 > U 91.176.221.245:63719 -> 212.212.212.212:5744 > INVITE sip:19174250000 at 212.212.212.213:5060;nat=yes SIP/2.0. > Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-6f0161f0. > From: "EXT 101" ;tag=f8c2b14a55549ac2o0. > To: ;tag=as1fcb82f4. > Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. > CSeq: 103 INVITE. > Max-Forwards: 70. > Route: ;lr;ftag=f8c2b14a55549ac2o0;did=9ae.775cc5c5>. > Proxy-Authorization: Digest > username="WindowP1",realm="myserver",nonce="54f46d7a0000081272baa39f9e34a0ee81f471dec7b034ba",uri=" > sip:19174250000 at 212.212.212.213:5060 > ",algorithm=MD5,response="4096f485853bf6a209424c36dac2342b". > Contact: "EXT 101" . > Expires: 30. > User-Agent: Cisco/SPA525G2-7.5.6. > Content-Length: 224. > Content-Type: application/sdp. > . > v=0. > o=- 30981 30982 IN IP4 192.168.0.101. > s=-. > c=IN IP4 0.0.0.0. > t=0 0. > m=audio 16422 RTP/AVP 0 8 101. > a=rtpmap:0 PCMU/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > a=ptime:30. > a=sendonly. > > U 212.212.212.212:5744 -> 91.176.221.245:63719 > SIP/2.0 100 Giving a try. > Via: SIP/2.0/UDP 192.168.0.101:5060 > ;received=91.176.221.245;rport=63719;branch=z9hG4bK-6f0161f0. > From: "EXT 101" ;tag=f8c2b14a55549ac2o0. > To: ;tag=as1fcb82f4. > Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. > CSeq: 103 INVITE. > Server: OpenSIPS (1.7.2-notls (x86_64/linux)). > Content-Length: 0. > . > > > U 212.212.212.212:5744 -> 212.212.212.213:5060 > INVITE sip:19174250000 at 212.212.212.213:5060 SIP/2.0. > Record-Route: . > Via: SIP/2.0/UDP 212.212.212.212:5744;branch=z9hG4bKa7d5.c5b6d177.0. > Via: SIP/2.0/UDP 192.168.0.101:5060 > ;rport=63719;received=91.176.221.245;branch=z9hG4bK-6f0161f0. > From: "EXT 101" ;tag=f8c2b14a55549ac2o0. > To: ;tag=as1fcb82f4. > Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. > CSeq: 103 INVITE. > Max-Forwards: 69. > Proxy-Authorization: Digest > username="WindowP1",realm="myserver",nonce="54f46d7a0000081272baa39f9e34a0ee81f471dec7b034ba",uri=" > sip:19174250000 at 212.212.212.213:5060 > ",algorithm=MD5,response="4096f485853bf6a209424c36dac2342b". > Contact: "EXT 101" . > Expires: 30. > User-Agent: Cisco/SPA525G2-7.5.6. > Content-Length: 224. > Content-Type: application/sdp. > . > v=0. > o=- 30981 30982 IN IP4 192.168.0.101. > s=-. > c=IN IP4 0.0.0.0. > t=0 0. > m=audio 16422 RTP/AVP 0 8 101. > a=rtpmap:0 PCMU/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > a=ptime:30. > a=sendonly. > > U 212.212.212.213:5060 -> 212.212.212.212:5744 > SIP/2.0 100 Trying. > Via: SIP/2.0/UDP 212.212.212.212:5744 > ;branch=z9hG4bKa7d5.c5b6d177.0;received=212.212.212.212;rport=5744. > Via: SIP/2.0/UDP 192.168.0.101:5060 > ;rport=63719;received=91.176.221.245;branch=z9hG4bK-6f0161f0. > Record-Route: . > From: "EXT 101" ;tag=f8c2b14a55549ac2o0. > To: ;tag=as1fcb82f4. > Call-ID: 5832b9ea-a4a32aa2 at 192.168.0.101. > CSeq: 103 INVITE. > Server: SIP Server 9.21/CS. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE. > Supported: replaces, timer. > Contact: . > Content-Length: 0. > . > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 10 17:12:02 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 10 Mar 2015 12:12:02 -0400 Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: <1425981984139-7595727.post@n2.nabble.com> References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> <1425981984139-7595727.post@n2.nabble.com> Message-ID: On Tue, Mar 10, 2015 at 6:06 AM, mahan77 wrote: > Hello Terrance, > > Thank you for your time to replay back. > It was basic dispatcher Config file and posted in the first place. > > This is my sip trace. > > interface: eth0 (192.168.1.0/255.255.255.0) > filter: (ip or ip6) and ( port 5060 ) > > U 192.168.1.64:5060 -> 192.168.1.150:5060 > . > Gb.."........ > ?. > > U 87.117.75.1:5060 -> 192.168.1.150:5060 > INVITE sip:442032912345 at 192.168.1.150:5060 SIP/2.0. > Via: SIP/2.0/UDP 87.117.75.1:5060;rport;branch=z9hG4bK9gZ0vUKSc0Q3m. > Max-Forwards: 68. > From: "07720212345" ;tag=1Z1Z5983N78ZN. > To: . > Call-ID: fe855718-40e4-1233-4c90-aba651435a79. > CSeq: 72611343 INVITE. > Contact: . > User-Agent: TelNG GW. > Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, > REFER, NOTIFY, PUBLISH, SUBSCRIBE. > Supported: timer, precondition, path, replaces. > Allow-Events: talk, hold, conference, presence, dialog, line-seize, > call-info, sla, include-session-description, presence.winfo, > message-summary, refer. > Session-Expires: 1800;refresher=uac. > Min-SE: 120. > Privacy: none. > Content-Type: application/sdp. > Content-Disposition: session. > Content-Length: 225. > X-3C-ACCOUNT: 8166. > X-3C-DIRECTION: in. > X-FS-Support: update_display,send_info. > P-Asserted-Identity: "07720212345" . > . > v=0. > o=FreeSWITCH 1425866039 1425866040 IN IP4 87.117.75.1. > s=FreeSWITCH. > c=IN IP4 87.117.75.1. > t=0 0. > m=audio 28776 RTP/AVP 8 0 18 101 13. > a=fmtp:18 annexb=no. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-16. > a=ptime:20. > > > U 192.168.1.150:5060 -> 192.168.1.85:5060 > INVITE sip:442032912345 at 192.168.1.150:5060 SIP/2.0. > Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK9gZ0vUKSc0Q3m. > Via: SIP/2.0/UDP > 87.117.75.1:5060 > ;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. > Max-Forwards: 67. > From: "07720212345" ;tag=1Z1Z5983N78ZN. > To: . > Call-ID: fe855718-40e4-1233-4c90-aba651435a79. > CSeq: 72611343 INVITE. > Contact: . > User-Agent: TelNG GW. > Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, > REFER, NOTIFY, PUBLISH, SUBSCRIBE. > Supported: timer, precondition, path, replaces. > Allow-Events: talk, hold, conference, presence, dialog, line-seize, > call-info, sla, include-session-description, presence.winfo, > message-summary, refer. > Session-Expires: 1800;refresher=uac. > Min-SE: 120. > Privacy: none. > Content-Type: application/sdp. > Content-Disposition: session. > Content-Length: 225. > X-3C-ACCOUNT: 8166. > X-3C-DIRECTION: in. > X-FS-Support: update_display,send_info. > P-Asserted-Identity: "07720212345" . > . > v=0. > o=FreeSWITCH 1425866039 1425866040 IN IP4 87.117.75.1. > s=FreeSWITCH. > c=IN IP4 87.117.75.1. > t=0 0. > m=audio 28776 RTP/AVP 8 0 18 101 13. > a=fmtp:18 annexb=no. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-16. > a=ptime:20. > > > U 192.168.1.85:5060 -> 192.168.1.150:5060 > OPTIONS sip:2001 at 192.168.1.64:5060;ob SIP/2.0. > Via: SIP/2.0/UDP 192.168.1.85:5060;branch=z9hG4bK2460f825;rport. > Max-Forwards: 70. > From: "asterisk" ;tag=as2b561864. > To: . > Contact: . > Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. > CSeq: 102 OPTIONS. > User-Agent: Asterisk PBX SVN-branch-13-r432059. > Date: Mon, 09 Mar 2015 09:53:35 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE. > Supported: replaces, timer. > Content-Length: 0. > . > > > U 192.168.1.85:5060 -> 192.168.1.150:5060 > SIP/2.0 401 Unauthorized. > Via: SIP/2.0/UDP > 192.168.1.150:5060 > ;branch=z9hG4bK9gZ0vUKSc0Q3m;received=192.168.1.150;rport=5060. > Via: SIP/2.0/UDP > 87.117.75.1:5060 > ;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. > From: "07720212345" ;tag=1Z1Z5983N78ZN. > To: ;tag=as63edc664. > Call-ID: fe855718-40e4-1233-4c90-aba651435a79. > CSeq: 72611343 INVITE. > Server: Asterisk PBX SVN-branch-13-r432059. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE. > Supported: replaces, timer. > WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4c8254d0". > Content-Length: 0. > . > > > U 192.168.1.150:5060 -> 192.168.1.85:5060 > OPTIONS sip:2001 at 192.168.1.64:5060;ob SIP/2.0. > Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK2460f825. > Via: SIP/2.0/UDP > 192.168.1.85:5060;received=192.168.1.85;branch=z9hG4bK2460f825;rport=5060. > Max-Forwards: 69. > From: "asterisk" ;tag=as2b561864. > To: . > Contact: . > Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. > CSeq: 102 OPTIONS. > User-Agent: Asterisk PBX SVN-branch-13-r432059. > Date: Mon, 09 Mar 2015 09:53:35 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE. > Supported: replaces, timer. > Content-Length: 0. > . > > > U 192.168.1.150:5060 -> 87.117.75.1:5060 > SIP/2.0 401 Unauthorized. > Via: SIP/2.0/UDP > 87.117.75.1:5060 > ;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. > From: "07720212345" ;tag=1Z1Z5983N78ZN. > To: ;tag=as63edc664. > Call-ID: fe855718-40e4-1233-4c90-aba651435a79. > CSeq: 72611343 INVITE. > Server: Asterisk PBX SVN-branch-13-r432059. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE. > Supported: replaces, timer. > WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4c8254d0". > Content-Length: 0. > . > > > U 192.168.1.85:5060 -> 192.168.1.150:5060 > SIP/2.0 404 Not Found. > Via: SIP/2.0/UDP > 192.168.1.150:5060;branch=z9hG4bK2460f825;received=192.168.1.150. > Via: SIP/2.0/UDP > 192.168.1.85:5060;received=192.168.1.85;branch=z9hG4bK2460f825;rport=5060. > From: "asterisk" ;tag=as2b561864. > To: ;tag=as2ed4c72b. > Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. > CSeq: 102 OPTIONS. > Server: Asterisk PBX SVN-branch-13-r432059. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE. > Supported: replaces, timer. > Accept: application/sdp. > Content-Length: 0. > . > > > U 192.168.1.150:5060 -> 192.168.1.85:5060 > SIP/2.0 404 Not Found. > Via: SIP/2.0/UDP > 192.168.1.85:5060;received=192.168.1.85;branch=z9hG4bK2460f825;rport=5060. > From: "asterisk" ;tag=as2b561864. > To: ;tag=as2ed4c72b. > Call-ID: 6432c1a87201b6d9051df2e71c82e6a7 at 192.168.1.85:5060. > CSeq: 102 OPTIONS. > Server: Asterisk PBX SVN-branch-13-r432059. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE. > Supported: replaces, timer. > Accept: application/sdp. > Content-Length: 0. > . > > > U 87.117.75.1:5060 -> 192.168.1.150:5060 > ACK sip:442032912345 at 192.168.1.150:5060 SIP/2.0. > Via: SIP/2.0/UDP 87.117.75.1:5060;rport;branch=z9hG4bK9gZ0vUKSc0Q3m. > Max-Forwards: 68. > From: "07720212345" ;tag=1Z1Z5983N78ZN. > To: ;tag=as63edc664. > Call-ID: fe855718-40e4-1233-4c90-aba651435a79. > CSeq: 72611343 ACK. > Content-Length: 0. > . > > > U 192.168.1.150:5060 -> 192.168.1.85:5060 > ACK sip:442032912345 at 192.168.1.150:5060 SIP/2.0. > Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK9gZ0vUKSc0Q3m. > Via: SIP/2.0/UDP > 87.117.75.1:5060 > ;received=87.117.75.1;rport=5060;branch=z9hG4bK9gZ0vUKSc0Q3m. > Max-Forwards: 67. > From: "07720212345" ;tag=1Z1Z5983N78ZN. > To: ;tag=as63edc664. > Call-ID: fe855718-40e4-1233-4c90-aba651435a79. > CSeq: 72611343 ACK. > Content-Length: 0. > . > > > U 192.168.1.64:5060 -> 192.168.1.150:5060 > . > ................ > > > many thanks > sathees > > > > > > > > -- > View this message in context: > http://opensips-open-sip-server.1449251.n2.nabble.com/incoming-DID-will-not-pass-to-asterisk-tp7595694p7595727.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 > This is your whole config? route{ if ( !mf_process_maxfwd_header("10") ) { sl_send_reply("483","To Many Hops"); drop(); } ds_select_dst("1", "0"); forward(); #t_relay(); } Terrance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Tue Mar 10 17:12:10 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 10 Mar 2015 12:12:10 -0400 Subject: [OpenSIPS-Users] ERROR:siptrace:pipport2su: bad protocol Message-ID: I am configuring siptrace with homer server and getting following error, ERROR:siptrace:pipport2su: bad protocol ERROR:siptrace:pipport2su: bad protocol ERROR:siptrace:pipport2su: bad protocol Razvan fix following patch but still getting above error in log https://github.com/OpenSIPS/opensips/commit/178b0cc26b05a81947de150fe1c2df36d600ccaa Am i missing something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Tue Mar 10 17:42:27 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 10 Mar 2015 12:42:27 -0400 Subject: [OpenSIPS-Users] ERROR:siptrace:pipport2su: bad protocol In-Reply-To: References: Message-ID: I set debug=6 and here is the logs most of time error pop'ed up near "tm" module DBG:tm:run_trans_callbacks: trans=0x7f9570f06710, callback type 1024, id 1 entered DBG:siptrace:trace_onreq_out: trace on req out DBG:core:parse_headers: flags=40 DBG:siptrace:trace_msg_out: trace msg out ERROR:siptrace:pipport2su: bad protocol On Tue, Mar 10, 2015 at 12:12 PM, Satish Patel wrote: > I am configuring siptrace with homer server and getting following error, > > ERROR:siptrace:pipport2su: bad protocol > ERROR:siptrace:pipport2su: bad protocol > ERROR:siptrace:pipport2su: bad protocol > > Razvan fix following patch but still getting above error in log > https://github.com/OpenSIPS/opensips/commit/178b0cc26b05a81947de150fe1c2df36d600ccaa > > Am i missing something? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sathees.co.uk Tue Mar 10 18:38:49 2015 From: mail at sathees.co.uk (mahan77) Date: Tue, 10 Mar 2015 10:38:49 -0700 (MST) Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> <1425981984139-7595727.post@n2.nabble.com> Message-ID: <1426009129676-7595760.post@n2.nabble.com> Hello Terrance.Yes it?s the basics scripts.I?m trying to setup OpenSIPS as a proxy to asterisk via dispatcher modules. First part I will able to register sippers on asterisk via dispatcher modules. I?m trying work my way up. This is my second part of the test; send incoming calls to asterisk IVR. If you have any working dispatcher scripts can you post or mail me. It will help me to understand more.Many thanks.Sathees -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/incoming-DID-will-not-pass-to-asterisk-tp7595694p7595760.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 10 18:57:32 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 10 Mar 2015 13:57:32 -0400 Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: <1426009129676-7595760.post@n2.nabble.com> References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> <1425981984139-7595727.post@n2.nabble.com> <1426009129676-7595760.post@n2.nabble.com> Message-ID: Hello Mahan, My suggestion would be to do a lot more research: i) http://www.opensips.org/Documentation/Tutorials-OpenSIPSAsteriskIntegration ii) http://www.voip-sip.org/wp-content/uploads/2011/08/Building-Telephony-Systems-with-OpenSIPS-1.6.pdf Take a few weeks and get to know opensips and build up your config to do what you require from it as a proxy. Without more work on your part, I really can't offer any help myself. Maybe others on here can. If this is too hard a task for you. you can possibly seek an individual/company that can offer consulting work for your company. Terrance ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 10 21:29:08 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 10 Mar 2015 16:29:08 -0400 Subject: [OpenSIPS-Users] Safe Place/Method to Fix Contact In-Reply-To: <54FD5322.5030207@opensips.org> References: <54FD5322.5030207@opensips.org> Message-ID: Hello R?zvan, Thank you for your response. I think I am making a mess of this. Maybe if I explain what I am trying to accomplish. Please consider the following: U 2015/03/10 15:31:47.591498 25.21.74.12:5060 -> 192.168.2.5:5060 INVITE sip:9187321212 at 74.75.31.22 SIP/2.0. Contact: . U 2015/03/10 15:31:47.598538 192.168.2.5:5060 -> 192.168.2.10:5060 INVITE sip:9187321212 at 192.168.2.10:5060 SIP/2.0. Contact: . U 2015/03/10 15:31:47.857774 192.168.2.10:5060 -> 192.168.2.5:5060 SIP/2.0 100 Trying. Contact: . U 2015/03/10 15:31:47.858765 192.168.2.10:5060 -> 192.168.2.5:5060 SIP/2.0 200 OK. Contact: . U 2015/03/10 15:31:47.903559 192.168.2.5:5060 -> 25.21.74.12:5060 SIP/2.0 200 OK. Contact: . U 2015/03/10 15:31:47.945974 25.21.74.12:5060 -> 192.168.2.5:5060 ACK sip:192.168.2.20:5060 SIP/2.0. Contact: . U 2015/03/10 15:31:48.204696 192.168.2.5:5060 -> 192.168.2.10:5060 ACK sip:9187321212 at 192.168.2.10:5060 SIP/2.0. Contact: . U 2015/03/10 15:32:31.488749 25.21.74.12:5060 -> 192.168.2.5:5060 BYE sip:192.168.2.20:5060 SIP/2.0. Contact: . U 2015/03/10 15:32:31.658439 192.168.2.5:5060 -> 192.168.2.10:5060 BYE sip:9187321212 at 192.168.2.10:5060 SIP/2.0. Contact: . ? 25,21.74.12 Underline Carrier 192.168.2.5 Opensips 192.168.2.10 Gateway The contacts that I am attempting to do is modify is: Message Two: Original: Contact: . Modified: Contact: . Message Five: Original: Contact: . Modified: Contact: . Message Seven: Original: Contact: . Modified: Contact: . Message Nine: Original: Contact: . Modified: Contact: . When I attempt to making such modifications, I am receiving errors such as: Failed to match the sequential request to a known dialog Attempt to route with preloaded Route's What are the requirements to shape the Contact header to point to the right IP and still maintain the preloaded route. Kind Regards, Terrance -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sathees.co.uk Tue Mar 10 22:07:12 2015 From: mail at sathees.co.uk (mahan77) Date: Tue, 10 Mar 2015 14:07:12 -0700 (MST) Subject: [OpenSIPS-Users] Can somebody explain of this error? Message-ID: <1426021632213-7595766.post@n2.nabble.com> Hello,Can somebody explain of this error?DBG:core:get_hdr_field: [38]; uri=[sip:442032912345 at ddns.domain.com] DBG:core:get_hdr_field: to body []Many thanks Sathees -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Can-somebody-explain-of-this-error-tp7595766.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sathees.co.uk Tue Mar 10 22:08:04 2015 From: mail at sathees.co.uk (mahan77) Date: Tue, 10 Mar 2015 14:08:04 -0700 (MST) Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> <1425981984139-7595727.post@n2.nabble.com> <1426009129676-7595760.post@n2.nabble.com> Message-ID: <1426021684333-7595767.post@n2.nabble.com> Thank youi Will look into -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/incoming-DID-will-not-pass-to-asterisk-tp7595694p7595767.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 10 22:43:44 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 10 Mar 2015 17:43:44 -0400 Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: <1426021684333-7595767.post@n2.nabble.com> References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> <1425981984139-7595727.post@n2.nabble.com> <1426009129676-7595760.post@n2.nabble.com> <1426021684333-7595767.post@n2.nabble.com> Message-ID: The OpenSIPS project owners offer some excellent consulting solutions that will save you a lot of time. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sathees.co.uk Tue Mar 10 23:02:05 2015 From: mail at sathees.co.uk (mahan77) Date: Tue, 10 Mar 2015 15:02:05 -0700 (MST) Subject: [OpenSIPS-Users] incoming DID will not pass to asterisk In-Reply-To: References: <1425896033806-7595694.post@n2.nabble.com> <1425941490713-7595723.post@n2.nabble.com> <1425981984139-7595727.post@n2.nabble.com> <1426009129676-7595760.post@n2.nabble.com> <1426021684333-7595767.post@n2.nabble.com> Message-ID: <1426024925288-7595772.post@n2.nabble.com> Hello again,I love to learn. That?s why I?m trying myself. Thank you againsathees -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/incoming-DID-will-not-pass-to-asterisk-tp7595694p7595772.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpyle at fidelityvoice.com Wed Mar 11 01:20:53 2015 From: jpyle at fidelityvoice.com (Jeff Pyle) Date: Tue, 10 Mar 2015 20:20:53 -0400 Subject: [OpenSIPS-Users] Can somebody explain of this error? In-Reply-To: <1426021632213-7595766.post@n2.nabble.com> References: <1426021632213-7595766.post@n2.nabble.com> Message-ID: Sathees, That's not an error, just a debug statement. (Notice the DBG in DBG:core:get_hdr_field.) If you don't want to see those, set the debug= value lower in opensips.cfg. I believe 3 is a normal running value. 2 is even less verbose. - Jeff On Tue, Mar 10, 2015 at 5:07 PM, mahan77 wrote: > Hello, Can somebody explain of this error? DBG:core:get_hdr_field: [38]; > uri=[sip:442032912345 at ddns.domain.com] DBG:core:get_hdr_field: to body [< > sip:442032912345 at ddns.domain.com>] Many thanks Sathees > ------------------------------ > View this message in context: Can somebody explain of this error? > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Wed Mar 11 04:41:35 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 10 Mar 2015 23:41:35 -0400 Subject: [OpenSIPS-Users] set_advertised_address in on_reply Message-ID: Hello Everyone, When trying to change the record_route using set_advertised_address in the on_reply route there is no change. I am testing using some test headers and know that the location is getting triggered however, cannot change the RR using set_advertised_address. Is this possible? Kind Regards, Terrance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From varadhan.work at gmail.com Wed Mar 11 04:47:05 2015 From: varadhan.work at gmail.com (Varadhan Work) Date: Wed, 11 Mar 2015 09:17:05 +0530 Subject: [OpenSIPS-Users] Blox SBC In-Reply-To: References: Message-ID: Source code https://github.com/blox-org On Tue, Mar 10, 2015 at 5:40 PM, Varadhan Work wrote: > Hello, > > I'm Varadhan, > > We have come up with an idea to build opensource SBC with opensips as core > SIP session route, thanks to opensips and its community. > > Now we have launched beta version of Blox (www.blox.org) > > Blox is a Session Border Controller(SBC) used to control VoIP signaling > and media streams. SBC is responsible for setting up, conducting, and > tearing down calls. SBC allows owners to control the types of call that can > be placed through the networks and also overcome some of the problems > caused by firewalls and NAT for VoIP calls. A common location for a > stand-alone SBC is a connection point, called a border, between a private > local area network (LAN) and the Internet. SBC polices real-time voice > traffic between IP network borders ensuring your private network is > robustly secure and fully manageable. > You can download and install Blox via www.blox.org, please post your > valuable feedback. > > Thanks & Regards, > Varadhan M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.pinassi at unisi.it Wed Mar 11 09:33:27 2015 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Wed, 11 Mar 2015 09:33:27 +0100 Subject: [OpenSIPS-Users] Sad and frustrated: PRESENCE not working Message-ID: <54FFFDD7.1080808@unisi.it> Hi all, my fight to have Presence and BLF working continue. Here's a "step by step" trace when, on my phone with account 5002, i enabled a BLF for account 5008. I use OpenSIPS 1.11.3-tls. First, the phone send SUBSCRIBE packet: *SUBSCRIBE sip:presence at voip.unisi.it:5060 SIP/2.0 * Via: SIP/2.0/UDP 172.20.1.10:37508;branch=z9hG4bK-h30k6rwp6oy5;rport From: ;tag=pkntk9npjh To: ;tag=f315b2d58ae8829149b784764c5a40e3-2387 Call-ID: 54b1fe548d09-v32qemyjagpv CSeq: 3 SUBSCRIBE Max-Forwards: 70 Contact: ;reg-id=1 Event: dialog Accept: application/dialog-info+xml User-Agent: snom760/8.7.3.25.9 Expires: 3600 Content-Length: 0 *SIP/2.0 200 OK * Via: SIP/2.0/UDP 172.20.1.10:37508;received=172.20.1.10;branch=z9hG4bK-h30k6rwp6oy5;rport=37508 From: ;tag=pkntk9npjh To: ;tag=f315b2d58ae8829149b784764c5a40e3-2387 Call-ID: 54b1fe548d09-v32qemyjagpv CSeq: 3 SUBSCRIBE Expires: 3600 Contact: Server: OpenSIPS (1.11.3-tls (i386/linux)) Content-Length: 0 Afterward, i get a NOTIFY with the state of the phone: *NOTIFY sip:5002 at 172.20.1.10:37508 SIP/2.0 * Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bK4e24.38cd2ef4.0 To: ;tag=pkntk9npjh From: ;tag=f315b2d58ae8829149b784764c5a40e3-2387 CSeq: 2 NOTIFY Call-ID: 54b1fe548d09-v32qemyjagpv Max-Forwards: 70 Content-Length: 147 User-Agent: OpenSIPS (1.11.3-tls (i386/linux)) Event: dialog Contact: Subscription-State: active;expires=3600 Content-Type: application/dialog-info+xml *SIP/2.0 200 Ok * Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bK4e24.38cd2ef4.0 From: ;tag=f315b2d58ae8829149b784764c5a40e3-2387 To: ;tag=pkntk9npjh Call-ID: 54b1fe548d09-v32qemyjagpv CSeq: 2 NOTIFY Content-Length: 0 At this point i expect a NOTIFY packet when 5008 was busy but none. Of course i have a row on active_watchers table. My config for PRESENCE and PUA is: #### PRESENCE modules loadmodule "presence.so" loadmodule "presence_mwi.so" loadmodule "presence_callinfo.so" loadmodule "presence_xml.so" loadmodule "presence_dialoginfo.so" modparam("presence", "server_address", "sip:presence at voip.unisi.it:5060") modparam("presence", "notify_offline_body", 1) modparam("presence", "fallback2db", 1) modparam("presence", "clean_period", 30) modparam("presence", "mix_dialog_presence", 1) modparam("presence_xml","force_active",1) #### PUA module loadmodule "pua.so" loadmodule "pua_dialoginfo.so" loadmodule "pua_usrloc.so" modparam("pua_dialoginfo", "presence_server", "sip:presence at voip.unisi.it:5060") modparam("pua_dialoginfo", "include_callid", 1) modparam("pua_dialoginfo", "include_tags", 1) modparam("pua_dialoginfo", "include_localremote", 1) modparam("pua_dialoginfo", "publish_on_trying", 1) modparam("pua_usrloc", "default_domain", "voip.unisi.it") and on main() route logic i have: ### PRESENCE if(is_method("PUBLISH|SUBSCRIBE")) { route(handle_presence); } [....] # Presence route route[handle_presence] { xlog("L_INFO","Route PRESENCE on $rm [$fd/$fu/$rd/$ru/$si/]\n"); if(!t_newtran()){ sl_reply_error(); exit; } if (is_method("PUBLISH")) { if($hdr(Sender)!= NULL) handle_publish("$hdr(Sender)"); else handle_publish(); } if (is_method("SUBSCRIBE")) { if(search("^Event: message-summary")) { # if there is no R-URI username, grab From URI if(!uri=~"sip:.+@") { # add From username as R-URI username avp_pushto("$ruri/username","$fU"); } # fix some broken subscriptions if(!search("^Accept: application/simple-message-summary")) { append_hf("Accept: application/simple-message-summary\r\n"); } setdsturi("sip:172.20.1.5:5060"); t_relay(); } else { handle_subscribe(); } } exit; } Just for info, the MWI (using Asterisk) works perfectly... Any suggestions ? Hints ? Thanks, Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)5000 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From bogdan at opensips.org Wed Mar 11 14:10:48 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 11 Mar 2015 15:10:48 +0200 Subject: [OpenSIPS-Users] First OpenSIPS Summit 2105 is here Message-ID: <55003ED8.2050507@opensips.org> Hi all, I'm really excited to announce the first OpenSIPS Summit for 2015 : 12th - 13th of May 2015, Amsterdam NL This event is a premiere as: * it is the first Summit taking place on the old continent (aka Europe :)) * it is the first 2-days event * it hosts an OpenSIPS Social Event on 12th evening The star of this Summit is OpenSIPS 2.1 (this is to be released on 18th of March), introducing to the participants, via presentations and workshops, all the great additions we have in 2.1 - webRTC, async queries, SIP compression, fraud detection and many others. Of course, the Summit is not only about 2.1, but also about tools, platform or engines which are OpenSIPS interconnected (like billing, interfaces and others) We are heavily working on setting the final schedule (topics and presenters) and we are open to anyone willing to give a presentation on any OpenSIPS topic ( see the call for papers http://www.opensips.org/Community/Summit-2015Amsterdam#toc6 ). We already have an awesome set of speakers from various and interesting companies/institutes across Europe ;) The Social Event is to be held on the 12th of May in the evening, it is open to anyone (not related to the Summit registration). If you want to meet and see faces behind nicks/emails, to share a beer (or an Amsterdam coffee :D), to shake hands and have a good time, simply drop an email. The Summit registration is already available (space is not infinite, first come, first served): http://www.opensips.org/Community/Summit-2015Amsterdam#toc7 http://www.opensips.org/Community/Summit-Registration I'm really looking forward to see a lot of people in Amsterdam, especially all those people who could not make it to the Summits in US ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com From ter.devor at gmail.com Wed Mar 11 16:29:31 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Wed, 11 Mar 2015 11:29:31 -0400 Subject: [OpenSIPS-Users] Blox SBC In-Reply-To: References: Message-ID: Hello Vardhan, Seems very interesting at first look. Are you one of the developers of the project? Also, can it be run in a NAT environment as a bridge (ie, WAN<--------------->192.168.2.5<---------->WAN) Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Wed Mar 11 17:41:41 2015 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 11 Mar 2015 12:41:41 -0400 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] First OpenSIPS Summit 2105 is here In-Reply-To: <55003ED8.2050507@opensips.org> References: <55003ED8.2050507@opensips.org> Message-ID: >> The star of this Summit is OpenSIPS 2.1 (this is to be released on 18th of March), Great!, Are we going to release stable version of 2.1? On Wed, Mar 11, 2015 at 9:10 AM, Bogdan-Andrei Iancu wrote: > Hi all, > > I'm really excited to announce the first OpenSIPS Summit for 2015 : > 12th - 13th of May 2015, Amsterdam NL > > This event is a premiere as: > * it is the first Summit taking place on the old continent (aka Europe > :)) > * it is the first 2-days event > * it hosts an OpenSIPS Social Event on 12th evening > > The star of this Summit is OpenSIPS 2.1 (this is to be released on 18th of > March), introducing to the participants, via presentations and workshops, > all the great additions we have in 2.1 - webRTC, async queries, SIP > compression, fraud detection and many others. > Of course, the Summit is not only about 2.1, but also about tools, > platform or engines which are OpenSIPS interconnected (like billing, > interfaces and others) > > We are heavily working on setting the final schedule (topics and > presenters) and we are open to anyone willing to give a presentation on any > OpenSIPS topic ( see the call for papers http://www.opensips.org/ > Community/Summit-2015Amsterdam#toc6 ). > We already have an awesome set of speakers from various and interesting > companies/institutes across Europe ;) > > The Social Event is to be held on the 12th of May in the evening, it is > open to anyone (not related to the Summit registration). If you want to > meet and see faces behind nicks/emails, to share a beer (or an Amsterdam > coffee :D), to shake hands and have a good time, simply drop an email. > > The Summit registration is already available (space is not infinite, first > come, first served): > http://www.opensips.org/Community/Summit-2015Amsterdam#toc7 > http://www.opensips.org/Community/Summit-Registration > > > I'm really looking forward to see a lot of people in Amsterdam, especially > all those people who could not make it to the Summits in US ! > > Best regards, > > -- > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > _______________________________________________ > Devel mailing list > Devel at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varadhan.work at gmail.com Wed Mar 11 17:51:17 2015 From: varadhan.work at gmail.com (Varadhan Work) Date: Wed, 11 Mar 2015 22:21:17 +0530 Subject: [OpenSIPS-Users] Blox SBC In-Reply-To: References: Message-ID: Hello Terrance, Thanks, Yes I'm the core developer of blox, Kindly check blox forum for Q&A Your questions are much appreciated. Thanks & regards, Varadhan M On Wednesday, March 11, 2015, Terrance Devor wrote: > Hello Vardhan, > > Seems very interesting at first look. Are you one of the developers of the > project? > Also, can it be run in a NAT environment as a bridge (ie, > WAN<--------------->192.168.2.5<---------->WAN) > > Terrance. > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladpaiu at opensips.org Wed Mar 11 18:13:59 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Wed, 11 Mar 2015 19:13:59 +0200 Subject: [OpenSIPS-Users] [NEW] Topology Hiding Module Message-ID: <550077D7.9080702@opensips.org> Hello, I am happy to announce the new topology_hiding module. Topology hiding is usually utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network. The new topology_hiding module strips and restores the headers that contain topology information (Via, Record-Route, Route and Contact headers) , and optionally it can also change the Call-ID of the requests. Compared to the topology hiding solution offered by the B2B modules, it has the great advantage that it can be used together with other script functionalities that were previously incompatible ( eg. dialog vars & profiles, accounting, etc.). Compared to the previous solution of topology hiding which was integrated into the dialog module ( which only supported topology hiding for INVITE based dialogs ), the new module can work in stand-alone mode as well ( without dialog support ), thus allowing to do topology hiding for all types of dialogs ( eg. Presence dialogs ) and also for standalone initial requests ( eg. SIP MESSAGE ). Find the module readme at [1] and a tutorial with a script example at [2]. Testing and feedback are very much welcome. [1] http://www.opensips.org/html/docs/modules/2.1.x/topology_hiding.html [2] http://www.opensips.org/Documentation/Tutorials-Topology-Hiding Best Regards, -- Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com From bogdan at opensips.org Wed Mar 11 18:28:27 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 11 Mar 2015 19:28:27 +0200 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] First OpenSIPS Summit 2105 is here In-Reply-To: References: <55003ED8.2050507@opensips.org> Message-ID: <55007B3B.1020705@opensips.org> Hi Satish, OpenSIPS 2.1 is to be released as beta on 18th of March and in 1.5 months max it will move to stable stage. So, by the time of the Summit, 2.1 will be released as stable :) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11.03.2015 18:41, Satish Patel wrote: > >> The star of this Summit is OpenSIPS 2.1 (this is to be released on > 18th of March), > > Great!, Are we going to release stable version of 2.1? > > > > On Wed, Mar 11, 2015 at 9:10 AM, Bogdan-Andrei Iancu > > wrote: > > Hi all, > > I'm really excited to announce the first OpenSIPS Summit for 2015 : > 12th - 13th of May 2015, Amsterdam NL > > This event is a premiere as: > * it is the first Summit taking place on the old continent > (aka Europe :)) > * it is the first 2-days event > * it hosts an OpenSIPS Social Event on 12th evening > > The star of this Summit is OpenSIPS 2.1 (this is to be released on > 18th of March), introducing to the participants, via presentations > and workshops, all the great additions we have in 2.1 - webRTC, > async queries, SIP compression, fraud detection and many others. > Of course, the Summit is not only about 2.1, but also about tools, > platform or engines which are OpenSIPS interconnected (like > billing, interfaces and others) > > We are heavily working on setting the final schedule (topics and > presenters) and we are open to anyone willing to give a > presentation on any OpenSIPS topic ( see the call for papers > http://www.opensips.org/Community/Summit-2015Amsterdam#toc6 ). > We already have an awesome set of speakers from various and > interesting companies/institutes across Europe ;) > > The Social Event is to be held on the 12th of May in the evening, > it is open to anyone (not related to the Summit registration). If > you want to meet and see faces behind nicks/emails, to share a > beer (or an Amsterdam coffee :D), to shake hands and have a good > time, simply drop an email. > > The Summit registration is already available (space is not > infinite, first come, first served): > http://www.opensips.org/Community/Summit-2015Amsterdam#toc7 > http://www.opensips.org/Community/Summit-Registration > > > I'm really looking forward to see a lot of people in Amsterdam, > especially all those people who could not make it to the Summits > in US ! > > Best regards, > > -- > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > _______________________________________________ > Devel mailing list > Devel at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel > > > > > _______________________________________________ > Devel mailing list > Devel at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sathees.co.uk Wed Mar 11 22:21:00 2015 From: mail at sathees.co.uk (mahan77) Date: Wed, 11 Mar 2015 14:21:00 -0700 (MST) Subject: [OpenSIPS-Users] Can somebody explain of this error? In-Reply-To: References: <1426021632213-7595766.post@n2.nabble.com> Message-ID: <1426108860847-7595796.post@n2.nabble.com> thank you -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Can-somebody-explain-of-this-error-tp7595766p7595796.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres.moya.i at gmail.com Wed Mar 11 23:58:41 2015 From: andres.moya.i at gmail.com (Andres Moya) Date: Wed, 11 Mar 2015 22:58:41 -0000 Subject: [OpenSIPS-Users] need help with radius authentication Message-ID: <9B8D7AB327D64D94A444B09C81238B72@samsung> Hello, First time on the list. Was able to solve problem by documentation before, but now completely confused. I am trying to learn authentication against radius server. [root at rad47 /]# rpm -qa | grep opensips opensips-aaa_radius-1.11.3-1.el6.x86_64 opensips-yum-releases-1.11-1.el6.noarch opensips-auth_aaa-1.11.3-1.el6.x86_64 opensips-1.11.3-1.el6.x86_64 Added in config file: loadmodule "auth.so" loadmodule "auth_aaa.so" loadmodule "aaa_radius.so" modparam("auth_aaa", "aaa_url", "radius:/etc/radiusclient-ng/radiusclient.conf") Created route from some examples and calling it from main route: route[AUTH] { if (is_method("REGISTER") || from_uri==myself) { # authenticate requests if (!aaa_www_authorize("172.21.7.47")) { www_challenge("$fd", "0"); exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) consume_credentials(); } # if caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (from_uri!=myself && uri!=myself) { sl_send_reply("403","Not relaying"); exit; } return; } [root at rad47 /]# cat /etc/radiusclient-ng/radiusclient.conf | grep -v ^# auth_order radius,local login_tries 4 login_timeout 60 nologin /etc/nologin issue /etc/radiusclient-ng/issue authserver 127.0.0.1:1812 acctserver 127.0.0.1:1813 servers /etc/radiusclient-ng/servers dictionary /etc/radiusclient-ng/dictionary login_radius /usr/sbin/login.radius seqfile /etc/opensips/radius.seq mapfile /etc/radiusclient-ng/port-id-map default_realm radius_timeout 10 radius_retries 3 bindaddr * login_local /bin/login Then i run opensips it initialize ok. Then i try to register it challenge me ok. But there is no request done to RADIUS over network, and client keep sending REGISTER in response 401 Unauthorized. There is nothing in logs. I?ve run out of ideas. Please someone help. Regards Andres -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank21118 at yahoo.com Thu Mar 12 02:02:03 2015 From: frank21118 at yahoo.com (bluerain) Date: Wed, 11 Mar 2015 18:02:03 -0700 (MST) Subject: [OpenSIPS-Users] xmlrpc call to standby Opensips Message-ID: <1426122123514-7595798.post@n2.nabble.com> I have 2 opensips setup as HA. The opensips have 2 interface, one public and one private. The public is the "floating IP" between the 2 HA pair opensip. I've learn to use the following python call to enable or disable a node on load balancer remotely: opensips = xmlrpclib.ServerProxy('http://192.168.1.1:8000/RPC2') print opensips.lb_status(21,0); The issue with the above is that I have to use the "live" opensips. If the swap happens, the above line is useless. But then if I put both IP in the script: opensips = xmlrpclib.ServerProxy('http://192.168.1.1:8000/RPC2') print opensips.lb_status(21,0); opensips = xmlrpclib.ServerProxy('http://192.168.1.2:8000/RPC2') print opensips.lb_status(21,0); When I execute the script, it seems it just "hang" there because it try to setup a connection to the "stand by" opensips where it is not running. But when I try to do the public IP opensips = xmlrpclib.ServerProxy('http://99.66.66.66:8000/RPC2') print opensips.lb_status(21,0); It seems not working because I guess it is only listening on the private side? Thus: 1. Is there a time-out thing I can set so that I can point the both private IP of the opensips and that if it send the xmlrpc call to the "standby" opensips, it will just timeout in 1 second. 2. If the above is no way, then is there way I can make oepnsip listen on public side for xmlrpc call? Although I don't like it, even though I have firewall in front which only allow 5060. Thank you! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/xmlrpc-call-to-standby-Opensips-tp7595798.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From osas at voipembedded.com Thu Mar 12 05:04:04 2015 From: osas at voipembedded.com (Ovidiu Sas) Date: Thu, 12 Mar 2015 00:04:04 -0400 Subject: [OpenSIPS-Users] xmlrpc call to standby Opensips In-Reply-To: <1426122123514-7595798.post@n2.nabble.com> References: <1426122123514-7595798.post@n2.nabble.com> Message-ID: Use two floating IPs: one for the public interface and one for the private interface. In your script, use the private floating IP. Regards, Ovidiu Sas On Wed, Mar 11, 2015 at 9:02 PM, bluerain wrote: > I have 2 opensips setup as HA. The opensips have 2 interface, one public and > one private. The public is the "floating IP" between the 2 HA pair opensip. > > I've learn to use the following python call to enable or disable a node on > load balancer remotely: > > opensips = xmlrpclib.ServerProxy('http://192.168.1.1:8000/RPC2') > print opensips.lb_status(21,0); > > The issue with the above is that I have to use the "live" opensips. If the > swap happens, the above line is useless. But then if I put both IP in the > script: > > opensips = xmlrpclib.ServerProxy('http://192.168.1.1:8000/RPC2') > print opensips.lb_status(21,0); > opensips = xmlrpclib.ServerProxy('http://192.168.1.2:8000/RPC2') > print opensips.lb_status(21,0); > > When I execute the script, it seems it just "hang" there because it try to > setup a connection to the "stand by" opensips where it is not running. > > But when I try to do the public IP > > opensips = xmlrpclib.ServerProxy('http://99.66.66.66:8000/RPC2') > print opensips.lb_status(21,0); > > It seems not working because I guess it is only listening on the private > side? > > Thus: > > 1. Is there a time-out thing I can set so that I can point the both private > IP of the opensips and that if it send the xmlrpc call to the "standby" > opensips, it will just timeout in 1 second. > > 2. If the above is no way, then is there way I can make oepnsip listen on > public side for xmlrpc call? Although I don't like it, even though I have > firewall in front which only allow 5060. > > Thank you! > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/xmlrpc-call-to-standby-Opensips-tp7595798.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 -- VoIP Embedded, Inc. http://www.voipembedded.com From acmicrox at gmail.com Thu Mar 12 08:37:56 2015 From: acmicrox at gmail.com (microx) Date: Thu, 12 Mar 2015 00:37:56 -0700 (MST) Subject: [OpenSIPS-Users] OpenSIPS scalability with TLS connections. Message-ID: <1426145876185-7595800.post@n2.nabble.com> Dear all, OpenSIPS can achieve extremely high performance according to the tests provided by the official site. However, it seems that the results were based on UDP. I am trying to use OpenSIPS to set up a scalable SIP server which aims to support tens of thousands SIP clients using TLS. Such a large number of SIP clients would send REGISTER requests in different time slots, but each SIP client keeps its TLS connection alive. Due to my own limitation, I can establish about 2000 TLS connections between SIP clients and OpenSIPS server. I am curious that has anyone employed OpenSIPS to build a scalable SIP server with so many lasting TLS connections (e.g., 50000 TLS connections)? Any comment is greatly appreciated. Best wishes, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-scalability-with-TLS-connections-tp7595800.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogdan at opensips.org Thu Mar 12 16:24:34 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 12 Mar 2015 17:24:34 +0200 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: <412370C2-D775-420C-8E2A-704D3A12BD01@gmail.com> References: <54EC8943.2070308@opensips.org> <4fda8f6d562934872688560256868ff7@voip-demos.com> <412370C2-D775-420C-8E2A-704D3A12BD01@gmail.com> Message-ID: <5501AFB2.7080608@opensips.org> Fixed ! Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.03.2015 02:28, Satish Patel wrote: > Bogdan, > > I am running 2.1.x and so far great, I had issue with sipteace with homer which I already reported. So please look into it before release. > > -- > Sent from my iPhone > >> On Mar 8, 2015, at 7:02 PM, Terrance Devor wrote: >> >> Good news, >> >> What is rtpengine support. Will the proxy manage RTP directly? Or will >> we still have to use RTP/Media Proxy >> >> >> Terrance >> ? >> _______________________________________________ >> 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 bogdan at opensips.org Thu Mar 12 16:25:20 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 12 Mar 2015 17:25:20 +0200 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: References: <54EC8943.2070308@opensips.org> <4fda8f6d562934872688560256868ff7@voip-demos.com> Message-ID: <5501AFE0.6040100@opensips.org> Hi Terrance, RTPengine is an alternative to MediaProxy or RTPproxy. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.03.2015 01:02, Terrance Devor wrote: > Good news, > > What is rtpengine support. Will the proxy manage RTP directly? Or will > we still have to use RTP/Media Proxy > > > Terrance > ? > > > _______________________________________________ > 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 Mar 12 16:26:08 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 12 Mar 2015 17:26:08 +0200 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: <54EC8943.2070308@opensips.org> References: <54EC8943.2070308@opensips.org> Message-ID: <5501B010.2000507@opensips.org> The D day for releasing 2.1 is 18th of March ! Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 24.02.2015 16:22, Bogdan-Andrei Iancu wrote: > Hello all, > > Everybody is looking forward for the next OpenSIPS release, the major > 2.1, which is planned for end of February - at least this was the plan > so far. > I our desire to make of 2.1 a radical improvement, we committed to > several major changes/redesigns and new valuable functionalities. And > they do burn time to get them done, especially as we want them : in > the best possible way. > > In oder to finish all we committed for, the release date is now > estimated for first half of March - some important parts of code still > need to be settled down and we do not want to make any kind of > compromise in quality. > > Just to give you a heads up on what OpenSIPS 2.1 will bring: > - internal re-design around async reactors for load-balancing > tasks inside OpenSIPS > - async I/O support in scripts for db queries, exec, rest client > - refactoring of the networking and protocol related code (protos > are now modules) > - webSockets support > - Quality Based Routing new module > - Compression new module > - Fraud Detection new module > - Emergency Call handling new module > - rtpengine support > - partitioning support in Dynamic Routing, Diaplan and Dispatcher > > and many other - when the coding taks is done, we will proceed withe > "bothersome" task of updating docs, new and migration. > > Whoever gives a try to 2.1 version, please report any problems or > crashes asap to us ! better have them done now rather than later :P > > Best regards, > From campusvtv at gmail.com Thu Mar 12 16:31:15 2015 From: campusvtv at gmail.com (campusvtv) Date: Thu, 12 Mar 2015 10:31:15 -0500 Subject: [OpenSIPS-Users] PUA_USRLOC Message-ID: <5501B143.4040506@gmail.com> Hello, maybe I don't understood completely how pua_usrloc module work. I'm trying using this module without success. I understood I have to put the pua_set_publish function on the REGISTER block, like: if (is_method("REGISTER")) { pua_set_publish(); Only when the user is registered and his registration is present on the location table, OpenSIPs generate a PUBLISH SIP MESSAGE that save on the presentity table?; so if another user subscribe for status of this user, he see the user online. I'm trying with X-Lite and 3CX without success. I think en both case, the problem is here: Mar 12 10:28:06 li926-75 /sbin/opensips[24300]: DBG:pua:publ_cback_func: Record not found Any hint? Regards From David.Crow at vc3.com Mon Mar 2 15:46:34 2015 From: David.Crow at vc3.com (David Crow) Date: Mon, 2 Mar 2015 14:46:34 +0000 Subject: [OpenSIPS-Users] Changing Address of Opensips Server In-Reply-To: <54F0C351.4020004@opensips.org> References: <3C131E7252D2744FB12C4269037C8763011FEA962A@VC3-CAE-EXCH-01.vc3.com> <3C131E7252D2744FB12C4269037C8763011FEB07B9@VC3-CAE-EXCH-01.vc3.com> <54F0C351.4020004@opensips.org> Message-ID: <3C131E7252D2744FB12C4269037C8763011FED9C43@VC3-CAE-EXCH-01.vc3.com> I have 0 in as the port, I've also tried putting 5060 to see if that makes a difference. -David From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Friday, February 27, 2015 2:20 PM To: OpenSIPS users mailling list; David Crow Subject: Re: [OpenSIPS-Users] Changing Address of Opensips Server Hi David, Are you sure it is not a port issue ? maybe the src port does not match the port your have in the address table. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 26.02.2015 15:38, David Crow wrote: I've done some more troubleshooting on this and it doesn't appear to have anything to do with the NAT. The issue seems to be related to one host sending calls to Opensips. From all other hosts it works fine, but this one host doesn't work at all. I've double checked the ip address, port, etc. I"ve also tried removing the address from the table and adding it back, still nothing. Very strange. -David From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of David Crow Sent: Tuesday, February 24, 2015 5:10 PM To: 'users at lists.opensips.org' Subject: [OpenSIPS-Users] Changing Address of Opensips Server I'm moving our one of our opensips server to a new datacenter with new ip addresses and I'm running into an issue. It seems to be failing to find the group properly based on the 503 message I'm getting back. $avp(s:group) = get_source_group(); # Reject if no group found for this call if ($avp(s:group) == -1) { sl_send_reply("503","Service Unavailable - NOPERM"); exit; } This server is behind a firewall doing NAT and I've changed all references in the opensips.cfg to the new external address. Opensipsctl address dump shows the address table and the server that's sending the calls from properly. I'm not really sure where to look next, I'm pretty green when it comes to opensips. I only have to tinker with it when I change something like this. Any assistance would be greatly appreciated. David Crow | Senior Systems Architect 1301 Gervais Street, Suite 1800 | Columbia, SC 29201 (d) 803.978.2727 | (f) 803.733.5888 david.crow at vc3.com| www.VC3.com Follow us: [Description: Description: Description: Description: Description: cid:image002.png at 01CC30E6.8E093080] [Description: Description: Description: Description: Description: cid:image004.png at 01CC30E6.8E093080] [cid:image003.jpg at 01CE41C2.E8635D50] [cid:image004.png at 01D054CD.C48A6F20] _______________________________________________ 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: image001.png Type: image/png Size: 1198 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1325 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 6800 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 24150 bytes Desc: image004.png URL: From uzcudunl at yahoo.it Tue Mar 3 00:21:46 2015 From: uzcudunl at yahoo.it (leo) Date: Mon, 2 Mar 2015 16:21:46 -0700 (MST) Subject: [OpenSIPS-Users] OpenSIPS and Apple Push Notification In-Reply-To: <53970570.5080102@opensips.org> References: <1402325945452-7591783.post@n2.nabble.com> <1402376798211-7591786.post@n2.nabble.com> <53970570.5080102@opensips.org> Message-ID: <1425338506602-7595564.post@n2.nabble.com> Hello Bogdan, Wow!!! It took me so much to understand this... hahaha I just need the last help: - considering that the UAC has an unlimited expiry (so the lookup will return 1) - my actual configuration is trying to send the INVITE to the contact in the DB but it will timeout (because the UAC is not connected anymore but it has unlimited expiry). - after this time out i should send the PN and wait for the UAC to re-register and then establish a new INVITE with this new info. Could you give me a couple of ideas on how to implement this? Thanks a lot! Leo -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-and-Apple-Push-Notification-tp7591783p7595564.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From john.morris at thetmcteam.com Wed Mar 4 22:57:10 2015 From: john.morris at thetmcteam.com (John Morris) Date: Wed, 4 Mar 2015 16:57:10 -0500 Subject: [OpenSIPS-Users] Opensips-CP Message-ID: To whom it may concern, I am looking to implement the Opensips-cp system on top of our current Opensips servers/dbs. Do you offer a consulting contract to help guide us through this to help prevent us from having downtime? If so what is the cost and how long would it take? Can we schedule a call to discuss? Thank you, John From achalkov at ya.ru Fri Mar 6 12:02:39 2015 From: achalkov at ya.ru (=?koi8-r?B?/sHMy8/XIOHS1KPN?=) Date: Fri, 06 Mar 2015 14:02:39 +0300 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: <54F97699.9070802@opensips.org> References: <272051425555896@web6j.yandex.ru> <54F84E58.4080706@opensips.org> <768261425561731@web7o.yandex.ru> <2539131425632764@web1m.yandex.ru> <54F97699.9070802@opensips.org> Message-ID: <3182941425639759@web13m.yandex.ru> Yes, i sure. I have only 1 branch because i have only one instance to receive sent MESSAGE and i dont add branches manually. Actually, that is all MESSAGE routing: ... if (is_method("MESSAGE")) route(MESSAGE); ... route[MESSAGE] { ... if (!lookup("location")) { ... } else { t_on_reply("ON_REPLY"); if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); t_relay("0x01"); $var(retcode) = $retcode; xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode) LOGHDR"); ifdef(`LOGS', `xlog("L_INFO", "[MESSAGE] Request is leaving server LOGHDR");') exit; } } and that is debug=4 log from moment, when i killed softphone (destination of MESSAGE) without sip unregistering, but with removing tcp/tls connection: Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6695]: DBG:stun:receive: Sending: from [9 x.x.x.x 3631] to [y.y.y.y 50693] Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6695]: DBG:stun:receive: #012#012 Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6695]: DBG:stun:freeStunMsg: freeing Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6695]: DBG:stun:freeStunMsg: freeing Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6695]: DBG:stun:stun_loop: READING Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6713]: DBG:tm:timer_routine: timer routine:2,tl=0x7ff79cd256b0 next=(nil), timeout=12 Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6713]: DBG:tm:wait_handler: removing 0x7ff79cd25630 from table Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6713]: DBG:tm:delete_cell: delete transaction 0x7ff79cd25630 Mar 6 13:40:57 cs17792 /usr/sbin/opensips[6713]: DBG:tm:wait_handler: done Mar 6 13:41:02 cs17792 /usr/sbin/opensips[6698]: DBG:core:udp_rcv_loop: probing packet received len = 2 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcpconn_ev: data available on 0x7ff79cd2c578 53 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_del: io_watch_del op on index -1 53 (0x77dd80, 53, -1, 0x0,0x1) fd_no=40 called Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:send2child: to tcp child 0 0(6717), 0x7ff79cd2c578 rw 1 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:handle_io: We have received conn 0x7ff79cd2c578 with rw 1 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_add: io_watch_add op on 36 (0x77dee0, 36, 2, 0x7ff79cd2c578,1), fd_no=1 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: Using the global ( per process ) buff Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:tls_update_fd: New fd is 36 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: ERROR:core:_tls_read: SYSCALL error -> (104) Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: ERROR:core:_tls_read: TLS connection to y.y.y.y:58858 read failed Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: ERROR:core:_tls_read: TLS read error: 5 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: read= -1 bytes, parsed=0, state=0, error=1 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: last char=0x00, parsed msg=#012 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: ERROR:core:tcp_read_req: failed to read Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x3) fd_no=2 called Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: releasing con 0x7ff79cd2c578, state -2, fd=36, id=2 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: extra_data 0x7ff79cd2c6f8 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcp_child: reader response= 7ff79cd2c578, -2 from 0 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:tcpconn_destroy: destroying connection 0x7ff79cd2c578, flags 0002 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:tls_close: closing TLS connection Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:tls_update_fd: New fd is 53 Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: ERROR:core:tls_shutdown: something wrong in SSL: Mar 6 13:41:03 cs17792 /usr/sbin/opensips[6734]: DBG:core:tls_tcpconn_clean: entered Mar 6 13:41:05 cs17792 /usr/sbin/opensips[6705]: DBG:msilo:m_clean_silo: cleaning stored messages - 20 Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7ff7a39ac9c8 Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7ff7a39aca10 Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7ff7a39aca18)[0]=[username] Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_query_avp: no result after query Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_close_query: close avp query Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_columns: freeing result columns at 0x7ff7a39aca10 Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_rows: freeing 0 rows Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_result: freeing result set at 0x7ff7a39ac9c8 Mar 6 13:41:07 cs17792 /usr/sbin/opensips[6715]: DBG:core:destroy_avp_list: destroying list (nil) Mar 6 13:41:10 cs17792 /usr/sbin/opensips[6696]: DBG:core:udp_rcv_loop: probing packet received len = 2 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcpconn_ev: data available on 0x7ff79cd21908 52 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_del: io_watch_del op on index -1 52 (0x77dd80, 52, -1, 0x0,0x1) fd_no=39 called Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:send2child: to tcp child 0 0(6717), 0x7ff79cd21908 rw 1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:handle_io: We have received conn 0x7ff79cd21908 with rw 1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_add: io_watch_add op on 36 (0x77dee0, 36, 2, 0x7ff79cd21908,1), fd_no=1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: Using the global ( per process ) buff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: read= 573 bytes, parsed=573, state=4, error=1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: last char=0x33, parsed msg=#012MESSAGE sip:achalkov1 at x.x.x.x:3631;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP y.y.y.y:59137;branch=z9hG4bK-d8754z-b937eb7870cff11c-1---d8754z-;rport#015#012Max-Forwards: 70#015#012To: #015#012From: "achalkov";tag=64746f23#015#012Call-ID: NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI.#015#012CSeq: 2 MESSAGE#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012Content-Type: text/plain#015#012User-Agent: Zoiper r21367#015#012Allow-Events: presence, kpml#015#012Content-Length: 3#015#012#015#012123 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: content-length= 3 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: We're releasing the connection in state 3 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: releasing con 0x7ff79cd21908, state 0, fd=36, id=1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: extra_data (nil) Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: SIP Request: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: method: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: uri: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: version: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=2 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via_param: found param type 232, = ; state=6 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via_param: found param type 235, = ; state=17 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via: end of header reached, state=5 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: via found, flags=2 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: this is the first via Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: After parse_msg... Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: preparing to run routing scripts... Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi: no destination URI Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=10 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: end of header reached, state=10 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: to body [#015#012] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to_param: tag=64746f23 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: end of header reached, state=29 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi_attr: no destination URI Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=40 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: cseq : <2> Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: content_length=3 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: found end of header Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_contact_body: no contact header! Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: [MAIN] Incoming request (M=MESSAGE IP=tcp:y.y.y.y:59141 fromIP=tcp:y.y.y.y:59141 RURI=sip:achalkov1 at x.x.x.x:3631;transport=TCP DURI= F=sip:achalkov at x.x.x.x:3631;transport=TCP T=sip:achalkov1 at x.x.x.x:3631;transport=TCP oP=TCP dP= rP=TCP ID=NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI. ct= cseq=2 UA=Zoiper r21367)#012MESSAGE sip:achalkov1 at x.x.x.x:3631;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP y.y.y.y:59137;branch=z9hG4bK-d8754z-b937eb7870cff11c-1---d8754z-;rport#015#012Max-Forwards: 70#015#012To: #015#012From: "achalkov";tag=64746f23#015#012Call-ID: NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI.#015#012CSeq: 2 MESSAGE#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012Content-Type: text/plain#015#012User-Agent: Zoiper r21367#015#012Allow-Events: presence, kpml#015#012Content-Length: 3#015#012#015#012123 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:maxfwd:is_maxfwd_present: value = 70 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_methods: methods 0x173F Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:uri:has_totag: no totag Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=78 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: start searching: hash=43604, isACK=0 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:matching_3261: RFC3261 transaction matching failed Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: no transaction found Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcp_child: reader response= 7ff79cd21908, 0 from 0 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7ff79cd21908,1), fd_no=38 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=200 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:rr:find_first_route: No Route headers found Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:rr:loose_route: There is no Route HF Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=4000 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:auth:pre_auth: credentials with given realm not found Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi: no destination URI Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi_attr: no destination URI Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_contact_body: no contact header! Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: [AUTH] Result: no credentials (M=MESSAGE IP=tcp:y.y.y.y:59141 fromIP=tcp:y.y.y.y:59141 RURI=sip:achalkov1 at x.x.x.x:3631;transport=TCP DURI= F=sip:achalkov at x.x.x.x:3631;transport=TCP T=sip:achalkov1 at x.x.x.x:3631;transport=TCP oP=TCP dP= rP=TCP ID=NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI. ct= cseq=2 UA=Zoiper r21367) Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:auth:build_auth_hf: 'WWW-Authenticate: Digest realm="x.x.x.x", nonce="54f9845e8218cc613726d1518e7e7f6b1f64cf1e", qop="auth"#015#012' Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: tcp connection found (0x7ff79cd21908), acquiring fd Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: c= 0x7ff79cd21908, n=16 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_ser_child: read response= 7ff79cd21908, 1, fd -1 from 17 (6717) Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: after receive_fd: c= 0x7ff79cd21908 n=8 fd=36 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: sending... Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:async_tsend_stream: Async succesful write from first try on 0x7ff79cd21908 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: after write: c= 0x7ff79cd21908 n=548 fd=36 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: buf=#012SIP/2.0 401 Unauthorized#015#012Via: SIP/2.0/TCP y.y.y.y:59137;received=y.y.y.y;branch=z9hG4bK-d8754z-b937eb7870cff11c-1---d8754z-;rport=59141#015#012To: ;tag=d8c8651e9db6867219201727ad85910e.0fda#015#012From: "achalkov";tag=64746f23#015#012Call-ID: NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI.#015#012CSeq: 2 MESSAGE#015#012WWW-Authenticate: Digest realm="x.x.x.x", nonce="54f9845e8218cc613726d1518e7e7f6b1f64cf1e", qop="auth"#015#012Server: Softswitch#015#012Content-Length: 0#015#012#015#012 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:destroy_avp_list: destroying list (nil) Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: cleaning up Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: tcp_read_req end Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcpconn_ev: data available on 0x7ff79cd21908 52 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_del: io_watch_del op on index -1 52 (0x77dd80, 52, -1, 0x0,0x1) fd_no=39 called Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:send2child: to tcp child 0 0(6717), 0x7ff79cd21908 rw 1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:handle_io: We have received conn 0x7ff79cd21908 with rw 1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_add: io_watch_add op on 36 (0x77dee0, 36, 2, 0x7ff79cd21908,1), fd_no=1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: Using the global ( per process ) buff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: read= 863 bytes, parsed=863, state=4, error=1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: last char=0x33, parsed msg=#012MESSAGE sip:achalkov1 at x.x.x.x:3631;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP y.y.y.y:59137;branch=z9hG4bK-d8754z-bfd5c930058a8509-1---d8754z-;rport#015#012Max-Forwards: 70#015#012To: #015#012From: "achalkov";tag=64746f23#015#012Call-ID: NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI.#015#012CSeq: 3 MESSAGE#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012Content-Type: text/plain#015#012User-Agent: Zoiper r21367#015#012Authorization: Digest username="achalkov",realm="x.x.x.x",nonce="54f9845e8218cc613726d1518e7e7f6b1f64cf1e",uri="sip:achalkov1 at x.x.x.x:3631;transport=TCP",response="7937faa022bb7c6b585df82ac2df0b61",cnonce="52edf7bcbdb8c892c00c506d46140e1b",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: presence, kpml#015#012Content-Length: 3#015#012#015#012123 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: content-length= 3 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: We're releasing the connection in state 3 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: releasing con 0x7ff79cd21908, state 0, fd=36, id=1 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: extra_data (nil) Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: SIP Request: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: method: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: uri: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: version: Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=2 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via_param: found param type 232, = ; state=6 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via_param: found param type 235, = ; state=17 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via: end of header reached, state=5 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: via found, flags=2 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: this is the first via Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: After parse_msg... Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: preparing to run routing scripts... Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi: no destination URI Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=10 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: end of header reached, state=10 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: to body [#015#012] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to_param: tag=64746f23 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: end of header reached, state=29 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi_attr: no destination URI Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=40 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: cseq : <3> Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: content_length=3 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: found end of header Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_contact_body: no contact header! Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: [MAIN] Incoming request (M=MESSAGE IP=tcp:y.y.y.y:59141 fromIP=tcp:y.y.y.y:59141 RURI=sip:achalkov1 at x.x.x.x:3631;transport=TCP DURI= F=sip:achalkov at x.x.x.x:3631;transport=TCP T=sip:achalkov1 at x.x.x.x:3631;transport=TCP oP=TCP dP= rP=TCP ID=NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI. ct= cseq=3 UA=Zoiper r21367)#012MESSAGE sip:achalkov1 at x.x.x.x:3631;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP y.y.y.y:59137;branch=z9hG4bK-d8754z-bfd5c930058a8509-1---d8754z-;rport#015#012Max-Forwards: 70#015#012To: #015#012From: "achalkov";tag=64746f23#015#012Call-ID: NmRjMDQ1NGNiY2ExMjQzNzQxMDg0NDY2M2U4YmY3OGI.#015#012CSeq: 3 MESSAGE#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012Content-Type: text/plain#015#012User-Agent: Zoiper r21367#015#012Authorization: Digest username="achalkov",realm="x.x.x.x",nonce="54f9845e8218cc613726d1518e7e7f6b1f64cf1e",uri="sip:achalkov1 at x.x.x.x:3631;transport=TCP",response="7937faa022bb7c6b585df82ac2df0b61",cnonce="52edf7bcbdb8c892c00c506d46140e1b",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: presence, kpml#015#012Content-Length: 3#015#012#015#012123 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:maxfwd:is_maxfwd_present: value = 70 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_methods: methods 0x173F Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:uri:has_totag: no totag Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=78 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: start searching: hash=43605, isACK=0 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:matching_3261: RFC3261 transaction matching failed Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: no transaction found Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcp_child: reader response= 7ff79cd21908, 0 from 0 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7ff79cd21908,1), fd_no=38 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=200 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:rr:find_first_route: No Route headers found Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:rr:loose_route: There is no Route HF Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:auth:check_nonce: comparing [54f9845e8218cc613726d1518e7e7f6b1f64cf1e] and [54f9845e8218cc613726d1518e7e7f6b1f64cf1e] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ff7a39ab7d0 (tail=140701578473280) MC=0x7ff7a39aafa0 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7ff7a39c4850 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7ff7a39c4898 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7ff7a39c48a8)[0]=[ha1] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7ff7a39c48b8)[1]=[mediaproxy] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7ff7a39d4a38 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:db_mysql:db_mysql_str2val: converting STRING [659cc07a1ab8ccbbc3b5ec2172bc6473] Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:auth:check_response: our result = '7937faa022bb7c6b585df82ac2df0b61' Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:auth:check_response: authorization is OK Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_free_columns: freeing result columns at 0x7ff7a39c4898 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_free_rows: freeing 1 rows Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_free_row: freeing row values at 0x7ff7a39d4a48 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_free_rows: freeing rows at 0x7ff7a39d4a38 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:db_free_result: freeing result set at 0x7ff7a39c4850 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:registrar:lookup: found a complete match Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:registrar:lookup: setting as ruri Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:registrar:lookup: looking for branches Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:registrar:lookup: found a complete match Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:registrar:lookup: setting as ruri Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:registrar:lookup: looking for branches Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:comp_scriptvar: str 29 : y.y.y.y Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_newtran: transaction on entrance=(nil) Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=78 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: start searching: hash=43605, isACK=0 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:matching_3261: RFC3261 transaction matching failed Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: no transaction found Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:run_reqin_callbacks: trans=0x7ff79cd25630, callback type 1, id 1 entered Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:tm:run_reqin_callbacks: trans=0x7ff79cd25630, callback type 1, id 0 entered Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:_shm_resize: resize(0) called Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:mk_proxy: doing DNS lookup... Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=2000 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:build_req_buf_from_sip_req: id added: <;i=1>, rcv proto=2 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: no open tcp connection found, opening new one Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 32768 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 65536 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 131072 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 262144 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting buf has no effect Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 133120 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=133120,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 135168 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=135168,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 137216 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=137216,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 139264 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=139264,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 141312 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=141312,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 143360 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=143360,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 145408 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=145408,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 147456 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=147456,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 149504 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=149504,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 151552 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: setting snd: set=151552,verify=262142 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6717]: DBG:core:probe_max_sock_buff: trying : 153600 Mar 6 13:41:14 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_ser_child: read response= 7ff79cd21908, 1, fd -1 from 17 (6717) Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcpconn_ev: data available on 0x7ff79cd21908 52 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_del: io_watch_del op on index -1 52 (0x77dd80, 52, -1, 0x0,0x1) fd_no=39 called Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:send2child: to tcp child 0 0(6717), 0x7ff79cd21908 rw 1 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcp_child: reader response= 7ff79cd21908, 0 from 0 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7ff79cd21908,1), fd_no=38 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_ser_child: read response= 7ff79cd21908, 1, fd -1 from 17 (6717) Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcpconn_ev: data available on 0x7ff79cd21908 52 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_del: io_watch_del op on index -1 52 (0x77dd80, 52, -1, 0x0,0x1) fd_no=39 called Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:send2child: to tcp child 0 0(6717), 0x7ff79cd21908 rw 1 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcp_child: reader response= 7ff79cd21908, 0 from 0 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7ff79cd21908,1), fd_no=38 Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_ser_child: read response= 7ff79cd21908, 1, fd -1 from 17 (6717) Mar 6 13:41:16 cs17792 /usr/sbin/opensips[6705]: DBG:msilo:m_clean_silo: cleaning stored messages - 30 Mar 6 13:41:17 cs17792 /usr/sbin/opensips[6699]: DBG:core:udp_rcv_loop: probing packet received len = 2 Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7ff7a39ac9c8 Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7ff7a39aca10 Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7ff7a39aca18)[0]=[username] Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_query_avp: no result after query Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_close_query: close avp query Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_columns: freeing result columns at 0x7ff7a39aca10 Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_rows: freeing 0 rows Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_result: freeing result set at 0x7ff7a39ac9c8 Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6715]: DBG:core:destroy_avp_list: destroying list (nil) Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6713]: DBG:tm:timer_routine: timer routine:2,tl=0x7ff79cd256b0 next=(nil), timeout=33 Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6713]: DBG:tm:wait_handler: removing 0x7ff79cd25630 from table Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6713]: DBG:tm:delete_cell: delete transaction 0x7ff79cd25630 Mar 6 13:41:20 cs17792 /usr/sbin/opensips[6713]: DBG:tm:wait_handler: done Mar 6 13:41:25 cs17792 /usr/sbin/opensips[6697]: DBG:core:udp_rcv_loop: probing packet received len = 2 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcpconn_ev: data available on 0x7ff79cd21908 52 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_del: io_watch_del op on index -1 52 (0x77dd80, 52, -1, 0x0,0x1) fd_no=39 called Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6734]: DBG:core:send2child: to tcp child 0 0(6717), 0x7ff79cd21908 rw 1 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:handle_io: We have received conn 0x7ff79cd21908 with rw 1 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_add: io_watch_add op on 36 (0x77dee0, 36, 2, 0x7ff79cd21908,1), fd_no=1 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: Using the global ( per process ) buff Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: read= 764 bytes, parsed=764, state=4, error=1 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: last char=0x0A, parsed msg=#012SUBSCRIBE sip:achalkov at x.x.x.x:3631;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP y.y.y.y:59137;branch=z9hG4bK-d8754z-810228177c128e2d-1---d8754z-;rport#015#012Max-Forwards: 70#015#012Contact: #015#012To: "achalkov"#015#012From: "achalkov";tag=7b947279#015#012Call-ID: ZDJkMGIzM2E0MWMwMjc5M2U3NTY0OGFmMjhmMWJjNTE.#015#012CSeq: 1 SUBSCRIBE#015#012Expires: 600#015#012Accept: application/watcherinfo+xml#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri#015#012User-Agent: Zoiper r21367#015#012Event: presence.winfo#015#012Allow-Events: presence, kpml#015#012Content-Length: 0#015#012#015#012 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: content-length= 0 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: We're releasing the connection in state 3 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: releasing con 0x7ff79cd21908, state 0, fd=36, id=1 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:release_tcpconn: extra_data (nil) Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: SIP Request: Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_tcp_child: reader response= 7ff79cd21908, 0 from 0 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6734]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7ff79cd21908,1), fd_no=38 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: method: Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: uri: Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_msg: version: Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=2 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via_param: found param type 232, = ; state=6 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via_param: found param type 235, = ; state=17 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_via: end of header reached, state=5 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: via found, flags=2 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: this is the first via Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: After parse_msg... Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: preparing to run routing scripts... Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi: no destination URI Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=10 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: end of header reached, state=10 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: [60]; uri=[sip:achalkov at x.x.x.x:3631;transport=TCP] Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: to body ["achalkov"#015#012] Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to_param: tag=7b947279 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: end of header reached, state=29 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi_attr: no destination URI Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=40 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=20 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: cseq : <1> Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=8000000 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: [MAIN] Incoming request (M=SUBSCRIBE IP=tcp:y.y.y.y:59141 fromIP=tcp:y.y.y.y:59141 RURI=sip:achalkov at x.x.x.x:3631;transport=TCP DURI= F=sip:achalkov at x.x.x.x:3631;transport=TCP T=sip:achalkov at x.x.x.x:3631;transport=TCP oP=TCP dP= rP=TCP ID=ZDJkMGIzM2E0MWMwMjc5M2U3NTY0OGFmMjhmMWJjNTE. ct= cseq=1 UA=Zoiper r21367)#012SUBSCRIBE sip:achalkov at x.x.x.x:3631;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP y.y.y.y:59137;branch=z9hG4bK-d8754z-810228177c128e2d-1---d8754z-;rport#015#012Max-Forwards: 70#015#012Contact: #015#012To: "achalkov"#015#012From: "achalkov";tag=7b947279#015#012Call-ID: ZDJkMGIzM2E0MWMwMjc5M2U3NTY0OGFmMjhmMWJjNTE.#015#012CSeq: 1 SUBSCRIBE#015#012Expires: 600#015#012Accept: application/watcherinfo+xml#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri#015#012User-Agent: Zoiper r21367#015#012Event: presence.winfo#015#012Allow-Events: presence, kpml#015#012Content-Length: 0#015#012#015 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:maxfwd:is_maxfwd_present: value = 70 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: content_length=0 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:get_hdr_field: found end of header Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:decode_mime_type: Decoding MIME type for:[application/watcherinfo+xml] Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_methods: methods 0x173F Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_supported: parsing [Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri#015#012] 0x7ff7a39be888 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:sipmsgops:sip_validate_hdrs: duplicate header 'Content-Length' Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:uri:has_totag: no totag Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=78 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: start searching: hash=54316, isACK=0 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:tm:matching_3261: RFC3261 transaction matching failed Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:tm:t_lookup_request: no transaction found Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=200 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:rr:find_first_route: No Route headers found Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:rr:loose_route: There is no Route HF Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi: no destination URI Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:pv_get_dsturi_attr: no destination URI Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: [MAIN] Not allowed method - Sending 405 Method Not Allowed (M=SUBSCRIBE IP=tcp:y.y.y.y:59141 fromIP=tcp:y.y.y.y:59141 RURI=sip:achalkov at x.x.x.x:3631;transport=TCP DURI= F=sip:achalkov at x.x.x.x:3631;transport=TCP T=sip:achalkov at x.x.x.x:3631;transport=TCP oP=TCP dP= rP=TCP ID=ZDJkMGIzM2E0MWMwMjc5M2U3NTY0OGFmMjhmMWJjNTE. ct= cseq=1 UA=Zoiper r21367) Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:parse_headers: flags=ffffffffffffffff Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: tcp connection found (0x7ff79cd21908), acquiring fd Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: c= 0x7ff79cd21908, n=16 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6734]: DBG:core:handle_ser_child: read response= 7ff79cd21908, 1, fd -1 from 17 (6717) Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: after receive_fd: c= 0x7ff79cd21908 n=8 fd=36 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: sending... Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:async_tsend_stream: Async succesful write from first try on 0x7ff79cd21908 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: after write: c= 0x7ff79cd21908 n=454 fd=36 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_send: buf=#012SIP/2.0 405 Method Not Allowed#015#012Via: SIP/2.0/TCP y.y.y.y:59137;received=y.y.y.y;branch=z9hG4bK-d8754z-810228177c128e2d-1---d8754z-;rport=59141#015#012To: "achalkov";tag=d8c8651e9db6867219201727ad85910e.c770#015#012From: "achalkov";tag=7b947279#015#012Call-ID: ZDJkMGIzM2E0MWMwMjc5M2U3NTY0OGFmMjhmMWJjNTE.#015#012CSeq: 1 SUBSCRIBE#015#012Server: Softswitch#015#012Content-Length: 0#015#012#015#012 Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:destroy_avp_list: destroying list (nil) Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:receive_msg: cleaning up Mar 6 13:41:26 cs17792 /usr/sbin/opensips[6717]: DBG:core:tcp_read_req: tcp_read_req end Mar 6 13:41:27 cs17792 /usr/sbin/opensips[6705]: DBG:msilo:m_clean_silo: cleaning stored messages - 40 Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7ff7a39ac9c8 Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7ff7a39aca10 Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7ff7a39aca18)[0]=[username] Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_query_avp: no result after query Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_close_query: close avp query Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_columns: freeing result columns at 0x7ff7a39aca10 Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_rows: freeing 0 rows Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_result: freeing result set at 0x7ff7a39ac9c8 Mar 6 13:41:31 cs17792 /usr/sbin/opensips[6715]: DBG:core:destroy_avp_list: destroying list (nil) Mar 6 13:41:32 cs17792 /usr/sbin/opensips[6698]: DBG:core:udp_rcv_loop: probing packet received len = 2 Mar 6 13:41:37 cs17792 /usr/sbin/opensips[6705]: DBG:msilo:m_clean_silo: cleaning stored messages - 50 Mar 6 13:41:40 cs17792 /usr/sbin/opensips[6696]: DBG:core:udp_rcv_loop: probing packet received len = 2 Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7ff7a39ac9c8 Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7ff7a39aca10 Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7ff7a39aca18)[0]=[username] Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_query_avp: no result after query Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:avpops:db_close_query: close avp query Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_columns: freeing result columns at 0x7ff7a39aca10 Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_rows: freeing 0 rows Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:core:db_free_result: freeing result set at 0x7ff7a39ac9c8 Mar 6 13:41:42 cs17792 /usr/sbin/opensips[6715]: DBG:core:destroy_avp_list: destroying list (nil) 06.03.2015, 12:43, "Vlad Paiu" : > Hello, > > OpenSIPS complains that there is an error when connecting via TCP to > that endpoint. > Now, are you sure you do not have multple branches when relaying that > SIP MESSAGE,out of which only one fails ? In t_relay(), if you have > multiple branches and at least one succceeds, you will get a 1 return code. > > Please post the complete debug=4 logs for the processing. In the > previous email, you've truncated the logs to the moment OpenSIPS gets > blocked in trying to connect to the endpoint - what happens afterwards ( > after connet timeout ) would also be helpfull. > > Best Regards, > > Vlad Paiu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 06.03.2015 11:06, ?????? ????? wrote: >> ?do anyone have any idea about how to handle that? >> >> ?05.03.2015, 16:22, "?????? ?????" : >>> ?debug=4 >>> >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_read_req: We're releasing the connection in state 3 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:io_watch_del: io_watch_del op on index -1 36 (0x77dee0, 36, -1, 0x10,0x1) fd_no=2 called >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?releasing con 0x7f2be91663a8, state 0, fd=36, id=1 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:release_tcpconn: ?extra_data (nil) >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: SIP Request: >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?method: ? >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_tcp_child: reader response= 7f2be91663a8, 0 from 0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?uri: ???? >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:io_watch_add: io_watch_add op on 52 (0x77dd80, 52, 2, 0x7f2be91663a8,1), fd_no=38 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_msg: ?version: >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 232, = ; state=6 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via_param: found param type 235, = ; state=17 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_via: end of header reached, state=5 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: via found, flags=2 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: this is the first via >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: After parse_msg... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:receive_msg: preparing to run routing scripts... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=8000000 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=10 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={}, ruri={sip:achalkov1 at x.x.x.x:3631;transport=TCP} >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: [51]; uri=[sip:achalkov1 at x.x.x.x:3631;transport=TCP] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: to body [#015#012] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: cseq : <3> >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:maxfwd:is_maxfwd_present: value = 70 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: content_length=3 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:get_hdr_field: found end of header >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to_param: tag=b2b91161 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: end of header reached, state=29 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_to: display={"achalkov"}, ruri={sip:achalkov at x.x.x.x:3631;transport=TCP} >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_methods: methods 0x173F >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:uri:has_totag: no totag >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=200 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:find_first_route: No Route headers found >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:rr:loose_route: There is no Route HF >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_nonce: comparing [54f85536be0ae02858c2001d58774c222d958f86] and [54f85536be0ae02858c2001d58774c222d958f86] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f2bef4e28b0 (tail=139826675195936) MC=0x7f2bef4e2080 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4f5968 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7f2bef4f6368 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6378)[0]=[ha1] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4f6388)[1]=[mediaproxy] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7f2bef4f6a48 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:db_mysql:db_mysql_str2val: converting STRING [659cc07a1ab8ccbbc3b5ec2172bc6473] >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: our result = '06223b730875bf2c01ad98448dd08438' >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:auth:check_response: authorization is OK >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4f6368 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing 1 rows >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_row: freeing row values at 0x7f2bef4f6a58 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_rows: freeing rows at 0x7f2bef4f6a48 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:db_free_result: freeing result set at 0x7f2bef4f5968 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: found a complete match >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: setting as ruri >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:registrar:lookup: looking for branches >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:comp_scriptvar: str 29 : 83.149.9.184 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_newtran: transaction on entrance=(nil) >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=ffffffffffffffff >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=78 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: start searching: hash=32018, isACK=0 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:matching_3261: RFC3261 transaction matching failed >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:t_lookup_request: no transaction found >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 1 entered >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:tm:run_reqin_callbacks: trans=0x7f2be91669a0, callback type 1, id 0 entered >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:_shm_resize: resize(0) called >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:mk_proxy: doing DNS lookup... >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:parse_headers: flags=2000 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:build_req_buf_from_sip_req: id added: <;i=1>, rcv proto=2 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:tcp_send: no open tcp connection found, opening new one >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 32768 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=32768,verify=65536 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 65536 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=65536,verify=131072 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 131072 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=131072,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 262144 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=262144,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting buf has no effect >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 133120 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=133120,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 135168 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=135168,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 137216 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=137216,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 139264 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=139264,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 141312 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=141312,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 143360 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=143360,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 145408 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=145408,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 147456 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=147456,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 149504 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=149504,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 151552 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=151552,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 153600 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=153600,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 155648 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=155648,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 157696 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=157696,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 159744 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=159744,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 161792 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=161792,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 163840 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=163840,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 165888 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=165888,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 167936 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=167936,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: trying : 169984 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19012]: DBG:core:probe_max_sock_buff: setting snd: set=169984,verify=262142 >>> ?Mar ?5 16:07:46 cs17792 /usr/sbin/opensips[19028]: DBG:core:handle_ser_child: read response= 7f2be91663a8, 1, fd -1 from 17 (19012) >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:ops_dbquery_avps: query [SELECT username FROM silo GROUP BY username HAVING count(*) > 0] >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2bef4e3aa8 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f2bef4e3af0 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f2bef4e3af8)[0]=[username] >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_query_avp: no result after query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:avpops:db_close_query: close avp query >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_columns: freeing result columns at 0x7f2bef4e3af0 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_rows: freeing 0 rows >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:db_free_result: freeing result set at 0x7f2bef4e3aa8 >>> ?Mar ?5 16:07:49 cs17792 /usr/sbin/opensips[19010]: DBG:core:destroy_avp_list: destroying list (nil) >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:timer_routine: timer routine:2,tl=0x7f2be9166a20 next=(nil), timeout=36 >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: removing 0x7f2be91669a0 from table >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:delete_cell: delete transaction 0x7f2be91669a0 >>> ?Mar ?5 16:07:52 cs17792 /usr/sbin/opensips[19009]: DBG:tm:wait_handler: done >>> >>> ?debug=3 with check >>> >>> ??????????????????if ($si != "127.0.0.1") t_on_failure("ON_FAIL_MESSAGE"); >>> ??????????????????t_relay("0x01"); >>> ??????????????????$var(retcode) = $retcode; >>> ??????????????????xlog("L_INFO", "[!!!MESSAGE_DEBUG!!!] t_relay returns $var(retcode)"); >>> >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [MAIN] Incoming request (MESSAGE) >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:probe_max_sock_buff: using snd buffer of 255 kb >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: poll error: flags 24 - 4 8 16 32 >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR [server=x.x.x.x:65106] (111) Connection refused >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:core:tcp_send: connect failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:msg_send: tcp_send failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: ERROR:tm:t_forward_nonack: sending request failed >>> ?Mar ?5 16:15:01 cs17792 /usr/sbin/opensips[19205]: [!!!MESSAGE_DEBUG!!!] t_relay returns 1 >>> >>> ?05.03.2015, 15:39, "Vlad Paiu" : >>>> ???Hello, >>>> >>>> ???Since TLS doesn't support async in 1.11, you should get an error >>>> ???straight out of t_relay() >>>> ???Can you please post the full debug logs here ? >>>> >>>> ???Best Regards, >>>> >>>> ???Vlad Paiu >>>> ???OpenSIPS Developer >>>> ???http://www.opensips-solutions.com >>>> >>>> ???On 05.03.2015 13:44, ?????? ????? wrote: >>>>> ????Hi all! >>>>> >>>>> ????Can someone help us?. I cannot understand how TLS in opensips 1.11 works. >>>>> ????The problem is when we use TLS, i cannot handle connection problems. >>>>> >>>>> ????When i use TCP in async mode, i have 408 in failure route when outgoing TCP connection fails, when i use TCP in sync mode, i have negative status after t_relay(), however, after TLS, i cannot catch neither 408, or negative t_relay() status. So, how to handle TLS connection error? >>>>> >>>>> ????_______________________________________________ >>>>> ????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 From achalkov at yandex.ru Fri Mar 6 09:00:32 2015 From: achalkov at yandex.ru (=?koi8-r?B?/sHMy8/XIOHS1KPN?=) Date: Fri, 06 Mar 2015 11:00:32 +0300 Subject: [OpenSIPS-Users] TLS handling In-Reply-To: 2540000002454456062 References: <272051425555896@web6j.yandex.ru> <54F84E58.4080706@opensips.org> <768261425561731@web7o.yandex.ru> Message-ID: <1981411425628832@web29m.yandex.ru> An HTML attachment was scrubbed... URL: From dsmaldone at alida.it Sun Mar 8 10:24:21 2015 From: dsmaldone at alida.it (ALIDA SRL - Danilo SMALDONE) Date: Sun, 8 Mar 2015 10:24:21 +0100 Subject: [OpenSIPS-Users] Destination IP in the Branch and Reply Routes In-Reply-To: References: Message-ID: You can use nat_uac_test() Take a look at http://www.opensips.org/html/docs/modules/1.11.x/nathelper.html Il 08/Mar/2015 02:25 "Terrance Devor" ha scritto: > Hello Everyone, > > Our opensips is in a nat'ed environment , and we need a way to test if the > destination ip (ie, where the next message is going to be sent) is public > or > private. Is there a variable, or even better a function that can test for > this. > > Kind Regards, > > Terrance > > _______________________________________________ > 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 sobomax at sippysoft.com Mon Mar 9 22:42:07 2015 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 9 Mar 2015 14:42:07 -0700 Subject: [OpenSIPS-Users] Announcing rtpproxy v2.0.0 Message-ID: Hi All, I'm happy to announce that we have released rtpproxy v2.0.0. You can review the release notes here: https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 -sobomax -------------- next part -------------- An HTML attachment was scrubbed... URL: From jehanzaib_kiani at hotmail.com Wed Mar 11 06:36:08 2015 From: jehanzaib_kiani at hotmail.com (jehanzaib) Date: Tue, 10 Mar 2015 22:36:08 -0700 (MST) Subject: [OpenSIPS-Users] REGISTER request to other servers Message-ID: <1426052168190-7595776.post@n2.nabble.com> Hi team, I am looking for a solution of my problem. i have 1 opensip server and 2 other asterisk servers. i want to get my user registered on asterisk servers. so user will send the regsiter request to opensip and opensip will redirect the regsiter request to one of the asteirsk servers. So user will actually register on asterisk server but all the request would come directly to opensip. i tried it many ways but no luck yet. this is what i am doing? #if (method=="REGISTER") { xlog("REGISTER from $fu"); # rewrite current URI, which is always part of destination ser rewritehostport("asterisk1.com:5060"); append_branch("sip:redirect at asterisk2.com"); sl_send_reply("300", "Redirect"); return; } its not working i see on the phone says Redirect but the REGISTER request is not going to anywhere. any help please thanks -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/REGISTER-request-to-other-servers-tp7595776.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From andreas at jibemobile.com Thu Mar 12 16:09:45 2015 From: andreas at jibemobile.com (Andreas Bachmann) Date: Thu, 12 Mar 2015 15:09:45 +0000 Subject: [OpenSIPS-Users] Problem with opensips core dumping on high load Message-ID: Hello, I recognized opensips coredumping in the latest version when being under high load. The problem is an invalid pointer when iterating over the user location in memory table (DB mode is 0). Below the backtrace of where this happen. Note: we added an extra NULL check in the line to make sure that _r is not null. But as u can see the one is still crashing so we assume that the location table got corrupted ? pointer not null but pointing to nirwana. We are load testing only register cycles (register/401/register/200). After the trace the current config ? The important part is the ?route[register_request]?. Tests have shown that if we strip off the cachedb calls or using cache local instead of cache_mysql ? this not happening. Could it be a conflict in the timer procedure used by both modules? The cache needs to be distributed ? that?s why cache_mysql was chosen. Any thoughts? Core was generated by `/opt/opensips/sbin/opensips -P /var/run/opensips.pid -w /opt/opensips -m 8192 -'. Program terminated with signal SIGSEGV, Segmentation fault. #0 nodb_timer (_r=0x7f8f00000000) at urecord.c:223 223 if (!_r->contacts) return 0; (gdb) #0 nodb_timer (_r=0x7f8f00000000) at urecord.c:223 ptr = t = #1 timer_urecord (_r=_r at entry=0x7f8f00000000, ins_list=ins_list at entry=0x7f8fed2ec480) at urecord.c:367 No locals. #2 0x00007f91eed428ac in mem_timer_udomain (_d=0x7f8fed2ec478) at udomain.c:791 ptr = 0x7f8f00000000 dest = i = 61 ret = flush = 0 it = {node = 0x7f8ff14136c8, map = 0x7f8fed2f0238} __FUNCTION__ = "mem_timer_udomain" #3 0x00007f91eed356fe in synchronize_all_udomains () at dlist.c:694 res = 0 ptr = 0x7f8fed2ec418 #4 0x00007f91eed47ca7 in timer (ticks=, param=) at ul_mod.c:439 __FUNCTION__ = "timer" #5 0x00000000004df9c8 in timer_ticker (drift=, timer_list=) at timer.c:384 t = 0x7f91f1186da0 j = 300 ij = 300050000 ij_marker = 300050000 #6 run_timer_process (tpl=0x7f91f11862e8, tpl=0x7f91f11862e8) at timer.c:506 multiple = cnt = o_tv = tv = {tv_sec = 0, tv_usec = 0} drift = 0 uinterval = 100000 wait = #7 start_timer_processes () at timer.c:616 tpl = 0x7f91f11862e8 pid = __FUNCTION__ = "start_timer_processes" #8 0x00000000004170f9 in main_loop () at main.c:1016 i = pid = si = 0x0 startup_done = 0x0 chd_rank = 64 rc = load_p = 0x7f8fed2f67c8 #9 main (argc=, argv=) at main.c:1634 cfg_log_stderr = cfg_stream = c = r = tmp = 0x7fff9dd62f17 "" tmp_len = port = proto = options = 0x5c59a8 "f:cCm:M:b:l:n:N:rRvdDFETSVhw:t:u:g:P:G:W:o:" ret = -1 seed = 3178038181 __FUNCTION__ = "main" Configuration: ####### Global Parameters ######### tcp_children=256 tcp_max_connections=500000 tcp_keepalive=1 tcp_keepcount=3 tcp_keepidle=300 tcp_keepinterval=300 tcp_connection_lifetime=1200 tcp_max_msg_chunks=20 tcp_max_msg_time=15 tcp_connect_timeout=1 tcp_send_timeout=1 #tcp_async=1 disable_tls=yes tls_verify_server = 1 # There won't be a client presenting a real valid cert. If a client would # presente a cert - even if not required (see below) this option would make # the client connecting fail (see opensips docu). tls_verify_client = 0 tls_require_client_certificate = 0 tls_method = TLSv1 disable_core_dump=no debug=0 server_header="Server: Jibe Mobile SIP Proxy 1.10.1" log_stderror=no log_facility=LOG_LOCAL0 fork=yes children=64 auto_aliases=no listen=... ####### Modules Section ######## #set module path mpath="/opt/opensips/lib64/opensips/modules/" # helper and util modules loadmodule "maxfwd.so" loadmodule "db_mysql.so" loadmodule "textops.so" loadmodule "sipmsgops.so" # ----- Management interface ----- loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") modparam("mi_fifo", "fifo_mode", 0666) # core modules for sip routing and checking # ----- Stateless signalling ---- loadmodule "sl.so" # ----- Transaction Management ----- loadmodule "tm.so" # NOTE: signaling.so requires sl/tm loaded before itself loadmodule "signaling.so" # set final reply timer for SIP messages in seconds modparam("tm", "fr_timer", 32) modparam("tm", "fr_inv_timer", 150) # ----- Record Routing ----- loadmodule "rr.so" modparam("rr", "append_fromtag", 1) modparam("rr", "enable_double_rr", 1) # Dialog module to track RTP proxy in use for the RTP session loadmodule "dialog.so" # ----- user location ----- loadmodule "usrloc.so" modparam("usrloc", "db_mode", 0) # In memory only modparam("usrloc", "timer_interval", 300) modparam("usrloc", "nat_bflag", "nat_branch") # ----- Registrar ------ loadmodule "registrar.so" modparam("registrar", "max_contacts", 1) modparam("registrar", "default_expires", 3600) modparam("registrar", "min_expires", 20) modparam("registrar", "max_expires", 3600) modparam("registrar", "tcp_persistent_flag", "tcp_persistent") modparam("registrar", "mcontact_avp", "$avp(contact_info)") modparam("registrar", "received_avp", "$avp(42)") #GRUU support for SERV-2317: 1=disable is default, 0=enable modparam("registrar", "disable_gruu", 1) # ----- Authentication ----- loadmodule "auth.so" loadmodule "auth_db.so" modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url", "mysql://....") modparam("auth_db", "load_credentials", "") # ----- Database operations for AVP ----- loadmodule "avpops.so" modparam("avpops", "db_url", "1 mysql://...") modparam("avpops", "db_url", "2 mysql://...") modparam("avpops", "db_url", "3 mysql://...") # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- # ----- CacheDB binding for cache interface loadmodule "cachedb_sql.so" modparam("cachedb_sql", "db_url","mysql://opensips:opensipsrw at 69.194.8.32/opensips") modparam("cachedb_sql", "cache_clean_period",3600) # ----- URI ----- loadmodule "uri.so" modparam("uri", "use_uri_table", 0) modparam("uri", "db_url", "mysql://opensips:opensipsrw at 69.194.8.32/opensips") # ----- Accounting ----- loadmodule "acc.so" modparam("acc", "db_url", "mysql://opensips:opensipsrw at 69.194.8.32/opensips") modparam("acc", "db_flag", "DB_FLAG") modparam("acc", "cdr_flag", "CDR_FLAG") modparam("acc", "early_media", 1) modparam("acc", "report_cancels", 1) modparam("acc", "db_missed_flag", 2) modparam("acc", "failed_transaction_flag", 3) modparam("acc", "detect_direction", 0) # ----- NAT Helper ----- loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 0) modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT, set to 1 modparam("nathelper", "sipping_bflag", 7) # Changed from 8 to 7 modparam("nathelper", "sipping_from", "sip:pinger at rcs.jibemobile.com") modparam("nathelper", "received_avp", "$avp(42)") # ----- STUN Binding based keep-alive - RFC 6223 loadmodule "stun.so" modparam("stun", "primary_ip", "...") modparam("stun", "primary_port", "5671") modparam("stun", "alternate_ip", "127.0.0.1") modparam("stun", "alternate_port", "6600") # ----- RTPProxy ----- loadmodule "rtpproxy.so" # Retry lost rtpproxy mgmt connections after 20 seconds modparam("rtpproxy", "rtpproxy_disable_tout", 20) # Wait 2 seconds after sending an rtp mgmt packet for a response (US is a long way away) modparam("rtpproxy", "rtpproxy_tout", 2) # Retry 10 times after a timeout modparam("rtpproxy", "rtpproxy_retr", 10) modparam("rtpproxy", "rtpproxy_sock", "0 == udp:69.194.11.206:7890 udp:69.194.11.207:7890 udp:69.194.11.208:7890 udp:69.194.11.209:7890") ####### Routing Logic ######## ############################## # main request routing logic # ############################## route { $var(hub) = NULL; $var(local_location) = "sip:.,;transport=tcp"; $var(imas) = "sip:...;transport=udp"; $var(rls) = "sip:...;transport=udp"; $var(mps) = "sip:...;transport=udp"; $var(otherCloud) = NULL; $var(conference_factory) = "sip:conference at jibemobile.com"; $var(network_wifi) = "..."; # wifi $var(network_mobile) = "..."; # mobile #COM-97 $var(blackBird) = "true"; xlog("JIBE CN ($ci): Incoming request: $rm: $ruri from: $si:$sp on $pr (source=$hdr(P-Request-Source))\r\n"); route(sanity_check); route(receive_lb_message); # Not sure if this is the right place to trigger accounting # aba: !!! NO IT'S NOT !!! if (is_method("INVITE")) { route(db_cdr_accounting); } if ( has_totag() ) { route(in_dialog_request); } else if ( is_method("REGISTER") ) { route(register_request); } else if ( is_method("CANCEL") ) { route(cancel_request); } else if ( $hdr(P-Request-Source) == "hub" ) { # check if we are on the right proxy - if not, send request to the right one route(check_hub_request); # hit target proxy - route to client route(terminating_hub_request); } else if ($hdr(P-Request-Source) == "server") { route(check_server_request); if(is_method("SUBSCRIBE") && ($hdr(Event) =~ "presence" || $hdr(Event) =~ "xcap") ) { route(presence_server); exit; } # terminating hub routing - do media proxying and traffic shaping route(originating_server_request); } else if ( $hdr(P-Request-Source) == "proxy") { # terminating proxy routing - do media proxying and traffic shaping route(terminating_proxy_request); } else { # Client requests # set avp to mark the transaction as client originated # avps are bound to the current transaction/message and will be available # in onreply for this transaction/message $avp(client_originating_request) = "yes"; if ( is_method("OPTIONS") ) { route(options_request); } else if (is_method("MESSAGE") && $cT =~ "system-request") { #originating system request SCA-5684 route(system_message_request); } else { # originating client request - traffic shaping, lookup of target node and media proxying route(originating_client_request); } } } ########################################################################################## # SANITY CHECK ON INCOMING MESSAGES # ########################################################################################## route[sanity_check] { xlog("JIBE CN ($ci): Sanity check on incoming request\r\n"); if ( !mf_process_maxfwd_header("10") ) { sl_send_reply("483","Too Many Hops"); exit; } } ######################################################################################### # REGISTER request # ########################################################################################## route[register_request] { # authenticate the REGISTER requests if (!www_authorize("rcs.jibemobile.com", "subscriber")) { xlog("JIBE CN ($ci): Not authenticated - challenging user\r\n"); www_challenge("rcs.jibemobile.com", "0"); exit; } # USER authenticated - continue with setting keep alive values #For keep-alive negotiation RFC-6223 $avp(1) = $(hdr(Via)[0]) ; #If Keep header exists in via[0], initiate negotiation if ($avp(1) =~ "keep") { #Different keep alive value if network access info. is provided if ($hdr(P-Access-Network-Info)) { #Mobile Network if ($hdr(P-Access-Network-Info) =~ "3GPP-GERAN" || $hdr(P-Access-Network-Info) =~ "3GPP-UTRAN-TDD" || $hdr(P-Access-Network-Info) =~ "3GPP-E-UTRAN-TDD" || $hdr(P-Access-Network-Info) =~ "3GPP2-1X" || $hdr(P-Access-Network-Info) =~ "3GPP2-1X-HRPD") { avp_subst("$avp(1)/$avp(2)","/keep/keep=240/ig"); } else if ($hdr(P-Access-Network-Info) =~ "IEEE-802.16e") { #Wi-Max Network avp_subst("$avp(1)/$avp(2)","/keep/keep=10/ig"); } else if ($hdr(P-Access-Network-Info) =~ "IEEE-802.11" || $hdr(P-Access-Network-Info) =~ "ethernet") { #Ethernet Network avp_subst("$avp(1)/$avp(2)","/keep/keep=240/ig"); } else { #Unknown avp_subst("$avp(1)/$avp(2)","/keep/keep=0/ig"); } } else if($var(network_mobile) != $var(network_wifi)) { #No Access-Network-Info header, look at interface of which the request came in from if(dst_ip == ...) { avp_subst("$avp(1)/$avp(2)","/keep/keep=240/ig"); } else if(dst_ip == ...) { avp_subst("$avp(1)/$avp(2)","/keep/keep=240/ig"); } } else { #Let client make the call since network is not identified avp_subst("$avp(1)/$avp(2)","/keep/keep=240/ig"); } #We can't trap REGISTER request's response object, so adding a new header instead append_to_reply("J-Via: $avp(2)\r\n"); } #SERV-1071: Add P-Associated-URI to successful REGISTER responses for Samsung append_to_reply("P-Associated-URI: , \r\n"); # IanB - ensure client TCP connections stay open if (proto==TCP) { # Keep TCP/TLS connections open until the registration # expires, by setting the tcp_persistent_flag setflag(tcp_persistent); } # TODO - check if this really required force_rport(); if ($hdr(User-Agent) !~ "SRG") { xlog("L_INFO", "JIBE CN ($ci): NAT Fixing Register.\n"); fix_nated_register(); } ####################################################################### # 200 OK or Error responses gets sent with save() action # Note: Any append_to_reply call will be too late after this point! ####################################################################### # IanB - 'f' to force save as part of single registration configuration if ( !save("location", "f") ) { sl_reply_error(); exit; } if (registered("location", "$fu")) { # store location for the user in the share location cache xlog("JIBE CN ($ci): storing proxy: $var(local_location) for $tU\r\n"); xlog("JIBE CN ($ci): contact expire=$ct.fields(expires) and hdr(Expires) = $hdr(Expires)\r\n"); # # If expire header/contact param exists then specify cache timeout # $avp(expireValue) = $ct.fields(expires); if ($avp(expireValue) == NULL) { if( is_present_hf("Expires") && $(hdr(Expires){s.int}) != 0) { $avp(expireValue) = $(hdr(Expires){s.int}); } } if ($avp(expireValue) != NULL) { #cache_store("sql","proxy_$tU","$var(local_location)", $(avp(expireValue){s.int})); } else { #cache_store("sql","proxy_$tU","$var(local_location)"); } } else { # remove store location for the user in the share location cache xlog("JIBE CN ($ci): removing proxy: $var(proxy_location) for $tU\r\n"); #cache_remove("sql", "proxy_$tU"); } # SERV-783 MSRPS based on bearer xlog("JIBE CN ($ci): Checking for bearer from P-Access-Network-Info header or network interface came through\n"); if ($hdr(P-Access-Network-Info)) { #Mobile Network if ($hdr(P-Access-Network-Info) =~ "3GPP") { xlog("JIBE CN ($ci): P-Access-Network-Info header: 3GPP detected\n"); append_hf("P-Network-Mode: Mobile\r\n"); } else if ($hdr(P-Access-Network-Info) =~ "IEEE-802" || $hdr(P-Access-Network-Info) =~ "ethernet") { xlog("JIBE CN ($ci): P-Access-Network-Info header: IEEE-802 or ethernet detected\n"); append_hf("P-Network-Mode: Wifi\r\n"); } else { xlog("JIBE CN ($ci): P-Access-Network-Info header: unknown detected\n"); #Unknown? } } else if($var(network_mobile) != $var(network_wifi)) { xlog("JIBE CN ($ci): No P-Access-Network-Info header found\nChecking interface received from...\n"); #No Access-Network-Info header, look at interface of which the request came in from if(dst_ip == 127.0.0.1) { xlog("JIBE CN ($ci): message received on loopback interface\n"); } else if(dst_ip == ....) { xlog("JIBE CN ($ci): message received on mobile interface\n"); append_hf("P-Network-Mode: Mobile\r\n"); } else if(dst_ip == ...) { xlog("JIBE CN ($ci): message received on wireless interface\n"); append_hf("P-Network-Mode: Wifi\r\n"); } } route(third_party_register); exit; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Mar 12 17:12:31 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 12 Mar 2015 18:12:31 +0200 Subject: [OpenSIPS-Users] ERROR:siptrace:pipport2su: bad protocol In-Reply-To: References: Message-ID: <5501BAEF.2070002@opensips.org> Just to let people know, this was fixed in 2.1 (it was triggered by adding the new websocket protocol). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.03.2015 18:42, Satish Patel wrote: > I set debug=6 and here is the logs most of time error pop'ed up near > "tm" module > > > DBG:tm:run_trans_callbacks: trans=0x7f9570f06710, callback type 1024, > id 1 entered > DBG:siptrace:trace_onreq_out: trace on req out > DBG:core:parse_headers: flags=40 > DBG:siptrace:trace_msg_out: trace msg out > ERROR:siptrace:pipport2su: bad protocol > > > On Tue, Mar 10, 2015 at 12:12 PM, Satish Patel > wrote: > > I am configuring siptrace with homer server and getting following > error, > > ERROR:siptrace:pipport2su: bad protocol > ERROR:siptrace:pipport2su: bad protocol > ERROR:siptrace:pipport2su: bad protocol > > Razvan fix following patch but still getting above error in log > https://github.com/OpenSIPS/opensips/commit/178b0cc26b05a81947de150fe1c2df36d600ccaa > > Am i missing something? > > > > > _______________________________________________ > 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 ter.devor at gmail.com Thu Mar 12 18:22:37 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Thu, 12 Mar 2015 13:22:37 -0400 Subject: [OpenSIPS-Users] Announcing rtpproxy v2.0.0 In-Reply-To: References: Message-ID: Good news. Can install it into my OpenSIPS 1.8 server and click play?? Or are there modifications needed in opensips.cfg -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Thu Mar 12 18:25:50 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Thu, 12 Mar 2015 13:25:50 -0400 Subject: [OpenSIPS-Users] Destination IP in the Branch and Reply Routes In-Reply-To: References: Message-ID: Hello Danilo, Thank you for your response. We use nat_uac_test() in the config file for originating clients, unfortunately this is focused towards the destination (ie, the IP address of which the next signal is going to be sent to) T ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.mathew at divoxmedia.com Thu Mar 12 18:28:46 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Thu, 12 Mar 2015 22:58:46 +0530 Subject: [OpenSIPS-Users] Announcing rtpproxy v2.0.0 In-Reply-To: References: Message-ID: Hi, Maxim, Is there any plans for rtp header compression in future. I can't see anything in the change log for 2.0.0 On Tuesday, 10 March 2015, Maxim Sobolev wrote: > Hi All, > > I'm happy to announce that we have released rtpproxy v2.0.0. > > You can review the release notes here: > https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 > > -sobomax > > -- Sent from iPhone 6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Mar 12 20:16:25 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 12 Mar 2015 15:16:25 -0400 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: <5501B010.2000507@opensips.org> References: <54EC8943.2070308@opensips.org> <5501B010.2000507@opensips.org> Message-ID: On download page, http://www.opensips.org/Downloads/Downloads, currently we have following. GIT clone of development stable version 2.1.1 (MASTER): Does on march 18th release will be 2.1.2 ? On Thu, Mar 12, 2015 at 11:26 AM, Bogdan-Andrei Iancu wrote: > The D day for releasing 2.1 is 18th of March ! > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 24.02.2015 16:22, Bogdan-Andrei Iancu wrote: > >> Hello all, >> >> Everybody is looking forward for the next OpenSIPS release, the major >> 2.1, which is planned for end of February - at least this was the plan so >> far. >> I our desire to make of 2.1 a radical improvement, we committed to >> several major changes/redesigns and new valuable functionalities. And they >> do burn time to get them done, especially as we want them : in the best >> possible way. >> >> In oder to finish all we committed for, the release date is now estimated >> for first half of March - some important parts of code still need to be >> settled down and we do not want to make any kind of compromise in quality. >> >> Just to give you a heads up on what OpenSIPS 2.1 will bring: >> - internal re-design around async reactors for load-balancing tasks >> inside OpenSIPS >> - async I/O support in scripts for db queries, exec, rest client >> - refactoring of the networking and protocol related code (protos are >> now modules) >> - webSockets support >> - Quality Based Routing new module >> - Compression new module >> - Fraud Detection new module >> - Emergency Call handling new module >> - rtpengine support >> - partitioning support in Dynamic Routing, Diaplan and Dispatcher >> >> and many other - when the coding taks is done, we will proceed withe >> "bothersome" task of updating docs, new and migration. >> >> Whoever gives a try to 2.1 version, please report any problems or crashes >> asap to us ! better have them done now rather than later :P >> >> Best regards, >> >> > > _______________________________________________ > 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 satish.txt at gmail.com Thu Mar 12 20:39:47 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 12 Mar 2015 15:39:47 -0400 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: References: <54EC8943.2070308@opensips.org> <5501B010.2000507@opensips.org> Message-ID: Fetch MASTER 2.1.x and after compile i try to run and got this error, [root at opensips ]# /usr/local/opensips-2-head/sbin/opensips -c -f opensips.cfg Mar 13 01:03:43 [22204] CRITICAL:core:yyerror: parse error in config file opensips.cfg, line 60, column 1-12: syntax error Mar 13 01:03:43 [22204] CRITICAL:core:yyerror: parse error in config file opensips.cfg, line 60, column 1-12: Mar 13 01:03:43 [22204] ERROR:core:main: bad config file (2 errors) It is not supporting following option, after removing them it parse file successfully. disable_tcp=yes disable_tls=yes On Thu, Mar 12, 2015 at 3:16 PM, Satish Patel wrote: > On download page, http://www.opensips.org/Downloads/Downloads, currently > we have following. > > GIT clone of development stable version 2.1.1 (MASTER): > > Does on march 18th release will be 2.1.2 ? > > > > On Thu, Mar 12, 2015 at 11:26 AM, Bogdan-Andrei Iancu > wrote: > >> The D day for releasing 2.1 is 18th of March ! >> >> Best regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 24.02.2015 16:22, Bogdan-Andrei Iancu wrote: >> >>> Hello all, >>> >>> Everybody is looking forward for the next OpenSIPS release, the major >>> 2.1, which is planned for end of February - at least this was the plan so >>> far. >>> I our desire to make of 2.1 a radical improvement, we committed to >>> several major changes/redesigns and new valuable functionalities. And they >>> do burn time to get them done, especially as we want them : in the best >>> possible way. >>> >>> In oder to finish all we committed for, the release date is now >>> estimated for first half of March - some important parts of code still need >>> to be settled down and we do not want to make any kind of compromise in >>> quality. >>> >>> Just to give you a heads up on what OpenSIPS 2.1 will bring: >>> - internal re-design around async reactors for load-balancing tasks >>> inside OpenSIPS >>> - async I/O support in scripts for db queries, exec, rest client >>> - refactoring of the networking and protocol related code (protos >>> are now modules) >>> - webSockets support >>> - Quality Based Routing new module >>> - Compression new module >>> - Fraud Detection new module >>> - Emergency Call handling new module >>> - rtpengine support >>> - partitioning support in Dynamic Routing, Diaplan and Dispatcher >>> >>> and many other - when the coding taks is done, we will proceed withe >>> "bothersome" task of updating docs, new and migration. >>> >>> Whoever gives a try to 2.1 version, please report any problems or >>> crashes asap to us ! better have them done now rather than later :P >>> >>> Best regards, >>> >>> >> >> _______________________________________________ >> 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 tito at xsvoce.com Thu Mar 12 21:12:48 2015 From: tito at xsvoce.com (Tito Cumpen) Date: Thu, 12 Mar 2015 16:12:48 -0400 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: References: <54EC8943.2070308@opensips.org> <5501B010.2000507@opensips.org> Message-ID: Does rtp engine support ICE for both video and audio in its current version ? Does rtpengine have a page with info aside from : http://www.opensips.org/html/docs/modules/devel/rtpengine.html Satish, Are you streaming sip trace to another opensips 2.1 instance for homer purposes? The reason I ask is because I was having issues with hep headers when using versions of 1.1X Thanks, Tito On Thu, Mar 12, 2015 at 3:16 PM, Satish Patel wrote: > On download page, http://www.opensips.org/Downloads/Downloads, currently > we have following. > > GIT clone of development stable version 2.1.1 (MASTER): > > Does on march 18th release will be 2.1.2 ? > > > > On Thu, Mar 12, 2015 at 11:26 AM, Bogdan-Andrei Iancu > wrote: > >> The D day for releasing 2.1 is 18th of March ! >> >> Best regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 24.02.2015 16:22, Bogdan-Andrei Iancu wrote: >> >>> Hello all, >>> >>> Everybody is looking forward for the next OpenSIPS release, the major >>> 2.1, which is planned for end of February - at least this was the plan so >>> far. >>> I our desire to make of 2.1 a radical improvement, we committed to >>> several major changes/redesigns and new valuable functionalities. And they >>> do burn time to get them done, especially as we want them : in the best >>> possible way. >>> >>> In oder to finish all we committed for, the release date is now >>> estimated for first half of March - some important parts of code still need >>> to be settled down and we do not want to make any kind of compromise in >>> quality. >>> >>> Just to give you a heads up on what OpenSIPS 2.1 will bring: >>> - internal re-design around async reactors for load-balancing tasks >>> inside OpenSIPS >>> - async I/O support in scripts for db queries, exec, rest client >>> - refactoring of the networking and protocol related code (protos >>> are now modules) >>> - webSockets support >>> - Quality Based Routing new module >>> - Compression new module >>> - Fraud Detection new module >>> - Emergency Call handling new module >>> - rtpengine support >>> - partitioning support in Dynamic Routing, Diaplan and Dispatcher >>> >>> and many other - when the coding taks is done, we will proceed withe >>> "bothersome" task of updating docs, new and migration. >>> >>> Whoever gives a try to 2.1 version, please report any problems or >>> crashes asap to us ! better have them done now rather than later :P >>> >>> Best regards, >>> >>> >> >> _______________________________________________ >> 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 tito at xsvoce.com Thu Mar 12 21:21:10 2015 From: tito at xsvoce.com (Tito Cumpen) Date: Thu, 12 Mar 2015 16:21:10 -0400 Subject: [OpenSIPS-Users] orchestration. Message-ID: Group, I am curious about what the best approach towards orchestrating proxies based on incremental demand is. What is the best way to implement environmental variables such as ip addresses used in listening to interfaces and variables used to raise events. Is there a way for opensips to reach out and provision itself? Thanks, Tito -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at uphreak.com Thu Mar 12 21:25:04 2015 From: eric at uphreak.com (Eric Tamme) Date: Thu, 12 Mar 2015 14:25:04 -0600 Subject: [OpenSIPS-Users] Planning OpenSIPS 2.1 release - heads up In-Reply-To: References: <54EC8943.2070308@opensips.org> <5501B010.2000507@opensips.org> Message-ID: <5501F620.9060707@uphreak.com> Im not sure what you mean by "supports ICE". RTPEngine can inject itself as ice relay, or host, candidate for all streams, regardless of the number of streams in the SDP. I am working on a tutorial on how to use rtpengine with webrtc and non-webrtc clients. In the mean time you can check my github wiki for info https://github.com/etamme/federated-sip/wiki Or look at the rtpengine github https://github.com/sipwise/rtpengine for documentation. -Eric From ter.devor at gmail.com Thu Mar 12 23:00:13 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Thu, 12 Mar 2015 18:00:13 -0400 Subject: [OpenSIPS-Users] orchestration. In-Reply-To: References: Message-ID: 1) What is the best way? - Finite number of ways to cook a potato 2) Is there a way? If there is a will... :) Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Thu Mar 12 23:07:26 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Thu, 12 Mar 2015 18:07:26 -0400 Subject: [OpenSIPS-Users] rr not changed using set_advertised_address Message-ID: Hello Everyone, I sent this email earlier however did not seem to reach the list. Sorry for the redundancy. We are running opensips in a NAT environment. When trying to change the record_route using set_advertised_address in the on_reply route there is no change. I am testing using some test headers and know that the location is getting triggered however, cannot change the RR using set_advertised_address Is this not possible? Kind Regards, Terrance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Fri Mar 13 14:54:18 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Fri, 13 Mar 2015 09:54:18 -0400 Subject: [OpenSIPS-Users] Opensips-CP In-Reply-To: References: Message-ID: Bogdan/OpenSIPS team, What is the take on this. Can other users approach such offers or does the OpenSIPS team take presidency? Either way it's ok, and thought it was a good idea to ask before approaching John. Terrance ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Fri Mar 13 21:03:31 2015 From: satish.txt at gmail.com (Satish Patel) Date: Fri, 13 Mar 2015 16:03:31 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message Message-ID: Hello, Why we are getting 500 error in REGISTER time? Even i got register successfully, is it normal? 01:26:01.078025 ? REGISTER ? ? ? ??????????????????????????> ? ? 01:26:01.078032 ? REGISTER ? ? ? ????????????????????????>>> ? ? ? 01:26:01.078358 ? 401 Unauthorized ? ? ? ? ? ? ? 01:26:01.408025 ? REGISTER ? ? ? ? ????????????????????????>>> ? ? ? 01:26:01.408364 ? 200 OK ? ? ? ? ? ? ? 01:26:01.730166 ? REGISTER ? ? ? ? ????????????????????????>>> ? ? ? 01:26:01.730454 ? 401 Unauthorized ? ? ? ? ? ? ? 01:26:02.072789 ? REGISTER ? ? ? ? ????????????????????????>>> ? ? ? 01:26:02.073108 ? 200 OK ? ? ? ? From gsbabil at gmail.com Fri Mar 13 21:16:33 2015 From: gsbabil at gmail.com (Babil Golam Sarwar) Date: Fri, 13 Mar 2015 13:16:33 -0700 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Hi Satish, you should check the server logs. This could be caused by memory allocation failure, low memory and/or high CPU activity experienced by OpenSIPS on the server side. You can enable console debugging by adding the following to `opensips.cfg': debug=4 fork=no log_stderror=yes After that, restart OpenSIPS and watch the debug log output and system CPU usage. Regards, Babil (Golam Sarwar) PGP Key Fingerprint : D3A1 EED0 5BA0 72D3 A011 75CB 8EA6 7D99 F433 E92D PGP Key Download URL: http://bit.ly/gsbabil-pgp-key On Fri, Mar 13, 2015 at 1:03 PM, Satish Patel wrote: > Hello, > > Why we are getting 500 error in REGISTER time? Even i got register > successfully, is it normal? > > > 01:26:01.078025 ? REGISTER ? > ? ? ??????????????????????????> ? > ? 01:26:01.078032 ? REGISTER ? > ? ? ????????????????????????>>> ? ? > ? 01:26:01.078358 ? 401 Unauthorized ? ? > ? ? ? 01:26:01.078360 ? 401 Unauthorized ? ? > ? ? << ? 01:26:01.408019 ? REGISTER ? ? > ? ? ??????????????????????????> ? ? > ? 01:26:01.408025 ? REGISTER ? ? > ? ? ????????????????????????>>> ? ? > ? 01:26:01.408364 ? 200 OK ? ? > ? ? ? 01:26:01.408365 ? 200 OK ? ? > ? ? << ? 01:26:01.408381 ? 500 Server error occurred ? ? > ? ? ? 01:26:01.408382 ? 500 Server error occurred ? ? > ? ? << ? 01:26:01.730160 ? REGISTER ? ? > ? ? ??????????????????????????> ? ? > ? 01:26:01.730166 ? REGISTER ? ? > ? ? ????????????????????????>>> ? ? > ? 01:26:01.730454 ? 401 Unauthorized ? ? > ? ? ? 01:26:01.730455 ? 401 Unauthorized ? ? > ? ? << ? 01:26:02.072783 ? REGISTER ? ? > ? ? ??????????????????????????> ? ? > ? 01:26:02.072789 ? REGISTER ? ? > ? ? ????????????????????????>>> ? ? > ? 01:26:02.073108 ? 200 OK ? ? > ? ? ? 01:26:02.073109 ? 200 OK ? ? > ? ? << ? 01:26:02.073128 ? 500 Server error occurred ? ? > ? ? ? ? ? > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From satish.txt at gmail.com Fri Mar 13 21:30:20 2015 From: satish.txt at gmail.com (Satish Patel) Date: Fri, 13 Mar 2015 16:30:20 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Thanks for reply, I am not seeing any memory error in logs, This is testing box, so there is no load on CPU, I am registering single client. I am using multi-domain with mysql DB. This is what in debug i am seeing DBG:auth:check_response: authorization is OK ... DBG:core:mk_proxy: doing DNS lookup... DBG:sl:run_sl_callbacks: callback id 0 entered DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) On Fri, Mar 13, 2015 at 4:16 PM, Babil Golam Sarwar wrote: > Hi Satish, > you should check the server logs. This could be caused by memory > allocation failure, low memory and/or high CPU activity experienced by > OpenSIPS on the server side. > > You can enable console debugging by adding the following to `opensips.cfg': > > debug=4 > fork=no > log_stderror=yes > > After that, restart OpenSIPS and watch the debug log output and system > CPU usage. > > Regards, > Babil (Golam Sarwar) > > PGP Key Fingerprint : D3A1 EED0 5BA0 72D3 A011 75CB 8EA6 7D99 F433 E92D > PGP Key Download URL: http://bit.ly/gsbabil-pgp-key > > > On Fri, Mar 13, 2015 at 1:03 PM, Satish Patel > wrote: > > Hello, > > > > Why we are getting 500 error in REGISTER time? Even i got register > > successfully, is it normal? > > > > > > 01:26:01.078025 ? REGISTER ? > > ? ? ??????????????????????????> ? > > ? 01:26:01.078032 ? REGISTER ? > > ? ? ????????????????????????>>> ? ? > > ? 01:26:01.078358 ? 401 Unauthorized ? ? > > ? ? > ? 01:26:01.078360 ? 401 Unauthorized ? ? > > ? ? << > ? 01:26:01.408019 ? REGISTER ? ? > > ? ? ??????????????????????????> ? ? > > ? 01:26:01.408025 ? REGISTER ? ? > > ? ? ????????????????????????>>> ? ? > > ? 01:26:01.408364 ? 200 OK ? ? > > ? ? > ? 01:26:01.408365 ? 200 OK ? ? > > ? ? << > ? 01:26:01.408381 ? 500 Server error occurred ? ? > > ? ? > ? 01:26:01.408382 ? 500 Server error occurred ? ? > > ? ? << > ? 01:26:01.730160 ? REGISTER ? ? > > ? ? ??????????????????????????> ? ? > > ? 01:26:01.730166 ? REGISTER ? ? > > ? ? ????????????????????????>>> ? ? > > ? 01:26:01.730454 ? 401 Unauthorized ? ? > > ? ? > ? 01:26:01.730455 ? 401 Unauthorized ? ? > > ? ? << > ? 01:26:02.072783 ? REGISTER ? ? > > ? ? ??????????????????????????> ? ? > > ? 01:26:02.072789 ? REGISTER ? ? > > ? ? ????????????????????????>>> ? ? > > ? 01:26:02.073108 ? 200 OK ? ? > > ? ? > ? 01:26:02.073109 ? 200 OK ? ? > > ? ? << > ? 01:26:02.073128 ? 500 Server error occurred ? ? > > ? ? > ? ? ? > > > > _______________________________________________ > > 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 EWerkhoven at livevox.com Sat Mar 14 01:47:35 2015 From: EWerkhoven at livevox.com (Eric Werkhoven) Date: Sat, 14 Mar 2015 00:47:35 +0000 Subject: [OpenSIPS-Users] indeterminate is_present_hf behavior Message-ID: Hi, I've experienced some puzzling behavior with the is_present_hf function of the sipmsgops module, version 1.11. When checking for the presence of a custom header the function sometimes returns true and sometimes false for the same header in the same INVITE message. Here is the relevant code (debug xlog statements added, production code is sparser): case 3: xlog("L_INFO","TRACE[$ci]:route[conditions]:condition has header existence operator(3) where header $var(field) should exist"); if (is_present_hf("$var(field)") || $hdr($var(field)) != NULL) { xlog("L_DEBUG","TRACE[$ci]:route[conditions]:we've got a $var(field) header with value $hdr($var(field))"); if (is_present_hf("$var(field)")) { xlog("L_INFO","TRACE[$ci]:route[conditions]:111111111111111111111111111111111111111111111111we've got a $var(field) header with value $hdr($var(field))"); } else { xlog("L_INFO","TRACE[$ci]:route[conditions]:111111111111111111111111111111111111111111111111header $var(field) not found"); } } else { xlog("L_DEBUG","TRACE[$ci]:route[conditions]:header $var(field) not found"); $var(conditions_failed) = $var(conditions_failed) + 1; } if (is_present_hf("$var(field)")) { xlog("L_INFO","TRACE[$ci]:route[conditions]:222222222222222222222222222222222222222222222222we've got a $var(field) header with value $hdr($var(field))"); } else { xlog("L_INFO","TRACE[$ci]:route[conditions]:222222222222222222222222222222222222222222222222header $var(field) not found"); } break; which produces the following log: Mar 13 16:40:48 sipdr400 /usr/local/sbin/opensips[22721]: TRACE[1426279248727-2aab0be445b0-c8166130-00d1441a at XXX.XXX.XXX.XXX]:route[conditions]:condition has header existence operator(3) where header x-livevox-correlation-id should exist Mar 13 16:40:48 sipdr400 /usr/local/sbin/opensips[22721]: INFO:sipmsgops:parse_pvs_header: using hdr type name Mar 13 16:40:48 sipdr400 /usr/local/sbin/opensips[22721]: TRACE[1426279248727-2aab0be445b0-c8166130-00d1441a at XXX.XXX.XXX.XXX]:route[conditions]:111111111111111111111111111111111111111111111111we've got a x-livevox-correlation-id header with value xlvcorid Mar 13 16:40:48 sipdr400 /usr/local/sbin/opensips[22721]: TRACE[1426279248727-2aab0be445b0-c8166130-00d1441a at XXX.XXX.XXX.XXX]:route[conditions]:222222222222222222222222222222222222222222222222header x-livevox-correlation-id not found when handling this message: From: ;tag=2aaaf56b2208-0-13c4-6009-b6e9b3-2dc5137e-b6e9b3 To: Call-ID: 1426286197921-2aab3cfb22e0-c813f990-00d0059e at XXX.XXX.XXX.XXX CSeq: 1 INVITE Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;rport;branch=z9hG4bK-b6e9b3-ca80e5c0-3b30eff8-2aaaf4694408 x-accountid: 2 x-appid: 24601 x-joinsid: f652ceb9f649ceb50a1d44d2507891cc x-livevox-correlation-id: xlvcorid x-sid: 6ae1bd9e681f8da0c51809a87c345c86 x-vdirect: true Max-Forwards: 69 User-Agent: VCS11.6.67950.0 Contact: Content-Type: application/sdp Content-Length: 229 v=0 o=- 1 1 IN IP4 XXX.XXX.XXX.XXX s=XXX.XXX.XXX.XXX c=IN IP4 XXX.XXX.XXX.XXX t=0 0 m=audio 12334 RTP/AVP 101 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=ptime:20 This looks like a bug to me, or am I missing something? Anyone has an idea how this behavior is possible? thanks, Eric Werkhoven dev-voip, livevox.com? -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.mathew at divoxmedia.com Sat Mar 14 05:44:46 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Sat, 14 Mar 2015 10:14:46 +0530 Subject: [OpenSIPS-Users] Announcing rtpproxy v2.0.0 In-Reply-To: References: Message-ID: RFC3095 would be great. On Saturday, 14 March 2015, Maxim Sobolev wrote: > Do you have any particular RFC in mind? > On Mar 12, 2015 10:28 AM, "John Mathew" > wrote: > >> Hi, >> >> Maxim, >> Is there any plans for rtp header compression in future. I can't see >> anything in the change log for 2.0.0 >> >> On Tuesday, 10 March 2015, Maxim Sobolev > > wrote: >> >>> Hi All, >>> >>> I'm happy to announce that we have released rtpproxy v2.0.0. >>> >>> You can review the release notes here: >>> https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 >>> >>> -sobomax >>> >>> >> >> -- >> Sent from iPhone 6 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "rtpproxy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rtpproxy+unsubscribe at googlegroups.com >> >> . >> To post to this group, send email to rtpproxy at googlegroups.com >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com >> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- Sent from iPhone 6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.gonenc at eurotel.com.tr Thu Mar 12 19:33:08 2015 From: m.gonenc at eurotel.com.tr (Mete Gonenc) Date: Thu, 12 Mar 2015 20:33:08 +0200 Subject: [OpenSIPS-Users] [RTPproxy] Announcing rtpproxy v2.0.0 In-Reply-To: References: Message-ID: +++++1 That would be a great feature. On Thursday, March 12, 2015, John Mathew wrote: > Hi, > > Maxim, > Is there any plans for rtp header compression in future. I can't see > anything in the change log for 2.0.0 > > On Tuesday, 10 March 2015, Maxim Sobolev > wrote: > >> Hi All, >> >> I'm happy to announce that we have released rtpproxy v2.0.0. >> >> You can review the release notes here: >> https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 >> >> -sobomax >> >> > > -- > Sent from iPhone 6 > > -- > You received this message because you are subscribed to the Google Groups > "rtpproxy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rtpproxy+unsubscribe at googlegroups.com > . > To post to this group, send email to rtpproxy at googlegroups.com > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evillaron at gmail.com Sat Mar 14 02:07:13 2015 From: evillaron at gmail.com (Evandro Villaron Franceschinelli) Date: Fri, 13 Mar 2015 22:07:13 -0300 Subject: [OpenSIPS-Users] [NEW] Emergency call handling module Message-ID: *We are proud to present the opensips emergency module.* *Opensips: Emergency Module - Abstract* To make as emergency call using a single code (e.g.: 911 in US or 112 in Europe) has been a challenge for VOIP technology. This is a problem because a crucial information is missing: the user's location and the location is essential to route the call to the closest PSAP(call center responsible for answering emergency calls). This has been studied by many entities, such as the IETF, who created several RFC on the topic, and the American NENA (National Emergency Number Association), who devised a solution based on the concepts of the IETF. The main elements of this solution are, LIS (Location information server ,which is the node that determines the location of the VoIP terminal), ERDB (servers that determines the area's emergency closest PSAP due this location ), VPC (servers that manage the location and routing information associated with a call) and, most importantly, the SIP PROXY that can make routing the call according to the data sent by these servers. The OpenSIPS can be an element in this architecture acting as a SIP proxy, but need to meet the requirements of this solution. To provide this we have developed the Emergency Module, which basically makes the interface with the servers mentioned and adds the new SIP extensions that the IETF has created for this purpose. Including only two commands and some parameters in your configuration file, we enable OpenSIPS to be an important component in the solution of this problem, with great potential to meet American market or other countries that could adopt a similar architecture. For details on usage scenarios, configuration params, etc, see the online documentation at: http://www.opensips.org/html/docs/modules/2.1.x/emergency.html Best regards, Evandro/Robison -------------- next part -------------- An HTML attachment was scrubbed... URL: From sobomax at sippysoft.com Sat Mar 14 05:39:02 2015 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 13 Mar 2015 21:39:02 -0700 Subject: [OpenSIPS-Users] [RTPproxy] Re: Announcing rtpproxy v2.0.0 In-Reply-To: References: Message-ID: Do you have any particular RFC in mind? On Mar 12, 2015 10:28 AM, "John Mathew" wrote: > Hi, > > Maxim, > Is there any plans for rtp header compression in future. I can't see > anything in the change log for 2.0.0 > > On Tuesday, 10 March 2015, Maxim Sobolev wrote: > >> Hi All, >> >> I'm happy to announce that we have released rtpproxy v2.0.0. >> >> You can review the release notes here: >> https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 >> >> -sobomax >> >> > > -- > Sent from iPhone 6 > > -- > You received this message because you are subscribed to the Google Groups > "rtpproxy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rtpproxy+unsubscribe at googlegroups.com. > To post to this group, send email to rtpproxy at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sathees.co.uk Sat Mar 14 17:22:12 2015 From: mail at sathees.co.uk (mahan77) Date: Sat, 14 Mar 2015 09:22:12 -0700 (MST) Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL In-Reply-To: <14beab44bf6.danilo.sm@tin.it> References: <14beab44bf6.danilo.sm@tin.it> Message-ID: <1426350132371-7595887.post@n2.nabble.com> Hi Danilo,I?m having problem with OpenSips => Asterisk connection. Can you able to mail me your working OpenSips scripts. mail at Sathees.co.ukappreciatesathees -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OPENSIPS-IVR-CALL-CONTROL-tp7595634p7595887.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danilo.sm at tin.it Sat Mar 14 17:36:10 2015 From: danilo.sm at tin.it (danilo.sm at tin.it) Date: Sat, 14 Mar 2015 17:36:10 +0100 Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL In-Reply-To: <1426350132371-7595887.post@n2.nabble.com> References: <14beab44bf6.danilo.sm@tin.it> <1426350132371-7595887.post@n2.nabble.com> Message-ID: Hi I'm currently out of office. I will drop you an email on Monday Actually I got it working, but please tell me more about your scenario or post your section code Regards Danilo Il 14/Mar/2015 17:22 "mahan77" ha scritto: > Hi Danilo, I?m having problem with OpenSips => Asterisk connection. Can > you able to mail me your working OpenSips scripts. mail at Sathees.co.uk > appreciate sathees > ------------------------------ > View this message in context: Re: OPENSIPS + IVR CALL CONTROL > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.pisani at omnianet.it Sat Mar 14 17:46:23 2015 From: stefano.pisani at omnianet.it (Stefano Pisani) Date: Sat, 14 Mar 2015 17:46:23 +0100 Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL In-Reply-To: <1426350132371-7595887.post@n2.nabble.com> References: <14beab44bf6.danilo.sm@tin.it> <1426350132371-7595887.post@n2.nabble.com> Message-ID: <550465DF.9040506@omnianet.it> You should say something more about your issue. Il 14/03/2015 17:22, mahan77 ha scritto: > Hi Danilo, I?m having problem with OpenSips => Asterisk connection. > Can you able to mail me your working OpenSips scripts. mail at > Sathees.co.uk appreciate sathees > ------------------------------------------------------------------------ > View this message in context: Re: OPENSIPS + IVR CALL CONTROL > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sathees.co.uk Sat Mar 14 18:11:11 2015 From: mail at sathees.co.uk (mahan77) Date: Sat, 14 Mar 2015 10:11:11 -0700 (MST) Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL In-Reply-To: References: <14beab44bf6.danilo.sm@tin.it> <1426350132371-7595887.post@n2.nabble.com> Message-ID: <1426353071628-7595890.post@n2.nabble.com> Hello again Danilo, Thank you for the quick replay. I have asterisk server running at public IP. I have to use IVR, Voicemail, on hold message and incoming DDIs. All incoming DDI send direct to asterisk IP. Some DDI will play welcome message while phone rings, others will ring group and after certain time it will go direct to closed message. All these functions are working with asterisk right now. I?m getting high-level sip flood attack. Now I?m trying to secure server with OpenSIPS. That?s why if I see your scripts it will help me understand more. Looking forward to your email on Monday Many thanks sathees -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OPENSIPS-IVR-CALL-CONTROL-tp7595634p7595890.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From govoiper at gmail.com Sat Mar 14 21:12:23 2015 From: govoiper at gmail.com (SamyGo) Date: Sat, 14 Mar 2015 16:12:23 -0400 Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL In-Reply-To: <1426353071628-7595890.post@n2.nabble.com> References: <14beab44bf6.danilo.sm@tin.it> <1426350132371-7595887.post@n2.nabble.com> <1426353071628-7595890.post@n2.nabble.com> Message-ID: Thats sound like you need to ask for script doing the flood blocking and security rather than IVR call control etc. On Sat, Mar 14, 2015 at 1:11 PM, mahan77 wrote: > Hello again Danilo, > > Thank you for the quick replay. > > I have asterisk server running at public IP. > > I have to use IVR, Voicemail, on hold message and incoming DDIs. All > incoming DDI send direct to asterisk IP. > > Some DDI will play welcome message while phone rings, others will ring > group and after certain time it will go direct to closed message. All these > functions are working with asterisk right now. I?m getting high-level sip > flood attack. Now I?m trying to secure server with OpenSIPS. That?s why if > I see your scripts it will help me understand more. Looking forward to > your > email on Monday > > Many thanks > sathees > > > > > -- > View this message in context: > http://opensips-open-sip-server.1449251.n2.nabble.com/OPENSIPS-IVR-CALL-CONTROL-tp7595634p7595890.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danilo.sm at tin.it Sat Mar 14 21:46:34 2015 From: danilo.sm at tin.it (Vlad) Date: Sat, 14 Mar 2015 21:46:34 +0100 Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL Message-ID: <54AE9AF602268095@vsmtpvtin1.tin.it> (added by postmaster@tin.it) I will send you my few lines code...hope to help you Write you back asapIl 14/Mar/2015 18:11 mahan77 ha scritto: > > Hello again Danilo, > > Thank you for the quick replay. > > I have asterisk server running at public IP.? > > I have to use IVR, Voicemail, on hold message and incoming DDIs.? All > incoming DDI send direct to asterisk IP. > > Some DDI will play welcome message while phone rings, others will ring > group and after certain time it will go direct to closed message. All these > functions are working with asterisk right now.? I?m getting high-level sip > flood attack. Now I?m trying to secure server with OpenSIPS.? That?s why if > I see your scripts it will help me understand more.? Looking forward to your > email on Monday > > Many thanks > sathees > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OPENSIPS-IVR-CALL-CONTROL-tp7595634p7595890.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 ter.devor at gmail.com Sat Mar 14 22:50:41 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Sat, 14 Mar 2015 17:50:41 -0400 Subject: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL In-Reply-To: <5504a01b.a96ec20a.12fc.ffffc290SMTPIN_ADDED_BROKEN@mx.google.com> References: <5504a01b.a96ec20a.12fc.ffffc290SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Vlad, I think we could all benefit from the snippets if you know what I mean ;). T ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Mar 15 20:56:15 2015 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 15 Mar 2015 15:56:15 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Guys, any suggestion? it is Opensips 2.1.x Master branch. Is it a bug? On Fri, Mar 13, 2015 at 4:03 PM, Satish Patel wrote: > Hello, > > Why we are getting 500 error in REGISTER time? Even i got register > successfully, is it normal? > > > 01:26:01.078025 ? REGISTER ? > ? ? ??????????????????????????> ? > ? 01:26:01.078032 ? REGISTER ? > ? ? ????????????????????????>>> ? ? > ? 01:26:01.078358 ? 401 Unauthorized ? ? > ? ? ? 01:26:01.078360 ? 401 Unauthorized ? ? > ? ? << ? 01:26:01.408019 ? REGISTER ? ? > ? ? ??????????????????????????> ? ? > ? 01:26:01.408025 ? REGISTER ? ? > ? ? ????????????????????????>>> ? ? > ? 01:26:01.408364 ? 200 OK ? ? > ? ? ? 01:26:01.408365 ? 200 OK ? ? > ? ? << ? 01:26:01.408381 ? 500 Server error occurred ? ? > ? ? ? 01:26:01.408382 ? 500 Server error occurred ? ? > ? ? << ? 01:26:01.730160 ? REGISTER ? ? > ? ? ??????????????????????????> ? ? > ? 01:26:01.730166 ? REGISTER ? ? > ? ? ????????????????????????>>> ? ? > ? 01:26:01.730454 ? 401 Unauthorized ? ? > ? ? ? 01:26:01.730455 ? 401 Unauthorized ? ? > ? ? << ? 01:26:02.072783 ? REGISTER ? ? > ? ? ??????????????????????????> ? ? > ? 01:26:02.072789 ? REGISTER ? ? > ? ? ????????????????????????>>> ? ? > ? 01:26:02.073108 ? 200 OK ? ? > ? ? ? 01:26:02.073109 ? 200 OK ? ? > ? ? << ? 01:26:02.073128 ? 500 Server error occurred ? ? > ? ? ? ? ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asherif74 at hotmail.com Mon Mar 16 17:47:38 2015 From: asherif74 at hotmail.com (malik sherif) Date: Mon, 16 Mar 2015 16:47:38 +0000 Subject: [OpenSIPS-Users] SBC for Kamailio or Metaswitch In-Reply-To: References: , Message-ID: Hello, I have configured Kamailio server and sisp on the same machine. Is their a link as to how to configure sips as SBC for Kamailio serer or Metaswitch? Thanks for you help -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at uphreak.com Mon Mar 16 17:49:01 2015 From: eric at uphreak.com (Eric Tamme) Date: Mon, 16 Mar 2015 10:49:01 -0600 Subject: [OpenSIPS-Users] SBC for Kamailio or Metaswitch In-Reply-To: References: , Message-ID: <5507097D.1020203@uphreak.com> This is not a mailing list for Kamailio. On 03/16/2015 10:47 AM, malik sherif wrote: > > Hello, > I have configured Kamailio server and sisp on the same machine. Is > their a link as to how to configure sips as SBC for Kamailio serer or > Metaswitch? > Thanks for you help > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > 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 tito at xsvoce.com Mon Mar 16 17:53:32 2015 From: tito at xsvoce.com (Tito Cumpen) Date: Mon, 16 Mar 2015 12:53:32 -0400 Subject: [OpenSIPS-Users] orchestration. In-Reply-To: References: Message-ID: Terrance, Thanks for your two cents . The reason I ask is because I am hearing of aware of standards being drafted in this emerging need. I also need to weight the capabilities of opensips over sippservlets which by the way has some pretty effective ways of auto scaling : https://www.youtube.com/watch?v=Tsa0QgffZ28 On Thu, Mar 12, 2015 at 6:00 PM, Terrance Devor wrote: > 1) What is the best way? > - Finite number of ways to cook a potato > 2) Is there a way? > If there is a will... :) > > Terrance. > ? > > _______________________________________________ > 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 ter.devor at gmail.com Mon Mar 16 18:02:43 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Mon, 16 Mar 2015 13:02:43 -0400 Subject: [OpenSIPS-Users] SBC for Kamailio or Metaswitch In-Reply-To: <5507097D.1020203@uphreak.com> References: <5507097D.1020203@uphreak.com> Message-ID: Or Metaswich for that matter... -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at uphreak.com Mon Mar 16 18:03:04 2015 From: eric at uphreak.com (Eric Tamme) Date: Mon, 16 Mar 2015 11:03:04 -0600 Subject: [OpenSIPS-Users] orchestration. In-Reply-To: References: Message-ID: <55070CC8.2010809@uphreak.com> There are many ways of building scalable signaling networks with OpenSIPS, how you do it depends on your needs, and your capability. -Eric On 03/16/2015 10:53 AM, Tito Cumpen wrote: > Terrance, > > > Thanks for your two cents . The reason I ask is because I am hearing > of aware of standards being drafted in this emerging need. I also need > to weight the capabilities of opensips over sippservlets which by the > way has some pretty effective ways of auto scaling : > > https://www.youtube.com/watch?v=Tsa0QgffZ28 > > On Thu, Mar 12, 2015 at 6:00 PM, Terrance Devor > wrote: > > 1) What is the best way? > - Finite number of ways to cook a potato > 2) Is there a way? > If there is a will... :) > > Terrance. > ? > > _______________________________________________ > 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 kneeoh at yahoo.com Mon Mar 16 18:37:14 2015 From: kneeoh at yahoo.com (Kneeoh) Date: Mon, 16 Mar 2015 17:37:14 +0000 (UTC) Subject: [OpenSIPS-Users] 1.11.3 Crash on Fifo query Message-ID: <948650354.613863.1426527434100.JavaMail.yahoo@mail.yahoo.com> I just spun up a light system for testing some new things. I've been getting system crashes while running get_statistics. I've included all of the data I have. I was hoping someone could point me towards a solution to fix. Thank you. Environment: Cores: 2 x Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz Memory: 8 Gb Opensips 1.11.3 Children = 4 S_MEMORY=1024 P_MEMORY=64 Command: opensipsctl fifo get_statistics all | grep udp Debug 6 Output during crash: Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda24cf58 next=0x7f4fda575850, timeout=88 Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda575850 next=0x7f4fda5719f8, timeout=88 Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda5719f8 next=0x7f4fda56d798, timeout=88 Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node <> ; val Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node <> ; val Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node <> ; val Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:handle_sigs: status = 139 Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: child process 17057 exited by a signal 11 Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: core was generated Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: terminating due to SIGCHLD Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17051]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17050]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17053]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17052]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17058]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:cleanup: cleanup Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: NOTICE:cachedb_couchbase:destroy: destroy module cachedb_couchbase ... Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: tm_shutdown : start Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:unlink_timer_lists: emptying DELETE list for set 0 Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: emptying hash table Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: releasing timers Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: removing semaphores Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: destroying callback lists Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: tm_shutdown : done Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:shm_mem_destroy: destroying the shared memory lock Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:handle_sigs: terminating due to SIGCHLD From razvan at opensips.org Mon Mar 16 18:59:58 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 16 Mar 2015 19:59:58 +0200 Subject: [OpenSIPS-Users] [NEW] Emergency call handling module In-Reply-To: References: Message-ID: <55071A1E.6080603@opensips.org> Hello all! Thank you Evandro and Robison for the new emergency module. I bet the community will find it useful. I've added the extra documentation you provided on the wiki[1]. Therefore, anybody who is looking to deploy this feature on their platform can read and get some ideas about what the module does and how. The wiki page contains the following information: * The specifications and design of the NENA i2 architecture * Use case scenarios * Configuration examples [1] http://www.opensips.org/Documentation/Tutorials-Emergency-2-1 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/14/2015 03:07 AM, Evandro Villaron Franceschinelli wrote: > /*We are proud to present the opensips emergency module.*/ > > *Opensips: Emergency Module - Abstract* > To make as emergency call using a single code (e.g.: 911 in US or 112 > in Europe) has been a challenge for VOIP technology. This is a problem > because a crucial information is missing: the user's location and the > location is essential to route the call to the closest PSAP(call > center responsible for answering emergency calls). > > This has been studied by many entities, such as the IETF, who created > several RFC on the topic, and the American NENA (National Emergency > Number Association), who devised a solution based on the concepts of > the IETF. The main elements of this solution are, LIS (Location > information server ,which is the node that determines the location of > the VoIP terminal), ERDB (servers that determines the area's emergency > closest PSAP due this location ), VPC (servers that manage the > location and routing information associated with a call) and, most > importantly, the SIP PROXY that can make routing the call according to > the data sent by these servers. > > The OpenSIPS can be an element in this architecture acting as a SIP > proxy, but need to meet the requirements of this solution. To provide > this we have developed the Emergency Module, which basically makes the > interface with the servers mentioned and adds the new SIP extensions > that the IETF has created for this purpose. Including only two > commands and some parameters in your configuration file, we enable > OpenSIPS to be an important component in the solution of this problem, > with great potential to meet American market or other countries that > could adopt a similar architecture. > > > For details on usage scenarios, configuration params, etc, see the > online documentation at: > http://www.opensips.org/html/docs/modules/2.1.x/emergency.html > > > Best regards, > > > Evandro/Robison > > > > _______________________________________________ > 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 asherif74 at hotmail.com Mon Mar 16 19:59:14 2015 From: asherif74 at hotmail.com (malik sherif) Date: Mon, 16 Mar 2015 18:59:14 +0000 Subject: [OpenSIPS-Users] Users Digest, Vol 80, Issue 52 In-Reply-To: References: Message-ID: Eric, Thanks for your reply, My question is not about Kamailio. I just want to configure SIPS as SBC and I looking for wiki or some info if available to configure it as SBC. Thanks Abdul > From: users-request at lists.opensips.org > Subject: Users Digest, Vol 80, Issue 52 > To: users at lists.opensips.org > Date: Mon, 16 Mar 2015 19:00:06 +0100 > > Send Users mailing list submissions to > users at lists.opensips.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-request at lists.opensips.org > > You can reach the person managing the list at > users-owner at lists.opensips.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: SBC for Kamailio or Metaswitch (malik sherif) > 2. Re: SBC for Kamailio or Metaswitch (Eric Tamme) > 3. Re: orchestration. (Tito Cumpen) > 4. Re: SBC for Kamailio or Metaswitch (Terrance Devor) > 5. Re: orchestration. (Eric Tamme) > 6. 1.11.3 Crash on Fifo query (Kneeoh) > 7. Re: [NEW] Emergency call handling module (R?zvan Crainea) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Mar 2015 16:47:38 +0000 > From: malik sherif > Subject: Re: [OpenSIPS-Users] SBC for Kamailio or Metaswitch > To: "users at lists.opensips.org" > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Hello, > I have configured Kamailio server and sisp on the same > machine. Is their a link as to how to configure sips as SBC for > Kamailio serer or Metaswitch? > Thanks for you help > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Mon, 16 Mar 2015 10:49:01 -0600 > From: Eric Tamme > Subject: Re: [OpenSIPS-Users] SBC for Kamailio or Metaswitch > To: OpenSIPS users mailling list > Message-ID: <5507097D.1020203 at uphreak.com> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > This is not a mailing list for Kamailio. > > > On 03/16/2015 10:47 AM, malik sherif wrote: > > > > Hello, > > I have configured Kamailio server and sisp on the same machine. Is > > their a link as to how to configure sips as SBC for Kamailio serer or > > Metaswitch? > > Thanks for you help > > > > ------------------------------------------------------------------------ > > > > > > > > > > _______________________________________________ > > 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: > > ------------------------------ > > Message: 3 > Date: Mon, 16 Mar 2015 12:53:32 -0400 > From: Tito Cumpen > Subject: Re: [OpenSIPS-Users] orchestration. > To: OpenSIPS users mailling list > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Terrance, > > > Thanks for your two cents . The reason I ask is because I am hearing of > aware of standards being drafted in this emerging need. I also need to > weight the capabilities of opensips over sippservlets which by the way has > some pretty effective ways of auto scaling : > > https://www.youtube.com/watch?v=Tsa0QgffZ28 > > On Thu, Mar 12, 2015 at 6:00 PM, Terrance Devor wrote: > > > 1) What is the best way? > > - Finite number of ways to cook a potato > > 2) Is there a way? > > If there is a will... :) > > > > Terrance. > > ? > > > > _______________________________________________ > > 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: > > ------------------------------ > > Message: 4 > Date: Mon, 16 Mar 2015 13:02:43 -0400 > From: Terrance Devor > Subject: Re: [OpenSIPS-Users] SBC for Kamailio or Metaswitch > To: OpenSIPS users mailling list > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Or Metaswich for that matter... > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 5 > Date: Mon, 16 Mar 2015 11:03:04 -0600 > From: Eric Tamme > Subject: Re: [OpenSIPS-Users] orchestration. > To: OpenSIPS users mailling list > Message-ID: <55070CC8.2010809 at uphreak.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > There are many ways of building scalable signaling networks with > OpenSIPS, how you do it depends on your needs, and your capability. > > -Eric > > On 03/16/2015 10:53 AM, Tito Cumpen wrote: > > Terrance, > > > > > > Thanks for your two cents . The reason I ask is because I am hearing > > of aware of standards being drafted in this emerging need. I also need > > to weight the capabilities of opensips over sippservlets which by the > > way has some pretty effective ways of auto scaling : > > > > https://www.youtube.com/watch?v=Tsa0QgffZ28 > > > > On Thu, Mar 12, 2015 at 6:00 PM, Terrance Devor > > wrote: > > > > 1) What is the best way? > > - Finite number of ways to cook a potato > > 2) Is there a way? > > If there is a will... :) > > > > Terrance. > > ? > > > > _______________________________________________ > > 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: > > ------------------------------ > > Message: 6 > Date: Mon, 16 Mar 2015 17:37:14 +0000 (UTC) > From: Kneeoh > Subject: [OpenSIPS-Users] 1.11.3 Crash on Fifo query > To: Opensips Users > Message-ID: > <948650354.613863.1426527434100.JavaMail.yahoo at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > I just spun up a light system for testing some new things. I've been getting system crashes while running get_statistics. I've included all of the data I have. I was hoping someone could point me towards a solution to fix. Thank you. > > > Environment: > > Cores: 2 x > Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz > > Memory: 8 Gb > > Opensips 1.11.3 > > Children = 4 > > > S_MEMORY=1024 > P_MEMORY=64 > > > Command: > > opensipsctl fifo get_statistics all | grep udp > > > Debug 6 Output during crash: > > Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda24cf58 next=0x7f4fda575850, timeout=88 > Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda575850 next=0x7f4fda5719f8, timeout=88 > Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda5719f8 next=0x7f4fda56d798, timeout=88 > Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node <> ; val > Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree > Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree > Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node <> ; val > Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree > Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node <> ; val > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:handle_sigs: status = 139 > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: child process 17057 exited by a signal 11 > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: core was generated > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: terminating due to SIGCHLD > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17051]: INFO:core:sig_usr: signal 15 received > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17050]: INFO:core:sig_usr: signal 15 received > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17053]: INFO:core:sig_usr: signal 15 received > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17052]: INFO:core:sig_usr: signal 15 received > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: INFO:core:sig_usr: signal 15 received > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17058]: INFO:core:sig_usr: signal 15 received > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:cleanup: cleanup > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: NOTICE:cachedb_couchbase:destroy: destroy module cachedb_couchbase ... > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: tm_shutdown : start > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:unlink_timer_lists: emptying DELETE list for set 0 > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: emptying hash table > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: releasing timers > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: removing semaphores > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: destroying callback lists > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: tm_shutdown : done > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:shm_mem_destroy: destroying the shared memory lock > Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:handle_sigs: terminating due to SIGCHLD > > > > ------------------------------ > > Message: 7 > Date: Mon, 16 Mar 2015 19:59:58 +0200 > From: R?zvan Crainea > Subject: Re: [OpenSIPS-Users] [NEW] Emergency call handling module > To: OpenSIPS users mailling list , > devel at lists.opensips.org, business at lists.opensips.org, > news at lists.opensips.org > Message-ID: <55071A1E.6080603 at opensips.org> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello all! > > Thank you Evandro and Robison for the new emergency module. I bet the > community will find it useful. > > I've added the extra documentation you provided on the wiki[1]. > Therefore, anybody who is looking to deploy this feature on their > platform can read and get some ideas about what the module does and how. > The wiki page contains the following information: > * The specifications and design of the NENA i2 architecture > * Use case scenarios > * Configuration examples > > [1] http://www.opensips.org/Documentation/Tutorials-Emergency-2-1 > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/14/2015 03:07 AM, Evandro Villaron Franceschinelli wrote: > > /*We are proud to present the opensips emergency module.*/ > > > > *Opensips: Emergency Module - Abstract* > > To make as emergency call using a single code (e.g.: 911 in US or 112 > > in Europe) has been a challenge for VOIP technology. This is a problem > > because a crucial information is missing: the user's location and the > > location is essential to route the call to the closest PSAP(call > > center responsible for answering emergency calls). > > > > This has been studied by many entities, such as the IETF, who created > > several RFC on the topic, and the American NENA (National Emergency > > Number Association), who devised a solution based on the concepts of > > the IETF. The main elements of this solution are, LIS (Location > > information server ,which is the node that determines the location of > > the VoIP terminal), ERDB (servers that determines the area's emergency > > closest PSAP due this location ), VPC (servers that manage the > > location and routing information associated with a call) and, most > > importantly, the SIP PROXY that can make routing the call according to > > the data sent by these servers. > > > > The OpenSIPS can be an element in this architecture acting as a SIP > > proxy, but need to meet the requirements of this solution. To provide > > this we have developed the Emergency Module, which basically makes the > > interface with the servers mentioned and adds the new SIP extensions > > that the IETF has created for this purpose. Including only two > > commands and some parameters in your configuration file, we enable > > OpenSIPS to be an important component in the solution of this problem, > > with great potential to meet American market or other countries that > > could adopt a similar architecture. > > > > > > For details on usage scenarios, configuration params, etc, see the > > online documentation at: > > http://www.opensips.org/html/docs/modules/2.1.x/emergency.html > > > > > > Best regards, > > > > > > Evandro/Robison > > > > > > > > _______________________________________________ > > 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: > > ------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > End of Users Digest, Vol 80, Issue 52 > ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.mathew at divoxmedia.com Tue Mar 17 04:56:14 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Tue, 17 Mar 2015 09:26:14 +0530 Subject: [OpenSIPS-Users] Announcing rtpproxy v2.0.0 In-Reply-To: References: Message-ID: Yes On Tuesday, 17 March 2015, Zheng Frank wrote: > Do you mean ROHC ? > > 2015-03-14 12:39 GMT+08:00 Maxim Sobolev >: > >> Do you have any particular RFC in mind? >> On Mar 12, 2015 10:28 AM, "John Mathew" > > wrote: >> >>> Hi, >>> >>> Maxim, >>> Is there any plans for rtp header compression in future. I can't see >>> anything in the change log for 2.0.0 >>> >>> >>> On Tuesday, 10 March 2015, Maxim Sobolev >> > wrote: >>> >>>> Hi All, >>>> >>>> I'm happy to announce that we have released rtpproxy v2.0.0. >>>> >>>> You can review the release notes here: >>>> https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 >>>> >>>> -sobomax >>>> >>>> >>> >>> -- >>> Sent from iPhone 6 >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "rtpproxy" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to rtpproxy+unsubscribe at googlegroups.com >>> >>> . >>> To post to this group, send email to rtpproxy at googlegroups.com >>> . >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com >>> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users at lists.sip-router.org >> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> > -- Sent from iPhone 6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danilo.sm at tin.it Tue Mar 17 11:26:44 2015 From: danilo.sm at tin.it (danilo.sm at tin.it) Date: Tue, 17 Mar 2015 11:26:44 +0100 (CET) Subject: [OpenSIPS-Users] R: Re: OPENSIPS + IVR CALL CONTROL Message-ID: <14c27457022.danilo.sm@tin.it> hi all Sorry for delay these are my few lines to include in the routing logic to manage OpenSips + Asterisk IVR On OpenSips Box if($rU=="){ rewriteuri("sip:@:"); t_relay(); resetflag(IDN); # Reset flag used to get in this subroutine } On Asterisk Box [inbound-context] include => exten_context [exten_context] exten => aexten,1,Answer() exten => aexten,n,Background(/ivr/ivr_file) exten => aexten,n,WaitExten(10) exten => aexten,n,NoOp() exten => aexten,n,Return() exten => t,1,Hangup() exten => 1,1,Dial(SIP//,20) exten => 2,1,Dial(SIP//,20) Hope this can help ----Messaggio originale---- Da: mail at sathees.co.uk Data: 14-mar-2015 18.11 A: Ogg: Re: [OpenSIPS-Users] OPENSIPS + IVR CALL CONTROL Hello again Danilo, Thank you for the quick replay. I have asterisk server running at public IP. I have to use IVR, Voicemail, on hold message and incoming DDIs. All incoming DDI send direct to asterisk IP. Some DDI will play welcome message while phone rings, others will ring group and after certain time it will go direct to closed message. All these functions are working with asterisk right now. I?m getting high-level sip flood attack. Now I?m trying to secure server with OpenSIPS. That?s why if I see your scripts it will help me understand more. Looking forward to your email on Monday Many thanks sathees -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OPENSIPS-IVR-CALL-CONTROL-tp7595634p7595890.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Tue Mar 17 14:12:35 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 09:12:35 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Bump! Developers any thought? It is critical, getting error on 2.1 branch. -- Sent from my iPhone > On Mar 15, 2015, at 3:56 PM, Satish Patel wrote: > > Guys, > > any suggestion? it is Opensips 2.1.x Master branch. Is it a bug? > >> On Fri, Mar 13, 2015 at 4:03 PM, Satish Patel wrote: >> Hello, >> >> Why we are getting 500 error in REGISTER time? Even i got register successfully, is it normal? >> >> >> 01:26:01.078025 ? REGISTER ? >> ? ? ??????????????????????????> ? >> ? 01:26:01.078032 ? REGISTER ? >> ? ? ????????????????????????>>> ? ? >> ? 01:26:01.078358 ? 401 Unauthorized ? ? >> ? ? > ? 01:26:01.078360 ? 401 Unauthorized ? ? >> ? ? <<> ? 01:26:01.408019 ? REGISTER ? ? >> ? ? ??????????????????????????> ? ? >> ? 01:26:01.408025 ? REGISTER ? ? >> ? ? ????????????????????????>>> ? ? >> ? 01:26:01.408364 ? 200 OK ? ? >> ? ? > ? 01:26:01.408365 ? 200 OK ? ? >> ? ? <<> ? 01:26:01.408381 ? 500 Server error occurred ? ? >> ? ? > ? 01:26:01.408382 ? 500 Server error occurred ? ? >> ? ? <<> ? 01:26:01.730160 ? REGISTER ? ? >> ? ? ??????????????????????????> ? ? >> ? 01:26:01.730166 ? REGISTER ? ? >> ? ? ????????????????????????>>> ? ? >> ? 01:26:01.730454 ? 401 Unauthorized ? ? >> ? ? > ? 01:26:01.730455 ? 401 Unauthorized ? ? >> ? ? <<> ? 01:26:02.072783 ? REGISTER ? ? >> ? ? ??????????????????????????> ? ? >> ? 01:26:02.072789 ? REGISTER ? ? >> ? ? ????????????????????????>>> ? ? >> ? 01:26:02.073108 ? 200 OK ? ? >> ? ? > ? 01:26:02.073109 ? 200 OK ? ? >> ? ? <<> ? 01:26:02.073128 ? 500 Server error occurred ? ? >> ? ? > ? ? ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 17 16:08:38 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 17 Mar 2015 11:08:38 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Hello Satish, I'm not a developer, but could you post your is_method("REGISTER") for the authentication block? Also post one of the entries in the Subscriber table. Are you using clear text password or encrypted? Please look at: http://www.techsupportalert.com/content/how-ask-question-when-you-want-technical-help.htm Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Tue Mar 17 16:25:10 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 11:25:10 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Here you go, Yes we are storing password in clear text, Everything works! authentication, calling etc.. Only issue is if i check on siptrace it is sending 500 Error, Don't know who is generating it. if (is_method("REGISTER")) { $var(auth_code) = www_authorize("", "subscriber"); if ( $var(auth_code) == -1 || $var(auth_code) == -2 ) { xlog("L_NOTICE","Auth error for $fU@$fd from $si cause $var(auth_code)"); } if ( $var(auth_code) < 0 ) { www_challenge("", "0"); exit; } if (!db_check_to()) { xlog("L_INFO", "Spoofed To-URI detected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("403","Forbidden auth ID"); exit; } if ( 0 ) setflag(TCP_PERSISTENT); if (!save("location")) xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_reply_error(); exit; } Here is the subscriber table entry: mysql> select * from subscriber; +----+----------+-------------------+----------+---------------+----------------------------------+----------------------------------+------+-------+ | id | username | domain | password | email_address | ha1 | ha1b | rpid | quota | +----+----------+-------------------+----------+---------------+----------------------------------+----------------------------------+------+-------+ | 53 | 1001 | sip.example.com | ty%^#Fg8 | | 7a38833eb31f51e2596aeb1e2fb7d94d | 2f39eaec251f1fab847a4ff7ee01765d | | 1 | On Tue, Mar 17, 2015 at 11:08 AM, Terrance Devor wrote: > Hello Satish, > > I'm not a developer, but could you post your is_method("REGISTER") for the > authentication block? Also post one of the entries in the Subscriber > table. Are > you using clear text password or encrypted? > > Please look at: > http://www.techsupportalert.com/content/how-ask-question-when-you-want-technical-help.htm > > Terrance. > ? > > _______________________________________________ > 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 ter.devor at gmail.com Tue Mar 17 17:26:46 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 17 Mar 2015 12:26:46 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Can you please provide a sip trace. Who is sending the 500? Your media server? T ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzcudunl at yahoo.it Tue Mar 17 17:37:48 2015 From: uzcudunl at yahoo.it (leo) Date: Tue, 17 Mar 2015 09:37:48 -0700 (MST) Subject: [OpenSIPS-Users] SIP/2.0 477 Send failed (477/TM) - Route Message-ID: <1426610268851-7595929.post@n2.nabble.com> Hello, I'm receiving the following message when a try to place a call: SIP/2.0 477 Send failed (477/TM) This is desired issue because the callee UA is not online and in userloc it is not expired yet. My question is, which would be the process or the route this event (477 Send failed) is processed? I've tried to log on failure_route, onreply_route and even on branch_route but it was unsuccessful. Thanks a lot, Leo -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/SIP-2-0-477-Send-failed-477-TM-Route-tp7595929.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From satish.txt at gmail.com Tue Mar 17 17:43:14 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 12:43:14 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: Following is trace, OpenSIPs sending 500 to UA ( SIP Phone), Here is the pastebin. http://pastebin.com/UPhNVSGZ [SIP-Phone] [OpenSIP Proxy] 11:33:21.331372 ? REGISTER ? ? ? ??????????????????????????> ? ? 11:33:21.331515 ? 401 Unauthorized ? ? ? ? ? 11:33:21.434499 ? 200 OK ? ? ? ? ? 11:33:21.547265 ? 401 Unauthorized ? ? ? ? ? 11:33:21.644437 ? 200 OK ? ? ? ? ? 11:33:21.747211 ? 401 Unauthorized ? ? ? ? ? 11:33:21.847256 ? 200 OK ? ? ? wrote: > Can you please provide a sip trace. Who is sending the 500? Your media > server? > > T > ? > > _______________________________________________ > 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 at uphreak.com Tue Mar 17 17:45:54 2015 From: eric at uphreak.com (Eric Tamme) Date: Tue, 17 Mar 2015 10:45:54 -0600 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: Message-ID: <55085A42.2010900@uphreak.com> This is a ladder diagram, not a sip trace. A ladder diagram is not useful in this case. Turn your debug up to 4, capture the log of the register/500 happening and submit a link to the pastebin. DO NOT paste the contents into an email. From satish.txt at gmail.com Tue Mar 17 18:07:32 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 13:07:32 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55085A42.2010900@uphreak.com> References: <55085A42.2010900@uphreak.com> Message-ID: Here is the debug 4 logs http://pastebin.com/CdPxFrNp 173.48.111.111 - UA 188.79.242.164 - OpenSIPs On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: > This is a ladder diagram, not a sip trace. A ladder diagram is not useful > in this case. > > Turn your debug up to 4, capture the log of the register/500 happening and > submit a link to the pastebin. DO NOT paste the contents into an email. > > > _______________________________________________ > 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 at uphreak.com Tue Mar 17 18:11:35 2015 From: eric at uphreak.com (Eric Tamme) Date: Tue, 17 Mar 2015 11:11:35 -0600 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> Message-ID: <55086047.6020406@uphreak.com> I do not see the 500 from opensips in this log. On 03/17/2015 11:07 AM, Satish Patel wrote: > Here is the debug 4 logs http://pastebin.com/CdPxFrNp > > 173.48.111.111 - UA > 188.79.242.164 - OpenSIPs > > On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme > wrote: > > This is a ladder diagram, not a sip trace. A ladder diagram is > not useful in this case. > > Turn your debug up to 4, capture the log of the register/500 > happening and submit a link to the pastebin. DO NOT paste the > contents into an email. > > > _______________________________________________ > 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 eric at uphreak.com Tue Mar 17 18:14:59 2015 From: eric at uphreak.com (Eric Tamme) Date: Tue, 17 Mar 2015 11:14:59 -0600 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55086047.6020406@uphreak.com> References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> Message-ID: <55086113.8010302@uphreak.com> Ah - nm, i see it in an sl callback Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) ... so are you doing anything statless in your config? This looks like it might be siptrace related. On 03/17/2015 11:11 AM, Eric Tamme wrote: > I do not see the 500 from opensips in this log. > > On 03/17/2015 11:07 AM, Satish Patel wrote: >> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >> >> 173.48.111.111 - UA >> 188.79.242.164 - OpenSIPs >> >> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme > > wrote: >> >> This is a ladder diagram, not a sip trace. A ladder diagram is >> not useful in this case. >> >> Turn your debug up to 4, capture the log of the register/500 >> happening and submit a link to the pastebin. DO NOT paste the >> contents into an email. >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Tue Mar 17 18:15:54 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 13:15:54 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55086047.6020406@uphreak.com> References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> Message-ID: I have set debug level 9 but still not seeing any 500 in logs debug=9 log_stderror=no log_facility=LOG_LOCAL7 On Tue, Mar 17, 2015 at 1:11 PM, Eric Tamme wrote: > I do not see the 500 from opensips in this log. > > > On 03/17/2015 11:07 AM, Satish Patel wrote: > > Here is the debug 4 logs http://pastebin.com/CdPxFrNp > > 173.48.111.111 - UA > 188.79.242.164 - OpenSIPs > > On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: > >> This is a ladder diagram, not a sip trace. A ladder diagram is not >> useful in this case. >> >> Turn your debug up to 4, capture the log of the register/500 happening >> and submit a link to the pastebin. DO NOT paste the contents into an >> email. >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Tue Mar 17 18:19:03 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 13:19:03 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55086113.8010302@uphreak.com> References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> Message-ID: I haven't done anything related "stateless". also in my config, i haven't manually specify that 500 error anywhere where i can doubt. I don't know from where it is coming. must be internally from opensips. On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme wrote: > Ah - nm, i see it in an sl callback > > Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) > > ... so are you doing anything statless in your config? This looks like it might be siptrace related. > > > > On 03/17/2015 11:11 AM, Eric Tamme wrote: > > I do not see the 500 from opensips in this log. > > On 03/17/2015 11:07 AM, Satish Patel wrote: > > Here is the debug 4 logs http://pastebin.com/CdPxFrNp > > 173.48.111.111 - UA > 188.79.242.164 - OpenSIPs > > On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: > >> This is a ladder diagram, not a sip trace. A ladder diagram is not >> useful in this case. >> >> Turn your debug up to 4, capture the log of the register/500 happening >> and submit a link to the pastebin. DO NOT paste the contents into an >> email. >> >> >> _______________________________________________ >> 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 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 eric at uphreak.com Tue Mar 17 18:20:03 2015 From: eric at uphreak.com (Eric Tamme) Date: Tue, 17 Mar 2015 11:20:03 -0600 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> Message-ID: <55086243.1070605@uphreak.com> Turn of your sip tracing and see if the issue occurs. Its running some sl_callbacks (which i assume are realated to siptrace). On 03/17/2015 11:19 AM, Satish Patel wrote: > I haven't done anything related "stateless". also in my config, i > haven't manually specify that 500 error anywhere where i can doubt. I > don't know from where it is coming. must be internally from opensips. > > On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme > wrote: > > Ah - nm, i see it in an sl callback > > Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) > > ... so are you doing anything statless in your config? This looks like it might be siptrace related. > > > > On 03/17/2015 11:11 AM, Eric Tamme wrote: >> I do not see the 500 from opensips in this log. >> >> On 03/17/2015 11:07 AM, Satish Patel wrote: >>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>> >>> 173.48.111.111 - UA >>> 188.79.242.164 - OpenSIPs >>> >>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme >> > wrote: >>> >>> This is a ladder diagram, not a sip trace. A ladder diagram >>> is not useful in this case. >>> >>> Turn your debug up to 4, capture the log of the register/500 >>> happening and submit a link to the pastebin. DO NOT paste >>> the contents into an email. >>> >>> >>> _______________________________________________ >>> 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 satish.txt at gmail.com Tue Mar 17 18:27:45 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 13:27:45 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55086243.1070605@uphreak.com> References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> Message-ID: Even after disabled "siptrace" it is happening. no luck :( On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme wrote: > Turn of your sip tracing and see if the issue occurs. Its running some > sl_callbacks (which i assume are realated to siptrace). > > > > On 03/17/2015 11:19 AM, Satish Patel wrote: > > I haven't done anything related "stateless". also in my config, i haven't > manually specify that 500 error anywhere where i can doubt. I don't know > from where it is coming. must be internally from opensips. > > On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme wrote: > >> Ah - nm, i see it in an sl callback >> >> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >> >> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >> >> >> >> On 03/17/2015 11:11 AM, Eric Tamme wrote: >> >> I do not see the 500 from opensips in this log. >> >> On 03/17/2015 11:07 AM, Satish Patel wrote: >> >> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >> >> 173.48.111.111 - UA >> 188.79.242.164 - OpenSIPs >> >> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: >> >>> This is a ladder diagram, not a sip trace. A ladder diagram is not >>> useful in this case. >>> >>> Turn your debug up to 4, capture the log of the register/500 happening >>> and submit a link to the pastebin. DO NOT paste the contents into an >>> email. >>> >>> >>> _______________________________________________ >>> 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 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 satish.txt at gmail.com Tue Mar 17 18:48:00 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 13:48:00 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> Message-ID: Eric, I found what was the issue, I sent you REGISTER method snippet before, if you look at it, If remove/comment out "sl_reply_error();" line in following code, it stopped sending 500 Error. Very interesting.. Do you think i need to put that in "curly braces" { } ? if (!save("location")) xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_reply_error(); exit; } On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel wrote: > Even after disabled "siptrace" it is happening. no luck :( > > On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme wrote: > >> Turn of your sip tracing and see if the issue occurs. Its running some >> sl_callbacks (which i assume are realated to siptrace). >> >> >> >> On 03/17/2015 11:19 AM, Satish Patel wrote: >> >> I haven't done anything related "stateless". also in my config, i >> haven't manually specify that 500 error anywhere where i can doubt. I >> don't know from where it is coming. must be internally from opensips. >> >> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme wrote: >> >>> Ah - nm, i see it in an sl callback >>> >>> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >>> >>> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >>> >>> >>> >>> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>> >>> I do not see the 500 from opensips in this log. >>> >>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>> >>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>> >>> 173.48.111.111 - UA >>> 188.79.242.164 - OpenSIPs >>> >>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: >>> >>>> This is a ladder diagram, not a sip trace. A ladder diagram is not >>>> useful in this case. >>>> >>>> Turn your debug up to 4, capture the log of the register/500 happening >>>> and submit a link to the pastebin. DO NOT paste the contents into an >>>> email. >>>> >>>> >>>> _______________________________________________ >>>> 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 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 satish.txt at gmail.com Tue Mar 17 18:52:19 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 13:52:19 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> Message-ID: I got those code from Book Building Telephony System with OpenSIPS 1.6 Here is the code from book if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) ##if (!www_authorize("", "subscriber")) ##{ ## www_challenge("", "0"); ## exit; ##} ## ##if (!db_check_to()) ##{ ## sl_send_reply("403","Forbidden auth ID"); ## exit; ##} if (!save("location")) sl_reply_error(); exit; } } On Tue, Mar 17, 2015 at 1:48 PM, Satish Patel wrote: > Eric, > > I found what was the issue, I sent you REGISTER method snippet before, if > you look at it, If remove/comment out "sl_reply_error();" line in > following code, it stopped sending 500 Error. Very interesting.. Do you > think i need to put that in "curly braces" { } ? > > if (!save("location")) > xlog("L_ERR", "Saving contact failed - M=$rm > RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); > sl_reply_error(); > > exit; > } > > > On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel > wrote: > >> Even after disabled "siptrace" it is happening. no luck :( >> >> On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme wrote: >> >>> Turn of your sip tracing and see if the issue occurs. Its running some >>> sl_callbacks (which i assume are realated to siptrace). >>> >>> >>> >>> On 03/17/2015 11:19 AM, Satish Patel wrote: >>> >>> I haven't done anything related "stateless". also in my config, i >>> haven't manually specify that 500 error anywhere where i can doubt. I >>> don't know from where it is coming. must be internally from opensips. >>> >>> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme wrote: >>> >>>> Ah - nm, i see it in an sl callback >>>> >>>> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >>>> >>>> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >>>> >>>> >>>> >>>> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>>> >>>> I do not see the 500 from opensips in this log. >>>> >>>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>> >>>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>>> >>>> 173.48.111.111 - UA >>>> 188.79.242.164 - OpenSIPs >>>> >>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: >>>> >>>>> This is a ladder diagram, not a sip trace. A ladder diagram is not >>>>> useful in this case. >>>>> >>>>> Turn your debug up to 4, capture the log of the register/500 happening >>>>> and submit a link to the pastebin. DO NOT paste the contents into an >>>>> email. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 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 eric at uphreak.com Tue Mar 17 18:54:32 2015 From: eric at uphreak.com (Eric Tamme) Date: Tue, 17 Mar 2015 11:54:32 -0600 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> Message-ID: <55086A58.2040903@uphreak.com> You are missing the left curly brace after your if statment.... im suprised your script runs at all On 03/17/2015 11:48 AM, Satish Patel wrote: > Eric, > > I found what was the issue, I sent you REGISTER method snippet before, > if you look at it, If remove/comment out "sl_reply_error();" line in > following code, it stopped sending 500 Error. Very interesting.. Do > you think i need to put that in "curly braces" { } ? > > if (!save("location")) > xlog("L_ERR", "Saving contact failed - M=$rm > RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); > sl_reply_error(); > > exit; > } > > > On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel > wrote: > > Even after disabled "siptrace" it is happening. no luck :( > > On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme > wrote: > > Turn of your sip tracing and see if the issue occurs. Its > running some sl_callbacks (which i assume are realated to > siptrace). > > > > On 03/17/2015 11:19 AM, Satish Patel wrote: >> I haven't done anything related "stateless". also in my >> config, i haven't manually specify that 500 error anywhere >> where i can doubt. I don't know from where it is coming. >> must be internally from opensips. >> >> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme > > wrote: >> >> Ah - nm, i see it in an sl callback >> >> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >> >> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >> >> >> >> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>> I do not see the 500 from opensips in this log. >>> >>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>>> >>>> 173.48.111.111 - UA >>>> 188.79.242.164 - OpenSIPs >>>> >>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme >>>> > wrote: >>>> >>>> This is a ladder diagram, not a sip trace. A >>>> ladder diagram is not useful in this case. >>>> >>>> Turn your debug up to 4, capture the log of the >>>> register/500 happening and submit a link to the >>>> pastebin. DO NOT paste the contents into an email. >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > > > > _______________________________________________ > 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 gsbabil at gmail.com Tue Mar 17 19:08:19 2015 From: gsbabil at gmail.com (Babil Golam Sarwar) Date: Tue, 17 Mar 2015 18:08:19 +0000 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55086D9B.2040103@gmail.com> References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> <55086D9B.2040103@gmail.com> Message-ID: There's a mismatched curly-brace issue in your configuration. Brace at line 2 matches with brace at line 18. Nothing matches with the closing curly-brace at line 19. I think we are missing a curly-brace at line 15. My two-cents to the OpenSIPS team would be consider verbose curly-braces for the configuration script. Python/C like tab-based indenting might seem to improve readability and keep the code concise, but it introduces these unintended errors. ``` 1 if (is_method("REGISTER")) 2 { 3 # authenticate the REGISTER requests (uncomment to enable auth) 4 ##if (!www_authorize("", "subscriber")) 5 ##{ 6 ## www_challenge("", "0"); 7 ## exit; 8 ##} 9 ## 10 ##if (!db_check_to()) 11 ##{ 12 ## sl_send_reply("403","Forbidden auth ID"); 13 ## exit; 14 ##} 15 if (!save("location")) 16 sl_reply_error(); 17 exit; 18 } 19 } 20 ``` -- Regards, Babil (Golam Sarwar) Skype: gsbabil Phone: +1-470-222-4511 (SMS and voice-mail only) PGP Key Fingerprint : D3A1 EED0 5BA0 72D3 A011 75CB 8EA6 7D99 F433 E92D PGP Key Download URL: http://bit.ly/gsbabil-pgp-key On Tue, Mar 17, 2015 at 11:06 AM Babil (Golam Sarwar) wrote: > There's a mismatched curly-brace issue in your configuration. > > Brace at line 2 matches with brace at line 18. Nothing matches with the > closing curly-brace at line 19. I think we are missing a curly-brace at > line 15. > > My two-cents to the OpenSIPS team would be consider verbose curly-braces > for the configuration script. Python/C like tab-based indenting might > seem to improve readability and keep the code concise, but it introduces > these unintended errors. > > > ``` > 1 if (is_method("REGISTER")) > 2 { > 3 # authenticate the REGISTER requests (uncomment to enable auth) > 4 ##if (!www_authorize("", "subscriber")) > 5 ##{ > 6 ## www_challenge("", "0"); > 7 ## exit; > 8 ##} > 9 ## > 10 ##if (!db_check_to()) > 11 ##{ > 12 ## sl_send_reply("403","Forbidden auth ID"); > 13 ## exit; > 14 ##} > 15 if (!save("location")) > 16 sl_reply_error(); > 17 exit; > 18 } > 19 } > 20 > ``` > > On 3/17/15 10:52 AM, Satish Patel wrote: > > I got those code from Book Building Telephony System with OpenSIPS 1.6 > > > > Here is the code from book > > > > if (is_method("REGISTER")) > > { > > # authenticate the REGISTER requests (uncomment to enable auth) > > ##if (!www_authorize("", "subscriber")) > > ##{ > > ## www_challenge("", "0"); > > ## exit; > > ##} > > ## > > ##if (!db_check_to()) > > ##{ > > ## sl_send_reply("403","Forbidden auth ID"); > > ## exit; > > ##} > > if (!save("location")) > > sl_reply_error(); > > exit; > > } > > } > > > > > > > > On Tue, Mar 17, 2015 at 1:48 PM, Satish Patel > > wrote: > > > > Eric, > > > > I found what was the issue, I sent you REGISTER method snippet > > before, if you look at it, If remove/comment out "sl_reply_error();" > > line in following code, it stopped sending 500 Error. Very > > interesting.. Do you think i need to put that in "curly braces" { } > ? > > > > if (!save("location")) > > xlog("L_ERR", "Saving contact failed - M=$rm > > RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); > > sl_reply_error(); > > > > exit; > > } > > > > > > On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel > > wrote: > > > > Even after disabled "siptrace" it is happening. no luck :( > > > > On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme > > wrote: > > > > Turn of your sip tracing and see if the issue occurs. Its > > running some sl_callbacks (which i assume are realated to > > siptrace). > > > > > > > > On 03/17/2015 11:19 AM, Satish Patel wrote: > >> I haven't done anything related "stateless". also in my > >> config, i haven't manually specify that 500 error anywhere > >> where i can doubt. I don't know from where it is coming. > >> must be internally from opensips. > >> > >> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme > >> > wrote: > >> > >> Ah - nm, i see it in an sl callback > >> > >> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: > DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) > >> > >> ... so are you doing anything statless in your config? > This looks like it might be siptrace related. > >> > >> > >> > >> On 03/17/2015 11:11 AM, Eric Tamme wrote: > >>> I do not see the 500 from opensips in this log. > >>> > >>> On 03/17/2015 11:07 AM, Satish Patel wrote: > >>>> Here is the debug 4 logs > http://pastebin.com/CdPxFrNp > >>>> > >>>> 173.48.111.111 - UA > >>>> 188.79.242.164 - OpenSIPs > >>>> > >>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme > >>>> > wrote: > >>>> > >>>> This is a ladder diagram, not a sip trace. A > >>>> ladder diagram is not useful in this case. > >>>> > >>>> Turn your debug up to 4, capture the log of the > >>>> register/500 happening and submit a link to the > >>>> pastebin. DO NOT paste the contents into an > email. > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 Users at lists.opensips.org> > >>>> http://lists.opensips.org/cgi- > bin/mailman/listinfo/users > >>> > >>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org org> > >>> http://lists.opensips.org/cgi- > bin/mailman/listinfo/users > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org 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 > > > > -- > Regards, > Babil (Golam Sarwar) > Skype: gsbabil > Phone: +1-470-222-4511 (SMS and voice-mail only) > > PGP Key Fingerprint : D3A1 EED0 5BA0 72D3 A011 75CB 8EA6 7D99 F433 E92D > PGP Key Download URL: http://bit.ly/gsbabil-pgp-key > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Tue Mar 17 19:09:49 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 14:09:49 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55086A58.2040903@uphreak.com> References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> <55086A58.2040903@uphreak.com> Message-ID: I have check on book example and it doesn't have any brace also. just wonder! Look at this link, someone posted link here, even they don't have curly brace On Tue, Mar 17, 2015 at 1:54 PM, Eric Tamme wrote: > You are missing the left curly brace after your if statment.... im > suprised your script runs at all > > > On 03/17/2015 11:48 AM, Satish Patel wrote: > > Eric, > > I found what was the issue, I sent you REGISTER method snippet before, > if you look at it, If remove/comment out "sl_reply_error();" line in > following code, it stopped sending 500 Error. Very interesting.. Do you > think i need to put that in "curly braces" { } ? > > if (!save("location")) > xlog("L_ERR", "Saving contact failed - M=$rm > RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); > sl_reply_error(); > > exit; > } > > > On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel > wrote: > >> Even after disabled "siptrace" it is happening. no luck :( >> >> On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme wrote: >> >>> Turn of your sip tracing and see if the issue occurs. Its running some >>> sl_callbacks (which i assume are realated to siptrace). >>> >>> >>> >>> On 03/17/2015 11:19 AM, Satish Patel wrote: >>> >>> I haven't done anything related "stateless". also in my config, i >>> haven't manually specify that 500 error anywhere where i can doubt. I >>> don't know from where it is coming. must be internally from opensips. >>> >>> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme wrote: >>> >>>> Ah - nm, i see it in an sl callback >>>> >>>> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >>>> >>>> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >>>> >>>> >>>> >>>> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>>> >>>> I do not see the 500 from opensips in this log. >>>> >>>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>> >>>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>>> >>>> 173.48.111.111 - UA >>>> 188.79.242.164 - OpenSIPs >>>> >>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: >>>> >>>>> This is a ladder diagram, not a sip trace. A ladder diagram is not >>>>> useful in this case. >>>>> >>>>> Turn your debug up to 4, capture the log of the register/500 happening >>>>> and submit a link to the pastebin. DO NOT paste the contents into an >>>>> email. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 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 satish.txt at gmail.com Tue Mar 17 19:10:44 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 14:10:44 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> <55086A58.2040903@uphreak.com> Message-ID: Sorry forgot to post link http://lists.opensips.org/pipermail/users/2012-August/022705.html also interesting thing, I am not seeing xlog in opensips.log, why? if ( 0 ) setflag(TCP_PERSISTENT); if (!save("location")) xlog("Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_reply_error(); exit; } On Tue, Mar 17, 2015 at 2:09 PM, Satish Patel wrote: > I have check on book example and it doesn't have any brace also. just > wonder! > > Look at this link, someone posted link here, even they don't have curly > brace > > > On Tue, Mar 17, 2015 at 1:54 PM, Eric Tamme wrote: > >> You are missing the left curly brace after your if statment.... im >> suprised your script runs at all >> >> >> On 03/17/2015 11:48 AM, Satish Patel wrote: >> >> Eric, >> >> I found what was the issue, I sent you REGISTER method snippet before, >> if you look at it, If remove/comment out "sl_reply_error();" line in >> following code, it stopped sending 500 Error. Very interesting.. Do you >> think i need to put that in "curly braces" { } ? >> >> if (!save("location")) >> xlog("L_ERR", "Saving contact failed - M=$rm >> RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >> sl_reply_error(); >> >> exit; >> } >> >> >> On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel >> wrote: >> >>> Even after disabled "siptrace" it is happening. no luck :( >>> >>> On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme wrote: >>> >>>> Turn of your sip tracing and see if the issue occurs. Its running >>>> some sl_callbacks (which i assume are realated to siptrace). >>>> >>>> >>>> >>>> On 03/17/2015 11:19 AM, Satish Patel wrote: >>>> >>>> I haven't done anything related "stateless". also in my config, i >>>> haven't manually specify that 500 error anywhere where i can doubt. I >>>> don't know from where it is coming. must be internally from opensips. >>>> >>>> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme wrote: >>>> >>>>> Ah - nm, i see it in an sl callback >>>>> >>>>> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >>>>> >>>>> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >>>>> >>>>> >>>>> >>>>> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>>>> >>>>> I do not see the 500 from opensips in this log. >>>>> >>>>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>>> >>>>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>>>> >>>>> 173.48.111.111 - UA >>>>> 188.79.242.164 - OpenSIPs >>>>> >>>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme wrote: >>>>> >>>>>> This is a ladder diagram, not a sip trace. A ladder diagram is not >>>>>> useful in this case. >>>>>> >>>>>> Turn your debug up to 4, capture the log of the register/500 >>>>>> happening and submit a link to the pastebin. DO NOT paste the contents >>>>>> into an email. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 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 john.mathew at divoxmedia.com Tue Mar 17 19:12:53 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Tue, 17 Mar 2015 23:42:53 +0530 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> <55086A58.2040903@uphreak.com> Message-ID: If you have more than one statements to be executed under an if condition it should have an open curly at the start of the statement and a close curly at the end of the statement. If there is no curly in the book, then thats wrong. On Tuesday, 17 March 2015, Satish Patel wrote: > I have check on book example and it doesn't have any brace also. just > wonder! > > Look at this link, someone posted link here, even they don't have curly > brace > > > On Tue, Mar 17, 2015 at 1:54 PM, Eric Tamme > wrote: > >> You are missing the left curly brace after your if statment.... im >> suprised your script runs at all >> >> >> On 03/17/2015 11:48 AM, Satish Patel wrote: >> >> Eric, >> >> I found what was the issue, I sent you REGISTER method snippet before, >> if you look at it, If remove/comment out "sl_reply_error();" line in >> following code, it stopped sending 500 Error. Very interesting.. Do you >> think i need to put that in "curly braces" { } ? >> >> if (!save("location")) >> xlog("L_ERR", "Saving contact failed - M=$rm >> RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >> sl_reply_error(); >> >> exit; >> } >> >> >> On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel > > wrote: >> >>> Even after disabled "siptrace" it is happening. no luck :( >>> >>> On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme >> > wrote: >>> >>>> Turn of your sip tracing and see if the issue occurs. Its running >>>> some sl_callbacks (which i assume are realated to siptrace). >>>> >>>> >>>> >>>> On 03/17/2015 11:19 AM, Satish Patel wrote: >>>> >>>> I haven't done anything related "stateless". also in my config, i >>>> haven't manually specify that 500 error anywhere where i can doubt. I >>>> don't know from where it is coming. must be internally from opensips. >>>> >>>> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme >>> > wrote: >>>> >>>>> Ah - nm, i see it in an sl callback >>>>> >>>>> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >>>>> >>>>> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >>>>> >>>>> >>>>> >>>>> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>>>> >>>>> I do not see the 500 from opensips in this log. >>>>> >>>>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>>> >>>>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>>>> >>>>> 173.48.111.111 - UA >>>>> 188.79.242.164 - OpenSIPs >>>>> >>>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme >>>> > wrote: >>>>> >>>>>> This is a ladder diagram, not a sip trace. A ladder diagram is not >>>>>> useful in this case. >>>>>> >>>>>> Turn your debug up to 4, capture the log of the register/500 >>>>>> happening and submit a link to the pastebin. DO NOT paste the contents >>>>>> into an email. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing listUsers at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing listUsers 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 listUsers 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 listUsers 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 >> >> > -- Sent from iPhone 6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at uphreak.com Tue Mar 17 19:13:37 2015 From: eric at uphreak.com (Eric Tamme) Date: Tue, 17 Mar 2015 12:13:37 -0600 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> <55086A58.2040903@uphreak.com> Message-ID: <55086ED1.4020203@uphreak.com> because the if statment does not evailuate true, so it skips the line immediately after it. This is how unbraced functions work. it then continues executing after and sends the error. On 03/17/2015 12:10 PM, Satish Patel wrote: > Sorry forgot to post link > http://lists.opensips.org/pipermail/users/2012-August/022705.html > > also interesting thing, I am not seeing xlog in opensips.log, why? > > > if ( 0 ) setflag(TCP_PERSISTENT); > > if (!save("location")) > xlog("Saving contact failed - M=$rm RURI=$ru > F=$fu T=$tu IP=$si ID=$ci\n"); > sl_reply_error(); > > exit; > } > > > > On Tue, Mar 17, 2015 at 2:09 PM, Satish Patel > wrote: > > I have check on book example and it doesn't have any brace also. > just wonder! > > Look at this link, someone posted link here, even they don't have > curly brace > > > On Tue, Mar 17, 2015 at 1:54 PM, Eric Tamme > wrote: > > You are missing the left curly brace after your if > statment.... im suprised your script runs at all > > > On 03/17/2015 11:48 AM, Satish Patel wrote: >> Eric, >> >> I found what was the issue, I sent you REGISTER method >> snippet before, if you look at it, If remove/comment out >> "sl_reply_error();" line in following code, it stopped >> sending 500 Error. Very interesting.. Do you think i need to >> put that in "curly braces" { } ? >> >> if (!save("location")) >> xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu >> T=$tu IP=$si ID=$ci\n"); >> sl_reply_error(); >> >> exit; >> } >> >> >> On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel >> > wrote: >> >> Even after disabled "siptrace" it is happening. no luck :( >> >> On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme >> > wrote: >> >> Turn of your sip tracing and see if the issue >> occurs. Its running some sl_callbacks (which i >> assume are realated to siptrace). >> >> >> >> On 03/17/2015 11:19 AM, Satish Patel wrote: >>> I haven't done anything related "stateless". also >>> in my config, i haven't manually specify that 500 >>> error anywhere where i can doubt. I don't know from >>> where it is coming. must be internally from opensips. >>> >>> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme >>> > wrote: >>> >>> Ah - nm, i see it in an sl callback >>> >>> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >>> >>> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >>> >>> >>> >>> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>>> I do not see the 500 from opensips in this log. >>>> >>>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>>> Here is the debug 4 logs >>>>> http://pastebin.com/CdPxFrNp >>>>> >>>>> 173.48.111.111 - UA >>>>> 188.79.242.164 - OpenSIPs >>>>> >>>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme >>>>> > >>>>> wrote: >>>>> >>>>> This is a ladder diagram, not a sip >>>>> trace. A ladder diagram is not useful in >>>>> this case. >>>>> >>>>> Turn your debug up to 4, capture the log >>>>> of the register/500 happening and submit a >>>>> link to the pastebin. DO NOT paste the >>>>> contents into an email. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Tue Mar 17 19:17:15 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 17 Mar 2015 14:17:15 -0400 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: <55086ED1.4020203@uphreak.com> References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> <55086A58.2040903@uphreak.com> <55086ED1.4020203@uphreak.com> Message-ID: Great! Guys!! here is my rectified code. look like it works, is that correct? if (!save("location")) { xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_reply_error(); exit; } exit; } On Tue, Mar 17, 2015 at 2:13 PM, Eric Tamme wrote: > because the if statment does not evailuate true, so it skips the line > immediately after it. This is how unbraced functions work. it then > continues executing after and sends the error. > > > On 03/17/2015 12:10 PM, Satish Patel wrote: > > Sorry forgot to post link > http://lists.opensips.org/pipermail/users/2012-August/022705.html > > also interesting thing, I am not seeing xlog in opensips.log, why? > > > if ( 0 ) setflag(TCP_PERSISTENT); > > if (!save("location")) > > xlog("Saving contact failed - M=$rm RURI=$ru F=$fu > T=$tu IP=$si ID=$ci\n"); > sl_reply_error(); > > exit; > } > > > > On Tue, Mar 17, 2015 at 2:09 PM, Satish Patel > wrote: > >> I have check on book example and it doesn't have any brace also. just >> wonder! >> >> Look at this link, someone posted link here, even they don't have curly >> brace >> >> >> On Tue, Mar 17, 2015 at 1:54 PM, Eric Tamme wrote: >> >>> You are missing the left curly brace after your if statment.... im >>> suprised your script runs at all >>> >>> >>> On 03/17/2015 11:48 AM, Satish Patel wrote: >>> >>> Eric, >>> >>> I found what was the issue, I sent you REGISTER method snippet before, >>> if you look at it, If remove/comment out "sl_reply_error();" line in >>> following code, it stopped sending 500 Error. Very interesting.. Do you >>> think i need to put that in "curly braces" { } ? >>> >>> if (!save("location")) >>> xlog("L_ERR", "Saving contact failed - M=$rm >>> RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >>> sl_reply_error(); >>> >>> exit; >>> } >>> >>> >>> On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel >>> wrote: >>> >>>> Even after disabled "siptrace" it is happening. no luck :( >>>> >>>> On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme wrote: >>>> >>>>> Turn of your sip tracing and see if the issue occurs. Its running >>>>> some sl_callbacks (which i assume are realated to siptrace). >>>>> >>>>> >>>>> >>>>> On 03/17/2015 11:19 AM, Satish Patel wrote: >>>>> >>>>> I haven't done anything related "stateless". also in my config, i >>>>> haven't manually specify that 500 error anywhere where i can doubt. I >>>>> don't know from where it is coming. must be internally from opensips. >>>>> >>>>> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme wrote: >>>>> >>>>>> Ah - nm, i see it in an sl callback >>>>>> >>>>>> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >>>>>> >>>>>> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >>>>>> >>>>>> >>>>>> >>>>>> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>>>>> >>>>>> I do not see the 500 from opensips in this log. >>>>>> >>>>>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>>>> >>>>>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>>>>> >>>>>> 173.48.111.111 - UA >>>>>> 188.79.242.164 - OpenSIPs >>>>>> >>>>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme >>>>>> wrote: >>>>>> >>>>>>> This is a ladder diagram, not a sip trace. A ladder diagram is not >>>>>>> useful in this case. >>>>>>> >>>>>>> Turn your debug up to 4, capture the log of the register/500 >>>>>>> happening and submit a link to the pastebin. DO NOT paste the contents >>>>>>> into an email. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 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 >>> >>> >> > > > _______________________________________________ > 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 Tue Mar 17 20:00:44 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 17 Mar 2015 21:00:44 +0200 Subject: [OpenSIPS-Users] WebSocket Support in OpenSIPS 2.1 Message-ID: <550879DC.6080707@opensips.org> Hello, all! Aaand, we're finally making it official: OpenSIPS 2.1 will have *WebSockets* support! Are you planning to use (or perhaps you're already using) WebRTC based SIP clients, but you are having hard time setting up the platform? Starting from now, it has never been simpler - based on your needs and feedback[1] we decided to implement a WebSocket server directly in OpenSIPS. And we're doing it now! Starting with the new OpenSIPS 2.1 release you will be able to plug your web-based SIP clients directly in your OpenSIPS server using the new WebSocket transport protocol[2]. We've also setup a short tutorial[3] for you to integrate this feature in your platform easier. Many thanks to Eric Tamme (lirakis) for all his help with the tutorial as well as for the intensive tests. [1] http://www.opensips.org/Community/IRCmeeting20141029 [2] http://www.opensips.org/html/docs/modules/2.1.x/proto_ws [3] http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 Best regards, -- R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From aronp at guaranteedplus.com Tue Mar 17 20:50:42 2015 From: aronp at guaranteedplus.com (Podrigal, Aron) Date: Tue, 17 Mar 2015 15:50:42 -0400 Subject: [OpenSIPS-Users] WebSocket Support in OpenSIPS 2.1 In-Reply-To: <550879DC.6080707@opensips.org> References: <550879DC.6080707@opensips.org> Message-ID: Thanks, great news! On Mar 17, 2015 3:00 PM, "R?zvan Crainea" wrote: > Hello, all! > > Aaand, we're finally making it official: OpenSIPS 2.1 will have > *WebSockets* support! > > Are you planning to use (or perhaps you're already using) WebRTC based SIP > clients, but you are having hard time setting up the platform? Starting > from now, it has never been simpler - based on your needs and feedback[1] > we decided to implement a WebSocket server directly in OpenSIPS. > > And we're doing it now! Starting with the new OpenSIPS 2.1 release you > will be able to plug your web-based SIP clients directly in your OpenSIPS > server using the new WebSocket transport protocol[2]. > > We've also setup a short tutorial[3] for you to integrate this feature in > your platform easier. Many thanks to Eric Tamme (lirakis) for all his help > with the tutorial as well as for the intensive tests. > > [1] http://www.opensips.org/Community/IRCmeeting20141029 > [2] http://www.opensips.org/html/docs/modules/2.1.x/proto_ws > [3] http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 > > Best regards, > -- > R?zvan Crainea > OpenSIPS Core Developer > http://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 satish.txt at gmail.com Wed Mar 18 05:17:02 2015 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 18 Mar 2015 00:17:02 -0400 Subject: [OpenSIPS-Users] ERROR:dialog:dlg_validate_dialog: Message-ID: I am getting following error in log, I can understand my contact: and Route: values mismatching here. why it is happening? is there a way to get rid on this error? Following is scenario. Only getting error in BYE message. [UA]--------[OpenSIP]-------[Freeswitch]---------[Opensip]---------[SIP Provide] ERROR:dialog:dlg_validate_dialog: failed to validate remote contact: dlg=[sip:16463737221 at 188.178.235.222:5061;transport=udp] , req=[sip:188.178.235.222;lr;ftag=840e2e35;did=1f4.ca6a6956] I am using fix_route_dialog() in loose_route() if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route() || match_dialog()) { if ($DLG_status!=NULL && !validate_dialog() ) { xlog(" in-dialog bogus request \n"); fix_route_dialog(); } xlog("L_INFO", "Loose route failed on $hdr(route)\n"); if (is_method("BYE")) { #setflag(ACC_DO); # do accounting ... #setflag(ACC_FAILED); # ... even if the transaction fails } else if (is_method("INVITE")) { # even if in most of the cases is useless, do RR for # re-INVITEs alos, as some buggy clients do change route set # during the dialog. record_route(); } if (check_route_param("nat=yes")) setflag(NAT); # route it out to whatever destination was set by loose_route() # in $du (destination URI). route(relay); } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server xlog("non loose-route section\n"); t_relay(); exit; } else { # ACK without matching transaction -> # ignore and discard xlog("ACK without matching transaction\n"); exit; } } xlog("L_INFO", "destination uri after loose_route: <$du>\n"); sl_send_reply("404","Not here"); } exit; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at ag-projects.com Wed Mar 18 08:36:26 2015 From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=) Date: Wed, 18 Mar 2015 08:36:26 +0100 Subject: [OpenSIPS-Users] WebSocket Support in OpenSIPS 2.1 In-Reply-To: <550879DC.6080707@opensips.org> References: <550879DC.6080707@opensips.org> Message-ID: <14411519-2D6B-45D3-B488-FF2A4B7C5E92@ag-projects.com> Congrats to the team! Great work! On 17 Mar 2015, at 20:00, R?zvan Crainea wrote: > Hello, all! > > Aaand, we're finally making it official: OpenSIPS 2.1 will have *WebSockets* support! > > Are you planning to use (or perhaps you're already using) WebRTC based SIP clients, but you are having hard time setting up the platform? Starting from now, it has never been simpler - based on your needs and feedback[1] we decided to implement a WebSocket server directly in OpenSIPS. > > And we're doing it now! Starting with the new OpenSIPS 2.1 release you will be able to plug your web-based SIP clients directly in your OpenSIPS server using the new WebSocket transport protocol[2]. > > We've also setup a short tutorial[3] for you to integrate this feature in your platform easier. Many thanks to Eric Tamme (lirakis) for all his help with the tutorial as well as for the intensive tests. > > [1] http://www.opensips.org/Community/IRCmeeting20141029 > [2] http://www.opensips.org/html/docs/modules/2.1.x/proto_ws > [3] http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 > > Best regards, > -- > R?zvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > 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 hamid2kviii at hotmail.com Wed Mar 18 11:31:05 2015 From: hamid2kviii at hotmail.com (Hamid Hashmi) Date: Wed, 18 Mar 2015 15:31:05 +0500 Subject: [OpenSIPS-Users] How to remove/update dialog In-Reply-To: References: Message-ID: How to remove dialog from table "dialog" ? OR is there any method to update the timeout value in dialog without calling create_dialog("B") ? RegardsHamid R. Hashmi From: hamid2kviii at hotmail.com To: users at lists.opensips.org Date: Tue, 10 Mar 2015 17:43:15 +0500 Subject: [OpenSIPS-Users] How to remove/update dialog route[sip]{... t_on_failure("1"); $DLG_timeout = 120; create_dialog("B"); t_relay();} failure_route[1]{... if(t_check_status("some reasson")){ route(pstn); }...} route[pstn]{... t_on_failure("2"); $DLG_timeout = 60; create_dialog("B"); t_relay();} How to remove previous dialog from table "dialog" ? OR is there any method to update the timeout value in dialog without calling create_dialog("B") ? RegardsHamid R. Hashmi _______________________________________________ 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 Mar 18 19:26:52 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 18 Mar 2015 20:26:52 +0200 Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.1 Release Candidate is out ! Message-ID: <5509C36C.7070601@opensips.org> Hi all, I'm really excited to announce that after almost one year of hard work, the OpenSIPS 2.1 RC is now available for download. http://opensips.org/pub/opensips/latest/src/ The 2.1 version is a major step in OpenSIPS evolution, encapsulating major redesign (protocols, timers, reactors, async support) and valuable additions (websockets, Fraud Detection, SIP Compression, Async DB queries, Topology Hiding and more). http://www.opensips.org/About/Version-2-1-0-Notes OpenSIPS 2.1 is the first in line benefiting of the New Design (NG) brainstorming and work - where many radical and innovative concepts have been introduced, to put OpenSIPS on the top of the SIP server engines - in terms of efficiency, scalability, features set and flexibility. OpenSIPS 2.1 is the result of the whole community effort - there were many people involved in the design, in implementation, testing and reporting - and we want to thank you all for making this release possible: https://github.com/OpenSIPS/opensips/blob/2.1/CREDITS Version 2.1 is a release candidate - the stable GA version is to be release in the next 1.5 month, after more in depth testing . In the mean while, enjoy the fantastic ride with OpenSIPS 2.1 :) Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com From satish.txt at gmail.com Wed Mar 18 21:47:47 2015 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 18 Mar 2015 16:47:47 -0400 Subject: [OpenSIPS-Users] ERROR:dialog:dlg_validate_dialog: In-Reply-To: References: Message-ID: I know you guys are super busy in OpenSIPS 2.1 release, but any suggestion on above issue? On Wed, Mar 18, 2015 at 12:17 AM, Satish Patel wrote: > I am getting following error in log, I can understand my contact: and > Route: values mismatching here. why it is happening? is there a way to get > rid on this error? > > Following is scenario. Only getting error in BYE message. > > [UA]--------[OpenSIP]-------[Freeswitch]---------[Opensip]---------[SIP > Provide] > > > ERROR:dialog:dlg_validate_dialog: failed to validate remote contact: > dlg=[sip:16463737221 at 188.178.235.222:5061;transport=udp] , > req=[sip:188.178.235.222;lr;ftag=840e2e35;did=1f4.ca6a6956] > > I am using fix_route_dialog() in loose_route() > > if (has_totag()) { > # sequential request withing a dialog should > # take the path determined by record-routing > if (loose_route() || match_dialog()) { > if ($DLG_status!=NULL && !validate_dialog() ) { > xlog(" in-dialog bogus request \n"); > fix_route_dialog(); > } > > xlog("L_INFO", "Loose route failed on > $hdr(route)\n"); > if (is_method("BYE")) { > #setflag(ACC_DO); # do accounting ... > #setflag(ACC_FAILED); # ... even if the > transaction fails > } else if (is_method("INVITE")) { > # even if in most of the cases is useless, > do RR for > # re-INVITEs alos, as some buggy clients > do change route set > # during the dialog. > record_route(); > } > > if (check_route_param("nat=yes")) > setflag(NAT); > > # route it out to whatever destination was set by > loose_route() > # in $du (destination URI). > route(relay); > } else { > > if ( is_method("ACK") ) { > if ( t_check_trans() ) { > # non loose-route, but stateful > ACK; must be an ACK after > # a 487 or e.g. 404 from upstream > server > xlog("non loose-route section\n"); > t_relay(); > exit; > } else { > # ACK without matching transaction > -> > # ignore and discard > xlog("ACK without matching > transaction\n"); > exit; > } > } > xlog("L_INFO", "destination uri after loose_route: > <$du>\n"); > sl_send_reply("404","Not here"); > } > exit; > } > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrb3942 at gmail.com Wed Mar 18 23:49:20 2015 From: rrb3942 at gmail.com (Ryan Bullock) Date: Wed, 18 Mar 2015 15:49:20 -0700 Subject: [OpenSIPS-Users] Announcing rtpproxy v2.0.0 In-Reply-To: References: Message-ID: Nice reduction in poll overhead. Looking forward to trying this out. Any thoughts on adding epoll support for linux? It can tend to reduce overhead quite a bit with many sockets. On Mon, Mar 16, 2015 at 8:56 PM, John Mathew wrote: > Yes > > On Tuesday, 17 March 2015, Zheng Frank wrote: > >> Do you mean ROHC ? >> >> 2015-03-14 12:39 GMT+08:00 Maxim Sobolev : >> >>> Do you have any particular RFC in mind? >>> On Mar 12, 2015 10:28 AM, "John Mathew" >>> wrote: >>> >>>> Hi, >>>> >>>> Maxim, >>>> Is there any plans for rtp header compression in future. I can't see >>>> anything in the change log for 2.0.0 >>>> >>>> >>>> On Tuesday, 10 March 2015, Maxim Sobolev wrote: >>>> >>>>> Hi All, >>>>> >>>>> I'm happy to announce that we have released rtpproxy v2.0.0. >>>>> >>>>> You can review the release notes here: >>>>> https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 >>>>> >>>>> -sobomax >>>>> >>>>> >>>> >>>> -- >>>> Sent from iPhone 6 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "rtpproxy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to rtpproxy+unsubscribe at googlegroups.com. >>>> To post to this group, send email to rtpproxy at googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com >>>> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users at lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >> > > -- > Sent from iPhone 6 > > _______________________________________________ > 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 carlos at nbtbizcapital.com Thu Mar 19 03:15:01 2015 From: carlos at nbtbizcapital.com (Carlos Cruz) Date: Wed, 18 Mar 2015 22:15:01 -0400 Subject: [OpenSIPS-Users] error 483 Message-ID: <034a01d061ea$81d58500$85808f00$@nbtbizcapital.com> Hi; Can someone tell me why or where I may find the info I need; I'm able to register external remote phones (hard phones), but the internal phone (soft phones) within the same network as the OpenSIPS test server report error 483. Thanks!! Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Mar 19 05:03:36 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 19 Mar 2015 00:03:36 -0400 Subject: [OpenSIPS-Users] Dispatcher user specific route question Message-ID: I have two Freeswitch in dispatcher table: +-------+-------------------------+--------------+ | setid | destination | description | +-------+-------------------------+--------------+ | 1 | sip:fs1.example.com | Freeswitch-1 | | 2 | sip:fs2.example.com | Freeswitch-2 | +-------+-------------------------+--------------+ I have created "zone" column in subscriber table. -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Mar 19 05:17:41 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 19 Mar 2015 00:17:41 -0400 Subject: [OpenSIPS-Users] Dispatcher user specific route question - 2.1 Message-ID: I have add extra "zone" column in subscriber table, +--------------+---------+ | username | zone | +--------------+---------+ | 1001 | 1 | | 1002 | 2 | +--------------+---------+ In dispatcher table I have following two Freeswitch in two groups. +-------+-----------------------------+--------------------+ | setid | destination | description | +-------+------------------------------+-------------------+ | 1 | sip:fs1.example.com | Freeswitch-1 | | 2 | sip:fs2.example.com | Freeswitch-2 | +-------+------------------------------+-------------------+ in opensips.cfg script i am query subscriber table base on incoming username and storing zone in avp(zone) variable, and calling same variable in following code if ( !ds_select_dst("$avp(zone)", "4", "FM10")) Question: now either user belongs to zone 1 or 2, so it is *NOT* going to do load-balancing between two. But if I want to allow some user to do load-balancing then how it will be possible in above scenario? Can i set "setid" on fly so i can pass request along with user request and set same group for both switch and user call load-balance on both switch? Any other idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: From 542590776 at qq.com Thu Mar 19 07:23:08 2015 From: 542590776 at qq.com (jacky) Date: Wed, 18 Mar 2015 23:23:08 -0700 (MST) Subject: [OpenSIPS-Users] Jitsi sent REGISTER, Opensips received nothing Message-ID: <1426746188154-7596019.post@n2.nabble.com> I have a test with one Jitsi using Opensips on the Internet Wireshark showed me that Jitsi sent several "REGISTER" packages, in the same time I used the command "tcpdump" to listen on the Opensips Server , but got nothing. Anyway, on the server, opensips, rtpproxy, media-dispatcher, media-relay are running! what happened to opensips server? why it won't response to distanced request? I appreciate your opinion, thanks a lot! Best regards -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Jitsi-sent-REGISTER-Opensips-received-nothing-tp7596019.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From GSims at nexepe.com Thu Mar 19 11:08:19 2015 From: GSims at nexepe.com (Gordon E. Sims, Jr.) Date: Thu, 19 Mar 2015 10:08:19 +0000 Subject: [OpenSIPS-Users] Jitsi sent REGISTER, Opensips received nothing In-Reply-To: <8518199.677.1426746226396.JavaMail.root@NXSSFUDF1.Nexepe.com> References: <8518199.677.1426746226396.JavaMail.root@NXSSFUDF1.Nexepe.com> Message-ID: I would take a look at the network in between. If Jitsi is sending out packets, and opensips is not receiving, then look at routers, switches and firewall in between. Are you able to ping the opensips device from the same network that Jitsi is on? This should verify basic routing, then start looking at any potential firewall rules. If you are not getting ping requests, then you will want to check your routing with opensips. Make sure can ping outside of your network that Jitsi is on as well. Just my thoughts, Gordon Sent from my iPhone6 > On Mar 19, 2015, at 1:23 AM, jacky <542590776 at qq.com> wrote: > > I have a test with one Jitsi using Opensips on the Internet > Wireshark showed me that Jitsi sent several "REGISTER" packages, in the same > time I used the command "tcpdump" to listen on the Opensips Server , but got > nothing. > Anyway, on the server, opensips, rtpproxy, media-dispatcher, media-relay are > running! > what happened to opensips server? why it won't response to distanced > request? > > I appreciate your opinion, thanks a lot! > > Best regards > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Jitsi-sent-REGISTER-Opensips-received-nothing-tp7596019.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 > > ------------------------------------------------------------- > This email was processed through Nexepe Spam filter to filter junk messages. > If you feel this message has been tagged incorrectly, you can > change its category by clicking the link below. > Click here http://10.0.9.41:5272/FrontController?operation=mbeu&f=00001_-940_20150319_183500.eml&chkBayesian=1&pr=1&mt=1&ma=s to mark email as junk. > ------------------------------------------------------------- Think before you Print. This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. From razvan at opensips.org Thu Mar 19 12:08:48 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Thu, 19 Mar 2015 13:08:48 +0200 Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.1 Release Candidate is out ! In-Reply-To: <5509C36C.7070601@opensips.org> References: <5509C36C.7070601@opensips.org> Message-ID: <550AAE40.1000405@opensips.org> On 03/18/2015 08:26 PM, Bogdan-Andrei Iancu wrote: > Hi all, > > I'm really excited to announce that after almost one year of hard work, > the OpenSIPS 2.1 RC is now available for download. > http://opensips.org/pub/opensips/latest/src/ > > The 2.1 version is a major step in OpenSIPS evolution, encapsulating > major redesign (protocols, timers, reactors, async support) and valuable > additions (websockets, Fraud Detection, SIP Compression, Async DB > queries, Topology Hiding and more). > http://www.opensips.org/About/Version-2-1-0-Notes > > OpenSIPS 2.1 is the first in line benefiting of the New Design (NG) > brainstorming and work - where many radical and innovative concepts have > been introduced, to put OpenSIPS on the top of the SIP server engines - > in terms of efficiency, scalability, features set and flexibility. > > OpenSIPS 2.1 is the result of the whole community effort - there were > many people involved in the design, in implementation, testing and > reporting - and we want to thank you all for making this release possible: > https://github.com/OpenSIPS/opensips/blob/2.1/CREDITS > > Version 2.1 is a release candidate - the stable GA version is to be > release in the next 1.5 month, after more in depth testing . > > In the mean while, enjoy the fantastic ride with OpenSIPS 2.1 :) For a better experience with the system provisioning and user management, we recommend you to use the new OpenSIPS Control Panel 6.1[1], which is now fully compatible with OpenSIPS 2.1. Many greetings from the OpenSIPS team [2]! [1] https://sourceforge.net/projects/opensips-cp [2] http://opensips.org/images/team/opensips-team.jpg Best regards, R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From m.adducchio at progel.net Thu Mar 19 12:29:36 2015 From: m.adducchio at progel.net (Mattia Adducchio) Date: Thu, 19 Mar 2015 12:29:36 +0100 Subject: [OpenSIPS-Users] Which port router open Message-ID: <550AB320.2030508@progel.net> Hello Everyone, I'm trying to setup my personal sip server. In this moment it works only in my network, but now I want to open the router port for external access. I have open the port 5060 but maybe it's not enough. Thank you, Mattia -------------- next part -------------- An HTML attachment was scrubbed... URL: From gsbabil at gmail.com Tue Mar 17 19:08:27 2015 From: gsbabil at gmail.com (Babil (Golam Sarwar)) Date: Tue, 17 Mar 2015 11:08:27 -0700 Subject: [OpenSIPS-Users] 500 Server error in REGISTER message In-Reply-To: References: <55085A42.2010900@uphreak.com> <55086047.6020406@uphreak.com> <55086113.8010302@uphreak.com> <55086243.1070605@uphreak.com> Message-ID: <55086D9B.2040103@gmail.com> There's a mismatched curly-brace issue in your configuration. Brace at line 2 matches with brace at line 18. Nothing matches with the closing curly-brace at line 19. I think we are missing a curly-brace at line 15. My two-cents to the OpenSIPS team would be consider verbose curly-braces for the configuration script. Python/C like tab-based indenting might seem to improve readability and keep the code concise, but it introduces these unintended errors. ``` 1 if (is_method("REGISTER")) 2 { 3 # authenticate the REGISTER requests (uncomment to enable auth) 4 ##if (!www_authorize("", "subscriber")) 5 ##{ 6 ## www_challenge("", "0"); 7 ## exit; 8 ##} 9 ## 10 ##if (!db_check_to()) 11 ##{ 12 ## sl_send_reply("403","Forbidden auth ID"); 13 ## exit; 14 ##} 15 if (!save("location")) 16 sl_reply_error(); 17 exit; 18 } 19 } 20 ``` On 3/17/15 10:52 AM, Satish Patel wrote: > I got those code from Book Building Telephony System with OpenSIPS 1.6 > > Here is the code from book > > if (is_method("REGISTER")) > { > # authenticate the REGISTER requests (uncomment to enable auth) > ##if (!www_authorize("", "subscriber")) > ##{ > ## www_challenge("", "0"); > ## exit; > ##} > ## > ##if (!db_check_to()) > ##{ > ## sl_send_reply("403","Forbidden auth ID"); > ## exit; > ##} > if (!save("location")) > sl_reply_error(); > exit; > } > } > > > > On Tue, Mar 17, 2015 at 1:48 PM, Satish Patel > wrote: > > Eric, > > I found what was the issue, I sent you REGISTER method snippet > before, if you look at it, If remove/comment out "sl_reply_error();" > line in following code, it stopped sending 500 Error. Very > interesting.. Do you think i need to put that in "curly braces" { } ? > > if (!save("location")) > xlog("L_ERR", "Saving contact failed - M=$rm > RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); > sl_reply_error(); > > exit; > } > > > On Tue, Mar 17, 2015 at 1:27 PM, Satish Patel > wrote: > > Even after disabled "siptrace" it is happening. no luck :( > > On Tue, Mar 17, 2015 at 1:20 PM, Eric Tamme > wrote: > > Turn of your sip tracing and see if the issue occurs. Its > running some sl_callbacks (which i assume are realated to > siptrace). > > > > On 03/17/2015 11:19 AM, Satish Patel wrote: >> I haven't done anything related "stateless". also in my >> config, i haven't manually specify that 500 error anywhere >> where i can doubt. I don't know from where it is coming. >> must be internally from opensips. >> >> On Tue, Mar 17, 2015 at 1:14 PM, Eric Tamme >> > wrote: >> >> Ah - nm, i see it in an sl callback >> >> Mar 17 22:19:01 sip2 /usr/local/opensips-2-head/sbin/opensips[31285]: DBG:sl:sl_reply_error: error text is Server error occurred (1/SL) >> >> ... so are you doing anything statless in your config? This looks like it might be siptrace related. >> >> >> >> On 03/17/2015 11:11 AM, Eric Tamme wrote: >>> I do not see the 500 from opensips in this log. >>> >>> On 03/17/2015 11:07 AM, Satish Patel wrote: >>>> Here is the debug 4 logs http://pastebin.com/CdPxFrNp >>>> >>>> 173.48.111.111 - UA >>>> 188.79.242.164 - OpenSIPs >>>> >>>> On Tue, Mar 17, 2015 at 12:45 PM, Eric Tamme >>>> > wrote: >>>> >>>> This is a ladder diagram, not a sip trace. A >>>> ladder diagram is not useful in this case. >>>> >>>> Turn your debug up to 4, capture the log of the >>>> register/500 happening and submit a link to the >>>> pastebin. DO NOT paste the contents into an email. >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Babil (Golam Sarwar) Skype: gsbabil Phone: +1-470-222-4511 (SMS and voice-mail only) PGP Key Fingerprint : D3A1 EED0 5BA0 72D3 A011 75CB 8EA6 7D99 F433 E92D PGP Key Download URL: http://bit.ly/gsbabil-pgp-key -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xF433E92D.asc Type: application/pgp-keys Size: 56372 bytes Desc: not available URL: From satish.txt at gmail.com Thu Mar 19 13:46:14 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 19 Mar 2015 08:46:14 -0400 Subject: [OpenSIPS-Users] Which port router open In-Reply-To: <550AB320.2030508@progel.net> References: <550AB320.2030508@progel.net> Message-ID: Default SIP port 5060 UDP also you need media port call RTP -- Sent from my iPhone > On Mar 19, 2015, at 7:29 AM, Mattia Adducchio wrote: > > Hello Everyone, > > I'm trying to setup my personal sip server. In this moment it works only in my network, but now I want to open the router port for external access. > > I have open the port 5060 but maybe it's not enough. > > Thank you, > Mattia > _______________________________________________ > 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 asherif74 at hotmail.com Thu Mar 19 15:03:15 2015 From: asherif74 at hotmail.com (malik sherif) Date: Thu, 19 Mar 2015 14:03:15 +0000 Subject: [OpenSIPS-Users] SIps as SBC In-Reply-To: References: Message-ID: Can SIPS can be used as an SBC? Thanks Abdul -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Thu Mar 19 15:24:44 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Thu, 19 Mar 2015 10:24:44 -0400 Subject: [OpenSIPS-Users] SIps as SBC In-Reply-To: References: Message-ID: Who?? T -------------- next part -------------- An HTML attachment was scrubbed... URL: From varadhan.work at gmail.com Thu Mar 19 15:58:27 2015 From: varadhan.work at gmail.com (Varadhan Work) Date: Thu, 19 Mar 2015 20:28:27 +0530 Subject: [OpenSIPS-Users] SIps as SBC In-Reply-To: References: Message-ID: Checkout Blox.org Thanks Varadhan M On Thu, Mar 19, 2015 at 7:33 PM, malik sherif wrote: > > > Can SIPS can be used as an SBC? > Thanks > Abdul > > _______________________________________________ > 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 peter.kust at businessuites.com Thu Mar 19 16:10:31 2015 From: peter.kust at businessuites.com (Peter Kust) Date: Thu, 19 Mar 2015 15:10:31 +0000 Subject: [OpenSIPS-Users] Presence Error messages Message-ID: <72838165E698AB40827E601B9E1F2B9AC01D8E@BSSHDCEXS01.colo.businessuites.com> I am attempting to troubleshoot what I think is a presence/b2b_sca issue. I keep getting an error message from presence as follows: ERROR:presence:update_presentity: No E_Tag match [ff5ad69c9be06cffaa136492f4fb3b50] At some point during the day, I will see this error message: ERROR:presence:handle_subscribe: in event specific subscription handling At this point, an outbound call from a line appearance provisioned to the b2b_sca module fails. The outbound call is being attempted from a Cisco SPA525G2, and the message on the phone screen shows "no line"-despite happening at a time when it is known there are no calls on the system that I can see. The observed behavior of the phone is to show "No line", and the phone itself gets a What do these error messages mean? What is the system trying to tell me? I am trying to get my brain around what the error messages are saying so I can figure out where to look next in my troubleshooting. The proxy is functioning well in all other respects. Cordially, Peter Nayland Kust Director of Technologies BusinesSuites 24624 Interstate 45 North, Suite 200 Houston, TX 77386 Tel: 281.378.8051 Fax: 855.287.6961 peter.kust at businessuites.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sevpal at aol.com Thu Mar 19 16:45:41 2015 From: sevpal at aol.com (sevpal) Date: Thu, 19 Mar 2015 11:45:41 -0400 Subject: [OpenSIPS-Users] Again BLF and Presence with Snom 7xx phones and OpenSips In-Reply-To: <54EF180A.4030405@opensips.org> References: <54EC4C92.8040204@unisi.it> <54EF180A.4030405@opensips.org> Message-ID: <8FD5BDF5F390435DA0908E29022FC007@LenovoPC> You need to handle the in-dialog SUBSCRIBE requests. eg: if has_totag() { ... if (loose_route()) { ... } else { ... if (is_method("SUBSCRIBE")) { route(2); exit; } ... } ... } From: Bogdan-Andrei Iancu Sent: Thursday, February 26, 2015 7:56 AM To: OpenSIPS users mailling list ; mailto:michele.pinassi at unisi.it Subject: Re: [OpenSIPS-Users] Again BLF and Presence with Snom 7xx phones and OpenSips Hi Michele, The problem in your script is that you do not handle the sequential (in-dialog) SUBSCRIBE requests (as you have the second one in your trace, ending with 404 and terminating the subscription). In the " if ( has_totag() ) " block, you have: } else { if (is_method("SUBSCRIBE") && $rd == "127.0.0.1:5060") { # CUSTOMIZE ME The $rd detection does not cover all your cases, as you configure the presence module to advertise as SIP contact "sip:presence at voip.unisi.it:5060". So, the test fails. You can adapt the test like: if (is_method("SUBSCRIBE") && $rd == "voip.unisi.it") { # CUSTOMIZE ME Or set the contact in presence with the real IP: modparam("presence", "server_address", mailto:sip:presence at 127.0.0.1:5060) Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.comOn 24.02.2015 12:04, Michele Pinassi wrote: Hi all, I'm still stuck on this issue: BLF not working. For example, on my SNOM 760 (ext 5002) i activated BLF for some ext, like 5020. Using SIPGREP i saw: SUBSCRIBE sip:5020 at voip.unisi.it;user=phone SIP/2.0. Via: SIP/2.0/UDP 172.20.1.10:57286;branch=z9hG4bK-nprg3gvnk4q1;rport. From: mailto:sip:5002 at voip.unisi.it:5060;tag=nyux2omhly. To: mailto:sip:5020 at voip.unisi.it;user=phone. Call-ID: 3944ec54dc20-pfzjpjhrpm6p. CSeq: 2 SUBSCRIBE. Max-Forwards: 70. Contact: mailto:sip:5002 at 172.20.1.10:57286;reg-id=1. Event: dialog. Accept: application/dialog-info+xml. User-Agent: snom760/8.7.3.25.9. Proxy-Authorization: Digest Expires: 3600. Content-Length: 0. SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.20.1.10:57286;received=172.20.1.10;branch=z9hG4bK-nprg3gvnk4q1;rport=57286. From: mailto:sip:5002 at voip.unisi.it:5060;tag=nyux2omhly. To: mailto:sip:5020 at voip.unisi.it;user=phone;tag=f315b2d58ae8829149b784764c5a40e3-163d. Call-ID: 3944ec54dc20-pfzjpjhrpm6p. CSeq: 2 SUBSCRIBE. Expires: 3600. Contact: mailto:sip:presence at voip.unisi.it:5060. Server: OpenSIPS (1.11.3-tls (i386/linux)). Content-Length: 0. NOTIFY sip:5002 at 172.20.1.10:57286 SIP/2.0. Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdb02.83d58916.0. To: mailto:sip:5002 at voip.unisi.it;tag=nyux2omhly. From: mailto:sip:5020 at voip.unisi.it;tag=f315b2d58ae8829149b784764c5a40e3-163d. CSeq: 1 NOTIFY. Call-ID: 3944ec54dc20-pfzjpjhrpm6p. Max-Forwards: 70. Content-Length: 147. User-Agent: OpenSIPS (1.11.3-tls (i386/linux)). Event: dialog. Contact: mailto:sip:presence at voip.unisi.it:5060. Subscription-State: active;expires=3600. Content-Type: application/dialog-info+xml. . SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdb02.83d58916.0. From: mailto:sip:5020 at voip.unisi.it;tag=f315b2d58ae8829149b784764c5a40e3-163d. To: mailto:sip:5002 at voip.unisi.it;tag=nyux2omhly. Call-ID: 3944ec54dc20-pfzjpjhrpm6p. CSeq: 1 NOTIFY. Content-Length: 0. SUBSCRIBE sip:presence at voip.unisi.it:5060 SIP/2.0. Via: SIP/2.0/UDP 172.20.1.25:32768;branch=z9hG4bK-lbgnea3kuorq;rport. From: mailto:sip:5007 at voip.unisi.it:5060;tag=w8vp9q5iyn. To: mailto:sip:5002 at voip.unisi.it;user=phone;tag=f315b2d58ae8829149b784764c5a40e3-29cc. Call-ID: 54ec3a578c9e-klgn0s3i32zo. CSeq: 75 SUBSCRIBE. Max-Forwards: 70. Contact: mailto:sip:5007 at 172.20.1.25:32768;reg-id=1. Event: dialog. Accept: application/dialog-info+xml. User-Agent: snom710/8.7.3.25.9. Expires: 3600. Content-Length: 0. SIP/2.0 404 Not here. Via: SIP/2.0/UDP 172.20.1.25:32768;received=172.20.1.25;branch=z9hG4bK-lbgnea3kuorq;rport=32768. From: mailto:sip:5007 at voip.unisi.it:5060;tag=w8vp9q5iyn. To: mailto:sip:5002 at voip.unisi.it;user=phone;tag=f315b2d58ae8829149b784764c5a40e3-29cc. Call-ID: 54ec3a578c9e-klgn0s3i32zo. CSeq: 75 SUBSCRIBE. Server: OpenSIPS (1.11.3-tls (i386/linux)). Content-Length: 0. NOTIFY sip:5002 at 172.20.1.10:57286 SIP/2.0. Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdbe9.7966c706.0. To: mailto:sip:5002 at voip.unisi.it;tag=iklb1qjh1v. From: mailto:sip:5007 at voip.unisi.it;tag=f315b2d58ae8829149b784764c5a40e3-b571. CSeq: 2 NOTIFY. Call-ID: ee35ec54a72b-draf1nwo4qn7. Max-Forwards: 70. Content-Length: 0. User-Agent: OpenSIPS (1.11.3-tls (i386/linux)). Event: dialog. Contact: mailto:sip:presence at voip.unisi.it:5060. Subscription-State: terminated;reason=timeout. SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.1.2:5060;branch=z9hG4bKdbe9.7966c706.0. From: mailto:sip:5007 at voip.unisi.it;tag=f315b2d58ae8829149b784764c5a40e3-b571. To: mailto:sip:5002 at voip.unisi.it;tag=iklb1qjh1v. Call-ID: ee35ec54a72b-draf1nwo4qn7. CSeq: 2 NOTIFY. Content-Length: 0. The line 5020 was active but no lamp was powered. Also no NOTIFY or other event was sent by Opensips server when i try to call (from another phone) 5020. The full opensips.cfg is available here: http://pastebin.com/e6SfbFfq Thanks for any help. Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)5000 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it _______________________________________________ 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 vladpaiu at opensips.org Thu Mar 19 17:24:48 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Thu, 19 Mar 2015 18:24:48 +0200 Subject: [OpenSIPS-Users] ERROR:dialog:dlg_validate_dialog: In-Reply-To: References: Message-ID: <550AF850.60503@opensips.org> Hello, Just to recap, you are saying that the Contact the user agent is sending is broken and you are happy that OpenSIPS is properly fixing the message, but you want to get rid of the ERRORs in the log ? If this is the case, you can use setdebug [1] for this. Try something like setdebug(-3) if ($DLG_status!=NULL && !validate_dialog() ) { xlog(" in-dialog bogus request \n"); fix_route_dialog(); } setdebug() http://www.opensips.org/Documentation/Script-CoreFunctions-2-1#toc48 Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 18.03.2015 22:47, Satish Patel wrote: > I know you guys are super busy in OpenSIPS 2.1 release, but any > suggestion on above issue? > > On Wed, Mar 18, 2015 at 12:17 AM, Satish Patel > wrote: > > I am getting following error in log, I can understand my contact: > and Route: values mismatching here. why it is happening? is there > a way to get rid on this error? > > Following is scenario. Only getting error in BYE message. > > [UA]--------[OpenSIP]-------[Freeswitch]---------[Opensip]---------[SIP > Provide] > > > ERROR:dialog:dlg_validate_dialog: failed to validate remote > contact: dlg=[sip:16463737221 > @188.178.235.222:5061;transport=udp] , > req=[sip:188.178.235.222;lr;ftag=840e2e35;did=1f4.ca6a6956] > > I am using fix_route_dialog() in loose_route() > > if (has_totag()) { > # sequential request withing a dialog should > # take the path determined by record-routing > if (loose_route() || match_dialog()) { > if ($DLG_status!=NULL && > !validate_dialog() ) { > xlog(" in-dialog bogus request \n"); > fix_route_dialog(); > } > > xlog("L_INFO", "Loose route failed on > $hdr(route)\n"); > if (is_method("BYE")) { > #setflag(ACC_DO); # do accounting ... > #setflag(ACC_FAILED); # ... even > if the transaction fails > } else if (is_method("INVITE")) { > # even if in most of the cases is > useless, do RR for > # re-INVITEs alos, as some buggy > clients do change route set > # during the dialog. > record_route(); > } > > if (check_route_param("nat=yes")) > setflag(NAT); > > # route it out to whatever destination was > set by loose_route() > # in $du (destination URI). > route(relay); > } else { > > if ( is_method("ACK") ) { > if ( t_check_trans() ) { > # non loose-route, but > stateful ACK; must be an ACK after > # a 487 or e.g. 404 from > upstream server > xlog("non loose-route > section\n"); > t_relay(); > exit; > } else { > # ACK without matching > transaction -> > # ignore and discard > xlog("ACK without matching > transaction\n"); > exit; > } > } > xlog("L_INFO", "destination uri after > loose_route: <$du>\n"); > sl_send_reply("404","Not here"); > } > exit; > } > > > > > > > > > > _______________________________________________ > 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 vladpaiu at opensips.org Thu Mar 19 17:26:50 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Thu, 19 Mar 2015 18:26:50 +0200 Subject: [OpenSIPS-Users] error 483 In-Reply-To: <034a01d061ea$81d58500$85808f00$@nbtbizcapital.com> References: <034a01d061ea$81d58500$85808f00$@nbtbizcapital.com> Message-ID: <550AF8CA.8070903@opensips.org> Hello, 483 usually means 'Too Many Hops'. If you do a SIP trace on the server, do you see OpenSIPS looping the request to itself ? Maybe the SIP phone sends the IP of the server instead of the domain that you have configured, and your script is configured to route out such requests. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 19.03.2015 04:15, Carlos Cruz wrote: > > Hi; > > Can someone tell me why or where I may find the info I need; I'm > able to register external remote phones (hard phones), but the > internal phone (soft phones) within the same network as the OpenSIPS > test server report error 483. > > Thanks!! > > Carlos > > > > _______________________________________________ > 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 satish.txt at gmail.com Thu Mar 19 17:29:53 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 19 Mar 2015 12:29:53 -0400 Subject: [OpenSIPS-Users] ERROR:dialog:dlg_validate_dialog: In-Reply-To: <550AF850.60503@opensips.org> References: <550AF850.60503@opensips.org> Message-ID: Great! will give it a shot! Just surprised why it is not matching both dlg and req? does fix_route_dialog(); has any impact on system when you have very high CPS etc? It would be good if fix issue from root, instead of external resources which eat CPU ticks :) dlg=[sip:16463737221 at 188.178.235.222:5061;transport=udp] , req=[sip:188.178.235.222;lr;ftag=840e2e35;did=1f4.ca6a6956] On Thu, Mar 19, 2015 at 12:24 PM, Vlad Paiu wrote: > Hello, > > Just to recap, you are saying that the Contact the user agent is sending > is broken and you are happy that OpenSIPS is properly fixing the message, > but you want to get rid of the ERRORs in the log ? If this is the case, you > can use setdebug [1] for this. > > Try something like > > setdebug(-3) > if ($DLG_status!=NULL && !validate_dialog() ) { > xlog(" in-dialog bogus request \n"); > fix_route_dialog(); > } > setdebug() > > http://www.opensips.org/Documentation/Script-CoreFunctions-2-1#toc48 > > Best Regards, > > Vlad Paiu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 18.03.2015 22:47, Satish Patel wrote: > > I know you guys are super busy in OpenSIPS 2.1 release, but any suggestion > on above issue? > > On Wed, Mar 18, 2015 at 12:17 AM, Satish Patel > wrote: > >> I am getting following error in log, I can understand my contact: and >> Route: values mismatching here. why it is happening? is there a way to get >> rid on this error? >> >> Following is scenario. Only getting error in BYE message. >> >> [UA]--------[OpenSIP]-------[Freeswitch]---------[Opensip]---------[SIP >> Provide] >> >> >> ERROR:dialog:dlg_validate_dialog: failed to validate remote contact: >> dlg=[sip:16463737221 at 188.178.235.222:5061;transport=udp] , >> req=[sip:188.178.235.222;lr;ftag=840e2e35;did=1f4.ca6a6956] >> >> I am using fix_route_dialog() in loose_route() >> >> if (has_totag()) { >> # sequential request withing a dialog should >> # take the path determined by record-routing >> if (loose_route() || match_dialog()) { >> if ($DLG_status!=NULL && !validate_dialog() ) { >> xlog(" in-dialog bogus request \n"); >> fix_route_dialog(); >> } >> >> xlog("L_INFO", "Loose route failed on >> $hdr(route)\n"); >> if (is_method("BYE")) { >> #setflag(ACC_DO); # do accounting ... >> #setflag(ACC_FAILED); # ... even if the >> transaction fails >> } else if (is_method("INVITE")) { >> # even if in most of the cases is >> useless, do RR for >> # re-INVITEs alos, as some buggy clients >> do change route set >> # during the dialog. >> record_route(); >> } >> >> if (check_route_param("nat=yes")) >> setflag(NAT); >> >> # route it out to whatever destination was set by >> loose_route() >> # in $du (destination URI). >> route(relay); >> } else { >> >> if ( is_method("ACK") ) { >> if ( t_check_trans() ) { >> # non loose-route, but stateful >> ACK; must be an ACK after >> # a 487 or e.g. 404 from upstream >> server >> xlog("non loose-route section\n"); >> t_relay(); >> exit; >> } else { >> # ACK without matching >> transaction -> >> # ignore and discard >> xlog("ACK without matching >> transaction\n"); >> exit; >> } >> } >> xlog("L_INFO", "destination uri after >> loose_route: <$du>\n"); >> sl_send_reply("404","Not here"); >> } >> exit; >> } >> >> >> >> >> >> >> > > > _______________________________________________ > 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 vladpaiu at opensips.org Thu Mar 19 17:30:56 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Thu, 19 Mar 2015 18:30:56 +0200 Subject: [OpenSIPS-Users] Dispatcher user specific route question - 2.1 In-Reply-To: References: Message-ID: <550AF9C0.6070801@opensips.org> Hello, If you want to do dispatching between multiple setids, ds_select_dst() allows that. See the docs at [1] , you can provide a comma separated list of setids - so your $avp(zone) can contain '1,2' and OpenSIPS will try to first send to the servers in setid 1, and then, if those fail, to the servers in setid 2. [1] http://www.opensips.org/html/docs/modules/1.11.x/dispatcher#id294368 Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 19.03.2015 06:17, Satish Patel wrote: > I have add extra "zone" column in subscriber table, > > +--------------+---------+ > | username | zone | > +--------------+---------+ > | 1001 | 1 | > | 1002 | 2 | > +--------------+---------+ > > > In dispatcher table I have following two Freeswitch in two groups. > > +-------+-----------------------------+--------------------+ > | setid | destination | description | > +-------+------------------------------+-------------------+ > | 1 | sip:fs1.example.com | Freeswitch-1 | > | 2 | sip:fs2.example.com | Freeswitch-2 | > +-------+------------------------------+-------------------+ > > > in opensips.cfg script i am query subscriber table base on incoming > username and storing zone in avp(zone) variable, and calling same > variable in following code > > if ( !ds_select_dst("$avp(zone)", "4", "FM10")) > > Question: now either user belongs to zone 1 or 2, so it is *NOT* going > to do load-balancing between two. But if I want to allow some user to > do load-balancing then how it will be possible in above scenario? > > Can i set "setid" on fly so i can pass request along with user request > and set same group for both switch and user call load-balance on both > switch? > > Any other idea? > > > _______________________________________________ > 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 vladpaiu at opensips.org Thu Mar 19 17:31:56 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Thu, 19 Mar 2015 18:31:56 +0200 Subject: [OpenSIPS-Users] Jitsi sent REGISTER, Opensips received nothing In-Reply-To: <1426746188154-7596019.post@n2.nabble.com> References: <1426746188154-7596019.post@n2.nabble.com> Message-ID: <550AF9FC.5070102@opensips.org> Hello, Well, if you did a tcpdump on the OpenSIPS box and saw nothing, then it means the packages aren't actually reaching the box. Please check that there are no firewalls in between the client and OpenSIPS that are blocking the traffic. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 19.03.2015 08:23, jacky wrote: > I have a test with one Jitsi using Opensips on the Internet > Wireshark showed me that Jitsi sent several "REGISTER" packages, in the same > time I used the command "tcpdump" to listen on the Opensips Server , but got > nothing. > Anyway, on the server, opensips, rtpproxy, media-dispatcher, media-relay are > running! > what happened to opensips server? why it won't response to distanced > request? > > I appreciate your opinion, thanks a lot! > > Best regards > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Jitsi-sent-REGISTER-Opensips-received-nothing-tp7596019.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 satish.txt at gmail.com Thu Mar 19 17:39:44 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 19 Mar 2015 12:39:44 -0400 Subject: [OpenSIPS-Users] Dispatcher user specific route question - 2.1 In-Reply-To: <550AF9C0.6070801@opensips.org> References: <550AF9C0.6070801@opensips.org> Message-ID: Thanks Vlad, Superb! so it will do round-robin? or fail-over? On Thu, Mar 19, 2015 at 12:30 PM, Vlad Paiu wrote: > Hello, > > If you want to do dispatching between multiple setids, ds_select_dst() > allows that. See the docs at [1] , you can provide a comma separated list > of setids - so your $avp(zone) can contain '1,2' and OpenSIPS will try to > first send to the servers in setid 1, and then, if those fail, to the > servers in setid 2. > > [1] http://www.opensips.org/html/docs/modules/1.11.x/dispatcher#id294368 > > Best Regards, > > Vlad Paiu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 19.03.2015 06:17, Satish Patel wrote: > > I have add extra "zone" column in subscriber table, > > +--------------+---------+ > | username | zone | > +--------------+---------+ > | 1001 | 1 | > | 1002 | 2 | > +--------------+---------+ > > > In dispatcher table I have following two Freeswitch in two groups. > > +-------+-----------------------------+--------------------+ > | setid | destination | description | > +-------+------------------------------+-------------------+ > | 1 | sip:fs1.example.com | Freeswitch-1 | > | 2 | sip:fs2.example.com | Freeswitch-2 | > +-------+------------------------------+-------------------+ > > > in opensips.cfg script i am query subscriber table base on incoming > username and storing zone in avp(zone) variable, and calling same variable > in following code > > if ( !ds_select_dst("$avp(zone)", "4", "FM10")) > > Question: now either user belongs to zone 1 or 2, so it is *NOT* going > to do load-balancing between two. But if I want to allow some user to do > load-balancing then how it will be possible in above scenario? > > Can i set "setid" on fly so i can pass request along with user request > and set same group for both switch and user call load-balance on both > switch? > > Any other idea? > > > _______________________________________________ > 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 vladpaiu at opensips.org Thu Mar 19 17:41:09 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Thu, 19 Mar 2015 18:41:09 +0200 Subject: [OpenSIPS-Users] Dispatcher user specific route question - 2.1 In-Reply-To: References: <550AF9C0.6070801@opensips.org> Message-ID: <550AFC25.2070507@opensips.org> Hello, It will do fail-over. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 19.03.2015 18:39, Satish Patel wrote: > Thanks Vlad, > > Superb! so it will do round-robin? or fail-over? > > On Thu, Mar 19, 2015 at 12:30 PM, Vlad Paiu > wrote: > > Hello, > > If you want to do dispatching between multiple setids, > ds_select_dst() allows that. See the docs at [1] , you can provide > a comma separated list of setids - so your $avp(zone) can contain > '1,2' and OpenSIPS will try to first send to the servers in setid > 1, and then, if those fail, to the servers in setid 2. > > [1] > http://www.opensips.org/html/docs/modules/1.11.x/dispatcher#id294368 > > Best Regards, > > Vlad Paiu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 19.03.2015 06:17, Satish Patel wrote: >> I have add extra "zone" column in subscriber table, >> >> +--------------+---------+ >> | username | zone | >> +--------------+---------+ >> | 1001 | 1 | >> | 1002 | 2 | >> +--------------+---------+ >> >> >> In dispatcher table I have following two Freeswitch in two groups. >> >> +-------+-----------------------------+--------------------+ >> | setid | destination | description | >> +-------+------------------------------+-------------------+ >> | 1 | sip:fs1.example.com | >> Freeswitch-1 | >> | 2 | sip:fs2.example.com | >> Freeswitch-2 | >> +-------+------------------------------+-------------------+ >> >> >> in opensips.cfg script i am query subscriber table base on >> incoming username and storing zone in avp(zone) variable, and >> calling same variable in following code >> >> if ( !ds_select_dst("$avp(zone)", "4", "FM10")) >> >> Question: now either user belongs to zone 1 or 2, so it is *NOT* >> going to do load-balancing between two. But if I want to allow >> some user to do load-balancing then how it will be possible in >> above scenario? >> >> Can i set "setid" on fly so i can pass request along with user >> request and set same group for both switch and user call >> load-balance on both switch? >> >> Any other idea? >> >> >> _______________________________________________ >> 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 satish.txt at gmail.com Thu Mar 19 17:42:21 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 19 Mar 2015 12:42:21 -0400 Subject: [OpenSIPS-Users] Dispatcher user specific route question - 2.1 In-Reply-To: <550AFC25.2070507@opensips.org> References: <550AF9C0.6070801@opensips.org> <550AFC25.2070507@opensips.org> Message-ID: Thanks! for quick answer!! On Thu, Mar 19, 2015 at 12:41 PM, Vlad Paiu wrote: > Hello, > > It will do fail-over. > > Best Regards, > > Vlad Paiu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 19.03.2015 18:39, Satish Patel wrote: > > Thanks Vlad, > > Superb! so it will do round-robin? or fail-over? > > On Thu, Mar 19, 2015 at 12:30 PM, Vlad Paiu wrote: > >> Hello, >> >> If you want to do dispatching between multiple setids, ds_select_dst() >> allows that. See the docs at [1] , you can provide a comma separated list >> of setids - so your $avp(zone) can contain '1,2' and OpenSIPS will try to >> first send to the servers in setid 1, and then, if those fail, to the >> servers in setid 2. >> >> [1] http://www.opensips.org/html/docs/modules/1.11.x/dispatcher#id294368 >> >> Best Regards, >> >> Vlad Paiu >> OpenSIPS Developerhttp://www.opensips-solutions.com >> >> On 19.03.2015 06:17, Satish Patel wrote: >> >> I have add extra "zone" column in subscriber table, >> >> +--------------+---------+ >> | username | zone | >> +--------------+---------+ >> | 1001 | 1 | >> | 1002 | 2 | >> +--------------+---------+ >> >> >> In dispatcher table I have following two Freeswitch in two groups. >> >> +-------+-----------------------------+--------------------+ >> | setid | destination | description | >> +-------+------------------------------+-------------------+ >> | 1 | sip:fs1.example.com | Freeswitch-1 | >> | 2 | sip:fs2.example.com | Freeswitch-2 | >> +-------+------------------------------+-------------------+ >> >> >> in opensips.cfg script i am query subscriber table base on incoming >> username and storing zone in avp(zone) variable, and calling same variable >> in following code >> >> if ( !ds_select_dst("$avp(zone)", "4", "FM10")) >> >> Question: now either user belongs to zone 1 or 2, so it is *NOT* going >> to do load-balancing between two. But if I want to allow some user to do >> load-balancing then how it will be possible in above scenario? >> >> Can i set "setid" on fly so i can pass request along with user request >> and set same group for both switch and user call load-balance on both >> switch? >> >> Any other idea? >> >> >> _______________________________________________ >> 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 bogdan at opensips.org Thu Mar 19 17:47:15 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 19 Mar 2015 18:47:15 +0200 Subject: [OpenSIPS-Users] SIP/2.0 477 Send failed (477/TM) - Route In-Reply-To: <1426610268851-7595929.post@n2.nabble.com> References: <1426610268851-7595929.post@n2.nabble.com> Message-ID: <550AFD93.5080308@opensips.org> Hi Leo, If you look in your logs, you should see some errors where OpenSIPS complains about not being able to open some TCP connection. Basically OpenSIPS tried to forward the call by TCP but failed for some reasons (TCP related). Check the logs. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.03.2015 18:37, leo wrote: > Hello, > > I'm receiving the following message when a try to place a call: > SIP/2.0 477 Send failed (477/TM) > > This is desired issue because the callee UA is not online and in userloc it > is not expired yet. > > My question is, which would be the process or the route this event (477 Send > failed) is processed? I've tried to log on failure_route, onreply_route and > even on branch_route but it was unsuccessful. > > Thanks a lot, > > Leo > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/SIP-2-0-477-Send-failed-477-TM-Route-tp7595929.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 tito at xsvoce.com Thu Mar 19 21:32:49 2015 From: tito at xsvoce.com (Tito Cumpen) Date: Thu, 19 Mar 2015 16:32:49 -0400 Subject: [OpenSIPS-Users] WebSocket Support in OpenSIPS 2.1 In-Reply-To: <14411519-2D6B-45D3-B488-FF2A4B7C5E92@ag-projects.com> References: <550879DC.6080707@opensips.org> <14411519-2D6B-45D3-B488-FF2A4B7C5E92@ag-projects.com> Message-ID: Great news, Are there any media engines that can be used in conjunction with opensips that would allow the interop between webrtc sip clients and standard sip? I am aware that freeswitch will currently do this. Thanks, Tito On Wed, Mar 18, 2015 at 3:36 AM, Sa?l Ibarra Corretg? wrote: > Congrats to the team! Great work! > > On 17 Mar 2015, at 20:00, R?zvan Crainea wrote: > > > Hello, all! > > > > Aaand, we're finally making it official: OpenSIPS 2.1 will have > *WebSockets* support! > > > > Are you planning to use (or perhaps you're already using) WebRTC based > SIP clients, but you are having hard time setting up the platform? Starting > from now, it has never been simpler - based on your needs and feedback[1] > we decided to implement a WebSocket server directly in OpenSIPS. > > > > And we're doing it now! Starting with the new OpenSIPS 2.1 release you > will be able to plug your web-based SIP clients directly in your OpenSIPS > server using the new WebSocket transport protocol[2]. > > > > We've also setup a short tutorial[3] for you to integrate this feature > in your platform easier. Many thanks to Eric Tamme (lirakis) for all his > help with the tutorial as well as for the intensive tests. > > > > [1] http://www.opensips.org/Community/IRCmeeting20141029 > > [2] http://www.opensips.org/html/docs/modules/2.1.x/proto_ws > > [3] http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 > > > > Best regards, > > -- > > R?zvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > 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 eric at uphreak.com Thu Mar 19 21:34:12 2015 From: eric at uphreak.com (Eric Tamme) Date: Thu, 19 Mar 2015 14:34:12 -0600 Subject: [OpenSIPS-Users] WebSocket Support in OpenSIPS 2.1 In-Reply-To: References: <550879DC.6080707@opensips.org> <14411519-2D6B-45D3-B488-FF2A4B7C5E92@ag-projects.com> Message-ID: <550B32C4.70004@uphreak.com> yes - a tutorial was linked in the announcement which includes setting up rtpengine with opensips+websockets to do rtp<->dtls-srtp interop. http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 -Eric On 03/19/2015 02:32 PM, Tito Cumpen wrote: > Great news, > > > Are there any media engines that can be used in conjunction with > opensips that would allow the interop between webrtc sip clients and > standard sip? I am aware that freeswitch will currently do this. > > Thanks, > Tito > > On Wed, Mar 18, 2015 at 3:36 AM, Sa?l Ibarra Corretg? > > wrote: > > Congrats to the team! Great work! > > On 17 Mar 2015, at 20:00, R?zvan Crainea > wrote: > > > Hello, all! > > > > Aaand, we're finally making it official: OpenSIPS 2.1 will have > *WebSockets* support! > > > > Are you planning to use (or perhaps you're already using) WebRTC > based SIP clients, but you are having hard time setting up the > platform? Starting from now, it has never been simpler - based on > your needs and feedback[1] we decided to implement a WebSocket > server directly in OpenSIPS. > > > > And we're doing it now! Starting with the new OpenSIPS 2.1 > release you will be able to plug your web-based SIP clients > directly in your OpenSIPS server using the new WebSocket transport > protocol[2]. > > > > We've also setup a short tutorial[3] for you to integrate this > feature in your platform easier. Many thanks to Eric Tamme > (lirakis) for all his help with the tutorial as well as for the > intensive tests. > > > > [1] http://www.opensips.org/Community/IRCmeeting20141029 > > [2] http://www.opensips.org/html/docs/modules/2.1.x/proto_ws > > [3] http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 > > > > Best regards, > > -- > > R?zvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at nbtbizcapital.com Thu Mar 19 21:58:23 2015 From: carlos at nbtbizcapital.com (Carlos Cruz) Date: Thu, 19 Mar 2015 16:58:23 -0400 Subject: [OpenSIPS-Users] error 483 In-Reply-To: <550AF8CA.8070903@opensips.org> References: <034a01d061ea$81d58500$85808f00$@nbtbizcapital.com> <550AF8CA.8070903@opensips.org> Message-ID: <068701d06287$703edf60$50bc9e20$@nbtbizcapital.com> this was it " Maybe the SIP phone sends the IP of the server instead of the domain that you have configured, and your script is configured to route out such requests" this was it thanks!!! Carlos From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Vlad Paiu Sent: Thursday, March 19, 2015 12:27 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] error 483 Hello, 483 usually means 'Too Many Hops'. If you do a SIP trace on the server, do you see OpenSIPS looping the request to itself ? Maybe the SIP phone sends the IP of the server instead of the domain that you have configured, and your script is configured to route out such requests. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 19.03.2015 04:15, Carlos Cruz wrote: Hi; Can someone tell me why or where I may find the info I need; I'm able to register external remote phones (hard phones), but the internal phone (soft phones) within the same network as the OpenSIPS test server report error 483. Thanks!! Carlos _______________________________________________ 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 542590776 at qq.com Fri Mar 20 02:32:28 2015 From: 542590776 at qq.com (jacky) Date: Thu, 19 Mar 2015 18:32:28 -0700 (MST) Subject: [OpenSIPS-Users] Jitsi sent REGISTER, Opensips received nothing In-Reply-To: <550AF9FC.5070102@opensips.org> References: <1426746188154-7596019.post@n2.nabble.com> <550AF9FC.5070102@opensips.org> Message-ID: <1426815148429-7596053.post@n2.nabble.com> I disableb the firewall, and they can ping each other through. Now, I rewrited the content of opensips.cfg, changed "modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:22222") " to "modparam("rtpproxy", "rtpproxy_sock", "udp:42.123.76.60:22222") " "42.123.76.60" is a public network IP. And now i got errors showed in opensips.log: localhost /usr/local/opensips_proxy/sbin/opensips[5179]: ERROR:rtpproxy:send_rtpp_command: timeout waiting reply from a RTP proxy localhost /usr/local/opensips_proxy/sbin/opensips[5179]: ERROR:rtpproxy:send_rtpp_command: timeout waiting reply from a RTP proxy localhost /usr/local/opensips_proxy/sbin/opensips[5179]: ERROR:rtpproxy:send_rtpp_command: proxy does not respond, disable it localhost /usr/local/opensips_proxy/sbin/opensips[5179]: ERROR:rtpproxy:send_rtpp_command: proxy does not respond, disable it localhost /usr/local/opensips_proxy/sbin/opensips[5179]: WARNING:rtpproxy:rtpp_test: can't get version of the RTP proxy localhost /usr/local/opensips_proxy/sbin/opensips[5179]: WARNING:rtpproxy:rtpp_test: can't get version of the RTP proxy localhost /usr/local/opensips_proxy/sbin/opensips[5179]: WARNING:rtpproxy:rtpp_test: support for RTP proxy has been disabled temporarily localhost /usr/local/opensips_proxy/sbin/opensips[5179]: WARNING:rtpproxy:rtpp_test: support for RTP proxy has been disabled temporarily localhost opensips: INFO:core:daemonize: pre-daemon process exiting with 0 thanks for your attention! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Jitsi-sent-REGISTER-Opensips-received-nothing-tp7596019p7596053.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogdan at opensips.org Fri Mar 20 12:14:48 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 20 Mar 2015 13:14:48 +0200 Subject: [OpenSIPS-Users] WebSocket Support in OpenSIPS 2.1 In-Reply-To: References: <550879DC.6080707@opensips.org> <14411519-2D6B-45D3-B488-FF2A4B7C5E92@ag-projects.com> Message-ID: <550C0128.8030407@opensips.org> Yes, there is rtpengine for example. Razvan put together the WS tutorial coveringthe media side too: http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.03.2015 22:32, Tito Cumpen wrote: > Great news, > > > Are there any media engines that can be used in conjunction with > opensips that would allow the interop between webrtc sip clients and > standard sip? I am aware that freeswitch will currently do this. > > Thanks, > Tito > > On Wed, Mar 18, 2015 at 3:36 AM, Sa?l Ibarra Corretg? > > wrote: > > Congrats to the team! Great work! > > On 17 Mar 2015, at 20:00, R?zvan Crainea > wrote: > > > Hello, all! > > > > Aaand, we're finally making it official: OpenSIPS 2.1 will have > *WebSockets* support! > > > > Are you planning to use (or perhaps you're already using) WebRTC > based SIP clients, but you are having hard time setting up the > platform? Starting from now, it has never been simpler - based on > your needs and feedback[1] we decided to implement a WebSocket > server directly in OpenSIPS. > > > > And we're doing it now! Starting with the new OpenSIPS 2.1 > release you will be able to plug your web-based SIP clients > directly in your OpenSIPS server using the new WebSocket transport > protocol[2]. > > > > We've also setup a short tutorial[3] for you to integrate this > feature in your platform easier. Many thanks to Eric Tamme > (lirakis) for all his help with the tutorial as well as for the > intensive tests. > > > > [1] http://www.opensips.org/Community/IRCmeeting20141029 > > [2] http://www.opensips.org/html/docs/modules/2.1.x/proto_ws > > [3] http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1 > > > > Best regards, > > -- > > R?zvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dotnetdub at gmail.com Fri Mar 20 14:56:09 2015 From: dotnetdub at gmail.com (dotnetdub) Date: Fri, 20 Mar 2015 13:56:09 +0000 Subject: [OpenSIPS-Users] CDRTool / Freeradius / MySQL Message-ID: Hi, sometime ago only myisam storage engine was supported. Is INNODb supported now? Many thanks Brian From stuart.mills at invosys.com Fri Mar 20 15:13:48 2015 From: stuart.mills at invosys.com (Stuart Mills, Invosys) Date: Fri, 20 Mar 2015 14:13:48 -0000 Subject: [OpenSIPS-Users] Intermittent call dropping issue Message-ID: <016001d06318$15eb4710$41c1d530$@invosys.com> Hi, I'm currently experiencing an issue when using OpenSIPS and FreeSWITCH within the same network. Calls arrive at the OpenSIPS border, then I use the dispatcher module to send to one of 3 FreeSWITCH instances. On a bad call it seems like 200OK is being sent back from FreeSWITCH on calls that will drop, it tries time and time again until giving up after 30 seconds, but OpenSIPS isn't responding with the ACK. The IP addresses in the trace I've got look good, all internal NAT addresses so I'm not sure how it could be missing this packet. Have any one experienced this using a similar setup? I can post the opensips.cfg file if necessary. Regards, Stuart Mills Senior Network Engineer Invosys Ltd. Direct. 0161 444 7403 Web. www.invosys.com cid:862D2963-B682-4FBA-A237-D1F118B1E624 DISCLAIMER: This e-mail and files transmitted with it are confidential and intended solely for the individual to whom they are addressed, and upon the basis that the recipient will conduct the appropriate virus checks. If you are not the addressee, you are not authorised to use the information or to place any reliance upon it, nor should you copy it or show it to anyone. Internet communications are not secure and Invosys Ltd are not responsible for the abuse by third parties, nor for any alteration or corruption in transmission, nor for any damage or loss caused by any virus or other defect. Registered and correspondence address: Invosys Ltd (5799390), New Bridgewater House, Mayfield Avenue, Worsley, Manchester, M28 3JF -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 12265 bytes Desc: not available URL: From i.p at ringcloud.ru Fri Mar 20 15:43:22 2015 From: i.p at ringcloud.ru (=?UTF-8?B?0JjQs9C+0YDRjCDQn9Cw0LLQu9C+0LI=?=) Date: Fri, 20 Mar 2015 18:43:22 +0400 Subject: [OpenSIPS-Users] How to handle "Event: dialog" Message-ID: Hi, list. I have a problem with presence module: most devices, that we uses, sends "Event: dialog" for subscribe to BLF, but opensips answer for this like: 192.168.1.122.5062 > 192.168.1.7.5060: SIP, length: 427 SUBSCRIBE sip:1002@ 192.168.1.7 SIP/2.0 ..... Accept: application/dialog-info+xml User-: Yealink SIP-T20P 7.72.14.6 *Event: dialog* 192.168.1.7.5060 > 192.168.1.122.5062: SIP, length: 377 SIP/2.0 489 Bad Event .... CSeq: 1 SUBSCRIBE Allow-Events: message-summary, *dialog;sla*, presence.winfo, presence -- ____________ ? ?????????, ?????? ????? RingCloud -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at uphreak.com Fri Mar 20 15:44:33 2015 From: eric at uphreak.com (Eric Tamme) Date: Fri, 20 Mar 2015 08:44:33 -0600 Subject: [OpenSIPS-Users] How to handle "Event: dialog" In-Reply-To: References: Message-ID: <550C3251.4040006@uphreak.com> Use the presence module along with the dialog event module. On 03/20/2015 08:43 AM, ????? ?????? wrote: > Hi, list. > > I have a problem with presence module: most devices, that we uses, > sends "Event: dialog" for subscribe to BLF, but opensips answer for > this like: > > 192.168.1.122.5062 > 192.168.1.7.5060: SIP, length: 427 > SUBSCRIBE sip:1002@ 192.168.1.7 SIP/2.0 > ..... > Accept: application/dialog-info+xml > User-: Yealink SIP-T20P 7.72.14.6 > *Event: dialog* > > 192.168.1.7.5060 > 192.168.1.122.5062: SIP, length: 377 > SIP/2.0 489 Bad Event > .... > CSeq: 1 SUBSCRIBE > Allow-Events: message-summary, *dialog;sla*, presence.winfo, > presence > > > > -- > ____________ > ? ?????????, > ?????? ????? > RingCloud > > > _______________________________________________ > 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 peter.kust at businessuites.com Fri Mar 20 16:59:59 2015 From: peter.kust at businessuites.com (Peter Kust) Date: Fri, 20 Mar 2015 15:59:59 +0000 Subject: [OpenSIPS-Users] Presence Error messages In-Reply-To: <72838165E698AB40827E601B9E1F2B9AC01D8E@BSSHDCEXS01.colo.businessuites.com> References: <72838165E698AB40827E601B9E1F2B9AC01D8E@BSSHDCEXS01.colo.businessuites.com> Message-ID: <72838165E698AB40827E601B9E1F2B9AC05194@BSSHDCEXS01.colo.businessuites.com> Can anyone give me any guidance on how to troubleshoot these errors? It's taking down one of our client's phone lines and I would really like to understand what is happening here. Cordially, Peter Nayland Kust Director of Technologies BusinesSuites 24624 Interstate 45 North, Suite 200 Houston, TX 77386 Tel: 281.378.8051 Fax: 855.287.6961 peter.kust at businessuites.com From: Peter Kust [mailto:peter.kust at businessuites.com] Sent: Thursday, March 19, 2015 10:11 AM To: 'users at lists.opensips.org' Subject: [OpenSIPS-Users] Presence Error messages I am attempting to troubleshoot what I think is a presence/b2b_sca issue. I keep getting an error message from presence as follows: ERROR:presence:update_presentity: No E_Tag match [ff5ad69c9be06cffaa136492f4fb3b50] At some point during the day, I will see this error message: ERROR:presence:handle_subscribe: in event specific subscription handling At this point, an outbound call from a line appearance provisioned to the b2b_sca module fails. The outbound call is being attempted from a Cisco SPA525G2, and the message on the phone screen shows "no line"-despite happening at a time when it is known there are no calls on the system that I can see. The observed behavior of the phone is to show "No line", and the phone itself gets a What do these error messages mean? What is the system trying to tell me? I am trying to get my brain around what the error messages are saying so I can figure out where to look next in my troubleshooting. The proxy is functioning well in all other respects. Cordially, Peter Nayland Kust Director of Technologies BusinesSuites 24624 Interstate 45 North, Suite 200 Houston, TX 77386 Tel: 281.378.8051 Fax: 855.287.6961 peter.kust at businessuites.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 20 17:48:39 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 20 Mar 2015 18:48:39 +0200 Subject: [OpenSIPS-Users] Presence Error messages In-Reply-To: <72838165E698AB40827E601B9E1F2B9AC01D8E@BSSHDCEXS01.colo.businessuites.com> References: <72838165E698AB40827E601B9E1F2B9AC01D8E@BSSHDCEXS01.colo.businessuites.com> Message-ID: <550C4F67.6070908@opensips.org> Hi Peter, The first error means: the presentity your PUBLISH tries to update (using etag as reference) does not exist anymore. The etag is created on the first PUBLISH and sent back to publisher - it will use this etag each time it wants to update that particular presentity. Maybe the re-publishing is too late and the presentity is already expired in opensips memory. Do you have dbg logs + pcap for this ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.03.2015 17:10, Peter Kust wrote: > > I am attempting to troubleshoot what I think is a presence/b2b_sca issue. > > I keep getting an error message from presence as follows: > > ERROR:presence:update_presentity: No E_Tag match > [ff5ad69c9be06cffaa136492f4fb3b50] > > At some point during the day, I will see this error message: > > ERROR:presence:handle_subscribe: in event specific subscription handling > > At this point, an outbound call from a line appearance provisioned to > the b2b_sca module fails. The outbound call is being attempted from a > Cisco SPA525G2, and the message on the phone screen shows ?no > line??despite happening at a time when it is known there are no calls > on the system that I can see. The observed behavior of the phone is > to show ?No line?, and the phone itself gets a > > What do these error messages mean? What is the system trying to tell > me? I am trying to get my brain around what the error messages are > saying so I can figure out where to look next in my troubleshooting. > The proxy is functioning well in all other respects. > > Cordially, > > Peter Nayland Kust > > Director of Technologies > > BusinesSuites > > 24624 Interstate 45 North, Suite 200 > > Houston, TX 77386 > > *Tel:*281.378.8051 > > *Fax:*855.287.6961 > > *peter.kust at businessuites.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 peter.kust at businessuites.com Fri Mar 20 20:54:45 2015 From: peter.kust at businessuites.com (Peter Kust) Date: Fri, 20 Mar 2015 19:54:45 +0000 Subject: [OpenSIPS-Users] Presence Error messages In-Reply-To: <550C4F67.6070908@opensips.org> References: <72838165E698AB40827E601B9E1F2B9AC01D8E@BSSHDCEXS01.colo.businessuites.com> <550C4F67.6070908@opensips.org> Message-ID: <72838165E698AB40827E601B9E1F2B9AC06788@BSSHDCEXS01.colo.businessuites.com> I'm running a rotating packet capture right now, but at the moment that error hasn't resurfaced since I started the capture. What is perplexing to me is that I have never seen in my logs a PUBLISH with that particular etag (as pulled from the sip-if-tag header on the received PUBLISH). Only once have I even seen that etag in the presentity table. Yet somewhere that etag has survived complete reboots of the involved phones and opensips itself. Where do I look to see what might be hanging on to that etag (presumably erroneously)? Also, it seems that the update_presentity is being called by SUBSCRIBE, not PUBLISH Mar 20 10:20:31 proxy-2 o[21911]: [83693] SUBSCRIBE [line-seize:15] sip:SLA-4103855210-1 at X.X.X.X From:sip:SLA-4103855210-1@ X.X.X.X To:sip:SLA-4103855210-1@ X.X.X.X Call-ID:4925925-382640b2@ Y.Y.Y.Y Cseq:40035 Contact:"5210" < Y.Y.Y.Y:5062> Mar 20 10:20:31 proxy-2 o[21911]: ERROR:presence:update_presentity: No E_Tag match [ff5ad69c9be06cffaa136492f4fb3b50] Mar 20 10:20:31 proxy-2 o[21911]: INFO:presence:update_subscription: notify Mar 20 10:20:31 proxy-2 o[21911]: INFO:presence:send_notify_request: NOTIFY sip:SLA-4103855210-1@@ X.X.X.X via sip:SLA-4103855210-1@ Y.Y.Y.Y:5062 on behalf of sip:SLA-4103855210-1@@ X.X.X.X for event line-seize, to_tag=e92fa9072a6867d6d6f7ec7d0c504ad5-5cd1, cseq=1 So I am trying to figure out where that etag is hiding. Because from what I can see it shouldn't be getting referenced at all. Cordially, Peter Nayland Kust Director of Technologies BusinesSuites 24624 Interstate 45 North, Suite 200 Houston, TX 77386 Tel: 281.378.8051 Fax: 855.287.6961 peter.kust at businessuites.com From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Friday, March 20, 2015 11:49 AM To: OpenSIPS users mailling list; Peter Kust Subject: Re: [OpenSIPS-Users] Presence Error messages Hi Peter, The first error means: the presentity your PUBLISH tries to update (using etag as reference) does not exist anymore. The etag is created on the first PUBLISH and sent back to publisher - it will use this etag each time it wants to update that particular presentity. Maybe the re-publishing is too late and the presentity is already expired in opensips memory. Do you have dbg logs + pcap for this ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.03.2015 17:10, Peter Kust wrote: I am attempting to troubleshoot what I think is a presence/b2b_sca issue. I keep getting an error message from presence as follows: ERROR:presence:update_presentity: No E_Tag match [ff5ad69c9be06cffaa136492f4fb3b50] At some point during the day, I will see this error message: ERROR:presence:handle_subscribe: in event specific subscription handling At this point, an outbound call from a line appearance provisioned to the b2b_sca module fails. The outbound call is being attempted from a Cisco SPA525G2, and the message on the phone screen shows "no line"-despite happening at a time when it is known there are no calls on the system that I can see. The observed behavior of the phone is to show "No line", and the phone itself gets a What do these error messages mean? What is the system trying to tell me? I am trying to get my brain around what the error messages are saying so I can figure out where to look next in my troubleshooting. The proxy is functioning well in all other respects. Cordially, Peter Nayland Kust Director of Technologies BusinesSuites 24624 Interstate 45 North, Suite 200 Houston, TX 77386 Tel: 281.378.8051 Fax: 855.287.6961 peter.kust at businessuites.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 osas at voipembedded.com Fri Mar 20 21:41:30 2015 From: osas at voipembedded.com (Ovidiu Sas) Date: Fri, 20 Mar 2015 16:41:30 -0400 Subject: [OpenSIPS-Users] Presence Error messages In-Reply-To: <72838165E698AB40827E601B9E1F2B9AC06788@BSSHDCEXS01.colo.businessuites.com> References: <72838165E698AB40827E601B9E1F2B9AC01D8E@BSSHDCEXS01.colo.businessuites.com> <550C4F67.6070908@opensips.org> <72838165E698AB40827E601B9E1F2B9AC06788@BSSHDCEXS01.colo.businessuites.com> Message-ID: It might be that the phone is generating a SUBSCRIBE with a particular SIP-If-Match header. For each line-seize subscription, a notification is sent out. If a SUBSCRIBE with a particular SIP-If-Match header is received, but no SIP-ETag is matched, a new notification is generated, but it seems that the phone ignores it and re-sends the subscription. Having the full pcap will help understand what's going on here. Regards, Ovidiu Sas On Fri, Mar 20, 2015 at 3:54 PM, Peter Kust wrote: > I?m running a rotating packet capture right now, but at the moment that > error hasn?t resurfaced since I started the capture. > > > > What is perplexing to me is that I have never seen in my logs a PUBLISH with > that particular etag (as pulled from the sip-if-tag header on the received > PUBLISH). Only once have I even seen that etag in the presentity table. > Yet somewhere that etag has survived complete reboots of the involved phones > and opensips itself. Where do I look to see what might be hanging on to > that etag (presumably erroneously)? > > > > Also, it seems that the update_presentity is being called by SUBSCRIBE, not > PUBLISH > > > > Mar 20 10:20:31 proxy-2 o[21911]: [83693] SUBSCRIBE [line-seize:15] > sip:SLA-4103855210-1 at X.X.X.X From:sip:SLA-4103855210-1@ X.X.X.X > To:sip:SLA-4103855210-1@ X.X.X.X Call-ID:4925925-382640b2@ Y.Y.Y.Y > Cseq:40035 Contact:"5210" < > Y.Y.Y.Y:5062> > > Mar 20 10:20:31 proxy-2 o[21911]: ERROR:presence:update_presentity: No E_Tag > match [ff5ad69c9be06cffaa136492f4fb3b50] > > Mar 20 10:20:31 proxy-2 o[21911]: INFO:presence:update_subscription: notify > > Mar 20 10:20:31 proxy-2 o[21911]: INFO:presence:send_notify_request: NOTIFY > sip:SLA-4103855210-1@@ X.X.X.X via sip:SLA-4103855210-1@ Y.Y.Y.Y:5062 on > behalf of sip:SLA-4103855210-1@@ X.X.X.X for event line-seize, > to_tag=e92fa9072a6867d6d6f7ec7d0c504ad5-5cd1, cseq=1 > > > > So I am trying to figure out where that etag is hiding. Because from what I > can see it shouldn?t be getting referenced at all. > > > > Cordially, > > > > Peter Nayland Kust > > Director of Technologies > > BusinesSuites > > 24624 Interstate 45 North, Suite 200 > > Houston, TX 77386 > > Tel: 281.378.8051 > > Fax: 855.287.6961 > > peter.kust at businessuites.com > > From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] > Sent: Friday, March 20, 2015 11:49 AM > To: OpenSIPS users mailling list; Peter Kust > Subject: Re: [OpenSIPS-Users] Presence Error messages > > > > Hi Peter, > > The first error means: the presentity your PUBLISH tries to update (using > etag as reference) does not exist anymore. The etag is created on the first > PUBLISH and sent back to publisher - it will use this etag each time it > wants to update that particular presentity. > > Maybe the re-publishing is too late and the presentity is already expired in > opensips memory. > > Do you have dbg logs + pcap for this ? > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > > http://www.opensips-solutions.com > > On 19.03.2015 17:10, Peter Kust wrote: > > I am attempting to troubleshoot what I think is a presence/b2b_sca issue. > > > > I keep getting an error message from presence as follows: > > ERROR:presence:update_presentity: No E_Tag match > [ff5ad69c9be06cffaa136492f4fb3b50] > > > > At some point during the day, I will see this error message: > > ERROR:presence:handle_subscribe: in event specific subscription handling > > > > At this point, an outbound call from a line appearance provisioned to the > b2b_sca module fails. The outbound call is being attempted from a Cisco > SPA525G2, and the message on the phone screen shows ?no line??despite > happening at a time when it is known there are no calls on the system that I > can see. The observed behavior of the phone is to show ?No line?, and the > phone itself gets a > > > > What do these error messages mean? What is the system trying to tell me? I > am trying to get my brain around what the error messages are saying so I can > figure out where to look next in my troubleshooting. The proxy is > functioning well in all other respects. > > > > Cordially, > > > > Peter Nayland Kust > > Director of Technologies > > BusinesSuites > > 24624 Interstate 45 North, Suite 200 > > Houston, TX 77386 > > Tel: 281.378.8051 > > Fax: 855.287.6961 > > peter.kust at businessuites.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 > -- VoIP Embedded, Inc. http://www.voipembedded.com From lists at kavun.ch Fri Mar 20 22:05:27 2015 From: lists at kavun.ch (Emrah) Date: Fri, 20 Mar 2015 22:05:27 +0100 Subject: [OpenSIPS-Users] 'opensipsdbctl create' returns 'ERROR: relation "call_center_id_seq" does not exist' Message-ID: <04BFA674-F83C-47B7-8476-F423420B9F4B@kavun.ch> Hi all, A Google search on this pointed me to here, the mailing list. I am using OpenSIPS2.1.0 and am trying to populate my Postgres database with the 'opensipsdbctl' script. I am getting the following error: ERROR: relation "call_center" does not exist ERROR: relation "call_center_id_seq" does not exist ERROR: Grant privileges to extra tables failed! OpenSIPS is also my gateway to learning about Postgres, and I apologize for the limited info in this post. A Google search returned a recent post about the same issue: http://opensips-open-sip-server.1449251.n2.nabble.com/Table-creation-errors-with-Postgres-td7595323.html I didn't find anything more on the subject and resorted on posting here to ask for help. Any pointers would be much appreciated! Best, Emrah -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzcudunl at yahoo.it Sun Mar 22 14:53:53 2015 From: uzcudunl at yahoo.it (leo) Date: Sun, 22 Mar 2015 06:53:53 -0700 (MST) Subject: [OpenSIPS-Users] SIP/2.0 477 Send failed (477/TM) - Route In-Reply-To: <550AFD93.5080308@opensips.org> References: <1426610268851-7595929.post@n2.nabble.com> <550AFD93.5080308@opensips.org> Message-ID: <1427032433169-7596066.post@n2.nabble.com> Hello Bogdan, Yes, you're correct. But my point is how could i manage that situation? From bogus@does.not.exist.com Wed Mar 18 09:56:13 2015 From: bogus@does.not.exist.com () Date: Wed, 18 Mar 2015 08:56:13 -0000 Subject: No subject Message-ID: redirect to the voicemail or other process)? Is it in the TM module? From the logs i see this: Mar 22 14:41:58 sip-lab /usr/sbin/opensips[17721]: DBG:core:tcp_send: no open tcp connection found, opening new one Mar 22 14:42:09 sip-lab /usr/sbin/opensips[17721]: ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s Mar 22 14:42:09 sip-lab /usr/sbin/opensips[17721]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Mar 22 14:42:09 sip-lab /usr/sbin/opensips[17721]: ERROR:core:tcp_send: connect failed Mar 22 14:42:09 sip-lab /usr/sbin/opensips[17721]: ERROR:tm:msg_send: tcp_send failed Mar 22 14:42:09 sip-lab /usr/sbin/opensips[17721]: ERROR:tm:t_forward_nonack: sending request failed Mar 22 14:42:09 sip-lab /usr/sbin/opensips[17721]: DBG:tm:t_relay_to: t_forward_nonack returned error I would, from the this latest TM errors to redirect the call to the voicemail but i don't understand where to place the t_relay. Thanks a lot!, Leo -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/SIP-2-0-477-Send-failed-477-TM-Route-tp7595929p7596066.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From linuxvenkey at gmail.com Mon Mar 23 06:58:01 2015 From: linuxvenkey at gmail.com (Venkatesh Macha) Date: Sun, 22 Mar 2015 22:58:01 -0700 (MST) Subject: [OpenSIPS-Users] SIP/2.0 477 Send failed (477/TM) - Route In-Reply-To: <1427032433169-7596066.post@n2.nabble.com> References: <1426610268851-7595929.post@n2.nabble.com> <550AFD93.5080308@opensips.org> <1427032433169-7596066.post@n2.nabble.com> Message-ID: <1427090281911-7596067.post@n2.nabble.com> Hi Leo, Actually 477 is transport error. The failure route is triggered only when there is a SIP failure. So if you want to handle the 477 send failed situation, Just use "0x02" flag with t_relay(). Here is the sample script. if (!t_relay("3")) { #0x02 option will make t_relay() to return failure to script instead of sending the 477 out #0x01 skips 100 trying message.. # So i am using 3, i.e 0x01 and 0x02.. # so now we can send call to voice mail etc,, # If you want to remove the user from location table remove it now , So that we can get 477 for next requests. if (!remove("location", "$ru")) sl_reply_error(); else xlog("L_INFO","AOR of $rU is Removed from DB"); if((is_method("INVITE"))) { # send to voice mail or do what you want to do. } } Cheers, Venkatesh Macha, VOIP Engineer. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/SIP-2-0-477-Send-failed-477-TM-Route-tp7595929p7596067.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From uzcudunl at yahoo.it Mon Mar 23 08:53:02 2015 From: uzcudunl at yahoo.it (leo) Date: Mon, 23 Mar 2015 00:53:02 -0700 (MST) Subject: [OpenSIPS-Users] SIP/2.0 477 Send failed (477/TM) - Route In-Reply-To: <1427090281911-7596067.post@n2.nabble.com> References: <1426610268851-7595929.post@n2.nabble.com> <550AFD93.5080308@opensips.org> <1427032433169-7596066.post@n2.nabble.com> <1427090281911-7596067.post@n2.nabble.com> Message-ID: <1427097182638-7596068.post@n2.nabble.com> Thanks a lot Venkatesh!!!! That was a fantastic clue!!! Just one more thing, following your advice, in the INVITE part of the script I'm calling an external app like: if (!t_relay("3")) { if((is_method("INVITE"))) { exec_avp("some script to wake-up the client"); } } The point is that the called UA wakes-up (so this part is working) but the call (invite) is not arriving, should i use something like: append_branch(); t_relay(); after my exec_avp("some script to wake-up the client"); ? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/SIP-2-0-477-Send-failed-477-TM-Route-tp7595929p7596068.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From vladpaiu at opensips.org Mon Mar 23 11:03:13 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Mon, 23 Mar 2015 12:03:13 +0200 Subject: [OpenSIPS-Users] Intermittent call dropping issue In-Reply-To: <016001d06318$15eb4710$41c1d530$@invosys.com> References: <016001d06318$15eb4710$41c1d530$@invosys.com> Message-ID: <550FE4E1.3050205@opensips.org> Hello, OpenSIPS shouldn't respond with the ACk - that should originate from the caller side and OpenSIPS should relay it. Please post the full SIP trace for your call. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 20.03.2015 16:13, Stuart Mills, Invosys wrote: > > Hi, > > I?m currently experiencing an issue when using OpenSIPS and FreeSWITCH > within the same network. > > Calls arrive at the OpenSIPS border, then I use the dispatcher module > to send to one of 3 FreeSWITCH instances. > > On a bad call it seems like 200OK is being sent back from FreeSWITCH > on calls that will drop, it tries time and time again until giving up > after 30 seconds, but OpenSIPS isn?t responding with the ACK. The IP > addresses in the trace I?ve got look good, all internal NAT addresses > so I?m not sure how it could be missing this packet. > > Have any one experienced this using a similar setup? I can post the > opensips.cfg file if necessary. > > Regards, > > *Stuart Mills* > > Senior Network Engineer > > *Invosys Ltd.* > > Direct. 0161 444 7403 > > Web. www.invosys.com > > > cid:862D2963-B682-4FBA-A237-D1F118B1E624 > > *DISCLAIMER:* This e-mail and files transmitted with it are > confidential and intended solely for the individual to whom they are > addressed, and upon the basis that the recipient will conduct the > appropriate virus checks. If you are not the addressee, you are not > authorised to use the information or to place any reliance upon it, > nor should you copy it or show it to anyone. Internet communications > are not secure and Invosys Ltd are not responsible for the abuse by > third parties, nor for any alteration or corruption in transmission, > nor for any damage or loss caused by any virus or other defect. > Registered and correspondence address: Invosys Ltd (5799390), New > Bridgewater House, Mayfield Avenue, Worsley, Manchester, M28 3JF > > > > _______________________________________________ > 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: not available Type: image/png Size: 12265 bytes Desc: not available URL: From vladpaiu at opensips.org Mon Mar 23 12:49:11 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Mon, 23 Mar 2015 13:49:11 +0200 Subject: [OpenSIPS-Users] 'opensipsdbctl create' returns 'ERROR: relation "call_center_id_seq" does not exist' In-Reply-To: <04BFA674-F83C-47B7-8476-F423420B9F4B@kavun.ch> References: <04BFA674-F83C-47B7-8476-F423420B9F4B@kavun.ch> Message-ID: <550FFDB7.9000809@opensips.org> Hello, This has been fixed on the 2.1 GIT branch. Please pull the latest changes and try again. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 20.03.2015 23:05, Emrah wrote: > Hi all, > A Google search on this pointed me to here, the mailing list. > I am using OpenSIPS2.1.0 and am trying to populate my Postgres > database with the 'opensipsdbctl' script. > I am getting the following error: > ERROR: relation "call_center" does not exist > ERROR: relation "call_center_id_seq" does not exist > *ERROR: Grant privileges to extra tables failed!* > > OpenSIPS is also my gateway to learning about Postgres, and I > apologize for the limited info in this post. > A Google search returned a recent post about the same issue: > http://opensips-open-sip-server.1449251.n2.nabble.com/Table-creation-errors-with-Postgres-td7595323.html > I didn't find anything more on the subject and resorted on posting > here to ask for help. > > Any pointers would be much appreciated! > > Best, > Emrah > > > _______________________________________________ > 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 komal.sharma at aricent.com Mon Mar 23 13:10:25 2015 From: komal.sharma at aricent.com (Komal Sharma) Date: Mon, 23 Mar 2015 12:10:25 +0000 Subject: [OpenSIPS-Users] mail regarding the opensips startup. Message-ID: Hi, I am getting the following error while starting the opensips: root at cdrtool:/etc/opensips# opensipsctl start database engine 'MYSQL' loaded Control engine 'FIFO' loaded INFO: Starting OpenSIPS : ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start failed And the related logs for the error are as follows: Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:new_db_id: error while parsing database URL: 'mysql: / / OpenSIPS: opensipsrw @ localhost / OpenSIPS' Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:db_do_init: cannot parse URL 'mysql: / / OpenSIPS: opensipsrw @ localhost / OpenSIPS' Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:usrloc:register_udomain: failed to open database connection Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:registrar:domain_fixup: failed to register domain Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:fix_actions: fixing failed (code=-1) at /usr//etc/opensips/opensips.cfg:233 Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: CRITICAL:core:fix_expr: fix_actions error Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:main: failed to fix configuration with err code -1 Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: INFO:core:cleanup: cleanup Can somebody helps me to resolve this issue. Best Regards. Komal Sharma. "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at kavun.ch Mon Mar 23 13:15:21 2015 From: lists at kavun.ch (Emrah) Date: Mon, 23 Mar 2015 13:15:21 +0100 Subject: [OpenSIPS-Users] 'opensipsdbctl create' returns 'ERROR: relation "call_center_id_seq" does not exist' In-Reply-To: <550FFDB7.9000809@opensips.org> References: <04BFA674-F83C-47B7-8476-F423420B9F4B@kavun.ch> <550FFDB7.9000809@opensips.org> Message-ID: Fantastic, thanks for the response. > On Mar 23, 2015, at 12:49 PM, Vlad Paiu wrote: > > Hello, > > This has been fixed on the 2.1 GIT branch. > Please pull the latest changes and try again. > > Best Regards, > Vlad Paiu > OpenSIPS Developer > http://www.opensips-solutions.com > On 20.03.2015 23:05, Emrah wrote: >> Hi all, >> A Google search on this pointed me to here, the mailing list. >> I am using OpenSIPS2.1.0 and am trying to populate my Postgres database with the 'opensipsdbctl' script. >> I am getting the following error: >> ERROR: relation "call_center" does not exist >> ERROR: relation "call_center_id_seq" does not exist >> ERROR: Grant privileges to extra tables failed! >> >> OpenSIPS is also my gateway to learning about Postgres, and I apologize for the limited info in this post. >> A Google search returned a recent post about the same issue: http://opensips-open-sip-server.1449251.n2.nabble.com/Table-creation-errors-with-Postgres-td7595323.html >> I didn't find anything more on the subject and resorted on posting here to ask for help. >> >> Any pointers would be much appreciated! >> >> Best, >> Emrah >> >> >> _______________________________________________ >> 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 aronp at guaranteedplus.com Mon Mar 23 13:56:03 2015 From: aronp at guaranteedplus.com (Podrigal, Aron) Date: Mon, 23 Mar 2015 08:56:03 -0400 Subject: [OpenSIPS-Users] mail regarding the opensips startup. In-Reply-To: References: Message-ID: Do you have spaces in the db dsn? On Mar 23, 2015 8:10 AM, "Komal Sharma" wrote: > Hi, > > I am getting the following error while starting the opensips: > > > > root at cdrtool:/etc/opensips# opensipsctl start > > database engine 'MYSQL' loaded > > Control engine 'FIFO' loaded > > > > INFO: Starting OpenSIPS : > > > > ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start > failed > > > > And the related logs for the error are as follows: > > > > > > > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:new_db_id: > error while parsing database URL: 'mysql: / / OpenSIPS: opensipsrw @ > localhost / OpenSIPS' > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:db_do_init: > cannot parse URL 'mysql: / / OpenSIPS: opensipsrw @ localhost / OpenSIPS' > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: > ERROR:usrloc:register_udomain: failed to open database connection > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: > ERROR:registrar:domain_fixup: failed to register domain > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:fix_actions: > fixing failed (code=-1) at /usr//etc/opensips/opensips.cfg:233 > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: CRITICAL:core:fix_expr: > fix_actions error > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: ERROR:core:main: failed > to fix configuration with err code -1 > > Mar 23 17:29:36 cdrtool /usr/sbin/opensips[8879]: INFO:core:cleanup: > cleanup > > > > > > > > Can somebody helps me to resolve this issue. > > > > Best Regards. > > Komal Sharma. > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be circulated > or used for any purpose other than for what it is intended. If you have > received this message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing the > contents of this message. Aricent accepts no responsibility for loss or > damage arising from the use of the information transmitted by this email > including damage from virus." > > _______________________________________________ > 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 alexfuttert at hotmail.com Mon Mar 23 17:05:22 2015 From: alexfuttert at hotmail.com (Alexander Freitez) Date: Mon, 23 Mar 2015 16:05:22 +0000 Subject: [OpenSIPS-Users] Opensips like SipProxy Message-ID: I'm beginner with opensips, but I'd like use it like SipProxy. Do you have some configuration example for this?.The idea is "sip users(public ip)-------> opensips (public and private ip)---------->asterisks (private ip)"Thank for you help.Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres.moya.i at gmail.com Mon Mar 23 17:26:24 2015 From: andres.moya.i at gmail.com (Andres Moya) Date: Mon, 23 Mar 2015 16:26:24 -0000 Subject: [OpenSIPS-Users] Opensips like SipProxy In-Reply-To: References: Message-ID: To pass between public/private you will need to use rtpproxy module. Default config is already sip proxy, and ready to customize. Asterisk itself do much much easier as private/public ?SBC?. What exactly scenario you try to achieve? From: Alexander Freitez Sent: Monday, March 23, 2015 4:05 PM To: users at lists.opensips.org Subject: [OpenSIPS-Users] Opensips like SipProxy I'm beginner with opensips, but I'd like use it like SipProxy. Do you have some configuration example for this?. The idea is "sip users(public ip)-------> opensips (public and private ip)---------->asterisks (private ip)" Thank for you help. Regards. -------------------------------------------------------------------------------- _______________________________________________ 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 Mar 23 19:38:17 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 23 Mar 2015 20:38:17 +0200 Subject: [OpenSIPS-Users] Contest and prices - OpenSIPS 2.1 testing Message-ID: <55105D99.2070301@opensips.org> Hi all, Starting this week and all the way to the date of 2.1 stable release (from RC to GA), we will open a weekly contest that will help with the testing :). What is the contest for ? For the best bug found :). Whoever finds the "uglies" bug in 2.1-rc will get an official OpenSIPS T-shirt, like these guys did :) : http://farm4.staticflickr.com/3947/15725260732_826db90980_z.jpg So, we pay you for for finding the best bug in OpenSIPS - attractive job ?? CONTEST IS ON !!!!! And we already have a strong candidate for this week. Best Regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com From alexfuttert at hotmail.com Mon Mar 23 19:57:55 2015 From: alexfuttert at hotmail.com (Alexander Freitez) Date: Mon, 23 Mar 2015 18:57:55 +0000 Subject: [OpenSIPS-Users] Opensips like SipProxy In-Reply-To: References: , Message-ID: Thank for you response. I have actually four servers with asterisk, all working with private Ip, Now I need connect a few users with public Ip to those asterisks, but I want to use Opensips like SBC, with two Ethernet interfaces, one with public Ip, and the another with private Ip. sip users(public ip)-------> opensips (public and private ip)---------->asterisks (private ip) Or that another solution can I to use?, what do you recomend me? Regards From: andres.moya.i at gmail.com To: users at lists.opensips.org Date: Mon, 23 Mar 2015 16:26:24 +0000 Subject: Re: [OpenSIPS-Users] Opensips like SipProxy To pass between public/private you will need to use rtpproxy module. Default config is already sip proxy, and ready to customize. Asterisk itself do much much easier as private/public ?SBC?. What exactly scenario you try to achieve? From: Alexander Freitez Sent: Monday, March 23, 2015 4:05 PM To: users at lists.opensips.org Subject: [OpenSIPS-Users] Opensips like SipProxy I'm beginner with opensips, but I'd like use it like SipProxy. Do you have some configuration example for this?. The idea is "sip users(public ip)-------> opensips (public and private ip)---------->asterisks (private ip)" Thank for you help. Regards. _______________________________________________ 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 andres.moya.i at gmail.com Mon Mar 23 20:49:12 2015 From: andres.moya.i at gmail.com (Andres Moya) Date: Mon, 23 Mar 2015 19:49:12 -0000 Subject: [OpenSIPS-Users] Opensips like SipProxy In-Reply-To: References: , Message-ID: <897EB846279349B19ABB7475532896F9@samsung> Well, this is my personal opinion. Maybe someone from the list will correct me. Opensips is a SIP proxy, not media proxy by initial design. Check SEMS maybe. Do you want to have password authenticated peers (with registrations or just calls)? Like people be able register/call through OpenSIPs on asterisks and you separate them by realms etc? If you already know asterisk well, install one as SBC, could be easier to come to working config. Hope someone give link to example configs. Start from reading documentation on general configuration and rtpproxy module. You have to be good in understanding SIP protocol, do you? if not have some reading to refresh knowledge. Regards From: Alexander Freitez Sent: Monday, March 23, 2015 6:57 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips like SipProxy Thank for you response. I have actually four servers with asterisk, all working with private Ip, Now I need connect a few users with public Ip to those asterisks, but I want to use Opensips like SBC, with two Ethernet interfaces, one with public Ip, and the another with private Ip. sip users(public ip)-------> opensips (public and private ip)---------->asterisks (private ip) Or that another solution can I to use?, what do you recomend me? Regards -------------------------------------------------------------------------------- From: andres.moya.i at gmail.com To: users at lists.opensips.org Date: Mon, 23 Mar 2015 16:26:24 +0000 Subject: Re: [OpenSIPS-Users] Opensips like SipProxy To pass between public/private you will need to use rtpproxy module. Default config is already sip proxy, and ready to customize. Asterisk itself do much much easier as private/public ?SBC?. What exactly scenario you try to achieve? From: Alexander Freitez Sent: Monday, March 23, 2015 4:05 PM To: users at lists.opensips.org Subject: [OpenSIPS-Users] Opensips like SipProxy I'm beginner with opensips, but I'd like use it like SipProxy. Do you have some configuration example for this?. The idea is "sip users(public ip)-------> opensips (public and private ip)---------->asterisks (private ip)" Thank for you help. Regards. -------------------------------------------------------------------------------- _______________________________________________ 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 uzcudunl at yahoo.it Tue Mar 24 16:48:58 2015 From: uzcudunl at yahoo.it (leo) Date: Tue, 24 Mar 2015 08:48:58 -0700 (MST) Subject: [OpenSIPS-Users] Opensips 1.11 - Debian Wheezy - libmysqlclient Message-ID: <1427212138142-7596120.post@n2.nabble.com> Hello: I'm trying to install opensips 1.11 from the Official OpenSIPS Debian/Ubuntu repository (APT i386/amd64) (by Dynamic Packet & OpenSIPS Solutions) -> http://apt.opensips.org (deb http://apt.opensips.org/ stable111 main) in a Debian Wheezy x64 but I'm finding a dependency problem regarding the libmysqlclient. Opensips installation requires libmysqlclient16 (that is it for squeeze/mysql 5.1) and in wheezy there is libmysqlclient18 (mysql 5.5). Is this just a package dependencies error or Opensips really requires mysql 5.1? Thanks a lot, Leo. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-Debian-Wheezy-libmysqlclient-tp7596120.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Tue Mar 24 17:38:56 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 24 Mar 2015 18:38:56 +0200 Subject: [OpenSIPS-Users] Opensips 1.11 - Debian Wheezy - libmysqlclient In-Reply-To: <1427212138142-7596120.post@n2.nabble.com> References: <1427212138142-7596120.post@n2.nabble.com> Message-ID: <55119320.5090609@opensips.org> Hi, Leo! No, there is no requirement for OpenSIPS to run with a specific mysql library version (client or server). I think this dependency is too strict, libmysqlclient18 should work without any issues. I will replace the dependency with the meta-package libmysqlclient. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/24/2015 05:48 PM, leo wrote: > Hello: > > I'm trying to install opensips 1.11 from the Official OpenSIPS Debian/Ubuntu > repository (APT i386/amd64) (by Dynamic Packet & OpenSIPS Solutions) -> > http://apt.opensips.org (deb http://apt.opensips.org/ stable111 main) in a > Debian Wheezy x64 but I'm finding a dependency problem regarding the > libmysqlclient. > > Opensips installation requires libmysqlclient16 (that is it for > squeeze/mysql 5.1) and in wheezy there is libmysqlclient18 (mysql 5.5). > > Is this just a package dependencies error or Opensips really requires mysql > 5.1? > > Thanks a lot, > > Leo. > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-Debian-Wheezy-libmysqlclient-tp7596120.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 Tue Mar 24 18:06:58 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 24 Mar 2015 19:06:58 +0200 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] Contest and prices - OpenSIPS 2.1 testing In-Reply-To: <55105D99.2070301@opensips.org> References: <55105D99.2070301@opensips.org> Message-ID: <551199B2.8070809@opensips.org> Hi, All! Hurry up, we already have three bugs reported[1] :). [1] http://www.opensips.org/Community/BugHuntContest Cheers, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/23/2015 08:38 PM, Bogdan-Andrei Iancu wrote: > Hi all, > > Starting this week and all the way to the date of 2.1 stable release > (from RC to GA), we will open a weekly contest that will help with the > testing :). > > What is the contest for ? For the best bug found :). Whoever finds the > "uglies" bug in 2.1-rc will get an official OpenSIPS T-shirt, like > these guys did :) : > http://farm4.staticflickr.com/3947/15725260732_826db90980_z.jpg > > So, we pay you for for finding the best bug in OpenSIPS - attractive > job ?? > > CONTEST IS ON !!!!! And we already have a strong candidate for this week. > > Best Regards, > From satish.txt at gmail.com Tue Mar 24 18:19:29 2015 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 24 Mar 2015 13:19:29 -0400 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] Contest and prices - OpenSIPS 2.1 testing In-Reply-To: <551199B2.8070809@opensips.org> References: <55105D99.2070301@opensips.org> <551199B2.8070809@opensips.org> Message-ID: Wow! so every person will get T-shirt who reported bug or one person among all bug reporter? On Tue, Mar 24, 2015 at 1:06 PM, R?zvan Crainea wrote: > Hi, All! > > Hurry up, we already have three bugs reported[1] :). > > [1] http://www.opensips.org/Community/BugHuntContest > > Cheers, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/23/2015 08:38 PM, Bogdan-Andrei Iancu wrote: > >> Hi all, >> >> Starting this week and all the way to the date of 2.1 stable release >> (from RC to GA), we will open a weekly contest that will help with the >> testing :). >> >> What is the contest for ? For the best bug found :). Whoever finds the >> "uglies" bug in 2.1-rc will get an official OpenSIPS T-shirt, like these >> guys did :) : >> http://farm4.staticflickr.com/3947/15725260732_826db90980_z.jpg >> >> So, we pay you for for finding the best bug in OpenSIPS - attractive job >> ?? >> >> CONTEST IS ON !!!!! And we already have a strong candidate for this week. >> >> Best Regards, >> >> > > _______________________________________________ > 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 at uphreak.com Tue Mar 24 18:20:53 2015 From: eric at uphreak.com (Eric Tamme) Date: Tue, 24 Mar 2015 11:20:53 -0600 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] Contest and prices - OpenSIPS 2.1 testing In-Reply-To: References: <55105D99.2070301@opensips.org> <551199B2.8070809@opensips.org> Message-ID: <55119CF5.9020901@uphreak.com> "the person who reports the "ugliest" bug will get an official OpenSIPS T-shirt along with our gratitude" On 03/24/2015 11:19 AM, Satish Patel wrote: > Wow! so every person will get T-shirt who reported bug or one person > among all bug reporter? > > > > On Tue, Mar 24, 2015 at 1:06 PM, R?zvan Crainea > wrote: > > Hi, All! > > Hurry up, we already have three bugs reported[1] :). > > [1] http://www.opensips.org/Community/BugHuntContest > > Cheers, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/23/2015 08:38 PM, Bogdan-Andrei Iancu wrote: > > Hi all, > > Starting this week and all the way to the date of 2.1 stable > release (from RC to GA), we will open a weekly contest that > will help with the testing :). > > What is the contest for ? For the best bug found :). Whoever > finds the "uglies" bug in 2.1-rc will get an official OpenSIPS > T-shirt, like these guys did :) : > http://farm4.staticflickr.com/3947/15725260732_826db90980_z.jpg > > So, we pay you for for finding the best bug in OpenSIPS - > attractive job ?? > > CONTEST IS ON !!!!! And we already have a strong candidate for > this week. > > Best Regards, > > > > _______________________________________________ > 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 ter.devor at gmail.com Tue Mar 24 20:19:39 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 24 Mar 2015 15:19:39 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 Message-ID: Hello Everyone, We are using Opensips 1.9.x and seeing that set_advertised_address is not changing the recoird route within the on_reply route. What we are trying to do is change the record route for internal vs. external signalling. Is it not possible to change the advertised address within the on_reply_route? Kind Regards, Terrance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank21118 at yahoo.com Tue Mar 24 20:57:37 2015 From: frank21118 at yahoo.com (bluerain) Date: Tue, 24 Mar 2015 12:57:37 -0700 (MST) Subject: [OpenSIPS-Users] opensips 1.9 error (I know it's very generic) Message-ID: <1427227057390-7596135.post@n2.nabble.com> I don't know how to describe the issue. But we've been running on 1.9 for years without any issue. Lately, it start acting up "weird". My setup is that I am using opensips as the signalling gateway and behind it, the asterisk as media gateway. So lately, asterisk would suddenly deem opensips to be down because I guess it is not getting response on SIP OPTION query back from opensips. But when I run fifo commands on opensips, it looks to be ok. But then if I send an INVITE, I get nothing back. I am not sure if anyone has this type of experience (yes I know this sound very generic), but any help would be greatly appreciated. The Syslog looks normal with the typical errors in them, nothing POP out of it that I can see. Below is a few lines from my syslog: Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:parse_msg: message=<> Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9806]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:parse_first_line: bad request first line Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:parse_first_line: at line 0 char 15: Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:parse_first_line: parsed so far: ?#001???cq#007?1?.?> Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:parse_msg: message=<> Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: ERROR:core:parse_msg: message=<> Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:core:parse_msg: message=<> Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:parse_msg: message=<> Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to change URI Contact Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: incoming reply Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to change URI Contact Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:rtpproxy:force_rtp_proxy: Unable to parse body Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: incoming reply Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to change URI Contact Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:rtpproxy:force_rtp_proxy: no available proxies Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: incoming reply Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:parse_msg: message=<> Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:parse_msg: message=<> Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9805]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:parse_msg: message=<> Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:parse_msg: message=<> Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9804]: ERROR:core:receive_msg: parse_msg failed Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:rtpproxy:send_rtpp_command: can't send command to a RTP proxy Connection refused Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: ERROR:rtpproxy:send_rtpp_command: proxy does not respond, disable it Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: WARNING:rtpproxy:rtpp_test: can't get version of the RTP proxy Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: WARNING:rtpproxy:rtpp_test: support for RTP proxy has been disabled temporarily -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/opensips-1-9-error-I-know-it-s-very-generic-tp7596135.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Wed Mar 25 09:44:31 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 25 Mar 2015 10:44:31 +0200 Subject: [OpenSIPS-Users] opensips 1.9 error (I know it's very generic) In-Reply-To: <1427227057390-7596135.post@n2.nabble.com> References: <1427227057390-7596135.post@n2.nabble.com> Message-ID: <5512756F.1060504@opensips.org> Hello! Is the RTPProxy server on localhost:12221 down, or it is not responding? If it is not responding, then this might be a network issue, congestion or something like this. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/24/2015 09:57 PM, bluerain wrote: > I don't know how to describe the issue. But we've been running on 1.9 for > years without any issue. Lately, it start acting up "weird". My setup is > that I am using opensips as the signalling gateway and behind it, the > asterisk as media gateway. So lately, asterisk would suddenly deem opensips > to be down because I guess it is not getting response on SIP OPTION query > back from opensips. But when I run fifo commands on opensips, it looks to > be ok. But then if I send an INVITE, I get nothing back. > > I am not sure if anyone has this type of experience (yes I know this sound > very generic), but any help would be greatly appreciated. > > The Syslog looks normal with the typical errors in them, nothing POP out of > it that I can see. > > Below is a few lines from my syslog: > Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:53 OSIPIBD-1 /usr/local/sbin/opensips[9806]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:parse_first_line: bad request first line > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:parse_first_line: at line 0 char 15: > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:parse_first_line: parsed so far: ?#001???cq#007?1?.?> > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to change > URI Contact > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9807]: incoming reply > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9806]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to change > URI Contact > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:rtpproxy:force_rtp_proxy: Unable to parse body > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9805]: incoming reply > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to change > URI Contact > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:rtpproxy:force_rtp_proxy: no available proxies > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: incoming reply > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:54 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:receive_msg: parse_msg failed > > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9805]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:parse_msg: message=<> > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9804]: > ERROR:core:receive_msg: parse_msg failed > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:rtpproxy:send_rtpp_command: can't send command to a RTP proxy > Connection refused > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > ERROR:rtpproxy:send_rtpp_command: proxy does not > respond, disable it > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > WARNING:rtpproxy:rtpp_test: can't get version of the RTP proxy > Mar 24 19:47:52 OSIPIBD-1 /usr/local/sbin/opensips[9807]: > WARNING:rtpproxy:rtpp_test: support for RTP proxy has > been disabled temporarily > > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/opensips-1-9-error-I-know-it-s-very-generic-tp7596135.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 Wed Mar 25 09:56:53 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 25 Mar 2015 10:56:53 +0200 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: Message-ID: <55127855.7060605@opensips.org> Hi, Terrance! No, you cannot change the advertised address in the onreply_route, since the Route headers have already been sent to your UAS. The proper way to do this is to make all the interface changes in the request route. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/24/2015 09:19 PM, Terrance Devor wrote: > Hello Everyone, > > We are using Opensips 1.9.x and seeing that set_advertised_address is not > changing the recoird route within the on_reply route. What we are > trying to do > is change the record route for internal vs. external signalling. Is it > not possible > to change the advertised address within the on_reply_route? > > > Kind Regards, > > Terrance. > > > _______________________________________________ > 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 ter.devor at gmail.com Wed Mar 25 14:52:28 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Wed, 25 Mar 2015 09:52:28 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: <55127855.7060605@opensips.org> References: <55127855.7060605@opensips.org> Message-ID: Hello Razvan, Thank you for your response. The problem I am experiencing is that I cannot catch the 200OK that OpenSIPS sends out except for within the onreply_route. I put debug messages all over the script, and the only place the 200OK that opensips would fire was in the onreply. Can you please tell me where to catch the 200 that OpenSIPS sends out within the request route? Thanks in Advance, Terrance ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank21118 at yahoo.com Wed Mar 25 15:02:54 2015 From: frank21118 at yahoo.com (bluerain) Date: Wed, 25 Mar 2015 07:02:54 -0700 (MST) Subject: [OpenSIPS-Users] opensips 1.9 error (I know it's very generic) In-Reply-To: <5512756F.1060504@opensips.org> References: <1427227057390-7596135.post@n2.nabble.com> <5512756F.1060504@opensips.org> Message-ID: <1427292174216-7596150.post@n2.nabble.com> Thx for the reply, but what is the function of rtpproxy? I use asterisk to handle my rtp (media). So can I remove the module from opensip being loaded? Also network congestion, but is on the localhost which is itself, how can there be network congestion? Thx. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/opensips-1-9-error-I-know-it-s-very-generic-tp7596135p7596150.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From frank21118 at yahoo.com Wed Mar 25 16:41:43 2015 From: frank21118 at yahoo.com (bluerain) Date: Wed, 25 Mar 2015 08:41:43 -0700 (MST) Subject: [OpenSIPS-Users] Opensips 1.11 on Centos 6.6, running but not listening? Message-ID: <1427298103877-7596152.post@n2.nabble.com> I am currently running Opensips 1.9 on Debian Whizzy, but as stated on my other thread, I am getting some weird error which opensips would suddenly stop working. So, I am starting a new installation of Opensips 1.11 on Centos 6.6 using the yum install method: 1. I was able to install yum opensips install with no issue, but there are some module it didn't install which I need (e.g. db_unixodbc and db_mysql and httpd) 2. So I went ahead download the source and all the dependency files needed and re-complie the oepnsips to get those .so files 3. After some tweaking of the database table structure and some other stuff, I was able to get opensips 1.11 running without error (on the message.log file) using my 1.9 config file. So I did opensipsctl restart (just to make sure opensips starts) I see: INFO: Restarting OpenSIPS : INFO: stopped INFO: Starting OpenSIPS : INFO: Removing stale PID file /var/run/opensips.pid. INFO: started (pid: 2079) but when I try to use a VoIP device to register to it, it doesn't response. thus I did: "sudo netstat -plnt" The only think I see that opensips is listening on is port 8888 by PID 2080 (I don't see 2079 at all) So what is happening? why no error and it seems opensips running but yet is not listsening on port 5060? I have 2 nic card and eth0 is the one with public IP and the default route where as the eth1 is the one with private IP and no default route. Thus I am sure everything is route out of the eth0 (public IP). When I do simply the command "opensips", it would simply return: Listening on udp: xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx]:5060 Aliases: *: (my FQDN):* So it looks like it think is listening on port 5060 but is not? Any help would be appreciated greatly! Thank you! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-on-Centos-6-6-running-but-not-listening-tp7596152.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From Ben.Newlin at inin.com Wed Mar 25 20:53:34 2015 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Wed, 25 Mar 2015 19:53:34 +0000 Subject: [OpenSIPS-Users] DROUTING module changing Carrier IDs Message-ID: I am using OpenSIPS 1.11 and I am recently getting some weird behavior from the DROUTING module. The module is corrupting the Carrier ID that is being returned via AVP. This behavior is occurring only with the Carrier ID, not the gateway or rule IDs, and only when it is returned from the DROUTING module via dr_is_gw() or do_routing(). If I query the database directly using AVPOPS, the Carrier ID is returned correctly. I have the following configuration. The startup_route was added specifically for this issue. #### Dynamic ROUTING module loadmodule "drouting.so" modparam("drouting", "db_url", "CFG_DB_URL") modparam("drouting", "persistent_state", DISABLE) modparam("drouting", "probing_interval", ENABLE) modparam("drouting", "force_dns", ENABLE) modparam("drouting", "ruri_avp", '$avp(dr_ruri)') modparam("drouting", "gw_id_avp", '$avp(dr_gw_id)') modparam("drouting", "gw_priprefix_avp", '$avp(dr_gw_prfx)') modparam("drouting", "rule_id_avp", '$avp(dr_rule_id)') modparam("drouting", "rule_prefix_avp", '$avp(dr_rule_prfx)') modparam("drouting", "carrier_id_avp", '$avp(dr_carr_id)') . . . startup_route { avp_db_query("select carrierid from dr_carriers", "$avp(ids)"); for ($var(id) in $(avp(ids)[*])) xlog("L_INFO", "Carrier ID: $var(id)\n"); } . . . route[get_route] { if (!do_routing("$avp(dr_group)", "", , "$var(rule_attr)", "$var(gw_attr)", "$var(carr_attr)")) { xlog("L_ERR", "get_route: failure from do_routing! $retcode\n"); route(reply_error, "500", "Server Internal Error"); } xlog("L_INFO", "get_route: rule_attr - $var(rule_attr)\n"); xlog("L_INFO", "get_route: gw_attr - $var(gw_attr)\n"); xlog("L_INFO", "get_route: carr_attr - $var(carr_attr)\n"); xlog("L_INFO", "get_route: ruri - $avp(dr_ruri)\n"); xlog("L_INFO", "get_route: gw_id - $avp(dr_gw_id)\n"); xlog("L_INFO", "get_route: gw_prfx - $avp(dr_gw_prfx)\n"); xlog("L_INFO", "get_route: rule_id - $avp(dr_rule_id)\n"); xlog("L_INFO", "get_route: rule_prfx - $avp(dr_rule_prfx)\n"); xlog("L_INFO", "get_route: carr_id - $avp(dr_carr_id)\n\n"); } The output from the above execution is: opensips[9801]: Carrier ID: IndyEdges opensips[9801]: Carrier ID: Level3-VT opensips: INFO:core:daemonize: pre-daemon process exiting with 0 opensips[9801]: get_route: rule_attr - opensips[9801]: get_route: gw_attr - opensips[9801]: get_route: carr_attr - id=pai;history=hi opensips[9801]: get_route: ruri - opensips[9801]: get_route: gw_id - Level3-VT1 opensips[9801]: get_route: gw_prfx - + opensips[9801]: get_route: rule_id - 4 opensips[9801]: get_route: rule_prfx - 1 opensips[9801]: get_route: carr_id - Level3-VT#012 You can see that the string '#012' has been appended to the Carrier ID. So far it has always been that string appended to the ID. It started occurring after I moved from a RHEL 7 server using MariaDB to a RHEL 6 server using MySQL, but in both cases I am using the provided OpenSIPS scripts to create all database tables. Any help would be appreciated. Ben Newlin -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Mar 26 05:09:48 2015 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 26 Mar 2015 00:09:48 -0400 Subject: [OpenSIPS-Users] loose_route() sending ACK itself Message-ID: Hi, senario: [UA]-------------[Opensips]---------[Freeswitch] UA sending correct ACK to freeswitch but Opensips loose_route() sending it to itself and it break dialog, If use fix_dialog_route() then it works, I don't have any IP address added in domain table also. How do i check whether Freeswitch using loose_route for strict route? I have following script: if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { #setflag(ACC_DO); # do accounting ... #setflag(ACC_FAILED); # ... even if the transaction fails } else if (is_method("INVITE")) { # even if in most of the cases is useless, do RR for # re-INVITEs alos, as some buggy clients do change route set # during the dialog. record_route(); } if (check_route_param("nat=yes")) setflag(NAT); # route it out to whatever destination was set by loose_route() # in $du (destination URI). route(relay); } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server xlog("non loose-route section\n"); #t_relay(); exit; } else { # ACK without matching transaction -> # ignore and discard xlog("ACK without matching transaction\n"); exit; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.mathew at divoxmedia.com Thu Mar 26 14:55:24 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Thu, 26 Mar 2015 19:25:24 +0530 Subject: [OpenSIPS-Users] Dialog hanging at State 5 Message-ID: Hi, Dialog state is hanging at "state 5" when there is no response from the destination. What config we need to add to get the dialog moved to failure_route if, opensips is not receiving any response from destination for any request sent out.? Or How can we drop the dialog instead of moving to failure_route? -- Regards, John Mathew CEO/Director Divox International Inc. Contact: +91-9037100001 Email/MSN: John.Mathew at divoxmedia.com WEB: www.divoxmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.pinassi at unisi.it Thu Mar 26 14:57:19 2015 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Thu, 26 Mar 2015 14:57:19 +0100 Subject: [OpenSIPS-Users] Routing NOTIFY to the phone Message-ID: <5514103F.1070601@unisi.it> Hi all, again on BLF...i noticed that after correct SUBSCRIPTION on the server and on the phones of the monitored extension, when one of that change its status, the NOTIFY was send to the server that reply with 404 and *not* to the monitoring phone. Here's a siptrace of what's happens: U 2015/03/26 14:52:15.359182 172.20.1.47:47362 -> 172.20.1.2:5060 NOTIFY sip:5023 at 172.20.1.27:32768 SIP/2.0. Via: SIP/2.0/UDP 172.20.1.47:47362;branch=z9hG4bK-xvlhtivkog2x;rport. From: ;tag=o5sz371uyn. To: ;tag=aqhxe3d198. Call-ID: 5512ce5dc6fa-5z8xbqdcqj6f. CSeq: 4 NOTIFY. Max-Forwards: 70. User-Agent: snom760/8.7.5.13. Contact: ;reg-id=1. Event: dialog. Subscription-State: active. Content-Type: application/dialog-info+xml. Content-Length: 619. . terminatedsip:5002 at voip.unisi.it:5060sip:2169 at 172.20.1.4:5060 U 2015/03/26 14:52:15.359534 172.20.1.2:5060 -> 172.20.1.47:47362 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 172.20.1.47:47362;received=172.20.1.47;branch=z9hG4bK-xvlhtivkog2x;rport=47362. From: ;tag=o5sz371uyn. To: ;tag=aqhxe3d198. Call-ID: 5512ce5dc6fa-5z8xbqdcqj6f. CSeq: 4 NOTIFY. Server: OpenSIPS (1.11.3-tls (i386/linux)). Content-Length: 0. . Here's the part of opensips.cfg involved: #### XCAP modules loadmodule "xcap.so" loadmodule "xcap_client.so" modparam("xcap", "integrated_xcap_server", 1) #### PRESENCE modules loadmodule "presence.so" loadmodule "presence_mwi.so" loadmodule "presence_callinfo.so" loadmodule "presence_xml.so" loadmodule "presence_dialoginfo.so" modparam("presence", "db_url", "mysql://") modparam("presence", "server_address", "sip:voip.unisi.it:5060") modparam("presence", "notify_offline_body", 1) modparam("presence", "fallback2db", 1) modparam("presence", "clean_period", 30) modparam("presence", "mix_dialog_presence", 1) modparam("presence_xml","force_active",1) [...] route { [...] ### PRESENCE if(is_method("PUBLISH|SUBSCRIBE")) { route(handle_presence); } [...] } # Presence route route[handle_presence] { xlog("L_INFO","Route PRESENCE on $rm [$fd/$fu/$rd/$ru/$si/]\n"); if(!t_newtran()){ sl_reply_error(); exit; } if (is_method("PUBLISH")) { if($hdr(Sender)!= NULL) handle_publish("$hdr(Sender)"); else handle_publish(); } else if (is_method("SUBSCRIBE")) { handle_subscribe(); } exit; } How i can route NOTIFY to the right extensions ? Thanks, Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)5000 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From bogdan at opensips.org Thu Mar 26 15:02:06 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 26 Mar 2015 16:02:06 +0200 Subject: [OpenSIPS-Users] DROUTING module changing Carrier IDs In-Reply-To: References: Message-ID: <5514115E.7020600@opensips.org> Hi Ben, If you run the "dr_carrier_status" MI command, do you see the same #012 in the ID of the carrier ? #012 is '\n' - are you sure you do not have it by mistake in DB ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.03.2015 21:53, Newlin, Ben wrote: > > I am using OpenSIPS 1.11 and I am recently getting some weird behavior > from the DROUTING module. The module is corrupting the Carrier ID that > is being returned via AVP. This behavior is occurring only with the > Carrier ID, not the gateway or rule IDs, and only when it is returned > from the DROUTING module via dr_is_gw() or do_routing(). If I query > the database directly using AVPOPS, the Carrier ID is returned correctly. > > I have the following configuration. The startup_route was added > specifically for this issue. > > #### Dynamic ROUTING module > > loadmodule "drouting.so" > > modparam("drouting", "db_url", "CFG_DB_URL") > > modparam("drouting", "persistent_state", DISABLE) > > modparam("drouting", "probing_interval", ENABLE) > > modparam("drouting", "force_dns", ENABLE) > > modparam("drouting", "ruri_avp", '$avp(dr_ruri)') > > modparam("drouting", "gw_id_avp", '$avp(dr_gw_id)') > > modparam("drouting", "gw_priprefix_avp", '$avp(dr_gw_prfx)') > > modparam("drouting", "rule_id_avp", '$avp(dr_rule_id)') > > modparam("drouting", "rule_prefix_avp", '$avp(dr_rule_prfx)') > > modparam("drouting", "carrier_id_avp", '$avp(dr_carr_id)') > > . > > . > > . > > startup_route { > > avp_db_query("select carrierid from dr_carriers", "$avp(ids)"); > > for ($var(id) in $(avp(ids)[*])) > > xlog("L_INFO", "Carrier ID: $var(id)\n"); > > } > > . > > . > > . > > route[get_route] > > { > > if (!do_routing("$avp(dr_group)", "", , "$var(rule_attr)", > "$var(gw_attr)", "$var(carr_attr)")) > > { > > xlog("L_ERR", "get_route: failure from do_routing! $retcode\n"); > > route(reply_error, "500", "Server Internal Error"); > > } > > xlog("L_INFO", "get_route: rule_attr - $var(rule_attr)\n"); > > xlog("L_INFO", "get_route: gw_attr - $var(gw_attr)\n"); > > xlog("L_INFO", "get_route: carr_attr - $var(carr_attr)\n"); > > xlog("L_INFO", "get_route: ruri - $avp(dr_ruri)\n"); > > xlog("L_INFO", "get_route: gw_id - $avp(dr_gw_id)\n"); > > xlog("L_INFO", "get_route: gw_prfx - $avp(dr_gw_prfx)\n"); > > xlog("L_INFO", "get_route: rule_id - $avp(dr_rule_id)\n"); > > xlog("L_INFO", "get_route: rule_prfx - $avp(dr_rule_prfx)\n"); > > xlog("L_INFO", "get_route: carr_id - $avp(dr_carr_id)\n\n"); > > } > > The output from the above execution is: > > opensips[9801]: Carrier ID: IndyEdges > > opensips[9801]: Carrier ID: Level3-VT > > opensips: INFO:core:daemonize: pre-daemon process exiting with 0 > > opensips[9801]: get_route: rule_attr - > > opensips[9801]: get_route: gw_attr - > > opensips[9801]: get_route: carr_attr - id=pai;history=hi > > opensips[9801]: get_route: ruri - > > opensips[9801]: get_route: gw_id - Level3-VT1 > > opensips[9801]: get_route: gw_prfx - + > > opensips[9801]: get_route: rule_id - 4 > > opensips[9801]: get_route: rule_prfx - 1 > > opensips[9801]: get_route: carr_id - Level3-VT#012 > > You can see that the string ?#012? has been appended to the Carrier > ID. So far it has always been that string appended to the ID. > > It started occurring after I moved from a RHEL 7 server using MariaDB > to a RHEL 6 server using MySQL, but in both cases I am using the > provided OpenSIPS scripts to create all database tables. > > Any help would be appreciated. > > Ben Newlin > > > > _______________________________________________ > 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 Mar 26 15:07:44 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 26 Mar 2015 16:07:44 +0200 Subject: [OpenSIPS-Users] Opensips 1.11 on Centos 6.6, running but not listening? In-Reply-To: <1427298103877-7596152.post@n2.nabble.com> References: <1427298103877-7596152.post@n2.nabble.com> Message-ID: <551412B0.9000704@opensips.org> Hi, First check if opensips actually started : run "ps auxw | grep opensips" If it didn't , check the logs (messages or syslog) for errors. If you see the process, check with "netstat -lnp | grep opensips" to see the listening interfaces of OpenSIPS. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.03.2015 17:41, bluerain wrote: > I am currently running Opensips 1.9 on Debian Whizzy, but as stated on my > other thread, I am getting some weird error which opensips would suddenly > stop working. > > So, I am starting a new installation of Opensips 1.11 on Centos 6.6 using > the yum install method: > > 1. I was able to install yum opensips install with no issue, but there are > some module it didn't install which I need (e.g. db_unixodbc and db_mysql > and httpd) > > 2. So I went ahead download the source and all the dependency files needed > and re-complie the oepnsips to get those .so files > > 3. After some tweaking of the database table structure and some other stuff, > I was able to get opensips 1.11 running without error (on the message.log > file) using my 1.9 config file. > > So I did opensipsctl restart (just to make sure opensips starts) > I see: > > INFO: Restarting OpenSIPS : > INFO: stopped > > INFO: Starting OpenSIPS : > INFO: Removing stale PID file /var/run/opensips.pid. > INFO: started (pid: 2079) > > but when I try to use a VoIP device to register to it, it doesn't response. > thus I did: > "sudo netstat -plnt" > > The only think I see that opensips is listening on is port 8888 by PID 2080 > (I don't see 2079 at all) > > So what is happening? why no error and it seems opensips running but yet is > not listsening on port 5060? > > I have 2 nic card and eth0 is the one with public IP and the default route > where as the eth1 is the one with private IP and no default route. Thus I > am sure everything is route out of the eth0 (public IP). > > When I do simply the command "opensips", it would simply return: > > Listening on > udp: xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx]:5060 > Aliases: > *: (my FQDN):* > > So it looks like it think is listening on port 5060 but is not? > > Any help would be appreciated greatly! > > Thank you! > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-on-Centos-6-6-running-but-not-listening-tp7596152.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 Thu Mar 26 15:08:14 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 26 Mar 2015 16:08:14 +0200 Subject: [OpenSIPS-Users] loose_route() sending ACK itself In-Reply-To: References: Message-ID: <551412CE.9030101@opensips.org> Hi, It may possible be that the received ACK is broken, leading to that kind of looping. By broken I mean heaving wrong RURI or Route headers. Can you post on a pastebin a sip capture of that call ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 26.03.2015 06:09, Satish Patel wrote: > Hi, > > senario: > > [UA]-------------[Opensips]---------[Freeswitch] > > > UA sending correct ACK to freeswitch but Opensips loose_route() > sending it to itself and it break dialog, If use fix_dialog_route() > then it works, I don't have any IP address added in domain table also. > > How do i check whether Freeswitch using loose_route for strict route? > > > I have following script: > > if (has_totag()) { > > if (loose_route()) { > > if (is_method("BYE")) { > #setflag(ACC_DO); # do accounting ... > #setflag(ACC_FAILED); # ... even if > the transaction fails > } else if (is_method("INVITE")) { > # even if in most of the cases is > useless, do RR for > # re-INVITEs alos, as some buggy > clients do change route set > # during the dialog. > record_route(); > } > > if (check_route_param("nat=yes")) > setflag(NAT); > > # route it out to whatever destination was set > by loose_route() > # in $du (destination URI). > route(relay); > } else { > > if ( is_method("ACK") ) { > if ( t_check_trans() ) { > # non loose-route, but > stateful ACK; must be an ACK after > # a 487 or e.g. 404 from > upstream server > xlog("non loose-route section\n"); > #t_relay(); > exit; > } else { > # ACK without matching > transaction -> > # ignore and discard > xlog("ACK without matching > transaction\n"); > exit; > } > } > > > > > > _______________________________________________ > 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 ter.devor at gmail.com Thu Mar 26 15:12:34 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Thu, 26 Mar 2015 10:12:34 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> Message-ID: I hope it's ok to re-phrase my question in this same email. Where is the best place to change the ip address using set_advertised_address for 200OK being sent out by OpenSIPS to the UAS. T. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at inin.com Thu Mar 26 15:53:34 2015 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Thu, 26 Mar 2015 14:53:34 +0000 Subject: [OpenSIPS-Users] DROUTING module changing Carrier IDs In-Reply-To: <5514115E.7020600@opensips.org> References: <5514115E.7020600@opensips.org> Message-ID: Bogdan, It did occur to me that the code seemed to be the octal for newline, but I don't know what the significance of that could be. The MI command output does not show the extra characters: ~]$ opensipsctl dr carrier_status ID:: Level3-VT Enabled=yes ID:: IndyEdges Enabled=yes I have also verified that the extra characters do not exist in the DB. They are also not returned from the DB when queried from anywhere else, and even the DROUTING module does not return the extra characters for any of the other string fields it is returning, only the Carrier ID. Ben Newlin From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Thursday, March 26, 2015 10:02 AM To: OpenSIPS users mailling list; Newlin, Ben Subject: Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs Hi Ben, If you run the "dr_carrier_status" MI command, do you see the same #012 in the ID of the carrier ? #012 is '\n' - are you sure you do not have it by mistake in DB ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.03.2015 21:53, Newlin, Ben wrote: I am using OpenSIPS 1.11 and I am recently getting some weird behavior from the DROUTING module. The module is corrupting the Carrier ID that is being returned via AVP. This behavior is occurring only with the Carrier ID, not the gateway or rule IDs, and only when it is returned from the DROUTING module via dr_is_gw() or do_routing(). If I query the database directly using AVPOPS, the Carrier ID is returned correctly. I have the following configuration. The startup_route was added specifically for this issue. #### Dynamic ROUTING module loadmodule "drouting.so" modparam("drouting", "db_url", "CFG_DB_URL") modparam("drouting", "persistent_state", DISABLE) modparam("drouting", "probing_interval", ENABLE) modparam("drouting", "force_dns", ENABLE) modparam("drouting", "ruri_avp", '$avp(dr_ruri)') modparam("drouting", "gw_id_avp", '$avp(dr_gw_id)') modparam("drouting", "gw_priprefix_avp", '$avp(dr_gw_prfx)') modparam("drouting", "rule_id_avp", '$avp(dr_rule_id)') modparam("drouting", "rule_prefix_avp", '$avp(dr_rule_prfx)') modparam("drouting", "carrier_id_avp", '$avp(dr_carr_id)') . . . startup_route { avp_db_query("select carrierid from dr_carriers", "$avp(ids)"); for ($var(id) in $(avp(ids)[*])) xlog("L_INFO", "Carrier ID: $var(id)\n"); } . . . route[get_route] { if (!do_routing("$avp(dr_group)", "", , "$var(rule_attr)", "$var(gw_attr)", "$var(carr_attr)")) { xlog("L_ERR", "get_route: failure from do_routing! $retcode\n"); route(reply_error, "500", "Server Internal Error"); } xlog("L_INFO", "get_route: rule_attr - $var(rule_attr)\n"); xlog("L_INFO", "get_route: gw_attr - $var(gw_attr)\n"); xlog("L_INFO", "get_route: carr_attr - $var(carr_attr)\n"); xlog("L_INFO", "get_route: ruri - $avp(dr_ruri)\n"); xlog("L_INFO", "get_route: gw_id - $avp(dr_gw_id)\n"); xlog("L_INFO", "get_route: gw_prfx - $avp(dr_gw_prfx)\n"); xlog("L_INFO", "get_route: rule_id - $avp(dr_rule_id)\n"); xlog("L_INFO", "get_route: rule_prfx - $avp(dr_rule_prfx)\n"); xlog("L_INFO", "get_route: carr_id - $avp(dr_carr_id)\n\n"); } The output from the above execution is: opensips[9801]: Carrier ID: IndyEdges opensips[9801]: Carrier ID: Level3-VT opensips: INFO:core:daemonize: pre-daemon process exiting with 0 opensips[9801]: get_route: rule_attr - opensips[9801]: get_route: gw_attr - opensips[9801]: get_route: carr_attr - id=pai;history=hi opensips[9801]: get_route: ruri - opensips[9801]: get_route: gw_id - Level3-VT1 opensips[9801]: get_route: gw_prfx - + opensips[9801]: get_route: rule_id - 4 opensips[9801]: get_route: rule_prfx - 1 opensips[9801]: get_route: carr_id - Level3-VT#012 You can see that the string '#012' has been appended to the Carrier ID. So far it has always been that string appended to the ID. It started occurring after I moved from a RHEL 7 server using MariaDB to a RHEL 6 server using MySQL, but in both cases I am using the provided OpenSIPS scripts to create all database tables. Any help would be appreciated. Ben Newlin _______________________________________________ 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 Thu Mar 26 16:32:30 2015 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Thu, 26 Mar 2015 15:32:30 +0000 Subject: [OpenSIPS-Users] DROUTING module changing Carrier IDs In-Reply-To: References: <5514115E.7020600@opensips.org> Message-ID: Bogdan, After further investigation I have found that the characters are an artifact of the syslog daemon on the system. When I run with "fork=no" and "log_stderr=yes" I do not see the characters in the screen output. I have also now noticed both newline characters - #015 and #012 - at other places in the logs, which also do not appear when logging to stderr. Sorry for the false alarm, but I appreciate the help to point me in the right direction. Ben Newlin From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Newlin, Ben Sent: Thursday, March 26, 2015 10:54 AM To: Bogdan-Andrei Iancu; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs Bogdan, It did occur to me that the code seemed to be the octal for newline, but I don't know what the significance of that could be. The MI command output does not show the extra characters: ~]$ opensipsctl dr carrier_status ID:: Level3-VT Enabled=yes ID:: IndyEdges Enabled=yes I have also verified that the extra characters do not exist in the DB. They are also not returned from the DB when queried from anywhere else, and even the DROUTING module does not return the extra characters for any of the other string fields it is returning, only the Carrier ID. Ben Newlin From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Thursday, March 26, 2015 10:02 AM To: OpenSIPS users mailling list; Newlin, Ben Subject: Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs Hi Ben, If you run the "dr_carrier_status" MI command, do you see the same #012 in the ID of the carrier ? #012 is '\n' - are you sure you do not have it by mistake in DB ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.03.2015 21:53, Newlin, Ben wrote: I am using OpenSIPS 1.11 and I am recently getting some weird behavior from the DROUTING module. The module is corrupting the Carrier ID that is being returned via AVP. This behavior is occurring only with the Carrier ID, not the gateway or rule IDs, and only when it is returned from the DROUTING module via dr_is_gw() or do_routing(). If I query the database directly using AVPOPS, the Carrier ID is returned correctly. I have the following configuration. The startup_route was added specifically for this issue. #### Dynamic ROUTING module loadmodule "drouting.so" modparam("drouting", "db_url", "CFG_DB_URL") modparam("drouting", "persistent_state", DISABLE) modparam("drouting", "probing_interval", ENABLE) modparam("drouting", "force_dns", ENABLE) modparam("drouting", "ruri_avp", '$avp(dr_ruri)') modparam("drouting", "gw_id_avp", '$avp(dr_gw_id)') modparam("drouting", "gw_priprefix_avp", '$avp(dr_gw_prfx)') modparam("drouting", "rule_id_avp", '$avp(dr_rule_id)') modparam("drouting", "rule_prefix_avp", '$avp(dr_rule_prfx)') modparam("drouting", "carrier_id_avp", '$avp(dr_carr_id)') . . . startup_route { avp_db_query("select carrierid from dr_carriers", "$avp(ids)"); for ($var(id) in $(avp(ids)[*])) xlog("L_INFO", "Carrier ID: $var(id)\n"); } . . . route[get_route] { if (!do_routing("$avp(dr_group)", "", , "$var(rule_attr)", "$var(gw_attr)", "$var(carr_attr)")) { xlog("L_ERR", "get_route: failure from do_routing! $retcode\n"); route(reply_error, "500", "Server Internal Error"); } xlog("L_INFO", "get_route: rule_attr - $var(rule_attr)\n"); xlog("L_INFO", "get_route: gw_attr - $var(gw_attr)\n"); xlog("L_INFO", "get_route: carr_attr - $var(carr_attr)\n"); xlog("L_INFO", "get_route: ruri - $avp(dr_ruri)\n"); xlog("L_INFO", "get_route: gw_id - $avp(dr_gw_id)\n"); xlog("L_INFO", "get_route: gw_prfx - $avp(dr_gw_prfx)\n"); xlog("L_INFO", "get_route: rule_id - $avp(dr_rule_id)\n"); xlog("L_INFO", "get_route: rule_prfx - $avp(dr_rule_prfx)\n"); xlog("L_INFO", "get_route: carr_id - $avp(dr_carr_id)\n\n"); } The output from the above execution is: opensips[9801]: Carrier ID: IndyEdges opensips[9801]: Carrier ID: Level3-VT opensips: INFO:core:daemonize: pre-daemon process exiting with 0 opensips[9801]: get_route: rule_attr - opensips[9801]: get_route: gw_attr - opensips[9801]: get_route: carr_attr - id=pai;history=hi opensips[9801]: get_route: ruri - opensips[9801]: get_route: gw_id - Level3-VT1 opensips[9801]: get_route: gw_prfx - + opensips[9801]: get_route: rule_id - 4 opensips[9801]: get_route: rule_prfx - 1 opensips[9801]: get_route: carr_id - Level3-VT#012 You can see that the string '#012' has been appended to the Carrier ID. So far it has always been that string appended to the ID. It started occurring after I moved from a RHEL 7 server using MariaDB to a RHEL 6 server using MySQL, but in both cases I am using the provided OpenSIPS scripts to create all database tables. Any help would be appreciated. Ben Newlin _______________________________________________ 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 Mar 26 16:35:48 2015 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 26 Mar 2015 17:35:48 +0200 Subject: [OpenSIPS-Users] DROUTING module changing Carrier IDs In-Reply-To: References: <5514115E.7020600@opensips.org> Message-ID: <55142754.6080605@opensips.org> ok, no worries :) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 26.03.2015 17:32, Newlin, Ben wrote: > > Bogdan, > > After further investigation I have found that the characters are an > artifact of the syslog daemon on the system. When I run with ?fork=no? > and ?log_stderr=yes? I do not see the characters in the screen output. > > I have also now noticed both newline characters - #015 and #012 ? at > other places in the logs, which also do not appear when logging to stderr. > > Sorry for the false alarm, but I appreciate the help to point me in > the right direction. > > Ben Newlin > > *From:*users-bounces at lists.opensips.org > [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Newlin, Ben > *Sent:* Thursday, March 26, 2015 10:54 AM > *To:* Bogdan-Andrei Iancu; OpenSIPS users mailling list > *Subject:* Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs > > Bogdan, > > It did occur to me that the code seemed to be the octal for newline, > but I don?t know what the significance of that could be. > > The MI command output does not show the extra characters: > > ~]$ opensipsctl dr carrier_status > > ID:: Level3-VT Enabled=yes > > ID:: IndyEdges Enabled=yes > > I have also verified that the extra characters do not exist in the DB. > They are also not returned from the DB when queried from anywhere > else, and even the DROUTING module does not return the extra > characters for any of the other string fields it is returning, only > the Carrier ID. > > Ben Newlin > > *From:*Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] > *Sent:* Thursday, March 26, 2015 10:02 AM > *To:* OpenSIPS users mailling list; Newlin, Ben > *Subject:* Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs > > Hi Ben, > > If you run the "dr_carrier_status" MI command, do you see the same > #012 in the ID of the carrier ? #012 is '\n' - are you sure you do not > have it by mistake in DB ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 25.03.2015 21:53, Newlin, Ben wrote: > > I am using OpenSIPS 1.11 and I am recently getting some weird > behavior from the DROUTING module. The module is corrupting the > Carrier ID that is being returned via AVP. This behavior is > occurring only with the Carrier ID, not the gateway or rule IDs, > and only when it is returned from the DROUTING module via > dr_is_gw() or do_routing(). If I query the database directly using > AVPOPS, the Carrier ID is returned correctly. > > I have the following configuration. The startup_route was added > specifically for this issue. > > #### Dynamic ROUTING module > > loadmodule "drouting.so" > > modparam("drouting", "db_url", "CFG_DB_URL") > > modparam("drouting", "persistent_state", DISABLE) > > modparam("drouting", "probing_interval", ENABLE) > > modparam("drouting", "force_dns", ENABLE) > > modparam("drouting", "ruri_avp", '$avp(dr_ruri)') > > modparam("drouting", "gw_id_avp", '$avp(dr_gw_id)') > > modparam("drouting", "gw_priprefix_avp", '$avp(dr_gw_prfx)') > > modparam("drouting", "rule_id_avp", '$avp(dr_rule_id)') > > modparam("drouting", "rule_prefix_avp", '$avp(dr_rule_prfx)') > > modparam("drouting", "carrier_id_avp", '$avp(dr_carr_id)') > > . > > . > > . > > startup_route { > > avp_db_query("select carrierid from dr_carriers", "$avp(ids)"); > > for ($var(id) in $(avp(ids)[*])) > > xlog("L_INFO", "Carrier ID: $var(id)\n"); > > } > > . > > . > > . > > route[get_route] > > { > > if (!do_routing("$avp(dr_group)", "", , "$var(rule_attr)", > "$var(gw_attr)", "$var(carr_attr)")) > > { > > xlog("L_ERR", "get_route: failure from do_routing! $retcode\n"); > > route(reply_error, "500", "Server Internal Error"); > > } > > xlog("L_INFO", "get_route: rule_attr - $var(rule_attr)\n"); > > xlog("L_INFO", "get_route: gw_attr - $var(gw_attr)\n"); > > xlog("L_INFO", "get_route: carr_attr - $var(carr_attr)\n"); > > xlog("L_INFO", "get_route: ruri - $avp(dr_ruri)\n"); > > xlog("L_INFO", "get_route: gw_id - $avp(dr_gw_id)\n"); > > xlog("L_INFO", "get_route: gw_prfx - $avp(dr_gw_prfx)\n"); > > xlog("L_INFO", "get_route: rule_id - $avp(dr_rule_id)\n"); > > xlog("L_INFO", "get_route: rule_prfx - $avp(dr_rule_prfx)\n"); > > xlog("L_INFO", "get_route: carr_id - $avp(dr_carr_id)\n\n"); > > } > > The output from the above execution is: > > opensips[9801]: Carrier ID: IndyEdges > > opensips[9801]: Carrier ID: Level3-VT > > opensips: INFO:core:daemonize: pre-daemon process exiting with 0 > > opensips[9801]: get_route: rule_attr - > > opensips[9801]: get_route: gw_attr - > > opensips[9801]: get_route: carr_attr - id=pai;history=hi > > opensips[9801]: get_route: ruri - > > opensips[9801]: get_route: gw_id - Level3-VT1 > > opensips[9801]: get_route: gw_prfx - + > > opensips[9801]: get_route: rule_id - 4 > > opensips[9801]: get_route: rule_prfx - 1 > > opensips[9801]: get_route: carr_id - Level3-VT#012 > > You can see that the string ?#012? has been appended to the > Carrier ID. So far it has always been that string appended to the ID. > > It started occurring after I moved from a RHEL 7 server using > MariaDB to a RHEL 6 server using MySQL, but in both cases I am > using the provided OpenSIPS scripts to create all database tables. > > Any help would be appreciated. > > Ben Newlin > > > > _______________________________________________ > > 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 frank21118 at yahoo.com Thu Mar 26 18:36:11 2015 From: frank21118 at yahoo.com (bluerain) Date: Thu, 26 Mar 2015 10:36:11 -0700 (MST) Subject: [OpenSIPS-Users] Opensips 1.11 on Centos 6.6, running but not listening? In-Reply-To: <551412B0.9000704@opensips.org> References: <1427298103877-7596152.post@n2.nabble.com> <551412B0.9000704@opensips.org> Message-ID: <1427391371184-7596167.post@n2.nabble.com> thx for the reply, I think I fixed the issue, but do you know why am I seeing so many of these error messages? Is it just means some of the SIP message opensips gets can not be parsed or have some weird stuff in it? I checked these IP, they are from VoIP devices manufactured by Grandstream (e.g. HT501) but when I do some wireshark at my firewall, I don't see these weird characters though, so where they from? (e.g. the opensips said it parsed "?#001??V?'?"???", I don't see those weird stuff in data captures at my firewall.) Or maybe I am not looking at the right places? Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3676]: ERROR:core:receive_msg: Unable to parse msg received from [xxx] Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3675]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_first_line: bad request first line Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_first_line: at line 0 char 14: Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_first_line: parsed so far: ?#001??V?'?"??? Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_msg: message=<> -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-on-Centos-6-6-running-but-not-listening-tp7596152p7596167.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From alipey at gmail.com Thu Mar 26 19:29:47 2015 From: alipey at gmail.com (Ali Pey) Date: Thu, 26 Mar 2015 14:29:47 -0400 Subject: [OpenSIPS-Users] DRouting and Range of numbers Message-ID: Hello, Is it possible to have a rule with a range of numbers in Dynamic routing? For instance I want 8881231231 to 5 to be routed to a specific gw. Can I do this with one rule only? I don't want 8881231236 to 9 to be routed to that gateway. Thanks, Ali Pey -------------- next part -------------- An HTML attachment was scrubbed... URL: From aqsyounas at gmail.com Thu Mar 26 19:41:35 2015 From: aqsyounas at gmail.com (Aqs Younas) Date: Thu, 26 Mar 2015 23:41:35 +0500 Subject: [OpenSIPS-Users] How to get rate(cps) it which calls are hitting opensips Message-ID: Hi, users. I am new to opensips, just started playing with it. Please pardon me for my naive question, but I want cps in opensips. I have tried the following snippet, but still calls went on. if (is_method("INVITE")) { if (!rl_check("$si", "3", "RED")) { xlog("L_ERR","Cps limit reached [$fu/$tu/$ru/$ci]"); sl_send_reply("403", "CPS Limit Exceeded"); exit; }; setflag(ACC_DO); # do accounting } Found at the following thread. http://opensips.org/pipermail/users/2012-April/021478.html Though this snippet is limiting the cps.(does not work for me) But I want is cps on over all opensips. Can anybody please tell me why this snippet is not working and how can i get overall cps on my box.I am using sipp for seding calls. Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laszlo at voipfreak.net Thu Mar 26 20:44:10 2015 From: laszlo at voipfreak.net (Laszlo) Date: Thu, 26 Mar 2015 20:44:10 +0100 Subject: [OpenSIPS-Users] How to get rate(cps) it which calls are hitting opensips In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 7:41 PM, Aqs Younas wrote: > Hi, users. > > I am new to opensips, just started playing with it. Please pardon me for > my naive question, but I want cps in opensips. > > I have tried the following snippet, but still calls went on. > > if (is_method("INVITE")) { > if (!rl_check("$si", "3", "RED")) { > xlog("L_ERR","Cps limit reached [$fu/$tu/$ru/$ci]"); > sl_send_reply("403", "CPS Limit Exceeded"); > exit; > }; > setflag(ACC_DO); # do accounting > } > > Found at the following thread. > http://opensips.org/pipermail/users/2012-April/021478.html > > Though this snippet is limiting the cps.(does not work for me) But I want > is cps on over all opensips. > > Can anybody please tell me why this snippet is not working and how can i > get overall cps on my box.I am using sipp for seding calls. > > Thanks for your help. > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > With using $si you limiting the individual source IPs. Take a look at http://www.opensips.org/html/docs/modules/devel/ratelimit.html#id293757 (the first example) Also make sure that you set the timer_interval -- Kind regards, Laszlo Bekesi http://voipfreak.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From 542590776 at qq.com Fri Mar 27 08:17:15 2015 From: 542590776 at qq.com (jacky) Date: Fri, 27 Mar 2015 00:17:15 -0700 (MST) Subject: [OpenSIPS-Users] Opensips is listenning port 5060, but NMap shows 5060 is closed Message-ID: <1427440635868-7596174.post@n2.nabble.com> I got Opensips on an Ubuntu Cloud Server, it is listenning the port 5060. But I test on the remote pc client with tools, and shows that the 5060 was closed: I am wondering that will it results to nothing received from sip clients???? Jitsi on my pc sended REGISTER, meanwhile, the remote Opensips got nothing. Thanks for your attention, I really appreciate your help! Best regards! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-is-listenning-port-5060-but-NMap-shows-5060-is-closed-tp7596174.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Fri Mar 27 09:25:56 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Fri, 27 Mar 2015 10:25:56 +0200 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> Message-ID: <55151414.6020308@opensips.org> Hi, Terrance! The routing logic (determinig the IPs and ports) have to be decided in the request route. The routing information in replies should be passed by OpenSIPS unchanged to the UAS, you _should not_ change the routing information in replies. If your message is comming from the internet, then it should have already arrived on the interface which as hassinged an advertised address. If you want to pass it to a private network, just use force_send_socket() to the private network. Let's take an example: if I have the following interfaces: listen=udp:10.0.0.1:5060 as 1.1.1.1 # used for public network listen=udp:10.0.0.2:5060 # used forprivate network The client sends the invite to OpenSIPS via public network, so it will get in OpenSIPS via 10.0.0.1. In request route I would do: route { ... if ($Ri == "10.0.0.1") force_send_socket(udp:10.0.0.2:5060); ... } This request will go to UAS with two Record Routes: udp:10.0.0.2:5060 udp:1.1.1.1:5060 Therefore, the reply will have the proper information in the Record Route header. I hope it is clear now. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/26/2015 04:12 PM, Terrance Devor wrote: > I hope it's ok to re-phrase my question in this same email. Where is > the best place to change > the ip address using set_advertised_address for 200OK being sent out > by OpenSIPS to the > UAS. > > T. > ? > > > _______________________________________________ > 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 Mar 27 09:29:01 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Fri, 27 Mar 2015 10:29:01 +0200 Subject: [OpenSIPS-Users] DRouting and Range of numbers In-Reply-To: References: Message-ID: <551514CD.2030802@opensips.org> Hi, Ali! Unfortunately drouting works only prefix based, so unless you write specific rules for the 5 numbers (i.e. add rules for each number from 8881231231 to 8881231235 in the table), you cannot achieve this. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/26/2015 08:29 PM, Ali Pey wrote: > Hello, > > Is it possible to have a rule with a range of numbers in Dynamic routing? > > For instance I want 8881231231 to 5 to be routed to a specific gw. Can > I do this with one rule only? > I don't want 8881231236 to 9 to be routed to that gateway. > > Thanks, > Ali Pey > > > > _______________________________________________ > 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 Mar 27 09:34:02 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Fri, 27 Mar 2015 10:34:02 +0200 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: References: Message-ID: <551515FA.90601@opensips.org> Hi, John! What do you mean the dialog is hanging in state 5? The dialog is never deleted from DB/memory? The dialog starts when the call is completed (the 200 OK is sent), so you can't "move a dialog" in failure route. What you can do is to handle the Request failure in failure_route and route it somewhere else, or drop it and the dialog is closed. To handle a request in failure_route, you have to engage it before sending the first request out, using: t_on_failure("handle_fails"); ... failure_route[handle_fails] { ... # handle the failed call ... } Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/26/2015 03:55 PM, John Mathew wrote: > Hi, > > Dialog state is hanging at "state 5" when there is no response from > the destination. > > What config we need to add to get the dialog moved to failure_route > if, opensips is not receiving any response from destination for any > request sent out.? > > Or > > > How can we drop the dialog instead of moving to failure_route? > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > WEB: www.divoxmedia.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 john.mathew at divoxmedia.com Fri Mar 27 09:40:36 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Fri, 27 Mar 2015 14:10:36 +0530 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: <551515FA.90601@opensips.org> References: <551515FA.90601@opensips.org> Message-ID: Hi Razvan, I mean dialog not deleted from memory and they are at state 5. This happens only for calls where, destination not responding for Register and Invite requests. And they are not deleted from memory. I guess i am missing some timer related configuration. On Friday, 27 March 2015, R?zvan Crainea wrote: > Hi, John! > > What do you mean the dialog is hanging in state 5? The dialog is never > deleted from DB/memory? > > The dialog starts when the call is completed (the 200 OK is sent), so you > can't "move a dialog" in failure route. > What you can do is to handle the Request failure in failure_route and > route it somewhere else, or drop it and the dialog is closed. To handle a > request in failure_route, you have to engage it before sending the first > request out, using: > > t_on_failure("handle_fails"); > ... > > > failure_route[handle_fails] { > ... > # handle the failed call > ... > } > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/26/2015 03:55 PM, John Mathew wrote: > > Hi, > > Dialog state is hanging at "state 5" when there is no response from the > destination. > > What config we need to add to get the dialog moved to failure_route if, > opensips is not receiving any response from destination for any request > sent out.? > > Or > > > How can we drop the dialog instead of moving to failure_route? > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > > WEB: www.divoxmedia.com > > > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- Sent from iPhone 6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladpaiu at opensips.org Fri Mar 27 14:09:56 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Fri, 27 Mar 2015 15:09:56 +0200 Subject: [OpenSIPS-Users] [Releases] Minor releases for 1.11, 1.10 and 1.8 branches Message-ID: <551556A4.1070201@opensips.org> Hello all, New minor releases for the currently maintained versions will be done Thursday 2nd of April, as follows: - 1.11.4 - 1.10.4 - 1.8.7 (see http://www.opensips.org/About/AvailableVersions). Please let us know if you have any pending bug reports or suggestions. Best Regards, -- Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com From michele.pinassi at unisi.it Fri Mar 27 14:26:35 2015 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Fri, 27 Mar 2015 14:26:35 +0100 Subject: [OpenSIPS-Users] NOTIFY not routed Message-ID: <55155A8B.4070604@unisi.it> A non-text attachment was scrubbed... Name: not available Type: application/pgp-encrypted Size: 11 bytes Desc: PGP/MIME version identification URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: encrypted.asc Type: application/octet-stream Size: 2818 bytes Desc: OpenPGP encrypted message URL: From michele.pinassi at unisi.it Fri Mar 27 15:29:34 2015 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Fri, 27 Mar 2015 15:29:34 +0100 Subject: [OpenSIPS-Users] Routing NOTIFY to the phone - MAYBE SOLVED Message-ID: <5515694E.4030106@unisi.it> Oh dear, maybe i've found the bug: in my routing logic, NOTIFY messages return true for "has_totag()" but false for "loose_route()" so they felt into sl_send_reply("404","Not here"). Maybe i've solved adding a else if(is_method("NOTIFY") and just relaying them, as follow: if (has_totag()) { if (loose_route()) { [...] } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { t_relay(); exit; } else { exit; } } else if(is_method("NOTIFY")) { t_relay(); exit; } sl_send_reply("404","Not here"); } exit; } Hope this works. Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)5000 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it From john.mathew at divoxmedia.com Fri Mar 27 16:06:26 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Fri, 27 Mar 2015 20:36:26 +0530 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: References: <551515FA.90601@opensips.org> Message-ID: Hi, Normally how do we handle the situation, when we do not receive any response from destination for any request? On Fri, Mar 27, 2015 at 2:10 PM, John Mathew wrote: > Hi Razvan, > > I mean dialog not deleted from memory and they are at state 5. This > happens only for calls where, destination not responding for Register and > Invite requests. And they are not deleted from memory. > > I guess i am missing some timer related configuration. > > > On Friday, 27 March 2015, R?zvan Crainea wrote: > >> Hi, John! >> >> What do you mean the dialog is hanging in state 5? The dialog is never >> deleted from DB/memory? >> >> The dialog starts when the call is completed (the 200 OK is sent), so you >> can't "move a dialog" in failure route. >> What you can do is to handle the Request failure in failure_route and >> route it somewhere else, or drop it and the dialog is closed. To handle a >> request in failure_route, you have to engage it before sending the first >> request out, using: >> >> t_on_failure("handle_fails"); >> ... >> >> >> failure_route[handle_fails] { >> ... >> # handle the failed call >> ... >> } >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/26/2015 03:55 PM, John Mathew wrote: >> >> Hi, >> >> Dialog state is hanging at "state 5" when there is no response from the >> destination. >> >> What config we need to add to get the dialog moved to failure_route if, >> opensips is not receiving any response from destination for any request >> sent out.? >> >> Or >> >> >> How can we drop the dialog instead of moving to failure_route? >> >> -- >> >> Regards, >> John Mathew >> CEO/Director >> Divox International Inc. >> Contact: +91-9037100001 >> Email/MSN: John.Mathew at divoxmedia.com >> WEB: www.divoxmedia.com >> >> >> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > -- > Sent from iPhone 6 > -- Regards, John Mathew CEO/Director Divox International Inc. Contact: +91-9037100001 Email/MSN: John.Mathew at divoxmedia.com WEB: www.divoxmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alipey at gmail.com Fri Mar 27 16:55:15 2015 From: alipey at gmail.com (Ali Pey) Date: Fri, 27 Mar 2015 11:55:15 -0400 Subject: [OpenSIPS-Users] DRouting and Range of numbers In-Reply-To: <551514CD.2030802@opensips.org> References: <551514CD.2030802@opensips.org> Message-ID: Hi Razvan. Thank you for the response. Regards, Ali Pey On Fri, Mar 27, 2015 at 4:29 AM, R?zvan Crainea wrote: > Hi, Ali! > > Unfortunately drouting works only prefix based, so unless you write > specific rules for the 5 numbers (i.e. add rules for each number from 8881231231 > to 8881231235 in the table), you cannot achieve this. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions www.opensips-solutions.com > > On 03/26/2015 08:29 PM, Ali Pey wrote: > > Hello, > > Is it possible to have a rule with a range of numbers in Dynamic routing? > > For instance I want 8881231231 to 5 to be routed to a specific gw. Can I > do this with one rule only? > I don't want 8881231236 to 9 to be routed to that gateway. > > Thanks, > Ali Pey > > > > _______________________________________________ > 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 ter.devor at gmail.com Sat Mar 28 01:14:07 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Fri, 27 Mar 2015 20:14:07 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: <55151414.6020308@opensips.org> References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> Message-ID: Hello Razvan, Thank you so much for your response. In our case it's not a 1:1 nat so we cannot listen on the public IP. I just need to change the RR when communicating locally vs externally. That is why I was referring to set_advertised_address. Will the same scenario still work? Or do I have to use a different function. ?T -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.mathew at divoxmedia.com Sun Mar 29 08:19:19 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Sun, 29 Mar 2015 11:49:19 +0530 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: References: <551515FA.90601@opensips.org> Message-ID: Guys, Waiting for your response. Any help will be appreciated. On Fri, Mar 27, 2015 at 8:36 PM, John Mathew wrote: > Hi, > > Normally how do we handle the situation, when we do not receive any > response from destination for any request? > > On Fri, Mar 27, 2015 at 2:10 PM, John Mathew > wrote: > >> Hi Razvan, >> >> I mean dialog not deleted from memory and they are at state 5. This >> happens only for calls where, destination not responding for Register and >> Invite requests. And they are not deleted from memory. >> >> I guess i am missing some timer related configuration. >> >> >> On Friday, 27 March 2015, R?zvan Crainea wrote: >> >>> Hi, John! >>> >>> What do you mean the dialog is hanging in state 5? The dialog is never >>> deleted from DB/memory? >>> >>> The dialog starts when the call is completed (the 200 OK is sent), so >>> you can't "move a dialog" in failure route. >>> What you can do is to handle the Request failure in failure_route and >>> route it somewhere else, or drop it and the dialog is closed. To handle a >>> request in failure_route, you have to engage it before sending the first >>> request out, using: >>> >>> t_on_failure("handle_fails"); >>> ... >>> >>> >>> failure_route[handle_fails] { >>> ... >>> # handle the failed call >>> ... >>> } >>> >>> Best regards, >>> >>> R?zvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/26/2015 03:55 PM, John Mathew wrote: >>> >>> Hi, >>> >>> Dialog state is hanging at "state 5" when there is no response from the >>> destination. >>> >>> What config we need to add to get the dialog moved to failure_route if, >>> opensips is not receiving any response from destination for any request >>> sent out.? >>> >>> Or >>> >>> >>> How can we drop the dialog instead of moving to failure_route? >>> >>> -- >>> >>> Regards, >>> John Mathew >>> CEO/Director >>> Divox International Inc. >>> Contact: +91-9037100001 >>> Email/MSN: John.Mathew at divoxmedia.com >>> WEB: www.divoxmedia.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> >> -- >> Sent from iPhone 6 >> > > > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > WEB: www.divoxmedia.com > > > > -- Regards, John Mathew CEO/Director Divox International Inc. Contact: +91-9037100001 Email/MSN: John.Mathew at divoxmedia.com WEB: www.divoxmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Mar 30 10:24:36 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 30 Mar 2015 11:24:36 +0300 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: References: <551515FA.90601@opensips.org> Message-ID: <55190844.3080008@opensips.org> Do the dialogs get stuckin state 5 and they are never deleted? By default, when a negative reply is received and there is no failure route armed to handle it, the transaction/dialog is destroyed and the reply is sent back to the client. Can you please be a bit more specific about what is happening with your call, and what would you like to happend? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/29/2015 09:19 AM, John Mathew wrote: > Guys, > > Waiting for your response. Any help will be appreciated. > > On Fri, Mar 27, 2015 at 8:36 PM, John Mathew > > wrote: > > Hi, > > Normally how do we handle the situation, when we do not receive > any response from destination for any request? > > On Fri, Mar 27, 2015 at 2:10 PM, John Mathew > > > wrote: > > Hi Razvan, > > I mean dialog not deleted from memory and they are at state 5. > This happens only for calls where, destination not responding > for Register and Invite requests. And they are not deleted > from memory. > > I guess i am missing some timer related configuration. > > > On Friday, 27 March 2015, R?zvan Crainea > wrote: > > Hi, John! > > What do you mean the dialog is hanging in state 5? The > dialog is never deleted from DB/memory? > > The dialog starts when the call is completed (the 200 OK > is sent), so you can't "move a dialog" in failure route. > What you can do is to handle the Request failure in > failure_route and route it somewhere else, or drop it and > the dialog is closed. To handle a request in > failure_route, you have to engage it before sending the > first request out, using: > > t_on_failure("handle_fails"); > ... > > > failure_route[handle_fails] { > ... > # handle the failed call > ... > } > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/26/2015 03:55 PM, John Mathew wrote: >> Hi, >> >> Dialog state is hanging at "state 5" when there is no >> response from the destination. >> >> What config we need to add to get the dialog moved to >> failure_route if, opensips is not receiving any response >> from destination for any request sent out.? >> >> Or >> >> >> How can we drop the dialog instead of moving to >> failure_route? >> >> -- >> >> Regards, >> John Mathew >> CEO/Director >> Divox International Inc. >> Contact: +91-9037100001 >> Email/MSN: John.Mathew at divoxmedia.com >> WEB: www.divoxmedia.com >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Sent from iPhone 6 > > > > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > > WEB: www.divoxmedia.com > > > > > > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > WEB: www.divoxmedia.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 Mon Mar 30 10:25:26 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 30 Mar 2015 11:25:26 +0300 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> Message-ID: <55190876.8040004@opensips.org> Hi, Terrance! Yes, using the set_advertise_address() function should work too, but only on requests, not on replies. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/28/2015 02:14 AM, Terrance Devor wrote: > Hello Razvan, > > > Thank you so much for your response. In our case it's not a 1:1 nat so > we cannot listen on > the public IP. I just need to change the RR when communicating locally > vs externally. That > is why I was referring to set_advertised_address. Will the same > scenario still work? Or do > I have to use a different function. > > > ?T > > > _______________________________________________ > 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 michele.pinassi at unisi.it Mon Mar 30 11:52:58 2015 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Mon, 30 Mar 2015 11:52:58 +0200 Subject: [OpenSIPS-Users] Relay SUBSCRIBE after handle_subscribe Message-ID: <55191CFA.3060708@unisi.it> Hi all, is possibile to relay SUBSCRIBE packet after an handle_subscribe() ? To be more clear, my OpenSIPS server get all SUBSCRIBE packets (send from phone A to phone B) so i can keep control of "who subscribe who" but i need to relay that packet to the correct destination. I did the following: # Presence route route[handle_presence] { if(!t_newtran()){ sl_reply_error(); exit; } xlog("L_INFO", "Route PRESENCE $rm for Event $hdr(Event) from $fu to $to R-URI $ru"); if (is_method("PUBLISH")) { handle_publish(); } else if (is_method("SUBSCRIBE")) { handle_subscribe(); t_relay(); } } else if(is_method("NOTIFY")) { t_relay(); } exit; } Is that correct ? There's another better way to do this ? Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)5000 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From ter.devor at gmail.com Mon Mar 30 16:19:35 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Mon, 30 Mar 2015 10:19:35 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: <55190876.8040004@opensips.org> References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: Hello Razvan, Thanks again for your input. >> but only on requests, not on replies. And that is the exact issue we are experiencing. If I understand correctly, we are unable to modify the Contact HDR and RR for relay signalling such as "ACK, Session Progress and 200 OKs"? Is this not capability not relevant when relaying messages? What is strange is that when I inject test HDR messages (ie, append_hf("X-TEST: ACK $si\r\n");) in the on_reply, I am able to hit the point where I need the modification of the RR and Contact however, all attempts to use set_advertised_address in the on_reply have failed. Your Help is greatly appreciate, I have struggled with this for a few weeks now :/ Terrance ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at inin.com Mon Mar 30 16:36:39 2015 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Mon, 30 Mar 2015 14:36:39 +0000 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: Terrance, I am doing something similar and have found the ?topology hiding? feature of the dialog module will do this. The feature?s purpose is to re-write all IP information in SIP headers to hide network topology, but in the process it will also perform the type of translation you are looking for. I am not sure if dialogs are something you want to use, but I thought I would mention it. Ben Newlin From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Terrance Devor Sent: Monday, March 30, 2015 10:20 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 Hello Razvan, Thanks again for your input. >> but only on requests, not on replies. And that is the exact issue we are experiencing. If I understand correctly, we are unable to modify the Contact HDR and RR for relay signalling such as "ACK, Session Progress and 200 OKs"? Is this not capability not relevant when relaying messages? What is strange is that when I inject test HDR messages (ie, append_hf("X-TEST: ACK $si\r\n");) in the on_reply, I am able to hit the point where I need the modification of the RR and Contact however, all attempts to use set_advertised_address in the on_reply have failed. Your Help is greatly appreciate, I have struggled with this for a few weeks now :/ Terrance ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Mar 30 18:54:29 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 30 Mar 2015 19:54:29 +0300 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] Contest and prices - OpenSIPS 2.1 testing In-Reply-To: <551199B2.8070809@opensips.org> References: <55105D99.2070301@opensips.org> <551199B2.8070809@opensips.org> Message-ID: <55197FC5.1010204@opensips.org> And the winner of the first Bug Hunt in OpenSIPS 2.1 edition is Eric Tamme(lirakis)with the TLS protocol issue[1]! Congrats, Eric! Starting from NOW, the second edition has started[2]! To join the contest, all you have to do is to report here[3] the bugs you find in OpenSIPS 2.1. [1] https://github.com/OpenSIPS/opensips/commit/bfbb5bb3645a9121277b2f9f67aa9dd546c35e8d [2] http://www.opensips.org/Community/BugHuntContest [3] https://github.com/OpenSIPS/opensips/issues Happy testing, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/24/2015 07:06 PM, R?zvan Crainea wrote: > Hi, All! > > Hurry up, we already have three bugs reported[1] :). > > [1] http://www.opensips.org/Community/BugHuntContest > > Cheers, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/23/2015 08:38 PM, Bogdan-Andrei Iancu wrote: >> Hi all, >> >> Starting this week and all the way to the date of 2.1 stable release >> (from RC to GA), we will open a weekly contest that will help with >> the testing :). >> >> What is the contest for ? For the best bug found :). Whoever finds >> the "uglies" bug in 2.1-rc will get an official OpenSIPS T-shirt, >> like these guys did :) : >> http://farm4.staticflickr.com/3947/15725260732_826db90980_z.jpg >> >> So, we pay you for for finding the best bug in OpenSIPS - attractive >> job ?? >> >> CONTEST IS ON !!!!! And we already have a strong candidate for this >> week. >> >> Best Regards, >> > > > _______________________________________________ > Devel mailing list > Devel at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel From john.mathew at divoxmedia.com Mon Mar 30 19:08:02 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Mon, 30 Mar 2015 22:38:02 +0530 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: <55190844.3080008@opensips.org> References: <551515FA.90601@opensips.org> <55190844.3080008@opensips.org> Message-ID: Razvan, I tried to reproduce the issue, by making UAS not to respond for opensips request. but opensips is handling it correctly. That means the issue is not during Request Timeout. Then what what could be reason, when intermittently Dialog not deleted from state 5 and once in 2-3 days state 5 calls will be 5000 numbers and opensips ran out of shmem and crashes. On Mon, Mar 30, 2015 at 1:54 PM, R?zvan Crainea wrote: > Do the dialogs get stuck in state 5 and they are never deleted? > By default, when a negative reply is received and there is no failure > route armed to handle it, the transaction/dialog is destroyed and the reply > is sent back to the client. > > Can you please be a bit more specific about what is happening with your > call, and what would you like to happend? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/29/2015 09:19 AM, John Mathew wrote: > > Guys, > > Waiting for your response. Any help will be appreciated. > > On Fri, Mar 27, 2015 at 8:36 PM, John Mathew > wrote: > >> Hi, >> >> Normally how do we handle the situation, when we do not receive any >> response from destination for any request? >> >> On Fri, Mar 27, 2015 at 2:10 PM, John Mathew >> wrote: >> >>> Hi Razvan, >>> >>> I mean dialog not deleted from memory and they are at state 5. This >>> happens only for calls where, destination not responding for Register and >>> Invite requests. And they are not deleted from memory. >>> >>> I guess i am missing some timer related configuration. >>> >>> >>> On Friday, 27 March 2015, R?zvan Crainea wrote: >>> >>>> Hi, John! >>>> >>>> What do you mean the dialog is hanging in state 5? The dialog is never >>>> deleted from DB/memory? >>>> >>>> The dialog starts when the call is completed (the 200 OK is sent), so >>>> you can't "move a dialog" in failure route. >>>> What you can do is to handle the Request failure in failure_route and >>>> route it somewhere else, or drop it and the dialog is closed. To handle a >>>> request in failure_route, you have to engage it before sending the first >>>> request out, using: >>>> >>>> t_on_failure("handle_fails"); >>>> ... >>>> >>>> >>>> failure_route[handle_fails] { >>>> ... >>>> # handle the failed call >>>> ... >>>> } >>>> >>>> Best regards, >>>> >>>> R?zvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/26/2015 03:55 PM, John Mathew wrote: >>>> >>>> Hi, >>>> >>>> Dialog state is hanging at "state 5" when there is no response from >>>> the destination. >>>> >>>> What config we need to add to get the dialog moved to failure_route if, >>>> opensips is not receiving any response from destination for any request >>>> sent out.? >>>> >>>> Or >>>> >>>> >>>> How can we drop the dialog instead of moving to failure_route? >>>> >>>> -- >>>> >>>> Regards, >>>> John Mathew >>>> CEO/Director >>>> Divox International Inc. >>>> Contact: +91-9037100001 >>>> Email/MSN: John.Mathew at divoxmedia.com >>>> WEB: www.divoxmedia.com >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>> >>> -- >>> Sent from iPhone 6 >>> >> >> >> >> -- >> >> Regards, >> John Mathew >> CEO/Director >> Divox International Inc. >> Contact: +91-9037100001 >> Email/MSN: John.Mathew at divoxmedia.com >> WEB: www.divoxmedia.com >> >> >> >> > > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > WEB: www.divoxmedia.com > > > > > > _______________________________________________ > 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 > > -- Regards, John Mathew CEO/Director Divox International Inc. Contact: +91-9037100001 Email/MSN: John.Mathew at divoxmedia.com WEB: www.divoxmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Mar 31 12:13:15 2015 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 31 Mar 2015 13:13:15 +0300 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: References: <551515FA.90601@opensips.org> <55190844.3080008@opensips.org> Message-ID: <551A733B.4000607@opensips.org> Hi, John! What OpenSIPS version are you running? Regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/30/2015 08:08 PM, John Mathew wrote: > Razvan, > > I tried to reproduce the issue, by making UAS not to respond for > opensips request. but opensips is handling it correctly. That means > the issue is not during Request Timeout. > > Then what what could be reason, when intermittently Dialog not deleted > from state 5 and once in 2-3 days state 5 calls will be 5000 numbers > and opensips ran out of shmem and crashes. > > On Mon, Mar 30, 2015 at 1:54 PM, R?zvan Crainea > wrote: > > Do the dialogs get stuckin state 5 and they are never deleted? > By default, when a negative reply is received and there is no > failure route armed to handle it, the transaction/dialog is > destroyed and the reply is sent back to the client. > > Can you please be a bit more specific about what is happening with > your call, and what would you like to happend? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/29/2015 09:19 AM, John Mathew wrote: >> Guys, >> >> Waiting for your response. Any help will be appreciated. >> >> On Fri, Mar 27, 2015 at 8:36 PM, John Mathew >> > >> wrote: >> >> Hi, >> >> Normally how do we handle the situation, when we do not >> receive any response from destination for any request? >> >> On Fri, Mar 27, 2015 at 2:10 PM, John Mathew >> > > wrote: >> >> Hi Razvan, >> >> I mean dialog not deleted from memory and they are at >> state 5. This happens only for calls where, destination >> not responding for Register and Invite requests. And they >> are not deleted from memory. >> >> I guess i am missing some timer related configuration. >> >> >> On Friday, 27 March 2015, R?zvan Crainea >> > wrote: >> >> Hi, John! >> >> What do you mean the dialog is hanging in state 5? >> The dialog is never deleted from DB/memory? >> >> The dialog starts when the call is completed (the 200 >> OK is sent), so you can't "move a dialog" in failure >> route. >> What you can do is to handle the Request failure in >> failure_route and route it somewhere else, or drop it >> and the dialog is closed. To handle a request in >> failure_route, you have to engage it before sending >> the first request out, using: >> >> t_on_failure("handle_fails"); >> ... >> >> >> failure_route[handle_fails] { >> ... >> # handle the failed call >> ... >> } >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 03/26/2015 03:55 PM, John Mathew wrote: >>> Hi, >>> >>> Dialog state is hanging at "state 5" when there is >>> no response from the destination. >>> >>> What config we need to add to get the dialog moved >>> to failure_route if, opensips is not receiving any >>> response from destination for any request sent out.? >>> >>> Or >>> >>> >>> How can we drop the dialog instead of moving to >>> failure_route? >>> >>> -- >>> >>> Regards, >>> John Mathew >>> CEO/Director >>> Divox International Inc. >>> Contact: +91-9037100001 >>> Email/MSN: John.Mathew at divoxmedia.com >>> WEB: www.divoxmedia.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> -- >> Sent from iPhone 6 >> >> >> >> >> -- >> >> Regards, >> John Mathew >> CEO/Director >> Divox International Inc. >> Contact: +91-9037100001 >> Email/MSN: John.Mathew at divoxmedia.com >> >> WEB: www.divoxmedia.com >> >> >> >> >> >> >> -- >> >> Regards, >> John Mathew >> CEO/Director >> Divox International Inc. >> Contact: +91-9037100001 >> Email/MSN: John.Mathew at divoxmedia.com >> >> WEB: www.divoxmedia.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 > > > > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > WEB: www.divoxmedia.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 michele.pinassi at unisi.it Tue Mar 31 12:21:50 2015 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Tue, 31 Mar 2015 12:21:50 +0200 Subject: [OpenSIPS-Users] Some questions about Presence server Message-ID: <551A753E.7060000@unisi.it> Hi all, i've read the tutorial on OpenSIPS site (http://www.opensips.org/Documentation/Tutorials-Presence-SimplePresConfig) but i suspect that my simple presence server don't work as expected, causing me some annoying troubles. Mainly, is not clear if the Basic Presence Server need OpenXCAP or similar server installed and working: seems not, but for some reasons my OpenSIPS's presence route (http://pastebin.com/FV2L6JaS) handle SUBSCRIBE and PRESENCE but don't send NOTIFY. I've tried suggested configuration but no way, NOTIFY weren't sent out. If i disable all routing and handling for SUBSCRIBE, NOTIFY and PRESENCE, all works as expected. But because i want to mantain control over my system, i want to let OpenSIPS manage all requests. You can see my config on http://pastebin.com/FV2L6JaS This issue caused me a lot of frustration because i can't figure out why doesn't work... Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)5000 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it From john.mathew at divoxmedia.com Tue Mar 31 12:29:21 2015 From: john.mathew at divoxmedia.com (John Mathew) Date: Tue, 31 Mar 2015 15:59:21 +0530 Subject: [OpenSIPS-Users] Dialog hanging at State 5 In-Reply-To: <551A733B.4000607@opensips.org> References: <551515FA.90601@opensips.org> <55190844.3080008@opensips.org> <551A733B.4000607@opensips.org> Message-ID: Opensips 1.11.3 On Tuesday, 31 March 2015, R?zvan Crainea wrote: > Hi, John! > > What OpenSIPS version are you running? > > Regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/30/2015 08:08 PM, John Mathew wrote: > > Razvan, > > I tried to reproduce the issue, by making UAS not to respond for opensips > request. but opensips is handling it correctly. That means the issue is not > during Request Timeout. > > Then what what could be reason, when intermittently Dialog not deleted > from state 5 and once in 2-3 days state 5 calls will be 5000 numbers and > opensips ran out of shmem and crashes. > > On Mon, Mar 30, 2015 at 1:54 PM, R?zvan Crainea > wrote: > >> Do the dialogs get stuck in state 5 and they are never deleted? >> By default, when a negative reply is received and there is no failure >> route armed to handle it, the transaction/dialog is destroyed and the reply >> is sent back to the client. >> >> Can you please be a bit more specific about what is happening with your >> call, and what would you like to happend? >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/29/2015 09:19 AM, John Mathew wrote: >> >> Guys, >> >> Waiting for your response. Any help will be appreciated. >> >> On Fri, Mar 27, 2015 at 8:36 PM, John Mathew > > wrote: >> >>> Hi, >>> >>> Normally how do we handle the situation, when we do not receive any >>> response from destination for any request? >>> >>> On Fri, Mar 27, 2015 at 2:10 PM, John Mathew >> > wrote: >>> >>>> Hi Razvan, >>>> >>>> I mean dialog not deleted from memory and they are at state 5. This >>>> happens only for calls where, destination not responding for Register and >>>> Invite requests. And they are not deleted from memory. >>>> >>>> I guess i am missing some timer related configuration. >>>> >>>> >>>> On Friday, 27 March 2015, R?zvan Crainea >>> > wrote: >>>> >>>>> Hi, John! >>>>> >>>>> What do you mean the dialog is hanging in state 5? The dialog is never >>>>> deleted from DB/memory? >>>>> >>>>> The dialog starts when the call is completed (the 200 OK is sent), so >>>>> you can't "move a dialog" in failure route. >>>>> What you can do is to handle the Request failure in failure_route and >>>>> route it somewhere else, or drop it and the dialog is closed. To handle a >>>>> request in failure_route, you have to engage it before sending the first >>>>> request out, using: >>>>> >>>>> t_on_failure("handle_fails"); >>>>> ... >>>>> >>>>> >>>>> failure_route[handle_fails] { >>>>> ... >>>>> # handle the failed call >>>>> ... >>>>> } >>>>> >>>>> Best regards, >>>>> >>>>> R?zvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/26/2015 03:55 PM, John Mathew wrote: >>>>> >>>>> Hi, >>>>> >>>>> Dialog state is hanging at "state 5" when there is no response from >>>>> the destination. >>>>> >>>>> What config we need to add to get the dialog moved to failure_route >>>>> if, opensips is not receiving any response from destination for any request >>>>> sent out.? >>>>> >>>>> Or >>>>> >>>>> >>>>> How can we drop the dialog instead of moving to failure_route? >>>>> >>>>> -- >>>>> >>>>> Regards, >>>>> John Mathew >>>>> CEO/Director >>>>> Divox International Inc. >>>>> Contact: +91-9037100001 >>>>> Email/MSN: John.Mathew at divoxmedia.com >>>>> WEB: www.divoxmedia.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Sent from iPhone 6 >>>> >>> >>> >>> >>> -- >>> >>> Regards, >>> John Mathew >>> CEO/Director >>> Divox International Inc. >>> Contact: +91-9037100001 >>> Email/MSN: John.Mathew at divoxmedia.com >>> >>> WEB: www.divoxmedia.com >>> >>> >>> >>> >> >> >> -- >> >> Regards, >> John Mathew >> CEO/Director >> Divox International Inc. >> Contact: +91-9037100001 >> Email/MSN: John.Mathew at divoxmedia.com >> >> WEB: www.divoxmedia.com >> >> >> >> >> >> _______________________________________________ >> Users mailing listUsers 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 >> >> > > > -- > > Regards, > John Mathew > CEO/Director > Divox International Inc. > Contact: +91-9037100001 > Email/MSN: John.Mathew at divoxmedia.com > > WEB: www.divoxmedia.com > > > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- Sent from iPhone 6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag at ag-projects.com Tue Mar 31 14:42:59 2015 From: ag at ag-projects.com (ag at ag-projects.com) Date: Tue, 31 Mar 2015 09:42:59 -0300 Subject: [OpenSIPS-Users] Some questions about Presence server In-Reply-To: <551A753E.7060000@unisi.it> References: <551A753E.7060000@unisi.it> Message-ID: If your OpenSIPS server acts like a Presence Agent (handles Publish and Subscribe internally and sends out Notifies) you will need an XCAP server to manage the presence policy of the end-points to know who is allowed to see the presence or not. If your OpenSIPS relay the Subscribe messages between the end-points and they generate the Notify then you do not need an XCAP server. Regards, Adrian On 31 Mar 2015, at 07:21, Michele Pinassi wrote: > Hi all, > > i've read the tutorial on OpenSIPS site > (http://www.opensips.org/Documentation/Tutorials-Presence-SimplePresConfig) > but i suspect that my simple presence server don't work as expected, > causing me some annoying troubles. > > Mainly, is not clear if the Basic Presence Server need OpenXCAP or > similar server installed and working: seems not, but for some reasons my > OpenSIPS's presence route (http://pastebin.com/FV2L6JaS) handle > SUBSCRIBE and PRESENCE but don't send NOTIFY. > > I've tried suggested configuration but no way, NOTIFY weren't sent out. > > If i disable all routing and handling for SUBSCRIBE, NOTIFY and > PRESENCE, all works as expected. But because i want to mantain control > over my system, i want to let OpenSIPS manage all requests. > > You can see my config on http://pastebin.com/FV2L6JaS > > This issue caused me a lot of frustration because i can't figure out why > doesn't work... > > Michele > > -- > Michele Pinassi > Responsabile Telefonia di Ateneo > Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena > tel: 0577.(23)5000 - fax: 0577.(23)2053 > > Per trovare una soluzione rapida ai tuoi problemi tecnici > consulta le FAQ di Ateneo, http://www.faq.unisi.it > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 31 14:58:10 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 31 Mar 2015 08:58:10 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: Hello Ben! I really appreciate this. I am assuming you are talking about topology_hiding()? Furthermore, what is the best place to have the command and signal internal devices with internal ips and external devices with external ips. We are trying to have the change applied branch and reply signalling (ie, INVITE, Session Progress, ACK and 200OKs). Finally do you use an if statement of some sort (ie if($si==.......)) to determine if the next signal would be internal vs external? Thanks in Advance, Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at inin.com Tue Mar 31 15:23:39 2015 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Tue, 31 Mar 2015 13:23:39 +0000 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: Yes, topology_hiding(). I am actually doing exactly what you have described wanting to do. I am using set_advertised_address() in request route and then in onreply_route to change the address in each direction. When topology_hiding() is being used, the module is already going to replace the IP addresses in all the headers in onreply_route and it will allow set_advertised_address() to change the address that it will use to do that. The relevant portion of my config looks something like below. I am using AVPs for the addresses which are populated from data elsewhere in the script. I am checking the source address ($si) of the initial request to determine which direction the request is going and set up the AVPs accordingly. route { . . . topology_hiding("U"); uac_replace_from("sip:$fU@$avp(inbound_ip)"); t_on_branch("route_branch"); t_on_reply("route_reply"); set_advertised_address("$avp(inbound_ip)"); set_advertised_port("$avp(inbound_port)"); route(relay); } branch_route[route_branch] { uac_replace_to("", "$ru"); } onreply_route[route_reply] { # Have to load the transaction to get the AVPs but # t_check_trans() can't be used in reply route. t_check_status(".*"); set_advertised_address("$avp(outbound_ip)"); set_advertised_port("$avp(outbound_port)"); } Ben Newlin From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Terrance Devor Sent: Tuesday, March 31, 2015 8:58 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 Hello Ben! I really appreciate this. I am assuming you are talking about topology_hiding()? Furthermore, what is the best place to have the command and signal internal devices with internal ips and external devices with external ips. We are trying to have the change applied branch and reply signalling (ie, INVITE, Session Progress, ACK and 200OKs). Finally do you use an if statement of some sort (ie if($si==.......)) to determine if the next signal would be internal vs external? Thanks in Advance, Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 31 15:51:42 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 31 Mar 2015 09:51:42 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: Hello Ben, This is great! Are you sure the set_advertised_address(outbound ip) actually changed the ip within the on_reply? The reason I ask is because we could not get it to work for us, and according to Razvan's original post. "No, you cannot change the advertised address in the onreply_route" Thanks in Advance, Terrance -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 31 15:53:02 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 31 Mar 2015 09:53:02 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: You know what.... Trying it right now within my script.... Will post how it goes. ? T -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 31 16:11:54 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 31 Mar 2015 10:11:54 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: Worked perfectly. It took me three weeks to finally get this to work thank to you. Kind Regards, Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at inin.com Tue Mar 31 16:13:14 2015 From: Ben.Newlin at inin.com (Newlin, Ben) Date: Tue, 31 Mar 2015 14:13:14 +0000 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: Terrance, Yes, I am sure it works. I have changed the values in onreply_route and see them change in the message. I believe Razvan?s comment applies only when operating in normal proxy mode. The usage of the Dialog module and topology_hiding() is what makes it work. Ben Newlin From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Terrance Devor Sent: Tuesday, March 31, 2015 9:52 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 Hello Ben, This is great! Are you sure the set_advertised_address(outbound ip) actually changed the ip within the on_reply? The reason I ask is because we could not get it to work for us, and according to Razvan's original post. "No, you cannot change the advertised address in the onreply_route" Thanks in Advance, Terrance -------------- next part -------------- An HTML attachment was scrubbed... URL: From ter.devor at gmail.com Tue Mar 31 17:47:18 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Tue, 31 Mar 2015 11:47:18 -0400 Subject: [OpenSIPS-Users] set_advertised_address suspected bug 1.9 In-Reply-To: References: <55127855.7060605@opensips.org> <55151414.6020308@opensips.org> <55190876.8040004@opensips.org> Message-ID: >> I have changed the values in onreply_route and see them change in the message. >> The usage of the Dialog module and topology_hiding() is what makes it work. I concur. I think the days of writing test headers (ie, append_hf("X-Test: blaaaa.....\r\n", "Call-ID")), and studying SIP signalling has come to an end. For a little white at least :). I really appreciate this everyone, and will be helping people on here every chance I get. Thanks Ben! Terrance. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladpaiu at opensips.org Tue Mar 31 19:10:45 2015 From: vladpaiu at opensips.org (Vlad Paiu) Date: Tue, 31 Mar 2015 20:10:45 +0300 Subject: [OpenSIPS-Users] Opensips is listenning port 5060, but NMap shows 5060 is closed In-Reply-To: <1427440635868-7596174.post@n2.nabble.com> References: <1427440635868-7596174.post@n2.nabble.com> Message-ID: <551AD515.2090009@opensips.org> Hello, It seems you have a firewall issue, since indeed OpenSIPS is listening on TCP port 5060. Fix that, and OpenSIPS should start receiving traffic. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 27.03.2015 09:17, jacky wrote: > I got Opensips on an Ubuntu Cloud Server, it is listenning the port 5060. > > > But I test on the remote pc client with tools, and shows that the 5060 was > closed: > > > > I am wondering that will it results to nothing received from sip clients???? > Jitsi on my pc sended REGISTER, meanwhile, the remote Opensips got nothing. > > Thanks for your attention, I really appreciate your help! > > > Best regards! > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-is-listenning-port-5060-but-NMap-shows-5060-is-closed-tp7596174.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 peter.kust at businessuites.com Tue Mar 31 23:02:19 2015 From: peter.kust at businessuites.com (Peter Kust) Date: Tue, 31 Mar 2015 21:02:19 +0000 Subject: [OpenSIPS-Users] OpenSIPS aborting with signal 6 Message-ID: <72838165E698AB40827E601B9E1F2B9AC1DC98@BSSHDCEXS01.colo.businessuites.com> Greetings. Today my proxy server decided to start crashing with a signal 6 error message. Following the troubleshooting steps on http://www.opensips.org/Documentation/TroubleShooting-OutOfMem, I obtained the memory status output (posted on pastebin at http://pastebin.com/0JFyAYXi) on one of the crashes (32Mb private memory 8GB shared memory). Oddly enough, I'm not seeing any out of memory errors or warnings themselves, just a sudden "exited on Signal 6" message, followed by the memory status. The server has 16GB of ram, and every time I run "opensipsctl fifo get_statistics all" the processes indicate plenty of available private and shared memory. Server is CentOS 6.6, running OpenSIPS 1.11.3, with 16GB of RAM. No changes were made to the system before these events started happening, although afterwards I did recompile OpenSIPS to add in the DBG_QM_MALLOC compile option per the TroubleShooting instructions. This system has run stably for about two weeks, and then this suddenly started happening. Has anyone experienced anything similar? Cordially, Peter Nayland Kust Director of Technologies BusinesSuites 24624 Interstate 45 North, Suite 200 Houston, TX 77386 Tel: 281.378.8051 Fax: 855.287.6961 peter.kust at businessuites.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: "d3138e979-a266-4b31-bdc7-d9829cd1fa3a" when using $(hdr(Referred-By){nameaddr.name}). Do I misunderstand anything or the example header field is not eligible? Thanks for any help. Best wishes, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Is-there-any-way-to-access-Referred-By-header-field-tp7597066p7597080.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: function but how they all work together in topology_hiding function scenario? PS: I can send my config in case someone needs to have a look. John --001a11c315286894f105188b2218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have modified my proxy config to sup= port topology_hiding function of dialog module. But I see lot of dialog rel= ated errors like ..

ERROR:dialog:push_reply_in_dialog: [487] reply i= n dlg state [2]: missing TAG param in TO hdr
ERROR:dialog:w_validate_dia= log: null dialog

I am just wondering if my configuration is co= rrect. How functions like loose_route(); match_dialog();, Validate_dialog()= , fix_route_dialog should be used in production environment to cover all ca= ses.

From documentation I find code snippets explaining applic= ation for each function but how they all work together in topology_hiding f= unction scenario?

PS: I can send my config in case someone nee= ds to have a look.

John

--001a11c315286894f105188b2218-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: On Mon, Jul 6, 2015 at 8:10 PM, Ovidiu Sas wrote: > Make sure that you are pointing to the right url: > http://www.opensips.org/html/docs/modules/devel/mi_http#id249072 > http://[opensips_IP]:[opensips_mi_port]/[mi_http_root] > > Regards, > Ovidiu Sas > > On Mon, Jul 6, 2015 at 10:51 AM, Alex Pappas wrote: > > Dear all, > > > > I have default configuration for both the above modules, but I'm not > able to > > send any commands.(ofc the httpd is loaded) > > > > When I try mi_http with get I always get back : > > Response: > > > > > > Unable to parse URL! > > > > > > > > When I try mi_xmlrpc_ng I always get "Unable to parse URL!" although I'm > > trying the example from the module documentation > > > > POST > > Content-Type text/xml > > http://127.0.0.1:8888/xmlrpc > > > > > > > > get_statistics > > > > > > dialog: > > > > > > tm: > > > > > > > > > > Response: > > > > > > Unable to parse URL! > > > > > > > > > > > > What am I doing wrong ?? > > > > thanx in advance > > Alex > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Alexandros Pappas | Business Development | Vieras Phone: +30 6937630910 Email: apappas at vieras.eu Skype: alex.pappas1 Twitter: @rebel_alx Business Intelligence through Social Media www.vieras.eu *www.linkedin.com/company/vieras * *www.facebook.com/VierasHotelMgmt * *twitter.com/VierasHotelMgmt * --001a113dd1e62e7964051a394d61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
From the default configuration i hit:
http://127.0.0.1:8888/mi/drouti= ng/dr_gw_status

On Mon, Jul 6, 2015 at 8:10 PM, Ovidiu Sas = <osas at voipemb= edded.com> wrote:
Make sur= e that you are pointing to the right url:
http://www.opensips.org/html/docs/mo= dules/devel/mi_http#id249072
http://[opensips_IP]:[opensips_mi_port]/[mi_http_root]

Regards,
Ovidiu Sas

On Mon, Jul 6, 2015 at 10:51 AM, Alex Pappas <apappas at vieras.eu> wrote:
> Dear all,
>
> I have default configuration for both the above modules, but I'm n= ot able to
> send any commands.(ofc the httpd is loaded)
>
> When I try mi_http with get I always get back :
> Response:
> <html>
> <body>
> Unable to parse URL!
> </body>
> </html>
>
> When I try mi_xmlrpc_ng I always get "Unable to parse URL!" = although I'm
> trying the example from the module documentation
>
> POST
> Content-Type text/xml
> http://127.0.0.1:8888/xmlrpc
>
> <?xml version=3D"1.0" ?>
> <methodCall>
>=C2=A0 =C2=A0 <methodName>get_statistics</methodName>
>=C2=A0 =C2=A0 <params>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <param>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <value><string>di= alog:</string></value>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </param>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <param>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <value><string>tm= :</string></value>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </param>
>=C2=A0 =C2=A0</params>
> </methodCall>
>
> Response:
> <html>
> <body>
> Unable to parse URL!
> </body>
> </html>
>
>
>
> What am I doing wrong ??
>
> thanx in advance
> Alex
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
>
http://lists.opensips.org/cgi-bin/mailm= an/listinfo/users
>



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Users mailing list
Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/li= stinfo/users



--
Alexandros = Pappas | Business Development | Vieras=C2=A0
Phone: +30 = 6937630910
Email: apappas at vieras.eu=C2=A0
Skype: alex.pappas1
Twitter: @rebel_alx
--001a113dd1e62e7964051a394d61-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: garbage in the beginning of the message, so opensips would say that it could't parse the first line. Whereas wireshark is a bit smarter to skip over it. On Sun, Jul 12, 2015 at 2:30 PM, John Nash wrote: > Hello Frank, > > I saw your message > http://lists.opensips.org/pipermail/users/2015-March/031296.html Did you > get any head or tail of this issue?..I also face the same situation where > in wireshark I see perfect messages but opensips log shows unable to parse > and shows junk characters > > John > > On Thu, Mar 26, 2015 at 7:37 PM, Bogdan-Andrei Iancu > wrote: > >> Hi, >> >> First check if opensips actually started : run "ps auxw | grep opensips" >> >> If it didn't , check the logs (messages or syslog) for errors. >> >> If you see the process, check with "netstat -lnp | grep opensips" to see >> the listening interfaces of OpenSIPS. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 25.03.2015 17:41, bluerain wrote: >> >>> I am currently running Opensips 1.9 on Debian Whizzy, but as stated on my >>> other thread, I am getting some weird error which opensips would suddenly >>> stop working. >>> >>> So, I am starting a new installation of Opensips 1.11 on Centos 6.6 using >>> the yum install method: >>> >>> 1. I was able to install yum opensips install with no issue, but there >>> are >>> some module it didn't install which I need (e.g. db_unixodbc and db_mysql >>> and httpd) >>> >>> 2. So I went ahead download the source and all the dependency files >>> needed >>> and re-complie the oepnsips to get those .so files >>> >>> 3. After some tweaking of the database table structure and some other >>> stuff, >>> I was able to get opensips 1.11 running without error (on the message.log >>> file) using my 1.9 config file. >>> >>> So I did opensipsctl restart (just to make sure opensips starts) >>> I see: >>> >>> INFO: Restarting OpenSIPS : >>> INFO: stopped >>> >>> INFO: Starting OpenSIPS : >>> INFO: Removing stale PID file /var/run/opensips.pid. >>> INFO: started (pid: 2079) >>> >>> but when I try to use a VoIP device to register to it, it doesn't >>> response. >>> thus I did: >>> "sudo netstat -plnt" >>> >>> The only think I see that opensips is listening on is port 8888 by PID >>> 2080 >>> (I don't see 2079 at all) >>> >>> So what is happening? why no error and it seems opensips running but >>> yet is >>> not listsening on port 5060? >>> >>> I have 2 nic card and eth0 is the one with public IP and the default >>> route >>> where as the eth1 is the one with private IP and no default route. Thus >>> I >>> am sure everything is route out of the eth0 (public IP). >>> >>> When I do simply the command "opensips", it would simply return: >>> >>> Listening on >>> udp: xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx]:5060 >>> Aliases: >>> *: (my FQDN):* >>> >>> So it looks like it think is listening on port 5060 but is not? >>> >>> Any help would be appreciated greatly! >>> >>> Thank you! >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-on-Centos-6-6-running-but-not-listening-tp7596152.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 >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Aron Podrigal - //Be happy :-) --001a113ff13c4ad694051ab5b81c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From what I have seen in the past, I believe that your cli= ent has some garbage in the beginning of the message, so opensips would say= that it could't parse the first line. Whereas wireshark is a bit smart= er to skip over it.

On Sun, Jul 12, 2015 at 2:30 PM, John Nash <john.nash778 at gmai= l.com> wrote:
Hello Frank,

I saw your message http://lists.opensips.org/pipermail/users/2015-March/031296.html Di= d you get any head or tail of this issue?..I also face the same situation w= here in wireshark I see perfect messages but opensips log shows unable to p= arse and shows junk characters

John

On Thu, Mar 26, 2015 = at 7:37 PM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrot= e:
Hi,

First check if opensips actually started : run "ps auxw | grep opensip= s"

If it didn't , check the logs (messages or syslog) for errors.

If you see the process, check with "netstat -lnp | grep opensips"= to see the listening interfaces of OpenSIPS.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 25.03.2015 17:41, bluerain wrote:
I am currently running Opensips 1.9 on Debian Whizzy, but as stated on my other thread, I am getting some weird error which opensips would suddenly stop working.

So, I am starting a new installation of Opensips 1.11 on Centos 6.6 using the yum install method:

1. I was able to install yum opensips install with no issue, but there are<= br> some module it didn't install which I need (e.g. db_unixodbc and db_mys= ql
and httpd)

2. So I went ahead download the source and all the dependency files needed<= br> and re-complie the oepnsips to get those .so files

3. After some tweaking of the database table structure and some other stuff= ,
I was able to get opensips 1.11 running without error (on the message.log file)=C2=A0 using my 1.9 config file.

So I did opensipsctl restart (just to make sure opensips starts)
I see:

INFO: Restarting OpenSIPS :
INFO: stopped

INFO: Starting OpenSIPS :
INFO: Removing stale PID file /var/run/opensips.pid.
INFO: started (pid: 2079)

but when I try to use a VoIP device to register to it, it doesn't respo= nse.
thus I did:
"sudo netstat -plnt"

The only think I see that opensips is listening on is port 8888 by PID 2080=
(I don't see 2079 at all)

So what is happening?=C2=A0 why no error and it seems opensips running but = yet is
not listsening on port 5060?

I have 2 nic card and eth0 is the one with public IP and the default route<= br> where as the eth1 is the one with private IP and no default route.=C2=A0 Th= us I
am sure everything is route out of the eth0 (public IP).

When I do simply the command "opensips", it would simply return:<= br>
Listening on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 udp: xxx.xxx.xxx.xxx [xxx.= xxx.xxx.xxx]:5060
Aliases:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *: (my FQDN):*

So it looks like it think is listening on port 5060 but is not?

Any help would be appreciated greatly!

Thank you!




--
View this message in context: http://opensips-open-si= p-server.1449251.n2.nabble.com/Opensips-1-11-on-Centos-6-6-running-but-not-= listening-tp7596152.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

_______________________________________________
Users mailing list
Users at lists.o= pensips.org
http://lists.opensips.org/cgi-bin/mailman/li= stinfo/users




_______________________________________________
Users mailing list
Users at lists.o= pensips.org
http://lists.opensips.org/cgi-bin/mailman/li= stinfo/users


_______________________________________________
Users mailing list
Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/li= stinfo/users




--
Aron Podrigal
-
//Be = happy :-)
--001a113ff13c4ad694051ab5b81c-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: -In the IP Auth tab, add the other sip server ip address in order to be trusted. =>Both of sip server should be allowed to talk to each other. Is it enough for linking the two sip servers? -Make a dialplan. Use a prefix, create a dialplan which regex for identifying the prefix in the sip uri and add the ip address of the other sip server. =>Let's choose 66 prefix for the Opensips 2 area. In dialing 661000 from sip client 2000, we can have something like that for the dialplan: matching regex: ^661000[0-9].* Matching flags 0 Substitution regex (66100[0-9])@.*(;.*) Replacement expression sip:\1 at 192.168.1.1 -Make a dynamic routing. Give the other sip server ip address and strip the prefix. In that case: Address: 192.168.1.1 Strip 2 PRI Prefix #66 Same thing in the opposite way on the other sip server. Someone could explain to me where i am wrong and/or maybe redirect me to a tutorial for dummies (wasn't able to find anything i understand in googling...maybe lake of good keyword....) ? Thank you in advance. Kevin --001a11c13574130889051b8f2be4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

First of all, i'm a noob in= the sip environment, network and even more in opensips so please excuse my= lack of accuracy/knowledge.
Here is my goal, in a test purpose (= yes it can be weird), i have the following installation:

SIP client (1000, registered on OpenSips 1) ------- OpenSips 1 (192.= 168.1.1) ----------- Opensips 2 (192.168.1.2) -------SIP client (2000, regi= stered on OpenSips 2)

The goal is for sip_client w= ith account 1000 to be able to call sip_client with account 2000.It should = be easy to do but i can't manage to configure it.

Each OpenSips can be managed by Opensips-cp.

From what i read, i saw the following step to do:
-In the = IP Auth tab, add the other sip server ip address in order to be trusted.
=3D>Both of sip server should be allowed to talk to each other. = Is it enough for linking the two sip servers?
-Make a dialplan. U= se a prefix, create a dialplan which regex for identifying the prefix in th= e sip uri and add the ip address of the other sip server.
=3D>= Let's choose 66 prefix for the Opensips 2 area. In dialing 661000 from = sip client 2000, we can have something like that for the dialplan: matching= regex: ^661000[0-9].* Matching flags 0 Substitution regex (66100[0-9])@.*(= ;.*) Replacement expression sip:\1 at 192.168= .1.1
-Make a dynamic routing. Give the other sip server ip ad= dress and strip the prefix.
In that case: Address: 192.168.1.1 St= rip 2 PRI Prefix #66

Same thing in the opposite wa= y on the other sip server.

Someone could explain t= o me where i am wrong and/or maybe redirect me to a tutorial for dummies (w= asn't able to find anything i understand in googling...maybe lake of go= od keyword....) ? Thank you in advance.

Kevin


--001a11c13574130889051b8f2be4-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: public IP for callee. Can you do a small test ? Re register your callee phone and within same second make a call to callee. I'm having doubts about a firewall closing the connection between the Callee UA and the OpenSIPS. On Aug 6, 2015 8:00 AM, "Nabeel" wrote: > My OpenSIPS runs on a public IP. The callee was connected to Wi-Fi in my > first test earlier, but in the second test the callee was connected to a > public IP (public mobile network). In both cases, the same '404 timeout' > error occurred on call attempt. The SIP trace for the second case is at > this link: > > http://pastebin.com/jGxRQ34q > > Regarding private IP, you said it's impossible to route from public IP to > private IP. Although at the IP level this may be true, even if the user is > on Wi-Fi, the whole point of NAT traversal is that the user's public IP is > discovered and the call can get connected, is that not right? I'm fact, > using a TURN server and a different SIP proxy, I was able to connect these > same devices under the same networks, so I know this should be possible. I > feel something is not configured correctly in OpenSIPS / rtpproxy. > > I did "opensipsctl ul show" and the results seem normal; please check it: > > http://pastebin.com/n1BbTuMK > > Perhaps the NAT processing just needs a bit more time; in thar case what > are the config options to increase the request timeout for UDP? I have > seen the 'tcp_send_timeout' and 'tcp_connect_timeout' options for TCP, but > please let me know if there are similar options for UDP. > On 6 Aug 2015 12:08, "Bogdan-Andrei Iancu" wrote: > >> Nabeel, >> >> I suppose you OpenSIPS seats on a public IP, right ? The callee looks to >> have a private IP. And, at IP level, it is impossible to route from a >> public IP to a private one. >> >> I see your script has NAT traversal support. My question is - did the >> callee properly registered via this script ? can you do an "opensipsctl ul >> show" to see the callee's registration ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 06.08.2015 07:14, Nabeel wrote: >> >> Hi, >> >> Yes, the destination IP is 192.168.0.19:60912 and both phones are >> registered to OpenSIPS. In this case, the callee is connected to Wi-Fi >> (hence 192.xx IP address) and the caller is connected to a mobile network. >> >> The opensips.cfg I am using was generated from 'make menuconfig', except >> with the addition of "alias=domain.com". I have attached my config file >> at this link: >> >> http://pastebin.com/0QRyC938 >> >> >> >> On 6 August 2015 at 05:00, SamyGo wrote: >> >>> Hi Nabeel, >>> Quick question; what is this destination ip? 192.168.0.19:60912 ? - Destination >>> User Agent Registered on OpenSIPS? >>> Can you share the opensips.cfg code snippet for this call ? >>> >>> On Wed, Aug 5, 2015 at 11:55 PM, Nabeel wrote: >>> >>>> Hi, >>>> >>>> I am using the residential script generated by 'make menuconfig', with >>>> UDP and NAT support enabled. I added "alias=domain.com" to the config >>>> because otherwise the UA did not register with my domain ( >>>> username at domain.com). When I attempt to make a call, I see '408 >>>> Request Timeout' in the sip trace and the call does not connect. Please >>>> check the log/trace below and advise how to fix this. >>>> >>>> SIP trace: >>>> >>>> http://pastebin.com/u5h9qGNr >>>> >>>> OpenSIPS log: >>>> >>>> http://pastebin.com/B8PUCKh0 >>>> >>>> _______________________________________________ >>>> 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 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 > > --001a11392244b62df2051ca45a77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Im afraid thats not how this works, regardi= ng your assumptions in last paragraph.=C2=A0

The NAT rela= ted parameters get saved in location table as OpenSIPS sets flags and upon = a call to that user those are used immediately and no timer is used as such= .=C2=A0

Now at the time of signalling rtpproxy has no rol= e to play to work NAT or anything.=C2=A0 RTPproxy will just use IP addresse= s in SDP as instructed in the script to have a media path.=C2=A0

From= the SIP trace you shared it do looks like its sending to the right public = IP for callee. Can you do a small test ? Re register your callee phone and = within same second make a call to callee. I'm having doubts about a fir= ewall closing the connection between the Callee UA and the OpenSIPS.=C2=A0<= /p>


On Aug 6, 2015 8:00 AM, "Nabeel" <<= a href=3D"mailto:nabeelshikder at gmail.com" target=3D"_blank">nabeelshikder at g= mail.com> wrote:

My OpenSIPS runs on a public IP.=C2=A0 The callee was co= nnected to Wi-Fi in my first test earlier, but in the second test the calle= e was connected to a public IP=C2=A0 (public mobile network).=C2=A0 In both= cases, the same '404 timeout' error occurred on call attempt.=C2= =A0 The SIP trace for the second case is at this link:

h= ttp://pastebin.com/jGxRQ34q

Regarding private IP, you said it's impossible to route = from public IP to private IP.=C2=A0 Although at the IP level this may be tr= ue, even if the user is on Wi-Fi, the whole point of NAT traversal is that = the user's public IP is discovered and the call can get connected, is t= hat not right?=C2=A0 I'm fact,=C2=A0 using a TURN server and a differen= t SIP proxy, I was able to connect these same devices under the same networ= ks, so I know this should be possible.=C2=A0 I feel something is not config= ured correctly in OpenSIPS / rtpproxy.

I did "opensipsctl ul show" and the results seem n= ormal; please check it:

h= ttp://pastebin.com/n1BbTuMK

Perhaps the NAT processing just needs a bit more time; in th= ar case what are the config options to increase the request timeout for UDP= ?=C2=A0 I have seen the 'tcp_send_timeout' and 'tcp_connect_tim= eout' options for TCP, but please let me know if there are similar opti= ons for UDP.

On 6 Aug 2015 12:08, "Bogdan-Andrei Iancu&q= uot; <bogdan at op= ensips.org> wrote:
=20 =20 =20
Nabeel,

I suppose you OpenSIPS seats on a public IP, right ? The callee looks to have a private IP. And, at IP level, it is impossible to route from a public IP to a private one.

I see your script has NAT traversal support. My question is - did the callee properly registered via this script ? can you do an "opensipsctl ul show" to see the callee's registration = ?

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.=
opensips-solutions.com
On 06.08.2015 07:14, Nabeel wrote:
Hi,

Yes, the destination IP is=C2=A0=C2=A0192.168.0.19:60912=C2=A0and both phones are registered to OpenSIPS.=C2=A0 In this case, the callee is connected to Wi-Fi (hence 192.xx IP address) and the caller is connected to a mobile network.

The opensips.cfg I am using was generated from 'make menuconfig', except= with the addition of "alias=3Ddomain.com". I have attached my config file at this link:




On 6 August 2015 at 05:00, SamyGo <gov= oiper at gmail.com> wrote:

Hi,

I am using the residential script generated by 'make menuconfig', with UDP and NAT su= pport enabled.=C2=A0 I added "alias=3Ddomain.com" to the config because otherwise the UA did not register with my domain (username at domain.com).=C2=A0When I attempt to make a call, I see '408 Request Timeout' in the sip trace and the call does not connect.=C2=A0 Please check the log/trace bel= ow and advise how to fix this.

SIP trace:

http://pastebin.com/u5h9qGNr

OpenSIPS log:=C2=A0


_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/= cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
U= sers at lists.opensips.org
http://lists.opensips.org/cgi-bi= n/mailman/listinfo/users




_______________________________________________
Users mailing list
Users at lists.o=
pensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
Users at lists.o= pensips.org
http://lists.opensips.org/cgi-bin/mailman/li= stinfo/users

--001a11392244b62df2051ca45a77-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: Service Type -> Sip-Session"...8295nX{S...FB.E&..#00923226363266 at testsip.vo= pium.com...00923226363266....testsip.vopium.com.4.255df06ae0000004eba572941= 9c1a1631fc466a68c4f151a5.=2C.*sip:923009682285 at testsip.vopium.com:6000...IN= VITE....auth...00000001...0a4f113b."796e09966708557df1dcf203c085f01a.......= .00923226363266=2C.727916929..........d....J.#.<..!X.wo.=2C.0S.language:en.= )rpid:sip:+923226363266@{****}.vopium.com"=20 Service Type -> Call-Check"...RS..........?.O...!923009682285 at testsip.vopiu= m.com.....=2C.727916929..........d......}F..q. Call-Check does not have Dige= st AVPs =0A= =0A= =0A= =0A= =0A= Hi Hamid=2C =0A= =20 =0A= I assume the perl script you mentioned in on the RADIUS server=0A= side=2C right ? =0A= =20 =0A= Have you checked if the RADIUS request you are processing actually=0A= contains those AVPS (Digest-URI and Digest-Realm) ? Use ngrep or=0A= tcpdump to get a network capture and visualize it with wireshark=0A= or similar. =0A= =20 =0A= Best Regards=2C =0A= =0A= Bogdan-Andrei Iancu=0A= OpenSIPS Founder and Developer=0A= http://www.opensips-solutions.com=0A= On 26.08.2015 18:06=2C Hamid Hashmi=0A= wrote: =0A= =0A= =0A= =0A= =0A= I am unable to use=0A= '$RAD_REQUEST{'Digest-URI'}=2C $RAD_REQUEST{'Digest-Realm'}=0A= etc=2C in my perl script in case=0A= of service type equals to=0A= 'Call-Check else cases are working fine like 'Sip-Sessions'=0A= etc. details are as follows.=0A= =20 =0A= =0A= $ opensips -V=0A= version: opensips=0A= 1.9.0-notls (x86_64/linux)=0A= flags: STATS: Off=2C=0A= USE_IPV6=2C USE_TCP=2C DISABLE_NAGLE=2C USE_MCAST=2C SHM_MEM=2C= =0A= SHM_MMAP=2C PKG_MALLOC=2C F_MALLOC=2C FAST_LOCK-ADAPTIVE_WAIT= =0A= ADAPTIVE_WAIT_LOOPS=3D1024=2C=0A= MAX_RECV_BUFFER_SIZE 262144=2C MAX_LISTEN 16=2C MAX_URI_SIZE=0A= 1024=2C BUF_SIZE 65535=0A= poll method support:=0A= poll=2C epoll_lt=2C epoll_et=2C sigio_rt=2C select.=0A= svnrevision: unknown=0A= @(#) $Id: main.c 9790=0A= 2013-02-15 10:14:34Z bogdan_iancu $=0A= main.c compiled on=0A= 06:43:47 Aug 25 2015 with gcc 4.9.2=0A= =20 =0A= =0A= $ radiusd -Xxx=0A= for logs click=0A= here=0A= =20 =0A= =0A= $ radiusd -v=0A= =0A= radiusd: FreeRADIUS=0A= Version 2.2.0=2C for host x86_64-unknown-linux-gnu=2C built o= n=0A= Aug 25 2015 at 07:43:23=0A= Copyright (C)=0A= 1999-2011 The FreeRADIUS server project and contributors.=0A= There is NO=0A= warranty=3B not even for MERCHANTABILITY or FITNESS FOR A=0A= PARTICULAR PURPOSE.=0A= You may redistribute=0A= copies of FreeRADIUS under the terms of the=0A= GNU General Public=0A= License.=0A= For more information=0A= about these matters=2C see the file named COPYRIGHT.=0A= =0A= =20 =0A= =0A= =0A= $ cat=0A= /etc/radiusclient-ng/dictionary.sip=0A= #=0A= # $Id:=0A= dictionary.opensips 7139 2010-08-17 14:06:00Z=0A= razvancrainea $=0A= #=0A= # SIP RADIUS=0A= attributes=0A= #=0A= # Proprietary=0A= indicates an attribute that hasn't=0A= # been standardized=0A= #=0A= #=0A= # NOTE: All standard=0A= (IANA registered) attributes are =0A= # defined in=0A= the default dictionary of the =0A= # =0A= radiusclient-ng library.=0A= #=0A= =20 =0A= =0A= =20 =0A= =0A= #### Attributes ###=0A= ATTRIBUTE=0A= Sip-Uri-User 208 string # Proprietary=2C=0A= auth_radius=0A= ATTRIBUTE Sip-Group=0A= 211 string # Proprietary=2C group_radius=0A= ATTRIBUTE Sip-Rpid =0A= 213 string # Proprietary=2C auth_radius=0A= ATTRIBUTE SIP-AVP =0A= 225 string # Proprietary=2C avp_radius=0A= ATTRIBUTE=0A= Sip-Call-Duration 227 integer=0A= ATTRIBUTE=0A= Sip-Call-Setuptime 228 integer=0A= =20 =0A= =0A= ### Service-Type=0A= Values ###=0A= VALUE Service-Type =0A= Call-Check 10 # Proprietary=2C group_radius=0A= VALUE Service-Type =0A= Group-Check 12 # Proprietary=2C group_radius=0A= VALUE Service-Type =0A= Sip-Session 15 # Proprietary=2C group_radius=0A= VALUE Service-Type =0A= SIP-Caller-AVPs 30 # Proprietary=2C avp_radius=0A= VALUE Service-Type =0A= SIP-Callee-AVPs 31 # Proprietary=2C avp_radius=0A= =20 =0A= =0A= ### Sip-Method=0A= Values ###=0A= VALUE Sip-Method =0A= Undefined 0=0A= VALUE Sip-Method =0A= Invite 1=0A= VALUE Sip-Method =0A= Cancel 2=0A= VALUE Sip-Method =0A= Ack 4=0A= VALUE Sip-Method =0A= Bye 8=0A= VALUE Sip-Method =0A= Info 16=0A= VALUE Sip-Method =0A= Options 32=0A= VALUE Sip-Method =0A= Update 64=0A= VALUE Sip-Method =0A= Register 128=0A= VALUE Sip-Method =0A= Message 256=0A= VALUE Sip-Method =0A= Subscribe 512=0A= VALUE Sip-Method =0A= Notify 1024=0A= VALUE Sip-Method =0A= Prack 2048=0A= VALUE Sip-Method =0A= Refer 4096=0A= VALUE Sip-Method =0A= Other 8192=0A= =20 =0A= =0A= =20 =0A= =0A= ### Lines Added=0A= ATTRIBUTE Sip-Method=0A= 101 integer=0A= ATTRIBUTE=0A= Sip-Response-Code 102 integer #=0A= Schulzrinne=2C acc=0A= ATTRIBUTE Sip-To-Tag=0A= 104 string # Schulzrinne=2C acc=0A= ATTRIBUTE=0A= Sip-From-Tag 105 string #=0A= Schulzrinne=2C acc=0A= ATTRIBUTE=0A= Sip-Translated-Request-URI 107 string #=0A= Proprietary=2C acc=0A= ATTRIBUTE Source-IP=0A= 214 string=0A= ATTRIBUTE=0A= Source-Port 215 string=0A= ATTRIBUTE Sip-Src-IP=0A= 108 string # Proprietary=2C acc=0A= ATTRIBUTE=0A= Sip-Src-Port 109 string #=0A= Proprietary=2C acc=0A= ATTRIBUTE=0A= Digest-Response 206 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE=0A= Sip-Uri-User 208 string #=0A= Proprietary=2C auth_radius=0A= ATTRIBUTE Sip-Group=0A= 211 string # Proprietary=2C=0A= group_radius=0A= ATTRIBUTE Sip-Rpid =0A= 213 string # Proprietary=2C=0A= auth_radius=0A= ATTRIBUTE SIP-AVP =0A= 225 string # Proprietary=2C=0A= avp_radius=0A= ATTRIBUTE=0A= Digest-Realm 1063 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE=0A= Digest-Nonce 1064 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE=0A= Digest-Method 1065 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE Digest-URI=0A= 1066 string # Sterman=2C auth_radius= =0A= ATTRIBUTE Digest-QOP=0A= 1067 string # Sterman=2C auth_radius= =0A= ATTRIBUTE=0A= Digest-Algorithm 1068 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE=0A= Digest-Body-Digest 1069 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE=0A= Digest-CNonce 1070 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE=0A= Digest-Nonce-Count 1071 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE=0A= Digest-User-Name 1072 string # Sterman=2C=0A= auth_radius=0A= ATTRIBUTE Contact =0A= 1073 integer=0A= =20 =0A= =0A= ###=0A= =0A= =20 =0A= =0A= =20 =0A= =0A= Regards=0A= Hamid R. Hashmi=0A= =0A= =20 =0A= =0A= =20 =0A= _______________________________________________=0A= Users mailing list=0A= Users at lists.opensips.org=0A= http://lists.opensips.org/cgi-bin/mailman/listinfo/users=0A= =0A= =0A= =20 =0A= =0A= =0A= _______________________________________________=0A= Users mailing list=0A= Users at lists.opensips.org=0A= http://lists.opensips.org/cgi-bin/mailman/listinfo/users = --_f21484e4-6516-4760-8519-a87db7c1109c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bogdan

=
Yes I am talking about perl script for RADIUS server. I have already c= hecked in traces.

From #: 00923226363266
To #: 92309682285

Service Type ->=3B Sip-Sessio= n
"...8295nX{S...FB.E&=3B..#00923226363266 at testsip.vopium.c= om..
.0092= 3226363266....testsip.vopium.com.4.255df06ae0000004eba5729419c1a1631fc466a6= 8c4f151a5.=2C.*sip:923009682285 at testsip.vopium.com:6000.
<= font face=3D"Courier New=2C sans-serif">..INVITE....auth...
00000001...
0a4f113b."796e09966708557df1dcf203c08= 5f01a........00923226363266=2C.727916929..........d....J.#.<=3B..!X.wo.= =2C.0S.
language:= en.)rpid:sip:+923226363266@{****}.vopium.com" =3B

Service Type ->=3B Call-Check
"...RS..........?.O...!923009682285 at testsip.vopiu= m.com.....
=2C.72= 7916929..........d......}F..q.<=3BQ..|D..."

------------------------------------------------------------------------= -
I am writing you this email and figured out my mistake (I was s= ending wrong realm in AVP: rpid ). Thank you for helping. =3B

Regards
Hamid R. Hashmi


Date: Thu=2C 27 Aug 2015 14:10:09 +0300
From: bogdan at opensi= ps.org
To: users at lists.opensips.org=3B freeradius-users at lists.freeradius= .org
Subject: Re: [OpenSIPS-Users] Service-Type ->=3B Call-Check does = not have Digest AVPs

=0A= =0A= =0A= =0A= =0A= Hi Hamid=2C
=0A=
=0A= I assume the perl script you mentioned in on the RADIUS server=0A= side=2C right ?
=0A=
=0A= Have you checked if the RADIUS request you are processing actually=0A= contains those AVPS (Digest-URI and Digest-Realm) ? Use ngrep or=0A= tcpdump to get a network capture and visualize it with wireshark=0A= or similar.
=0A=
=0A= Best Regards=2C
=0A=
=0A=
Bogdan-Andrei Iancu=0A=
OpenSIPS Founder and Developer=0A=
http://www.opensips-solutions.com
=0A=
On 26.08.2015 18:06=2C Hamid Hashmi= =0A= wrote:
=0A=
=0A=
= =0A= =0A=
=0A=
I am unable to use=0A=  =3B'$RAD_REQUEST{'Digest-URI'}=2C =3B$RAD_REQUEST{'Diges= t-Realm'}=0A= etc=2C =3Bin my perl script= in case=0A= of service type =3Bequals =3Bto=0A= 'Call-Check else cases are working fine like 'Sip-Sessions'=0A= etc. details are as follows.
=0A=

=0A=
=0A=
$ opensips -V<= /div>=0A=
version: opensips=0A= 1.9.0-notls (x86_64/linux)
=0A=
flags: STATS: Off=2C= =0A= USE_IPV6=2C USE_TCP=2C DISABLE_NAGLE=2C USE_MCAST=2C SHM_MEM=2C= =0A= SHM_MMAP=2C PKG_MALLOC=2C F_MALLOC=2C FAST_LOCK-ADAPTIVE_WAIT
=0A=
ADAPTIVE_WAIT_LOOPS= =3D1024=2C=0A= MAX_RECV_BUFFER_SIZE 262144=2C MAX_LISTEN 16=2C MAX_URI_SIZE=0A= 1024=2C BUF_SIZE 65535
=0A=
poll method support:= =0A= poll=2C epoll_lt=2C epoll_et=2C sigio_rt=2C select.=0A=
svnrevision: unknown<= /font>
=0A=
@(#) $Id: main.c 9790= =0A= 2013-02-15 10:14:34Z bogdan_iancu $
=0A=
main.c compiled on=0A= 06:43:47 Aug 25 2015 with gcc 4.9.2
=0A=

=0A=
=0A=
$ radiusd -Xxx=
=0A= =0A=

=0A=
=0A=
$ radiusd -v=0A=
=0A=
radiusd: FreeRADIUS= =0A= Version 2.2.0=2C for host x86_64-unknown-linux-gnu=2C built o= n=0A= Aug 25 2015 at 07:43:23
=0A=
Copyright (C)=0A= 1999-2011 The FreeRADIUS server project and contributors.
=0A=
There is NO=0A= warranty=3B not even for MERCHANTABILITY or FITNESS FOR A
=0A=
PARTICULAR PURPOSE.=
=0A=
You may redistribut= e=0A= copies of FreeRADIUS under the terms of the
=0A=
GNU General Public= =0A= License.
=0A=
For more informatio= n=0A= about these matters=2C see the file named COPYRIGHT.=0A=
=0A=

=0A=
=0A=
=0A=
$ cat=0A= /etc/radiusclient-ng/dictionary.sip
=0A=
#
=0A=
# $Id:=0A= dictionary.opensips 7139 2010-08-17 14:06:00Z=0A= razvancrainea $
=0A=
#
=0A=
# SIP RADIUS=0A= attributes
=0A=
#
=0A=
# Proprietary=0A= indicates an attribute that hasn't
=0A=
# been standardized=
=0A=
#
=0A=
#
=0A=
# NOTE: All standar= d=0A= (IANA registered) attributes are =3B
=0A=
#  =3B  =3B=  =3B defined in=0A= the default dictionary of the =3B
=0A=
#  =3B  =3B=  =3B=0A= radiusclient-ng library.
=0A=
#
=0A=

=0A=
=0A=

=0A=
=0A=
#### Attributes ###=
=0A=
ATTRIBUTE=0A= Sip-Uri-User  =3B  =3B  =3B  =3B 208  =3B= string  =3B  =3B # Proprietary=2C=0A= auth_radius
=0A=
ATTRIBUTE Sip-Group= =0A=  =3B  =3B  =3B  =3B  =3B  =3B211 &nbs= p=3Bstring  =3B  =3B # Proprietary=2C group_radius
=0A=
ATTRIBUTE Sip-Rpid =  =3B=0A=  =3B  =3B  =3B  =3B  =3B 213  =3Bstri= ng  =3B  =3B # Proprietary=2C auth_radius
=0A=
ATTRIBUTE SIP-AVP &= nbsp=3B=0A=  =3B  =3B  =3B  =3B  =3B  =3B225 &nbs= p=3Bstring  =3B  =3B # Proprietary=2C avp_radius
=0A=
ATTRIBUTE=0A= Sip-Call-Duration  =3B  =3B227  =3Binteger=
=0A=
ATTRIBUTE=0A= Sip-Call-Setuptime  =3B 228  =3Binteger
= =0A=

=0A=
=0A=
### Service-Type=0A= Values ###
=0A=
VALUE Service-Type =  =3B=0A=  =3B  =3B Call-Check  =3B  =3B  =3B 10 &n= bsp=3B # Proprietary=2C group_radius
=0A=
VALUE Service-Type =  =3B=0A=  =3B  =3B Group-Check  =3B  =3B  =3B12 &n= bsp=3B # Proprietary=2C group_radius
=0A=
VALUE Service-Type =  =3B=0A=  =3B  =3B Sip-Session  =3B  =3B  =3B15 &n= bsp=3B # Proprietary=2C group_radius
=0A=
VALUE Service-Type =  =3B=0A=  =3B  =3B SIP-Caller-AVPs  =3B30  =3B # Propr= ietary=2C avp_radius
=0A=
VALUE Service-Type =  =3B=0A=  =3B  =3B SIP-Callee-AVPs  =3B31  =3B # Propr= ietary=2C avp_radius
=0A=

=0A=
=0A=
### Sip-Method=0A= Values ###
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Undefined  =3B  =3B  =3B0
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Invite  =3B  =3B  =3B  =3B = 1
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Cancel  =3B  =3B  =3B  =3B = 2
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Ack  =3B  =3B  =3B  =3B &nb= sp=3B  =3B4
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Bye  =3B  =3B  =3B  =3B &nb= sp=3B  =3B8
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Info  =3B  =3B  =3B  =3B &n= bsp=3B 16
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Options  =3B  =3B  =3B  =3B= 32
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Update  =3B  =3B  =3B  =3B = 64
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Register  =3B  =3B  =3B 128
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Message  =3B  =3B  =3B  =3B= 256
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Subscribe  =3B  =3B  =3B512
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Notify  =3B  =3B  =3B  =3B = 1024
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Prack  =3B  =3B  =3B  =3B &= nbsp=3B2048
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Refer  =3B  =3B  =3B  =3B &= nbsp=3B4096
=0A=
VALUE Sip-Method &n= bsp=3B  =3B=0A=  =3B  =3B Other  =3B  =3B  =3B  =3B &= nbsp=3B8192
=0A=

=0A=
=0A=

=0A=
=0A=
### Lines Added
=0A=
ATTRIBUTE Sip-Metho= d=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B101  =3Binteger
=0A=
ATTRIBUTE=0A= Sip-Response-Code  =3B  =3B  =3B  =3B  = =3B  =3B 102  =3Binteger  =3B  =3B#=0A= Schulzrinne=2C acc
=0A=
ATTRIBUTE Sip-To-Ta= g=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B104  =3Bstring  =3B  =3B # Schulz= rinne=2C acc
=0A=
ATTRIBUTE=0A= Sip-From-Tag  =3B  =3B  =3B  =3B  =3B &nb= sp=3B  =3B  =3B  =3B105  =3Bstring  =3B  =3B #=0A= Schulzrinne=2C acc
=0A=
ATTRIBUTE=0A= Sip-Translated-Request-URI  =3B  =3B107  =3Bstrin= g  =3B  =3B #=0A= Proprietary=2C acc
=0A=
ATTRIBUTE Source-IP= =0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B 214  =3Bstring
=0A=
ATTRIBUTE=0A= Source-Port  =3B  =3B  =3B  =3B  =3B &nbs= p=3B  =3B  =3B  =3B 215  =3Bstring
=0A=
ATTRIBUTE Sip-Src-I= P=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B108  =3Bstring  =3B  =3B # Propri= etary=2C acc
=0A=
ATTRIBUTE=0A= Sip-Src-Port  =3B  =3B  =3B  =3B  =3B &nb= sp=3B  =3B  =3B  =3B109  =3Bstring  =3B  =3B #=0A= Proprietary=2C acc
=0A=
ATTRIBUTE=0A= Digest-Response  =3B  =3B  =3B  =3B  =3B =  =3B  =3B 206  =3Bstring  =3B  =3B # Sterman=2C=0A= auth_radius
=0A=
ATTRIBUTE=0A= Sip-Uri-User  =3B  =3B  =3B  =3B  =3B &nb= sp=3B  =3B  =3B  =3B208  =3Bstring  =3B  =3B #=0A= Proprietary=2C auth_radius
=0A=
ATTRIBUTE Sip-Group= =0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B 211  =3Bstring  =3B  =3B # Propr= ietary=2C=0A= group_radius
=0A=
ATTRIBUTE Sip-Rpid =  =3B=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B213  =3Bstring  =3B  =3B # Propri= etary=2C=0A= auth_radius
=0A=
ATTRIBUTE SIP-AVP &= nbsp=3B=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B 225  =3Bstring  =3B  =3B # Propr= ietary=2C=0A= avp_radius
=0A=
ATTRIBUTE=0A= Digest-Realm  =3B  =3B  =3B  =3B  =3B &nb= sp=3B  =3B  =3B  =3B1063  =3Bstring  =3B  =3B# Ster= man=2C=0A= auth_radius
=0A=
ATTRIBUTE=0A= Digest-Nonce  =3B  =3B  =3B  =3B  =3B &nb= sp=3B  =3B  =3B  =3B1064  =3Bstring  =3B  =3B# Ster= man=2C=0A= auth_radius
=0A=
ATTRIBUTE=0A= Digest-Method  =3B  =3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B 1065  =3Bstring  =3B  =3B# Sterman=2C= =0A= auth_radius
=0A=
ATTRIBUTE Digest-UR= I=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B1066  =3Bstring  =3B  =3B# Sterma= n=2C auth_radius
=0A=
ATTRIBUTE Digest-QO= P=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B1067  =3Bstring  =3B  =3B# Sterma= n=2C auth_radius
=0A=
ATTRIBUTE=0A= Digest-Algorithm  =3B  =3B  =3B  =3B  =3B=  =3B  =3B1068  =3Bstring  =3B  =3B# Sterman=2C=0A= auth_radius
=0A=
ATTRIBUTE=0A= Digest-Body-Digest  =3B  =3B  =3B  =3B  = =3B  =3B1069  =3Bstring  =3B  =3B# Sterman=2C=0A= auth_radius
=0A=
ATTRIBUTE=0A= Digest-CNonce  =3B  =3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B 1070  =3Bstring  =3B  =3B# Sterman=2C= =0A= auth_radius
=0A=
ATTRIBUTE=0A= Digest-Nonce-Count  =3B  =3B  =3B  =3B  = =3B  =3B1071  =3Bstring  =3B  =3B# Sterman=2C=0A= auth_radius
=0A=
ATTRIBUTE=0A= Digest-User-Name  =3B  =3B  =3B  =3B  =3B=  =3B  =3B1072  =3Bstring  =3B  =3B# Sterman=2C=0A= auth_radius
=0A=
ATTRIBUTE Contact &= nbsp=3B=0A=  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B 1073  =3Binteger
=0A=

=0A=
=0A=
###
=0A=
=0A=

=0A=
=0A=

=0A=
=0A=
Regards
=0A=
Hamid R. Hashmi
=0A=
=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
Users mailing list=0A=
Users at lists.opensips.org=0A=
http://lists.opensips.org/cg=
i-bin/mailman/listinfo/users=0A=
=0A=
=0A=
=0A= =0A= =0A=
_______________________________________________=0A= Users mailing list=0A= Users at lists.opensips.org=0A= http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<= /div> = --_f21484e4-6516-4760-8519-a87db7c1109c_-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: ssible to have all the tls version support (1.0, 1.1 and 1.2) within the sa= me instance of opensips ? * TLSv1_2 - means OpenSIPS will accept only TLSv1.2 connections (rfc= 3261 conformant). * TLSv1 - means OpenSIPS will accept only TLSv1 connections (rfc3261= conformant). Thanks Rahul Gupta ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------------ DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. --_000_5D7DF326E497124DACCD6F9DD6A1A2A089CE766ENWKNJEXMBX1corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, I am using opensips-1.11.5-tls and trying to fig= ure out which TLS versions are supported

 

From the documentation I see that either 1.0 or 1.2 = are supported. Is it possible to have all the tls version support (1.0, 1.1= and 1.2) within the same instance of opensips ?

·        TLSv1_2=  = - means OpenSIPS will accept only TLSv1.2 connections (rfc3261 conformant).<= o:p>

·        TLSv1 - means OpenSIPS will accept only TLSv1 connections (rfc3261 conformant).

Thanks

Rahul Gupta

-----------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------------------------------------

DISCLAIMER: This e-mai= l may contain information that is confidential, privileged or otherwise pro= tected from disclosure. If you are not an intended recipient of this e-mail= , do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender t= hat you have received it in error. Unintended recipients are prohibited fro= m taking action on the basis of information in this e-mail.E-mail messages = may contain computer viruses or other defects, may not be accurately replicated on other systems, or may b= e intercepted, deleted or interfered with without the knowledge of the send= er or the intended recipient. If you are not comfortable with the risks ass= ociated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the rig= ht, to the extent and under circumstances permitted by applicable law, to r= etain, monitor and intercept e-mail messages to and from its systems.

--_000_5D7DF326E497124DACCD6F9DD6A1A2A089CE766ENWKNJEXMBX1corp_-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: process starts but after few seconds (10") it goes down. In log we can see some access to database (Postgres), but after some queries it refuses new queries execution. An error message appears in log saying there's no authorization line in pg_hba.conf: Sep 15 12:03:27 server01 opensips[17471]: ERROR:db_postgres:db_postgres_new_connection: SSL error: called a function you should not call#012FATAL: no hay una l?nea en pg_hba.conf para <<192.168.1.119>>, usuario <>, base de datos <>, SSL inactivo#012 And it's true, theres no SSL-inactive auth line, but it is for SSL (ip, username and password have been double checked). In attached log file completed queries can be seen. This issue happened in two different environments after a system update (apt-get update && apt-get upgrade) and a service restart (service opensips restart). Before each upgrade a disk snapshot is taken but a restore from these snapshots (opensips and postgres) doesn't fix the issue. Queries executed [with psql] from console in OpenSIPS machine run ok. Adding no-ssl auth into pg_hba.conf OpenSIPS starts ok. --------------000300060105010104090305 Content-Type: application/x-compressed-tar; name="opensips.log.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="opensips.log.tgz" H4sIAGpf+lUAA+w9a1PbyJbzeX9F534JqWVAsvwA1+TuMsAk1CWQAbJTdVNTqrbUxrrRa/Qg MJUfv+d0S7YsG2yJliyEM1WDLVnn1adPn1e3PJ+5oeWHe7Z3+1NF/xT41+938a866KnZv4oy 6Gn9gfaT2ukN+t3eoKfA79TuQBv8RJSqCMr+i8OIBoT8ZI2YTR3mmhZd+rtV91/ov2vmE7VH 1M5Q0YadPglZcMcCRSVeohhDcvLrh6HhBWz48ODTIGRDYnvUtNxb4nhmbDOyH4fBvm2N9tNn 9sWNcN8c6b4XRrcBC/dC77+qRRZaty614afVo4rYfeT5dfBk18CMUxRHwG6tMGKBLkAMyfSC fzckkVMImH+nU9PUQaIBHRL+h1gRc0JiA0xihcT14I9rRRaM7t/MLAQ9ZBFSqYNQqKMDnewe KSQOjYwJC1PpFKR5KdSxF7sm+WUc6JHlsOCfQPMMPPn6+AD8uQ7uP46uLs4uPgwjZ6jriD/F MyT/SD/+Q0jrOzGZHzCDRsx8Q76EbPoLL47gNy4MFTXfNF+OlntXmyynuIQ8p1+flGn6q5ck V7DFsOJxnj1XZ9SYwA98+0GyjDfIoedyhnR65+NvWFWcFTe1QSDX1AbB84UWBPmhkAE1GQrq w+9N0DXPiehtdiAA7QYHwqH34+9mHT6J74S3tbgKjqWPrbFXFNHS0Utg5RUjuSzPxAMw3QWv OqsYKe5qDVCdHOZtkHQOiytLHFhSFAXg5EUIl6SJLw6ZDvD0iI7sOREi3k2KLwxsz5AjQQ5q QYj8qjQ5ujTSR2N73gInmKudZ7WwB2Fmfo61hzmcA6bnUMutkr8Svgx3RAJa2KVZ7oWk0Bac kfSGNIFGhq/7LAjRjXLBD85Nixkl1SpPjRybbExjO4IY27fA/W85t47lvhZO6f0r4tTw3Iga UdWsFreENI4m1fv3Yg2QYmwFqPyoiatVLsoJ3g0OlW1SX4oIEVBegHhNmvhA28fWLQQK844v x7tBAZoWtb3CGfansxgCpgS15nAW1FoS9FSt7VudY1jUboG+WptbD4+Jv5CkNlvK5BL7JJm5 EkuJISeqBDh58cElabJjNLAfdIeBwLLyQ6zVakbFfAXM94JIN6hrMDtsFWsmi5gR6SY4i0Zk eW6rmBtTWCZNHRxBN6ScvYWw7sXzCPaqjTw5VhjC0LWONcMMqmWqRIUA7bUfePcPcooEU3AL WfTpHXkB4BSkHnrGNzbnlGQoqbhqsCGWlzhi7eR52sOjWz7Wb9vPMQcJ12z68DoYtgyGDpZp mTRiVbNbwgO/80uUa5evMBzUwiLDr8qrsN/5i+WxBHPFC2gd7C2vfrSHP/CA4sDe8lbX9PYD FjKI7qrP16aY9HunhibOe0NSYjMlO68b6XV5Sz1/Dns/AfJcrD0lodo5kB2gx7jFe/KiVC8A iBif3rFl/HJC6uG58tEdU9seUeNbxxxtcGgrZzNTgdP9eGRb4eS1sBvGo9AIrNFSVW4Lw7iE +eioYseA5Zlt5tWwGXVr4bPEHgU7LOGVr9inwGFW3yXD7mvpM40CWtytWaoPKbC8xqXX5XXi IDR9Phc9RV7trKqNR+ZicAar/jedA24zrxyaqUPMFuRzGfJZLZH/DC1bUn80QlrIleBFeXG9 aeoLGRKOtuJcUPWs4W6AZX5/S9jDPiVsLIwefKZPzKCFLAofkKelW8gderkO6Ca9ZVXqZ3ED ZjlyugMATl6CcKnKzgrEWK1eVMzThIYTPbT+bhdXXhyN8JPO0+6VsVZc0z0fi/g17Jpi90zO nEJA+aHCa/IcgvDBNbJDxDFucIyM8W0cWbbkqCyFKmVv0g+xTeIHNYwfoorwQ/R4/UiD2h+Y OP2Reqc/uIn/Ub19zOXFqzckUoUhd7ldFEcdfoRUgUiPpBZlUlOsKFUs+LMKRYLgX5I4KslO zoukppykVLFIbijLlxwrbySTKgz5Tc45edTSwC1XJNL3peRFInlbSvUikb9/NieSerbPShWJ xG3nS+Qhc7/52IKIy3DwzCPebh7NMg9jjMQMFoa6OKFCnzBqsuCfO+q7rH/E79VBUGjrIR7g IU6I2elkqQglFqvxGB4aGBNxZgv1MQzxvmEYMvYC8lUUCizzT+wgIeTnhLyf1UJIXPadw6e2 ReE6NU1mEv6FpAjIdyuaEPhbDPITArT8JO+/o7yr1J17nAYLtIlFE8/MqVGYHk7SJk16Ugw+ gygTHrXGFjNzIyLKga9mPBpBREPMi8GCqDLTgsCnZqVTCKp/pyOdsa+HPjP4STmp6EBO4qg8 fkjeV1BeodxhPPoPMyJZA4Q8YaNHlBsc2Y185TnVDVeqLggvpDJtSHzNVB+0lzebaxyqzRuO Rki8EUTAsPMEMVY0k0GPQ5w18J1gqZPsDN6lZyASb0x+ORbnNfzz5WlXXVbvcQpwm39ip3JD K/cAgCbPsM1TwEcB4tDYjiodhVXuCd+OHIXVuSgJgumy1G3NEDbCTE9oqEceHoA5H3LUlFVg 7i29ZWK7flLpnaejip1XDR+SRhCxtfJNoKAuK7/Vg8ZPyGipAGSeGd1M3BteoMDbgcAi8OIo nyaVeUr0+qHFyfkHPYxoFIeyOLwDR4tvIxHVjRyXsmtyDZ9lTSGC9yHbnkHt/HhILgg2XBQQ Ok+Y2J/ghvmseG22z6Z5t7T9uBsx/Nu1fzsLGsB9I5Rg64k3gYKGRGQbpcA3AiYOGs0NAW9V qUUPHlWC9JCmV2MWts7ilogNRa0NF8LmF4tGiCFg8APztStDI4jAGpc50v+KWQAKqW2mflsj ESuKh+nmKlZd8+QMxbSA2JNlXugdW/R/ZL/yoRHj+HTjIu+GjvTJ+JVMrbJaXUzx1mhqUXvz XS3p+1ZakPWHtVu8KJMFgRfkG5RrWbwbMb+Sl1RGXjoWbS5AbV7lGzHmW7818VtTO5qjotZV NrQZ83MEpPvAa4rkvsX+Jv2MRihDpIOThwngjWW/N7USNkT8+NoKatlxwHJ01Fx/qAz3Sq8u MjyTVRiocPjTKKVfPfHFUDRcQ5uREd6smWqA09wIXWiEFzehrmmz6cm784Mh/yyEhg9JIo3Z wbybk8fm3evNU2A5BiwTLr1leTMh9bif1W7t5hx7PKJKhwmQo0HuyVVPbKfXw8hbcKYkny7U TI+2AcvUq2f/lbspzYlnNiP/TS8/9VYNVu5hs23dZGFkuZS/n1EcbFLhlral+Kah36A1W0U3 vMY2Ig5oUAa/QaQkh6imhMxZweRebfMfiGT3lc12Dn06tw9kEu5Ul45yZpmow6plXa1MipG/ 0piYzGZRvu5fe/NGEjtsiIhN10QSIeBpwBXLoO3avNml0dHN2PHzG77rCoGbMaEj/TsNk7e6 24sHf8mtrq+5x/Amic94zUCuOvM3F+hJ1b7C1WsOz+zkPOXlTZ+aDrdprBP/ihNl1eMW7yvv hFEwJL/Epj9UDzt7av9gT91T1cNhT+krxdRoDmBkyAZoh4sA1bUAnl38dplAnDi6wxzdci0Q NcTingFhOEyo64+fyAi+fSs2fACNA0kA/qZffr45+3T279P3al876O6S/avLLxcnN5fvO0q3 mHewCPvj0fVH/RqBd5TDw10Cv+AkE3z/x3tN6z8TAz9yNiQ7yv1gbB5oWq/XURRll3SVTr+n qQfdd7skjGgQvZ//RbExzYxAgh5uh7GBp8sWgsQh4HZ4WEI9WD8NMBVDJDCChcwy8C3CvMiR Ah/Htv1A8CkLVoq/mVlMdTg61OrEBDMfkOp2RPCY1gkjN8efieWR77g1ioiiG9mhceQRE3wM I2Lmu+LsodIT5vJOqHWe/uPo6uLsYgGCaYV0xOvghudg9i2EIJuYMSP/Pj/7lfiBN7KZU0b8 oZ0UGIvRmRerHSZv04Z7n8VJw0jtzfn1dB+Tssf/GyrFrNyUTCO610dsQu8sVBPXIycfU40f W2Ba0UkBOjJ4YODAPjNzNxlx+EpjGPC3Oy6o0ru369BxcXlzdnz6JCkXHjk9JkYMz6YYJUE2 LH8C+s8du5BFBHTx6Px8+Obo5OPwvz+effg4fPPp9OTsy6fhm/PLP4ZvLr6cn5fTsiW4bQv0 gdzxQ20Nnusk/BXDFGbCHjkWt/EQUnEfPDUa4BHSrklhIj/sFRplDAf1DLBCyvgElLf7LDJm Cy3ox34KYI/dU8e32R5MqT0jiN5m7MwDf1tNKex0SE5Lkw4PHx8tI9qgez5zypK4oGpz8xWm EiAtMH04ef43a//4aH+tSZTnUjet4FliEgCmokppWSIegvsrwX4GfHl5KI7MD7jK69/YwzOU cg4K/G9txYTflh31rY1uu40Wjz1mo7cGeGuAtwZ4gwZ4SoERMMQtjv7SfcuHiYH/J+KGSf6H BAZ5TyBWY0EA6vCeXJcIqEzKHM+FyGgIUYwVpZk7gZbwDmU+GMbEss2AFXv1jeHFbiSivvT5 IVHVKTDu/d16iBRM4IjxQK1E0JNhwrdMsWzgm29xqhDPNvHqLsHcCjUQGXxdjeOrOuj2D/7M hrEM+IAPPIsNVhw+EvwIhtyxojA15RA0d/uDblcZaAPlsNdT++oaOwGn6LLzHif7EG01xm7D 6W8J5kL2ej+DApKd+4O+3u/uQ6QX368RbU7xzJZ6gUXYC+2gSz6NSDihuIUWgva15t8qoB2E mUynBCjxYRVKXjBTZjBWZJ4BAkT8+iigrjEpkXdeRPhE+nkO2Sz5XATNTHDszkqbiHV2B8Zr SK5mm5r5FfLLqX58eXWq33y8Or3+eHl+sqO8WyMr9kxs1x8/ZTCqNWD8/K8PGYydQhjnPU3H M4ezPFDmnaLmSPe9MLoNWBE15OxkHh0CtCSjlkWyt7eGR1WU4ukGh+JGZfroI/SmKErS/VT7 L6ynkSO72lWYhDB/Ys6z+9+Kjl7E7iPPL6xryWO16pldlMjQztB3lgV5Df4EOwdTD97YLfin Zaj9dNK7jgKAdhQEFDwy+I6tdUZsoz8EjsWgo7JRnx50aWegmn3a77HRYDQ+pJqqap3x8ySU 7k5FbngCWvhJRWS0roY4hZXDycj95hMsdBKU4xa8nbFNb3XL1EcPSSXyN7hA8COxQoLR9puC oIFU4Q9S27ZAAMfw9+ezkxnBPCKFGHBAe/1DhZndvsKYydQ1YpY8IqyT6LPcP3oIxrccJlHc WMfnzEOPknpGZDngnw2FX47DqPD0hW0zm/B7gCKIjSgutsIkWGbjmsACHzOcWOMIB2CNN/YU n0aDw37n0Dxg6gimzahnaj2lrzFD0w46SrczXqPcVBznodrp00FfG/dUozfoqyM6OsDx7xxo mqH21ni75CLOzJu8dQwGwIDOeRrgz5Hp9YD9FbMwIvtElLm6Y6PbH5trlLnWRHwsPkDcHokF qQaWfIg8swwNYCibxRA40evzUkGUEFMD02NVxwcJmllksMar14qvRYXWjSegkk9nUuAtW9uC oOjaFgQZGxgEubVNPoXifaZFqRRP1RsFJN3bhZ209ME6qXUsfWyNvYKAk6fwb2Yd5BspYALD HcLuQWWxl65syPI02Wu9yHcOKDzxiFxLRzMITkQz01gGIs8R3qK+Nffy6FlAKj2qSVFyWSW5 5RHBSwSo4AajXCidxWB6ieDA8rvM4A6aWL96HaqYA/Vgtt4g377nFXXAs0F75jNukNNnWIfI DFjq9zn0FSHLIDlUlPf+t9ukTWZn0CmS0yuCEx8W3SGza9MH9/fv4d8Q//e/CbpONsU9Vaoc cQNJxH3+HRxdc3TuQbC4o9yrhxrtjJS8KFZhK6BWlgugMK2eaBV2+MyPiiRO76gtmts+/85C g/pMOMbgTrloLyCMVYgxoUG4S7w4mn2VhD6MRw5YPN7IOqd3A3rApe6av+O9nZBhdxWJ6Mhm epKBFqWA9Mv3CThqyQ8wJHz/drrbP3hbdqhQEcRZ19NWPUa6B2T0gN0iaGXEXR4I0WhujPqy xog3oE7JWBCSuHHNSyQ7nz9cnV7rN18+n8Ofy3+9g/sQOV/xn3DN7WqDg8Ka+xhlt7wEYccO 1gBVknzEw2TiwE0LZ9iZxge45Bikcp9hmo5EZ8lIpETkRoPmjaUUnlHYF0efTq93srjANHxV /nz/dU5b88ucFPxxyODH+tnFTco+tmRLwgTmCZ6K9MD7nhU6yno21ukIgKGC35FRPB6Dz54T Pis6FRbGPkfDsimIPyEUVmKwaTHLKwCVZjLnxcLnF8e4Mz8zd5Vd5d37rwNZ4758NCB6y0rC +67DCIDy5blf6MuVQwZgQmTHXBly+i6Rd1ihOiBjvmIidnQUUOerku44YAxx1C7PDGJZUymL GMGni+3n3w2b0SCzKGTWspLTlcOfGqcpM3IN8xyyebGp3Ag8E978KCw3Jgs7eZ5BtLBbzzRW 8/ATVyE3ADJ8FLEnCDxSQOJ4dwzzNPB33nOfrftLIqKyEyXRraxTDvGoFU7KO+Rro8IICC/u zPvgpbzKeoLodfWlfBC9FoZVScLFjEZBsEvTJGEAi2NBuOKh9ZIlT8HiSa0EWGyLmgwWekJR 78EW84A+8P0ypLeQed1qUIIhbahaGJYzN2K4owZrgaJf3wUrbTI/YNwfekO+gE8cuxYscxB2 eOgihTymDfPFwbU4XFp3vGDfOQHgAGFEDEEZ+fNrp4gECzegfDnXjy6vwNO/Pr262dEWek+q QHZyen56c7rTLYRs/blfZpquKBLIgLm0UJAeDVdU6tMH105vr28CnugrsfLbZUsdQyqDlGd2 2TyTBLDA3D4JvcjJRFyURU1qsZaNeOOM1iCxWQu7JKTM7DKzZc2JSONoUnQO4jOtnX6rjl72 rZVvt1kLz1NnR2OX87SYnO8CkTDoYptBUeeeP/RIB9jW7Xp+mWK8uvolq/6yrPq10PojC9kU SVczxiuqX7JwbqtfWbV6svrFR6Wu6ld/rvjVr6f2RU3l2bUvYf3qr3t1NXOhq0t63UsIqHDd y3x1dS8YjcO66l6Ai27rXs+sEsiue8GgLHSNVln3gpmZ1L0KZUMqqnt1NbbQI1NH3Usa74/W vSqS7oq6V3XyXFn3el7B7Ym6l7mRulcZw7zxuhcQXbqQv07dq4yxKlP3kuqjFHTikmMqxI5y 8Xnro219tPp9NKF8VTpn1zdXZxcfKvfPXE9YEjkDW8eqkWSmAsaTheKbzn2IIbmInREsft5Y MAXmIbESyf1n2ccNrlDK81eo6oz7tqkhk1optRw9XpErlbtdIydsm9QvWgjAZzIJ4fOTo8/6 R62npDCf3MxTFPol/AgxANSO0tVKJd1XpMXhgleYTPFUhtATfuHZMngZBUFOQpB/609Q6JVf 22pB0bQu9+w3Vy2QmQV5Yq/M6PBgWy1YrBZ0u1rJVrn11GrFXpmRNO+6idWCrtY5eP5OGbEm bKJaoGkVR6KpgIpFohpj9BVGotqgvkhUO9hWCxpXLdBG9VUL+MxMqgWHr7haII33R6sFFUn3 tVULxKKwkWpBccPcgGqBZlRbLShurMollCT6KAWdONPGFs5dcTrVLvoJehxY4kNEb3cjj3+H P/iNnx3FD4DCjxHbxY/givLnWaAbIftLfGaZzwEIOsajXVmU3sxdCPiJONSY3p/7Guj4jpT0 Fv98h06wH3h48mm4i3uwfdGPGqaP+CDwOXpmF8TvHOre2szUpzynFwTL6ZG8PHPxot3WMYuM SfPd1k6vfr91oChrO67SugFXO65dIy2h8NlZpcf669mHapzWNbg0gUsVuBTG50UWitbgkgGX HeAytTNt5XMMfGopn7BYtJTPngJ8djGo9Fo8mj0VuOwJLls8lh3gsg9czvyal5cdWINNDdgc CDajdnLYBQ4PUF2FP9pKHnvA42GyXCa+dlvnZR89AyXllbWa1wHyqs7GdRoatZVhzMqqndng tp7hQ2RYy8xcEdy2lV3s/1K7mcnbbnbxKC61NxtdzE+0lVeMS9X+bGjbzCuPTtFrwlxTpSH4 +eWvm2ERQ1MV3aY0k9bWscTYVEXfKZspbKOT2MfotKPMrNE069lKbjFK7agze9RubjFa7fBU UmvVFyPVDrpK+ex8Sy1THwPXTjfD8EtIK4n+TtFbzj/rljv2xFiZoyF/+x/Wu/Bq4NBZb7NJ IzqioehdUJLqynP6l5pYSC1cKGhGU3vxglNTm9pLtQOujWrZSX2jwwNJTe3zx9wU7r9ep11e Asyl5+YYRU7FEsfmGI8dh1fy1JyVpxL9dnR2rt9cHV1c67+dH30g2C1X9oyilciOT65SLJ3S WJrf627atzkakqq5bDrKvaBr06C3bfpurqVmk2368toPn2rT17aH+tTcpo9qtapNX1pHzco2 fW2uTV97OW36sCJvpEdfWnPNtkd/26O/idxGq3r0u93N9Oj3X3GPvjTeH+3Rr0i62x79bY/+ Uz363XKHJSwnekmPfnFjVTI/Vi6vt82PCde7lFe5MsUC63mSYdGqy+MAkk9n19enJymurlxc TU1hFD7U/+j4WD/9v9OLm51etW8PQETHJ1c7/erRJCMv2Bo89z0FS18Vy0yL+oH3/+1dD3fb NpK/j8Lbvfea3CoxSYl/pFv3mjpO12/TJI3Te7cv7fHRJGRzQ5FaknLsfvoDQFKiHFnCgAAk 0fRrY0u2MPwNZgaDwczgjsvp39GdO/ELL5rL7s9dUll16B5JQELZhC1p7N/LhtMgtcJkycA0 96IAm0/siUchyc2VDewBvRU6u49Nt3qOHWcjt/NvL67efTxCP1V9E3y1wFMJSD8psFFOoU4X SeAtcoTJBDcooOaGGAQ8Ot3PaP61HyV5oc2mHl53ApTjz9H73L0b5IeI71INIO089kioElvZ ecy18IEJRnOvyPwAGvHhIkb+HhU3adhJVuK/nyOUkehFNI2QEpBKOdrt6SNvkpuruSIXPSuf hlQqFRLS2LDylDspJsoJUoaWoaxO4lOqCjd+7hVp4fMlTQGJoeTav0ZeuQXljgocND+VEutN y3Gblq7Pn1JlKNThUkhKqX2O0zSvalZVkLv1Yxqp81qk7R6yRKomRmsUSDoA9Kjt8NEVHv09 CXIkSsJHRRki7xipfsPaS+QhYuu95mMmuA+vWR25eZDhLatfKJKW7lrMbnso3SWmeFfQ+yjC iGUIfyzs6NQpPzGo3+wivdy/VSIhqnGR01zsKqCk8G6mXQSoMBSVxyUtD2VZqiSPQrnWzedk MSjSToYSlduUjq+tdU6tGl4iBLmwr42z92WhhJLiaE2CvpJwRsd0uvvBhWgW4N134l+rSd1T J//oDmFkuZJjj1lZO9w94VfskHQcnEIbuQ94aeJN/SheqFMERfH6vWRZ4jdDFCM1kYXqTWVW TJm/Vb1JCjq6uAeYeeFippKR6kRSsf/aWeOlNt6r1Ex2fEXtdAT2xk/CGNWVtJ1jZwWPZMEH WXSlymKqD8Yqy/NXuZ97AoHRPZBM56TLQ97diGwfcjgqUl/9nJSzByiO1USZ+5rZTqztfc3s URPra2aPl5XdlUqlQtKn6B53zmy39a6vmT1iYr1pOW7T0vX5U3ys0MWdc18ze7wSqZpYhytS ul2h2NHzyY4vN12WSMXYeq/5mAn2NbPHmtTReyg9sUPbFfQ+isC6nqCvmT3K7AbV9Pqa2SMF 2OkqjieQGtbXzB7pitDXzB7TbPU1s8dKsK+Z7RNYD8Yh6Ti4Tlf4dLjsrK+ZPVp/q3qzr5k9 OpFU7L921nipjff2NbNHOnOqLVdfM9uNYGxfM3ucgdG+Zva4RbSbIYcjq5ndetlxaYvBNaP1 xyYETXnZMX72RRaf1lfiTk5OMMCM3mw/9/P8a5qFP1SDmi/RnT+bx+hlkM5WF/Y69ol+Z4yH U3OkA57n3ftPF2fnmx5pE+A29zA/fnV1Hl1//8xoXl2N30kw6UT87dWHcpE34fNTuKiZbCjT SqKCNElQQFYITb9zpqFrmf5o6Ji6lqRFxQWMe56m0OSmxkM2fyabB29FlapZFGqnD8hLIrYi Mgod93T+5dqb+XGcBs8c87kkmuTDZBab7zWMyh3+mpB/thsTSQ/34ZccFeHV2/Q6Sp4RYzUa DXUdygqAWOFVAGUFWkqV5ucPZkUQ0ls/NvMiIxBRHvhzdFlkeBrO8JMRQzrRDB2vVX6WD7R0 UaxeCiKPPfQZXqfo6rcmd4HtUq4n4S/kd89yFGNOaYV/hXcumFBOmEZSCrX6xdcblKHqD8jy c/pdteGIivvveKeKCEKZbjrRqAb4BdJGrnZ1X2CjRqxM+Vs8HHbpirU5CkXNEXWmlo/xDZPK X1wWfrHIn3346eP5pffp1w9v8bf3f3+Of3+Nio/0T6jkDhHywZL72JPhobGexItZkmPR0Kof MU+KRZZg6aUTVNwgjdvNxdRqvq8oLWfC3DAT9UOszwYSZizXMBNmv3v18/nlszVa7vPP+u+n n9ekFbrMMdHHvhb+Y+/i3acafnE/h3p1j1HC5gl/Cru96dcm0wmvV3NdzwA2VPjvtKvFdIqy deYPkQFVhW/m/sEzbFJB8ieaj1dibNMW6BsBsESp4zpbqH5Ris/WNXOgD/Tnp58tUfO+eTZC PBUNTqRfPTwDWPgeovdFif/6Y2BKhNgZFYYH8i4QO16hTMxjumIS6sRRIDIvi7vTDCFCQzk/ G4RFqVKTMBm+Xmw//BLEyM8ai0JjLeNUVzr+0jgtwYg1zGvE1tlmUCPQcrz1WdhsTGxeg7bh oUu71dJYrY9fuQoPJkCmj7Lbj7TW/UjrePxIH7vot8j7SuqA8B/1zuTSmRyN7LB3Jntnsncm 1TiThi7bmzQP15sUB/5Rd1IWf5+aP1muC70/2fuT0vxJd82ddI/Hm+zdyN6N7N3I3o3coxs5 esIxSWHYH3UiJXG39yF7H7L3IWW6cavzYm+RRQN0N4/wOwN0i98s//WicFCkJIUrI9/DdOZH yaDy6Lw68Wn5RvX7ABvG8oOFfz2gfXDID7QXjhfk6F+DDM1S4kyUP68adwzyNPiC19YomaYD rJWFHxT156pXlWUb5NTXwp/289oHfRC31I7a4ZwijOLwD8FNXb3Hadk6s8sZqHM5p7Zeupzr eiXT57z89PHi3U8S3E4GtA5Ga2C0ldk4PteaAaOLMZoEIzGGXZ3IMQY5rEFii99VnNgCYl8V 7wjLBa2rMK8wTKuEWa7HXQUaYKA2BvrQHekqXrw7+Ow08HZ7dhFG62K0pTPZVZRTjHJcKit2 kbuJ0tJ14ioQz6jeC3QVqEGAEqdotdfpoF9k6SbBSRyjxkauk0CHBOiQAl3tUrsqvSMClnhI jV14V7FaBCtxk6q4Qldxkj2pYa8sUrfR0j0p8ZGO9ryHASTZlBrENSpDYJ3ESPakxpjaXRLf O2h5XVZk4u/0lBhTJJX4E40UKpLYLzGk2cwvlqfloV/4Vz6mr1d9i9uc5B9ikjM47LYlNq+3 P1A4/Fj8MpZexdCrIHwdksc+cyk5q9iipmG5QZl2db/8cB/wlh/wttTHu43RQca7EapSLDoe eEFTt4x0dzvgortPINZtuFWsu8OHFiTziezi0KEHWpaOE/nBuykzVyonisV5Itawd6CeugNV dkEsRaM++j9qRwieanr2/uefX717LccTUqIdRySwlA7pUeGR4OcttlT0+3ovj5VPKLBHSmVH mm06plES5Tf8LTqYSZGeKOTN5koTOi6Xoq1aNdUXC2g/X1Dt4mzTBGgA5d3NuO7jerwbEW3L cxf48wedkchbqpsiHUZ/JsqRmuEPnqd+W+TjLP2I8qJDj3qwEy0v/KzQ6ItT7XP9R1IHf/mV J2a+JOGH4XL8RRCgfLqI43sNv413mdUvlgx8ocUoOdWg5kslHqnzAWFWiaNmmTHiMvl+liMP /+vPSMo5fkW0qnxNjNfkcx77UlhVXhnNpaRMDy1xlvkeHTTHJYn/wjiW88vlO29fP4g157aS fQu5hru1xxZyAp30x1vIkX5mfQs5pS3kqFhtbyEnsHvgzlLN0Vqp5khNqeY0aF+qSYzcHso0 LUOXvncu2XMohwiHXKZpGZayMwRMqy/TPLQyTctwVZZpYs3syzT7Ms1jKdPc36EAh2Hef5mm ZYyllmlyGCuuQDGHj9IHihu+d8tA8aYteRHnKXj7Un6o0Ty/fKMe88UaJc4m+tsfO0PX6A4w 7MW7N+8n9EPbW/7DHra6TeDhuN9Noxh9VwaIEAnMRzndr2N9GGjXWbqYazNyxkaDB1FOFrGW tzU8PAKAsoeR6/gzReaDThYo4+vPPcJ7Tgkhjuk09q+9KPSu7unua6K9wW9o5EfK9EUc/3sf cGp3HKLsjoiNj1BLtpfHwdWDB8lj4Q/ieVUgltywMvPnE3q/L2E6YfRnKsWkupPcwKJhQ1c+ pSFGewkZko5c+tYcysZgGcSMusk4zPIoToHD0s88ZpHb3L7yVHR3d1QPWXsNFovrVvR4sNgy wj5YrDhYTMRqe7CYzEofLN4RLCb2bx/BYnMoam76YHH7YLEp7Gae3cFi09X7YPGhBYvNKznh vV3BYvsJB4uFYX80WCyJu32wWFmwGG6YDyBYbIpMe98QLIYbK75gMdxH6YPFDd+by6s8gFjQ rrgIT5yBIXwRzQJoWBN/RFzsYn2wUNQFuebU51OjPozy1MIofc7dIYZRBObcPRbJIA1ONkUy mqX05KBlgK0bfja6fmJzhT2FdLaPBrGWOZWd6lax5FCiF6M91MsbJmv4Ygi6gr1d+GJY94ft bq28Nay7wna5Vt4a1n1hiWk5vvgTA8C6Jyw1m0c5i+v7/yQtt4NibJDsrf/SRSf1L7RnYng1 WT3tCgWBRQmoiyvALeZBFPpyLLyHsqvsowJCUsg2b8lhe2eGLIXWA27a4adzwhmIolATUn1M bO7SAZUgb2caukPguAj5TINd5OWDnEDxzxlMrxdFFINnt/5c43nxenDj5zceyeLTrqNblAzq ND36C226SKiS4UcowJ73t/QqONo8S6/8q4gMqhm6NkdZgBLwirckkN/c+hkl4WGX/gvtpIe/ aX6W+fdYnv7APr7N+/R0WEoBj1sZ0/Ilkdn8xs+QNsNWFuQVPDYhdYSunnYUDrR5FGrVB8Wa Hg5BWo4aYBWmw+LH9fB0Bnn98MRp+tciwlwxsT4UmU9mO0B5zhevoo9PLDy1wROyUhfrJtkY taMwje48Pygtn4ZfUFWbetWY3sy/m34NvRvkhygbaCeoCFbmqP7hJeblZGg4oujnsUdiFHgZ n8f3O4hy+ikbiEZzj2bMbSdocpXDbyIYYe6i4iYNdxAE6+6qlL0cnwhn+QN28UxTh7qk+I1Z fk0SwfGTL+bVqHWEFusnjdZXFD5/+PXHtxeXfxtc/vrj5dnHix/PT1xHB5fTiJANU5hs4Kma I5SRQ+VoGqEdMzY0FYvIcChURAyZEqJ9xrvny1c/nZ+YFvjcvDWjxkIZ5Url08fzny4uP51/ PDFMvrWvpfqMLFFESY416fFbbCfIV7C1I5M7QFnxIIubSz13kKkieOuEoGqJP7ySDcqwiVa+ V3NycPL67PTZ5/87+f0vz3f++PI/B7+NXv42fPmb+fI3Y8CDmj6ERxUgm2jplwH+ECm4aOaC BCLNLIsWW1xp+Mdq7ua3HpE0IhFzFFTVL8vTydLHjLFnq30u4mqZwrP2TxQUXgAOKSsT9ZbQ 9mEPLS6MLeTcFrusu1C1gfl99XI1uHj3PxefzvGqNVa9vAtm2IEbhhYrrc21tB/GSptm134S /UFb3D4g94JrYQDTo4GPWUuq5FScEKRWzqMnR5O6VRc1fOUZfJO69jUqbogUgXfaMhwLSf7E yOW7XnmTNsShP68md4c+cO2xj01Q9xKgcYTNJoSosCANFaHymGwHSS4veJdJ9ZMAxUX+QHy4 0Ckk1XL2wI5KW7+BrynG436DTK+h9q6EuQw3fu4VKblyXAKPNhFEybV/TRgXRj6JM9/tEgeu oE0LcRhzuS0dEYc98ej4XG1m52IsLI4GsKFjYUrDTnSkK192R3x9hnZ5Ul8TlClx2VaElG4q CNnVbqKjLBR3NMiq6iO+XspPiZUAayKOKNuaNuI72u3SmlawzAvfgTQ/OWErGZunOxoKW6+x duWovAV5B0lhon6LLXxIEv3LRu/byfIlp7bQsJFYDYNyDaRfP/7j/ETcuSsjgyyxDJKa66F9 XqV4WIYpklU0i5vewSyDXS3mxxa77TmTeiKDJXjw6uzvJwLnpvCCGxR8IYlSSb6DVcKOy8gy Efs7lgm+EC43OUdxjGrEF9LsSFAC4DWCc3LaTowrOD9P5sScvXp3dv72ZC/2wBV2+sCkoOLi lQCMfFExfuGzwOv7duF7pTRFYPD+w6eL9+8uTwxbnKlg3atbujALzm6dLH0PsUBLF7aDYg3L WQbX4r8jPrG8OVtBLGSdlsrgXE15FZ/bw/TJOGGs+5momL51Wiqnr6a8nD5x6QzzIMNWmzQU 3zF7MrIZDmb2+Ph5LKZFnLKzrg6qw6yWKTZL75Xccpalz7JyVvQ9hDo4udZmmgSHomzVdUcD cmvDm3+cjB2B9ROszOPa7HTpKIGRUYIrcsCLA4hPtQkYittAsx4RWHyh8xYzMxIb14A+Pmhi SJRzHyWG1khYUINxVizBeTcyS9iaq2dtYoauuHnKEP5VyKI8qks3LEuw/T+qaC0jjxyuWEiX ijHJ/iC8Kvsh7eCVsG0BO01XmNLk/u0OBeULDu9qu2iG7lTfXzdPSl4SsVXBhI/d276b54Zu nrbL2QWJTay2d/MksyII6c5LUdy1S1FcJZei+Na0/aUotAMl/tUeLkbxHWHX9j7WWrRiEay1 6MgZwaX26C9G8R1hVwjtbNeIafW3aK8x3+VLohZ5MYrvCjOXDBejEM2sLkYxdB1cpgy9G2XE cDeK74IL5UTcjSIS/qPXo8jj8a4bUqRxddcNKRw6xdImtVwd9nFDCoeFXiO2lxtSfJcvsZb1 hhQOq7U+PmM7VoHOyk5n0tDXvMn65Z7cyeVhOHVVan+xciXrX55+Fy5ms3uPvO5dyd6V3IMr uTzTlehFdrb5d1dWNXX9uTlMThk8PcDm2DxhmjbNsUlkhvPKrFbRVBlVlnVPW/QwLUdYmiHp fIk5i5LCu5luRzgWlujEztWxsCROllo0ayysyCCPS3oeyrJ0e2NdeOJEe8baujCk/nxODlOL lIHBNl8kgnc+bb7M2NmXsm3FRAtTQur1u0ut7GPH3SS+zVTto62PbYq0MAynhTZfGWhHTlRX dn47k3hvANwkCgjNdxATZntL5dlBTZhBYhS44VM+wi/IfpgUvGznkbgCYiZzPdpDyYa9j04q jrjll9zfN/MT/3pH+35HF7aMMKizw9cpYxM1cuuIh1VlBz1hlVmzMkqzg5yw5ZFFMRyhLgCr X+qIyxxnAikuAxoCUtx9D2w21RG3rEJg8l0hsBlmmnhTP4oXu5SEb4XlrQh1xDXZABjykejE rRDFaEe6owMuSa76w5bOS0lootFXE+0/8Otn9J8oCdHdc67YyY44Bh35QQhD2GxVjGOw2uAs tE7zbfcWgDMKuWWSyKVoO0hCFarTc8QcJXDGwgz8zAsXsx2CIa7nIbvZc8EV3Z0WDcZtLl9q fGe2uYy+ii2u0xCLr2Lz1Q+0EANbbCOJ4xID1lCAyJZGTPEVcV2GIOcNjuIuJrbgShBTl1su WVWanrjGmK8QUP2VPjCKs/u29NqdaLjCBPDGT0JyRefiCqPb3jbBdlUfafAVvXSr2V81QeRe kCCLrnaswuL2G+zn2o4tbOlnu53HkXIbSeDHMfai8yJKaA5ddaXrA++TSyKhlPEoiyxS0Wpj K2mVXWEeeZBVkxjOrcv08Rt9TvBnJs9e/uX5yW/GCQ+03Xf1oNFU3K0QTGF8+wkLKFhGBEQN +BzQHaBz9E2+khTmruioVHVCdaXXwjwZSBqNw+fBH/q07YuZMnrZdYiZ6Zy+ZmKlUFeKyYS5 fIlDO9g6Q3lOLjFCd/MIu5EPZlLx4bY7ErYKsxxuu3w9SHjPfV2xobfd5ASean/1c6+8WC3e kbrl8qVfzLP0ivQEvPPyNPhCauCmE+0aFeQV1suJlgW3xGcjxewR9jXusd6Phw5fa59NtIrs nkCdaObQ4L1AY9O4OSpoASF+fvritBx/gAeLpvenpm3ilzJQDEd8iycrCjK+fBSWxdcmkRUF GV8+Csey+cocGFGQ8eWjGNt8DTlZUZDxpaMYGTZfHIQRBR1fPoohZyIYKwoyvnwUlsN5XMOI gowvH4XD2XeAFQUZXz6KsWvJ1G46vnQUljHmu7uPEQUdXz6K4ZizPR4jCjK+fBQ2/PgKhIKM Lx+Fq/PtSlhRkPGlo8Cs4iv5YkRBx5ePAo8rU7vp+JJQ1NTwK3J/G6lORtMpCiA1whfv3rzf QqI87SIbpaqTRzrF8mtpX66k7Mhycuba3JEZ9tAVNz3LaR+ajgTvGT99Oet0+HrSbcviq8/Z DkHssN9AoMPXEIyhoQvc+S0xCB73GxDl+EdqQ5YoDt6GMM/20JCw827MNhlf9mwbQ8uQaTvK 8eWjcEwJO+8GCjK+fBRjU8LOu4GCjC8dxQjbKZlWkI4vH8VwKGHn3UBBxpePwuK8Np0VBRlf PgpnJGHn3UBBxpePYmxJ2Hk3UJDxpaOwDN7G9Gwo6PjyUQw5W22woiDjy0dh2RJ23g0UZHz5 KBxbws67gYKMLx/F2JHpNZfjS0dhGw7fxZaMKOj48lHgXbZM7abjy0dhuZytvxhRkPHlo3DG Mjf25fjyUYzHAgM3G1CQ8aWjcEx9KFO76fjyUWCXU6Z20/Hlo7ANvo6yrCjI+PJRuIbADJMN KMj40lG4uikhn2WFgo4vH4VpSo0+0vHloxgNpUbV6PjyUdhDqVE1Or58FO5IalSNji8dxVgf SY2q0fHlozAtqVE1Or58FCNLalSNji8fhc3ZvZIVBRlfPgrXlhpVo+NLP63SdUdmVK0cXz4K 05EZVSvHl49i5MqMqpXjy0dhc2bZs6Ig48tH4boyo2rl+NJRGPpY6lk0HV8+CnMsM6pWji8f haXLjKqV48tH4egyo2rl+PJRjA2ZUbVyfOkoTMOQGVUrx5ePYmjKjKqV48tHYZkyo2rl+PJR OEOZUbVyfPkohNZtbUBBxpdfDSOlSmyF4pirxBoojrhKrIHiiKvEGiiOuEqsgeKIq8RWKI65 SqyB4oirxBoojrhKrIHiiKvEGiiOuEpsheKYq8QaKI64SqyB4oirxBoojrhKrFEbccRVYsdT 4cFUJUaKt8hrziqxFQ1S/lUO/wWhuR9H5EbGFy+0T2cftOU7GkrIfd2hliYa+Vu+mzFJR09C boKHo3dICWN7X9bGBaEva2M4KOzL2lQYPebZ7svaWFD0ZW3sKPqyNgYUfVkbAEVf1saCoi9r Y0bRl7UxoejL2thR9GVtLCj6sjZ2FH1ZGwuKvqyNHUVf1saAoi9rA6Doy9pYUPRlbewo+rI2 FhR9WRs7ir6sjQFFX9YGQNGXtbGg6MvamE+r+rI2JhR9WRs7ir6sjQVFX9bGjqIva2NB0Ze1 saPoy9oYUPRlbQAUfVkbC4q+rI0ZRV/WxoSiL2tjR9GXtbGg6Mva2FH0ZW0sKPqyNnYUfVkb A4q+rA2Aoi9rY0HRl7Wxo3jiFR6dLWvLCz8rvFkaLmLkYWwBuXg7zegd7eQlynPtT+f/e36m +fl9EtxkaZIucnqj+oLc0/2nE53e5V6OQN/neYyI1NQlfuwR2qsnSNBXtqeQBv3nC+3NxZv3 D2DOIm8aTVNZSGuissb/9fUHLUMBwlKUHRIRR18nEtHp8YKbKMaGorifo9MPH9+feT+/f/3r 2/OBlvnJl9MX5qCaltNidohgitmEIqDlo17gx3GE0dTfv3N8yx7rKBzZOkIhMl7Qz/5gjM2X hu2+NF4axvg7NfwDiXVbYoss4iEUXnlhWlXiBmmSYDuODYCm3znT0LVMfzT1bRfb+AJP5IJU 0ybaPE1jRsEYV6SIZaH/eNTgUPOAVxJiMbDFpe9VNqgWka9RcUMxaoye1xIWRjRP8+I6Q3nz Zw8LoLdCONHw76JQO30AVRKxBpEr1z2df7nGa14cp8Ezx3wuiSb5MNG85nvLD56c3OGvCfnn h4qc+RLd+bN5jF4G6eykJs34cMZO6T3728Xb15XcGmAbsyTAo/4Gn/rzYoLpPS8VZoVXY54N iFWxDN/Vea3KkhS3plPykog1iFz5Op+mQ2kq1XQTJK9wb2JJgEfTTT5N58UE03ReKuxLu6lO CU2VSgglJkIJoTSVKuEQJEpDuBIOWyjhkE8JeTHBlJCXCrsSDtUp4VClEkKJiVBCKE2VSgj3 q4pohmgMSmKcgNBgdtpGIGUYwc3IqIUZGfGZEV5MMDPCS4XdjIzUmZGRSjMCJSbCjEBpHrYZ ubxYbc9IEJtV260moWyReNRWeNW43j8jckZxS+Z1oBk6/tKw2J4a+NVsgb8xUrG/DQqv0cEc rBuyRX8QbPS3h8Yre51QUBou+qjk8YMMzVBCz0HIL0oMWP/4Rn8s1vfp4ufzj3WojyNmYrew vjaf9W2HDGaD29Fit8S2Oktsq7TEUGIiLDGUptJdlQNa1C24QjotFNLhUkh1FpOXeTCd56XC ru2OOm13VGo7lJgIbYfS7Kbf5YJk1oabFbeFWXH51nleTDBt56XCru2uOm13VWo7lJgIbYfS PGxtJ9lBMz9iTYZxxiBZdeBaPm6h5WM+LefFBNNyXirsWj5Wp+VjlVoOJSZCy6E0VWq5uzuJ pilKbutUp0ezdF5dvKuI6PxEODTd5lvPW+Fqlb4HosSZ8yA3yan1ug5IPAITE5B45LbIvHP5 Mu/AMI/CyID0hJsKs464oETAVqui2zo5D7AqgokJWBXBNJUK7O4UszJQevahaXZfwM/73BZZ ei5fll57cHxpuqwT/eGXHBXh1dv0Okqe6XfGeBgMdR2a8wlYxqIED0XSaisN1fz8wSqgKCE5 z7AKqaGVoesoLzKf8RipLbkwJRtDNbTi0J+r0gT2pQOU7dnKvXJbZ3sC3CswMRHu1UFne9bS S8SQ/lM/ykT7jP/IDwI8pUWO/+rt61cftKsIz2++CEgIZbqItWf0Izf46bTPdIiTk4rOsPlU v3PZQw7Fjfw4vZZje1Hgrsv3vgwvnhMZCC1dH+uHgXCG8ETOs/TuXhFHb+cpWGMYmWpaUsRm N+GRyR/kau/OE/Kya20s3RpxBrnUuvNfsvt5Aa0X4XdAr4whswNKqJ1//Pj+IzO9y8u3Gsqy NCv9fVLfpU0XSSl/9+lCy2/SRRxS2SN/8GfdMN+8+vTq7UQjtcQ3/r22SHwt/u8E+RrCYnnt 3Vz5mE/JVJv7ma/99a9r+4Tvvx9oi3zhZ1GKf7XISWB/hsi7V36OtBD/5xdpjn9XAyO/I08Z JT5+qtuUPIE0dgQx8qloLOabNprTDKFn8MnYoOM1T/0wbGp8kWrFDYKW15RUsD9I/id0rio6 C1olTUataNQEMJN9wnA+KA9t8tSPiOTgsddSxap6YfxMpZHWDD5yxH334jSdl6loJdWaKClM JhVQMd5SoIQ1NW29ACpHSejlhV8sciwNISJl89jKvjC0/9ayAFtCQxsQLUnS08vSW9pNpTH8 V59UtDeHz5BPph1Le4MGB4lV1Xzoo1maRH/gwecZelG+XB6PobuIZr/ROs0XrNMAralot3nm qIbZunmmWiu71geyawYCDPxtroYKdNB9Oi8d0Aadlwj7zhycB9NuzXb6NbsdO0Su2Y6SNdtR sWY7YtZsi49cEcy91WKdoaS5duOXFX3A4Ku1Lo+uPWx58SodXSd+rBnDOtELMh776v9itfz/ mKVfiMZEc85p2MCX1UxQuuWTUO8AaBIPJOrDvQxAwj2wxdTU976Yssd5gNBMZ1ucRwU0cICH m4eQyA6QjaOhFAnZTdjW91nWbTJf7NqirNt0zKMo6wZFdqDFru28RI4yZWG7I+4ibMjuCAhQ 3O6IFx10d8RLB7Q74iUC2B0ND8vb4GYrxNuACadAb4MXHbu3AYQmztvgbiAB9Ta4eQjxNoBs FOdtAAm38Tba968AeBv8/Sv4vQ21/StA3ga0ErNdLJajhlaYt9GyThjicwBhivM52mGEeh7t qIH8j3akAF4ItEdEO33g6O4hTB+4e5dANAEIUJwm8KKD6gAvHZD08xLhkPsD8b652QrxvmHC KdD75kXH7n0DoYnzvrn7LkG9b24eQrxvIBvFed9Awm287/ZtnwDeN3/bJ37v2z4s09bSa4IY OJgfKtDAtcPIbuaAAMWZuZYNjqDGriU/ISYPyFJxJg9IuI3Ja99fCWDy+PsrtTd5BxhwUNuE D/Ro0HLTdns/jp4jwvZ+3B1VIHs/IEBxez9edNC9Hy8d0N6PlwigYkxpMSNPvbEoueevpgbI PRSgMLnnRgeUe246ELnnJgKIeUB7mLQ7aefoPiPM3nP31oHYeyBAcfaeFx3U3vPSAdl7XiLs cg9uq9FK7nl6sIgqXm/XZQYg+1CQgagaylYIgfLfihZEB1oR4tADLjw8NcT8CucavpxuEWUF 6PaFhhRQ8tCGl9jOMTdQErAmKBNq795/ujg7n9SfbDQcWavq+vzC/F3T5ngbX31SDjPtkeg6 3o3ASkwvTPwnVfJ+83nIOKgZw4wVVUjXz+rdzaA1xM2PrkEVMnFwKHcBsxsJFBHXOJD6eTwO Nv6sygZd4pCoivZWZpo5lAyDZ+m6eQgrODSQ3I6XgDByK0KwVYCSYl0F9IYtwR+UIxsGEi36 WxYBXfAaIGTm2BeAbyB+uwBwzRnUKo/DA+nbMsujGNqFjH5mjWm0xO7PL0zthLLur/Svv5fD OrxRF8y6b/EQKOEhuTrRTFJ7ndAWLYj4UZU5jyKLKdcY90gxpS6klpJQatRSbrzDvmUxZSuz yu6MQpeq4dUhuDEyPVG8e3UOwRMF2PUlncfsut4w67bLaNahbHNGokVjg1nXxVr1VjPEbNKh nBzrogVws0kX7Qqu1uOyN+qE/FNf4DZZuyeBNoCZ0yQJ+kEtyJBfgE19TQh/p5NHCZYfmWhv Lt68r8fVftBOitl82ceQp3frVmLkxQYSFTOpzKBT27alOAHGSE6MYDdhS5QbvK4jMldvSmlz Vyexi/aNn4TYIcD+DBb+aqxTzbZM1pbUdLiVh7Q2XqnBtTqRmTNodyVEWoNkJAHoflARPTUt xuYZe31+p/3zLw+BDyN1k//gG3BYAEwfEJe0yY2OOcYGhSYsXZO/Vz8wvsbPQ0BsDcpGYSma UMItUjQFXBXAnqLZ4qoA/hTN8UGZNv7cBsg5KCxDRGA+Oi869kx0IDRxmejcl3NBc9C5eQjJ PgeyUVz2OZBwm+zz9neDAbLP+e8G4zdt7mGZNu40XYhpg4UEBJo2XnTspg0ITZxp475dFGra uHkIMW1ANoozbUDCbUxb+8tNAaaN/3JTbtO2bQdcoGwWJT7thxwuaKPNy4ufzv729jUjHmv7 +YkFPD+xx2LHo0VFIscbCR5vx/kTeDxT8HhD5vH+rf/qv/qv/qv/6r/6r/6r/+q/+q/+q//q v1i//h/0osy1AOgDAA== --------------000300060105010104090305 Content-Type: text/plain; charset=UTF-8; name="system-info.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="system-info.txt" cm9vdEBzZXJ2ZXIwMTp+IyB1bmFtZSAtYQpMaW51eCBzZXJ2ZXIwMSAzLjIuMC00LWFtZDY0 ICMxIFNNUCBEZWJpYW4gMy4yLjY4LTErZGViN3UzIHg4Nl82NCBHTlUvTGludXgKCnJvb3RA c2VydmVyMDE6fiMgZHBrZyAtLWxpc3QgJ29wZW5zaXBzKicKRGVzZWFkbz1EZXNjb25vY2lk by9JbnN0YWxhci9FbGltaW5hci9QdXJnYXIvUmV0ZW5lcgp8IEVzdGFkbz1Oby9JbnN0YWxh ZG8vQ29uZmlnLWZpbGVzL0Rlc2VtcGFxdWV0YWRvL01lZGlvLWNvbmYvTWVkaW8taW5zdC9l c3BlcmEtZGlzcGFyby9wZW5kaWVudGUtZGlzcGFybwp8LyBFcnI/PShuaW5ndW5vKS9SZXF1 aWVyZS1yZWluc3QgKEVzdGFkbyxFcnI6IG1hecO6c2MuPW1hbG8pCnx8LyBOb21icmUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFZlcnNpw7NuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJxdWl0 ZWN0dXJhICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZXNjcmlwY2nDs24KKysrLT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0tPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PS09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09LT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQppaSAgb3BlbnNpcHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dmVyeSBmYXN0IGFuZCBjb25maWd1cmFibGUgU0lQIHNlcnZlcgp1biAgb3BlbnNpcHMtYjJi dWEtbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtYmVya2VsZXktbW9kdWxlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtY2FycmllcnJvdXRlLW1vZHVsZSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtY29u c29sZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtY3BsLW1vZHVsZSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtZGJodHRwLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtZGlh bHBsYW4tbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtZ2VvaXAtbW9kdWxlICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtaHR0cC1tb2R1bGVzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtaWRl bnRpdHktbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtamFiYmVyLW1vZHVsZSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtanNvbi1tb2R1bGUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQppaSAgb3BlbnNpcHMtbGRh cC1tb2R1bGVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFtZDY0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTERBUCBtb2R1bGVzIGZvciBPcGVu U0lQUwp1biAgb3BlbnNpcHMtbHVhLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMt bWVtY2FjaGVkLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRl c2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtbXlzcWwtbW9kdWxlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25p YmxlKQp1biAgb3BlbnNpcHMtcGVybC1tb2R1bGVzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQppaSAgb3BlbnNpcHMt cG9zdGdyZXMtbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFtZDY0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUG9zdGdyZVNRTCBkYXRhYmFz ZSBjb25uZWN0aXZpdHkgbW9kdWxlIGZvciBPcGVuU0lQUwppaSAgb3BlbnNpcHMtcHJlc2Vu Y2UtbW9kdWxlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFtZDY0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0lNUExFIHByZXNlbmNlIG1vZHVsZXMg Zm9yIE9wZW5TSVBTCnVuICBvcGVuc2lwcy1yYWJiaXRtcS1tb2R1bGUgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuaW5ndW5hPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7NuIGRpc3BvbmlibGUpCnVuICBv cGVuc2lwcy1yYWRpdXMtbW9kdWxlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxuaW5ndW5hPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5p bmd1bmEgZGVzY3JpcGNpw7NuIGRpc3BvbmlibGUpCnVuICBvcGVuc2lwcy1yZWRpcy1tb2R1 bGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxu aW5ndW5hPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7Nu IGRpc3BvbmlibGUpCmlpICBvcGVuc2lwcy1yZWdleC1tb2R1bGUgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEuMTEuNS0xICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQQ1JFIHJlZ2V4cCBtb2R1bGVzIGZvciBPcGVuU0lQUwp1biAgb3BlbnNpcHMt c25tcHN0YXRzLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRl c2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtdW5peG9kYmMtbW9kdWxlICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25p YmxlKQp1biAgb3BlbnNpcHMteG1scnBjLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMt eG1wcC1tb2R1bGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRl c2NyaXBjacOzbiBkaXNwb25pYmxlKQoKcm9vdEBzZXJ2ZXIwMTp+IyBkcGtnIC0tbGlzdCAn cG9zdGdyZXMqJwpEZXNlYWRvPURlc2Nvbm9jaWRvL0luc3RhbGFyL0VsaW1pbmFyL1B1cmdh ci9SZXRlbmVyCnwgRXN0YWRvPU5vL0luc3RhbGFkby9Db25maWctZmlsZXMvRGVzZW1wYXF1 ZXRhZG8vTWVkaW8tY29uZi9NZWRpby1pbnN0L2VzcGVyYS1kaXNwYXJvL3BlbmRpZW50ZS1k aXNwYXJvCnwvIEVycj89KG5pbmd1bm8pL1JlcXVpZXJlLXJlaW5zdCAoRXN0YWRvLEVycjog bWF5w7pzYy49bWFsbykKfHwvIE5vbWJyZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmVyc2nDs24gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBcnF1aXRlY3R1cmEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIERlc2NyaXBjacOzbgorKystPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PS09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09LT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0tPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp1biAgcG9zdGdy ZXNxbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5h IGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgcG9zdGdyZXNxbC05LjEgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3Vu YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNw b25pYmxlKQppaSAgcG9zdGdyZXNxbC1jbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5LjErMTM0d2hlZXp5NCAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFsbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZnJvbnQtZW5kIHByb2dyYW1zIGZvciBQb3N0Z3JlU1FMIChzdXBwb3J0ZWQgdmVyc2lv bikKaWkgIHBvc3RncmVzcWwtY2xpZW50LTkuMSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgOS4xLjE4LTArZGViN3UxICAgICAgICAgICAgICAg ICAgICAgICAgICBhbWQ2NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZy b250LWVuZCBwcm9ncmFtcyBmb3IgUG9zdGdyZVNRTCA5LjEKaWkgIHBvc3RncmVzcWwtY2xp ZW50LWNvbW1vbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMTM0d2hlZXp5NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hbmFnZXIgZm9yIG11bHRpcGxlIFBv c3RncmVTUUwgY2xpZW50IHZlcnNpb25zCnVuICBwb3N0Z3Jlc3FsLWNvbW1vbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuaW5ndW5h PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7NuIGRpc3Bv bmlibGUpCnVuICBwb3N0Z3Jlc3FsLWRvYy05LjEgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuaW5ndW5hPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7NuIGRpc3BvbmlibGUpCgoKCnJvb3RAc2Vy dmVyMDI6fiMgdW5hbWUgLWEKTGludXggc2VydmVyMDIgMy4yLjAtNC1hbWQ2NCAjMSBTTVAg RGViaWFuIDMuMi42OC0xK2RlYjd1MyB4ODZfNjQgR05VL0xpbnV4Cgpyb290QHNlcnZlcjAy On4jIGRwa2cgLS1saXN0ICdwb3N0Z3JlcyonCkRlc2VhZG89RGVzY29ub2NpZG8vSW5zdGFs YXIvRWxpbWluYXIvUHVyZ2FyL1JldGVuZXIKfCBFc3RhZG89Tm8vSW5zdGFsYWRvL0NvbmZp Zy1maWxlcy9EZXNlbXBhcXVldGFkby9NZWRpby1jb25mL01lZGlvLWluc3QvZXNwZXJhLWRp c3Bhcm8vcGVuZGllbnRlLWRpc3Bhcm8KfC8gRXJyPz0obmluZ3VubykvUmVxdWllcmUtcmVp bnN0IChFc3RhZG8sRXJyOiBtYXnDunNjLj1tYWxvKQp8fC8gTm9tYnJlICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBW ZXJzacOzbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFycXVpdGVjdHVyYSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVzY3JpcGNpw7NuCisrKy09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09LT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0tPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PS09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09CmlpICBwb3N0Z3Jlc3FsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkuMSsxMzR3aGVlenk0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgYWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBvYmplY3QtcmVsYXRpb25hbCBTUUwgZGF0YWJhc2UgKHN1cHBvcnRlZCB2ZXJzaW9u KQppaSAgcG9zdGdyZXNxbC05LjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA5LjEuMTgtMCtkZWI3dTEgICAgICAgICAgICAgICAg ICAgICAgICAgIGFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2Jq ZWN0LXJlbGF0aW9uYWwgU1FMIGRhdGFiYXNlLCB2ZXJzaW9uIDkuMSBzZXJ2ZXIKaWkgIHBv c3RncmVzcWwtOS4xLXBsc2ggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMS4zLTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhbWQ2NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBML3NoIHByb2Nl ZHVyYWwgbGFuZ3VhZ2UgZm9yIFBvc3RncmVTUUwgOS4xCnVuICBwb3N0Z3Jlc3FsLWNsaWVu dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxuaW5ndW5hPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNp w7NuIGRpc3BvbmlibGUpCmlpICBwb3N0Z3Jlc3FsLWNsaWVudC05LjEgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkuMS4xOC0wK2RlYjd1MSAg ICAgICAgICAgICAgICAgICAgICAgICAgYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBmcm9udC1lbmQgcHJvZ3JhbXMgZm9yIFBvc3RncmVTUUwgOS4xCmlpICBw b3N0Z3Jlc3FsLWNsaWVudC1jb21tb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDEzNHdoZWV6eTQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYW5hZ2VyIGZv ciBtdWx0aXBsZSBQb3N0Z3JlU1FMIGNsaWVudCB2ZXJzaW9ucwppaSAgcG9zdGdyZXNxbC1j b21tb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxMzR3aGVlenk0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsbCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUG9zdGdyZVNRTCBkYXRhYmFzZS1j bHVzdGVyIG1hbmFnZXIKaWkgIHBvc3RncmVzcWwtY29udHJpYiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOS4xKzEzNHdoZWV6eTQgICAg ICAgICAgICAgICAgICAgICAgICAgICBhbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGFkZGl0aW9uYWwgZmFjaWxpdGllcyBmb3IgUG9zdGdyZVNRTCAoc3VwcG9y dGVkIHZlcnNpb24pCmlpICBwb3N0Z3Jlc3FsLWNvbnRyaWItOS4xICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkuMS4xOC0wK2RlYjd1MSAgICAg ICAgICAgICAgICAgICAgICAgICAgYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhZGRpdGlvbmFsIGZhY2lsaXRpZXMgZm9yIFBvc3RncmVTUUwKdW4gIHBvc3Rn cmVzcWwtZGV2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPG5pbmd1bmE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChubyBoYXkgbmluZ3Vu YSBkZXNjcmlwY2nDs24gZGlzcG9uaWJsZSkKdW4gIHBvc3RncmVzcWwtZG9jLTkuMSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG5pbmd1 bmE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChubyBoYXkgbmluZ3VuYSBkZXNjcmlwY2nDs24gZGlz cG9uaWJsZSkKdW4gIHBvc3RncmVzcWwtcGxweXRob24tOS4xICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG5pbmd1bmE+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChubyBoYXkgbmluZ3VuYSBkZXNjcmlwY2nDs24gZGlzcG9uaWJsZSkKCg== --------------000300060105010104090305 Content-Type: application/x-compressed-tar; name="postgres.log.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="postgres.log.tgz" H4sIANdi+lUAA+1azW7jNhD2uU/BnnxRDJGS7djwbhBsfy5Be8jegkCgKdohKolaks4mfZs+ wz5CXqxD/ThO0CKkncgKEMKwSA4pfvNxZvhjl1KbteJ6lMn14I1SCGkSx/aJp2O8+4REwiia DjAZTyfxBJMJGYQ4nuLpAIVvBWg3bbShCqGBWPKM5rxIBf3Pdi/J32m65CXCYxSezuPZfIyR 5uqWq5CgsjGMq3GIx9dzdEVO8DUiUDgJZye7Xb78evkVyZIXWpQaXfz5+xzBawrDCyboHLIZ ZwYZusx4Au/WQhZopWSO2sL3G65406AAjj8N9WapmQLK1fAnJ4STrhGmMqei8EEXHYauHrCG 1eTdBp92To2gEEwcqZm+BjXZOhFpwGiWwcOiSzZK1BlD14GRVRketmT93SRG5NxmDQ9sVm5M 1Z+rhGn+rc7znbxKFLThieamFT6rgJ6yMJRt5U+KKtGS/dWKqvwtVToolVyJjOvA2ntpklVG 17rtUopi/QTPY0XdLqfFOuNpstW5rahVbqylmg9Haznt2looY46mMusaWgkDwxuEufdBeKAx e5JnxC1PvlPDQKZ9YMYdwtwH3/gwfI9zV/kFvysF1AT8FirrbxsyrJsABPusY2rQQK2qLfht RSNvgkwTS7YhJpMgqD1T8Vwa3uaZVGkdKQLr9ByGLVYyaGND068pNQxWcWmjoTfVLbnPZtrR mysmJ4cxuWWiYaChsCUUtK8RPjKOECjNFVrebzt7wJ3uCTcFuIbXWFqanIYlYdeB5Y7R0s0X CO586yUy6YiNvAK2Xcuya1pAM0F1DVLkDFxH5o7WTqKuubLea0DkyFf0CstD61A1tBZAg60V wh5sk+f3VRBzxBa/zN1VyjVEKslEKq8bgIWE16Fyk0oEsU4shUIpNVJbb0QsExb/HH2RBb8T ZwW0EYUAdTLxN00pAFAooyg/+7YRBUVV5KRueH12tb+dfz2/qMHeUIhJMFR2VnCKeIHKdXKz pCPQa4VKqihaLPCMjPDkdIRHGM8+fw6A1g1VQoKoJdjWLilonvJG38WiHc7KLi8vEGhkY7Z0 0ifyP2L5UP/w43+5f/jHm/warKchA9l2mVMPP9AKzi5AHFXsBvgBorguuaKgCEwIYGJbzDuq uJmF//b1eDTWYHtJ43uyRtJfa/Q/sRyRxn0OL53QGDvsz15Ymyjjpb3ms6GftYsRBOm3WJoi /y3bEUM57uusRw7O06NZjx02wz2CG/nv3Y9opKSvRkr8752PGOH3uYbuxtf9T+BHtMawtzT6 H4CPSOM+p+Fu9hsOC3ifQrnDUbhPcB2OaH2C+54ifNTfCO9wv+R2tfv8Iry++Wquoxc4jgmZ zU5J6AFr3yu5XVjPbuJaPMOnrx2Hc4KH6PyPX9oWP38a4tk0PAkxfFCI52EIH7dLuxq91w85 R7TNeI9fdQ62zWP/veIjfaSP9JF6m/4F21qIqAAoAAA= --------------000300060105010104090305-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: The process starts but after few seconds (10") it goes down. That day we did an apt-get update & apt-get upgrade and libpq5 package was upgraded. A downgrade to previous version fixes the issue. All other apps against Postgres in our organization work correctly. We have open a bug report in Debian's bur reporting system [1]. In log we can see some access to database (Postgres), but after some queries it refuses new queries execution. An error message appears in log saying there's no authorization line in pg_hba.conf: Sep 15 12:03:27 server01 opensips[17471]: ERROR:db_postgres:db_postgres_new_connection: SSL error: called a function you should not call#012FATAL: no hay una l?nea en pg_hba.conf para <<192.168.1.119>>, usuario <>, base de datos <>, SSL inactivo#012 And it's true, theres no SSL-inactive auth line, but it is for SSL (ip, username and password have been double checked). In attached log file completed queries can be seen. This issue happened in two different environments after a system update (apt-get update && apt-get upgrade) and a service restart (service opensips restart). Before each upgrade a disk snapshot is taken but a restore from these snapshots (opensips and postgres) doesn't fix the issue. Queries executed [with psql] from console in OpenSIPS machine run ok. Adding no-ssl auth into pg_hba.conf OpenSIPS starts ok. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799663 --------------090309030509080608060300 Content-Type: application/x-compressed-tar; name="opensips.log.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="opensips.log.tgz" H4sIAGpf+lUAA+w9a1PbyJbzeX9F534JqWVAsvwA1+TuMsAk1CWQAbJTdVNTqrbUxrrRa/Qg MJUfv+d0S7YsG2yJliyEM1WDLVnn1adPn1e3PJ+5oeWHe7Z3+1NF/xT41+938a866KnZv4oy 6Gn9gfaT2ukN+t3eoKfA79TuQBv8RJSqCMr+i8OIBoT8ZI2YTR3mmhZd+rtV91/ov2vmE7VH 1M5Q0YadPglZcMcCRSVeohhDcvLrh6HhBWz48ODTIGRDYnvUtNxb4nhmbDOyH4fBvm2N9tNn 9sWNcN8c6b4XRrcBC/dC77+qRRZaty614afVo4rYfeT5dfBk18CMUxRHwG6tMGKBLkAMyfSC fzckkVMImH+nU9PUQaIBHRL+h1gRc0JiA0xihcT14I9rRRaM7t/MLAQ9ZBFSqYNQqKMDnewe KSQOjYwJC1PpFKR5KdSxF7sm+WUc6JHlsOCfQPMMPPn6+AD8uQ7uP46uLs4uPgwjZ6jriD/F MyT/SD/+Q0jrOzGZHzCDRsx8Q76EbPoLL47gNy4MFTXfNF+OlntXmyynuIQ8p1+flGn6q5ck V7DFsOJxnj1XZ9SYwA98+0GyjDfIoedyhnR65+NvWFWcFTe1QSDX1AbB84UWBPmhkAE1GQrq w+9N0DXPiehtdiAA7QYHwqH34+9mHT6J74S3tbgKjqWPrbFXFNHS0Utg5RUjuSzPxAMw3QWv OqsYKe5qDVCdHOZtkHQOiytLHFhSFAXg5EUIl6SJLw6ZDvD0iI7sOREi3k2KLwxsz5AjQQ5q QYj8qjQ5ujTSR2N73gInmKudZ7WwB2Fmfo61hzmcA6bnUMutkr8Svgx3RAJa2KVZ7oWk0Bac kfSGNIFGhq/7LAjRjXLBD85Nixkl1SpPjRybbExjO4IY27fA/W85t47lvhZO6f0r4tTw3Iga UdWsFreENI4m1fv3Yg2QYmwFqPyoiatVLsoJ3g0OlW1SX4oIEVBegHhNmvhA28fWLQQK844v x7tBAZoWtb3CGfansxgCpgS15nAW1FoS9FSt7VudY1jUboG+WptbD4+Jv5CkNlvK5BL7JJm5 EkuJISeqBDh58cElabJjNLAfdIeBwLLyQ6zVakbFfAXM94JIN6hrMDtsFWsmi5gR6SY4i0Zk eW6rmBtTWCZNHRxBN6ScvYWw7sXzCPaqjTw5VhjC0LWONcMMqmWqRIUA7bUfePcPcooEU3AL WfTpHXkB4BSkHnrGNzbnlGQoqbhqsCGWlzhi7eR52sOjWz7Wb9vPMQcJ12z68DoYtgyGDpZp mTRiVbNbwgO/80uUa5evMBzUwiLDr8qrsN/5i+WxBHPFC2gd7C2vfrSHP/CA4sDe8lbX9PYD FjKI7qrP16aY9HunhibOe0NSYjMlO68b6XV5Sz1/Dns/AfJcrD0lodo5kB2gx7jFe/KiVC8A iBif3rFl/HJC6uG58tEdU9seUeNbxxxtcGgrZzNTgdP9eGRb4eS1sBvGo9AIrNFSVW4Lw7iE +eioYseA5Zlt5tWwGXVr4bPEHgU7LOGVr9inwGFW3yXD7mvpM40CWtytWaoPKbC8xqXX5XXi IDR9Phc9RV7trKqNR+ZicAar/jedA24zrxyaqUPMFuRzGfJZLZH/DC1bUn80QlrIleBFeXG9 aeoLGRKOtuJcUPWs4W6AZX5/S9jDPiVsLIwefKZPzKCFLAofkKelW8gderkO6Ca9ZVXqZ3ED ZjlyugMATl6CcKnKzgrEWK1eVMzThIYTPbT+bhdXXhyN8JPO0+6VsVZc0z0fi/g17Jpi90zO nEJA+aHCa/IcgvDBNbJDxDFucIyM8W0cWbbkqCyFKmVv0g+xTeIHNYwfoorwQ/R4/UiD2h+Y OP2Reqc/uIn/Ub19zOXFqzckUoUhd7ldFEcdfoRUgUiPpBZlUlOsKFUs+LMKRYLgX5I4KslO zoukppykVLFIbijLlxwrbySTKgz5Tc45edTSwC1XJNL3peRFInlbSvUikb9/NieSerbPShWJ xG3nS+Qhc7/52IKIy3DwzCPebh7NMg9jjMQMFoa6OKFCnzBqsuCfO+q7rH/E79VBUGjrIR7g IU6I2elkqQglFqvxGB4aGBNxZgv1MQzxvmEYMvYC8lUUCizzT+wgIeTnhLyf1UJIXPadw6e2 ReE6NU1mEv6FpAjIdyuaEPhbDPITArT8JO+/o7yr1J17nAYLtIlFE8/MqVGYHk7SJk16Ugw+ gygTHrXGFjNzIyLKga9mPBpBREPMi8GCqDLTgsCnZqVTCKp/pyOdsa+HPjP4STmp6EBO4qg8 fkjeV1BeodxhPPoPMyJZA4Q8YaNHlBsc2Y185TnVDVeqLggvpDJtSHzNVB+0lzebaxyqzRuO Rki8EUTAsPMEMVY0k0GPQ5w18J1gqZPsDN6lZyASb0x+ORbnNfzz5WlXXVbvcQpwm39ip3JD K/cAgCbPsM1TwEcB4tDYjiodhVXuCd+OHIXVuSgJgumy1G3NEDbCTE9oqEceHoA5H3LUlFVg 7i29ZWK7flLpnaejip1XDR+SRhCxtfJNoKAuK7/Vg8ZPyGipAGSeGd1M3BteoMDbgcAi8OIo nyaVeUr0+qHFyfkHPYxoFIeyOLwDR4tvIxHVjRyXsmtyDZ9lTSGC9yHbnkHt/HhILgg2XBQQ Ok+Y2J/ghvmseG22z6Z5t7T9uBsx/Nu1fzsLGsB9I5Rg64k3gYKGRGQbpcA3AiYOGs0NAW9V qUUPHlWC9JCmV2MWts7ilogNRa0NF8LmF4tGiCFg8APztStDI4jAGpc50v+KWQAKqW2mflsj ESuKh+nmKlZd8+QMxbSA2JNlXugdW/R/ZL/yoRHj+HTjIu+GjvTJ+JVMrbJaXUzx1mhqUXvz XS3p+1ZakPWHtVu8KJMFgRfkG5RrWbwbMb+Sl1RGXjoWbS5AbV7lGzHmW7818VtTO5qjotZV NrQZ83MEpPvAa4rkvsX+Jv2MRihDpIOThwngjWW/N7USNkT8+NoKatlxwHJ01Fx/qAz3Sq8u MjyTVRiocPjTKKVfPfHFUDRcQ5uREd6smWqA09wIXWiEFzehrmmz6cm784Mh/yyEhg9JIo3Z wbybk8fm3evNU2A5BiwTLr1leTMh9bif1W7t5hx7PKJKhwmQo0HuyVVPbKfXw8hbcKYkny7U TI+2AcvUq2f/lbspzYlnNiP/TS8/9VYNVu5hs23dZGFkuZS/n1EcbFLhlral+Kah36A1W0U3 vMY2Ig5oUAa/QaQkh6imhMxZweRebfMfiGT3lc12Dn06tw9kEu5Ul45yZpmow6plXa1MipG/ 0piYzGZRvu5fe/NGEjtsiIhN10QSIeBpwBXLoO3avNml0dHN2PHzG77rCoGbMaEj/TsNk7e6 24sHf8mtrq+5x/Amic94zUCuOvM3F+hJ1b7C1WsOz+zkPOXlTZ+aDrdprBP/ihNl1eMW7yvv hFEwJL/Epj9UDzt7av9gT91T1cNhT+krxdRoDmBkyAZoh4sA1bUAnl38dplAnDi6wxzdci0Q NcTingFhOEyo64+fyAi+fSs2fACNA0kA/qZffr45+3T279P3al876O6S/avLLxcnN5fvO0q3 mHewCPvj0fVH/RqBd5TDw10Cv+AkE3z/x3tN6z8TAz9yNiQ7yv1gbB5oWq/XURRll3SVTr+n qQfdd7skjGgQvZ//RbExzYxAgh5uh7GBp8sWgsQh4HZ4WEI9WD8NMBVDJDCChcwy8C3CvMiR Ah/Htv1A8CkLVoq/mVlMdTg61OrEBDMfkOp2RPCY1gkjN8efieWR77g1ioiiG9mhceQRE3wM I2Lmu+LsodIT5vJOqHWe/uPo6uLsYgGCaYV0xOvghudg9i2EIJuYMSP/Pj/7lfiBN7KZU0b8 oZ0UGIvRmRerHSZv04Z7n8VJw0jtzfn1dB+Tssf/GyrFrNyUTCO610dsQu8sVBPXIycfU40f W2Ba0UkBOjJ4YODAPjNzNxlx+EpjGPC3Oy6o0ru369BxcXlzdnz6JCkXHjk9JkYMz6YYJUE2 LH8C+s8du5BFBHTx6Px8+Obo5OPwvz+effg4fPPp9OTsy6fhm/PLP4ZvLr6cn5fTsiW4bQv0 gdzxQ20Nnusk/BXDFGbCHjkWt/EQUnEfPDUa4BHSrklhIj/sFRplDAf1DLBCyvgElLf7LDJm Cy3ox34KYI/dU8e32R5MqT0jiN5m7MwDf1tNKex0SE5Lkw4PHx8tI9qgez5zypK4oGpz8xWm EiAtMH04ef43a//4aH+tSZTnUjet4FliEgCmokppWSIegvsrwX4GfHl5KI7MD7jK69/YwzOU cg4K/G9txYTflh31rY1uu40Wjz1mo7cGeGuAtwZ4gwZ4SoERMMQtjv7SfcuHiYH/J+KGSf6H BAZ5TyBWY0EA6vCeXJcIqEzKHM+FyGgIUYwVpZk7gZbwDmU+GMbEss2AFXv1jeHFbiSivvT5 IVHVKTDu/d16iBRM4IjxQK1E0JNhwrdMsWzgm29xqhDPNvHqLsHcCjUQGXxdjeOrOuj2D/7M hrEM+IAPPIsNVhw+EvwIhtyxojA15RA0d/uDblcZaAPlsNdT++oaOwGn6LLzHif7EG01xm7D 6W8J5kL2ej+DApKd+4O+3u/uQ6QX368RbU7xzJZ6gUXYC+2gSz6NSDihuIUWgva15t8qoB2E mUynBCjxYRVKXjBTZjBWZJ4BAkT8+iigrjEpkXdeRPhE+nkO2Sz5XATNTHDszkqbiHV2B8Zr SK5mm5r5FfLLqX58eXWq33y8Or3+eHl+sqO8WyMr9kxs1x8/ZTCqNWD8/K8PGYydQhjnPU3H M4ezPFDmnaLmSPe9MLoNWBE15OxkHh0CtCSjlkWyt7eGR1WU4ukGh+JGZfroI/SmKErS/VT7 L6ynkSO72lWYhDB/Ys6z+9+Kjl7E7iPPL6xryWO16pldlMjQztB3lgV5Df4EOwdTD97YLfin Zaj9dNK7jgKAdhQEFDwy+I6tdUZsoz8EjsWgo7JRnx50aWegmn3a77HRYDQ+pJqqap3x8ySU 7k5FbngCWvhJRWS0roY4hZXDycj95hMsdBKU4xa8nbFNb3XL1EcPSSXyN7hA8COxQoLR9puC oIFU4Q9S27ZAAMfw9+ezkxnBPCKFGHBAe/1DhZndvsKYydQ1YpY8IqyT6LPcP3oIxrccJlHc WMfnzEOPknpGZDngnw2FX47DqPD0hW0zm/B7gCKIjSgutsIkWGbjmsACHzOcWOMIB2CNN/YU n0aDw37n0Dxg6gimzahnaj2lrzFD0w46SrczXqPcVBznodrp00FfG/dUozfoqyM6OsDx7xxo mqH21ni75CLOzJu8dQwGwIDOeRrgz5Hp9YD9FbMwIvtElLm6Y6PbH5trlLnWRHwsPkDcHokF qQaWfIg8swwNYCibxRA40evzUkGUEFMD02NVxwcJmllksMar14qvRYXWjSegkk9nUuAtW9uC oOjaFgQZGxgEubVNPoXifaZFqRRP1RsFJN3bhZ209ME6qXUsfWyNvYKAk6fwb2Yd5BspYALD HcLuQWWxl65syPI02Wu9yHcOKDzxiFxLRzMITkQz01gGIs8R3qK+Nffy6FlAKj2qSVFyWSW5 5RHBSwSo4AajXCidxWB6ieDA8rvM4A6aWL96HaqYA/Vgtt4g377nFXXAs0F75jNukNNnWIfI DFjq9zn0FSHLIDlUlPf+t9ukTWZn0CmS0yuCEx8W3SGza9MH9/fv4d8Q//e/CbpONsU9Vaoc cQNJxH3+HRxdc3TuQbC4o9yrhxrtjJS8KFZhK6BWlgugMK2eaBV2+MyPiiRO76gtmts+/85C g/pMOMbgTrloLyCMVYgxoUG4S7w4mn2VhD6MRw5YPN7IOqd3A3rApe6av+O9nZBhdxWJ6Mhm epKBFqWA9Mv3CThqyQ8wJHz/drrbP3hbdqhQEcRZ19NWPUa6B2T0gN0iaGXEXR4I0WhujPqy xog3oE7JWBCSuHHNSyQ7nz9cnV7rN18+n8Ofy3+9g/sQOV/xn3DN7WqDg8Ka+xhlt7wEYccO 1gBVknzEw2TiwE0LZ9iZxge45Bikcp9hmo5EZ8lIpETkRoPmjaUUnlHYF0efTq93srjANHxV /nz/dU5b88ucFPxxyODH+tnFTco+tmRLwgTmCZ6K9MD7nhU6yno21ukIgKGC35FRPB6Dz54T Pis6FRbGPkfDsimIPyEUVmKwaTHLKwCVZjLnxcLnF8e4Mz8zd5Vd5d37rwNZ4758NCB6y0rC +67DCIDy5blf6MuVQwZgQmTHXBly+i6Rd1ihOiBjvmIidnQUUOerku44YAxx1C7PDGJZUymL GMGni+3n3w2b0SCzKGTWspLTlcOfGqcpM3IN8xyyebGp3Ag8E978KCw3Jgs7eZ5BtLBbzzRW 8/ATVyE3ADJ8FLEnCDxSQOJ4dwzzNPB33nOfrftLIqKyEyXRraxTDvGoFU7KO+Rro8IICC/u zPvgpbzKeoLodfWlfBC9FoZVScLFjEZBsEvTJGEAi2NBuOKh9ZIlT8HiSa0EWGyLmgwWekJR 78EW84A+8P0ypLeQed1qUIIhbahaGJYzN2K4owZrgaJf3wUrbTI/YNwfekO+gE8cuxYscxB2 eOgihTymDfPFwbU4XFp3vGDfOQHgAGFEDEEZ+fNrp4gECzegfDnXjy6vwNO/Pr262dEWek+q QHZyen56c7rTLYRs/blfZpquKBLIgLm0UJAeDVdU6tMH105vr28CnugrsfLbZUsdQyqDlGd2 2TyTBLDA3D4JvcjJRFyURU1qsZaNeOOM1iCxWQu7JKTM7DKzZc2JSONoUnQO4jOtnX6rjl72 rZVvt1kLz1NnR2OX87SYnO8CkTDoYptBUeeeP/RIB9jW7Xp+mWK8uvolq/6yrPq10PojC9kU SVczxiuqX7JwbqtfWbV6svrFR6Wu6ld/rvjVr6f2RU3l2bUvYf3qr3t1NXOhq0t63UsIqHDd y3x1dS8YjcO66l6Ai27rXs+sEsiue8GgLHSNVln3gpmZ1L0KZUMqqnt1NbbQI1NH3Usa74/W vSqS7oq6V3XyXFn3el7B7Ym6l7mRulcZw7zxuhcQXbqQv07dq4yxKlP3kuqjFHTikmMqxI5y 8Xnro219tPp9NKF8VTpn1zdXZxcfKvfPXE9YEjkDW8eqkWSmAsaTheKbzn2IIbmInREsft5Y MAXmIbESyf1n2ccNrlDK81eo6oz7tqkhk1optRw9XpErlbtdIydsm9QvWgjAZzIJ4fOTo8/6 R62npDCf3MxTFPol/AgxANSO0tVKJd1XpMXhgleYTPFUhtATfuHZMngZBUFOQpB/609Q6JVf 22pB0bQu9+w3Vy2QmQV5Yq/M6PBgWy1YrBZ0u1rJVrn11GrFXpmRNO+6idWCrtY5eP5OGbEm bKJaoGkVR6KpgIpFohpj9BVGotqgvkhUO9hWCxpXLdBG9VUL+MxMqgWHr7haII33R6sFFUn3 tVULxKKwkWpBccPcgGqBZlRbLShurMollCT6KAWdONPGFs5dcTrVLvoJehxY4kNEb3cjj3+H P/iNnx3FD4DCjxHbxY/givLnWaAbIftLfGaZzwEIOsajXVmU3sxdCPiJONSY3p/7Guj4jpT0 Fv98h06wH3h48mm4i3uwfdGPGqaP+CDwOXpmF8TvHOre2szUpzynFwTL6ZG8PHPxot3WMYuM SfPd1k6vfr91oChrO67SugFXO65dIy2h8NlZpcf669mHapzWNbg0gUsVuBTG50UWitbgkgGX HeAytTNt5XMMfGopn7BYtJTPngJ8djGo9Fo8mj0VuOwJLls8lh3gsg9czvyal5cdWINNDdgc CDajdnLYBQ4PUF2FP9pKHnvA42GyXCa+dlvnZR89AyXllbWa1wHyqs7GdRoatZVhzMqqndng tp7hQ2RYy8xcEdy2lV3s/1K7mcnbbnbxKC61NxtdzE+0lVeMS9X+bGjbzCuPTtFrwlxTpSH4 +eWvm2ERQ1MV3aY0k9bWscTYVEXfKZspbKOT2MfotKPMrNE069lKbjFK7agze9RubjFa7fBU UmvVFyPVDrpK+ex8Sy1THwPXTjfD8EtIK4n+TtFbzj/rljv2xFiZoyF/+x/Wu/Bq4NBZb7NJ IzqioehdUJLqynP6l5pYSC1cKGhGU3vxglNTm9pLtQOujWrZSX2jwwNJTe3zx9wU7r9ep11e Asyl5+YYRU7FEsfmGI8dh1fy1JyVpxL9dnR2rt9cHV1c67+dH30g2C1X9oyilciOT65SLJ3S WJrf627atzkakqq5bDrKvaBr06C3bfpurqVmk2368toPn2rT17aH+tTcpo9qtapNX1pHzco2 fW2uTV97OW36sCJvpEdfWnPNtkd/26O/idxGq3r0u93N9Oj3X3GPvjTeH+3Rr0i62x79bY/+ Uz363XKHJSwnekmPfnFjVTI/Vi6vt82PCde7lFe5MsUC63mSYdGqy+MAkk9n19enJymurlxc TU1hFD7U/+j4WD/9v9OLm51etW8PQETHJ1c7/erRJCMv2Bo89z0FS18Vy0yL+oH3/+1dD3fb NpK/j8Lbvfea3CoxSYl/pFv3mjpO12/TJI3Te7cv7fHRJGRzQ5FaknLsfvoDQFKiHFnCgAAk 0fRrY0u2MPwNZgaDwczgjsvp39GdO/ELL5rL7s9dUll16B5JQELZhC1p7N/LhtMgtcJkycA0 96IAm0/siUchyc2VDewBvRU6u49Nt3qOHWcjt/NvL67efTxCP1V9E3y1wFMJSD8psFFOoU4X SeAtcoTJBDcooOaGGAQ8Ot3PaP61HyV5oc2mHl53ApTjz9H73L0b5IeI71INIO089kioElvZ ecy18IEJRnOvyPwAGvHhIkb+HhU3adhJVuK/nyOUkehFNI2QEpBKOdrt6SNvkpuruSIXPSuf hlQqFRLS2LDylDspJsoJUoaWoaxO4lOqCjd+7hVp4fMlTQGJoeTav0ZeuQXljgocND+VEutN y3Gblq7Pn1JlKNThUkhKqX2O0zSvalZVkLv1Yxqp81qk7R6yRKomRmsUSDoA9Kjt8NEVHv09 CXIkSsJHRRki7xipfsPaS+QhYuu95mMmuA+vWR25eZDhLatfKJKW7lrMbnso3SWmeFfQ+yjC iGUIfyzs6NQpPzGo3+wivdy/VSIhqnGR01zsKqCk8G6mXQSoMBSVxyUtD2VZqiSPQrnWzedk MSjSToYSlduUjq+tdU6tGl4iBLmwr42z92WhhJLiaE2CvpJwRsd0uvvBhWgW4N134l+rSd1T J//oDmFkuZJjj1lZO9w94VfskHQcnEIbuQ94aeJN/SheqFMERfH6vWRZ4jdDFCM1kYXqTWVW TJm/Vb1JCjq6uAeYeeFippKR6kRSsf/aWeOlNt6r1Ex2fEXtdAT2xk/CGNWVtJ1jZwWPZMEH WXSlymKqD8Yqy/NXuZ97AoHRPZBM56TLQ97diGwfcjgqUl/9nJSzByiO1USZ+5rZTqztfc3s URPra2aPl5XdlUqlQtKn6B53zmy39a6vmT1iYr1pOW7T0vX5U3ys0MWdc18ze7wSqZpYhytS ul2h2NHzyY4vN12WSMXYeq/5mAn2NbPHmtTReyg9sUPbFfQ+isC6nqCvmT3K7AbV9Pqa2SMF 2OkqjieQGtbXzB7pitDXzB7TbPU1s8dKsK+Z7RNYD8Yh6Ti4Tlf4dLjsrK+ZPVp/q3qzr5k9 OpFU7L921nipjff2NbNHOnOqLVdfM9uNYGxfM3ucgdG+Zva4RbSbIYcjq5ndetlxaYvBNaP1 xyYETXnZMX72RRaf1lfiTk5OMMCM3mw/9/P8a5qFP1SDmi/RnT+bx+hlkM5WF/Y69ol+Z4yH U3OkA57n3ftPF2fnmx5pE+A29zA/fnV1Hl1//8xoXl2N30kw6UT87dWHcpE34fNTuKiZbCjT SqKCNElQQFYITb9zpqFrmf5o6Ji6lqRFxQWMe56m0OSmxkM2fyabB29FlapZFGqnD8hLIrYi Mgod93T+5dqb+XGcBs8c87kkmuTDZBab7zWMyh3+mpB/thsTSQ/34ZccFeHV2/Q6Sp4RYzUa DXUdygqAWOFVAGUFWkqV5ucPZkUQ0ls/NvMiIxBRHvhzdFlkeBrO8JMRQzrRDB2vVX6WD7R0 UaxeCiKPPfQZXqfo6rcmd4HtUq4n4S/kd89yFGNOaYV/hXcumFBOmEZSCrX6xdcblKHqD8jy c/pdteGIivvveKeKCEKZbjrRqAb4BdJGrnZ1X2CjRqxM+Vs8HHbpirU5CkXNEXWmlo/xDZPK X1wWfrHIn3346eP5pffp1w9v8bf3f3+Of3+Nio/0T6jkDhHywZL72JPhobGexItZkmPR0Kof MU+KRZZg6aUTVNwgjdvNxdRqvq8oLWfC3DAT9UOszwYSZizXMBNmv3v18/nlszVa7vPP+u+n n9ekFbrMMdHHvhb+Y+/i3acafnE/h3p1j1HC5gl/Cru96dcm0wmvV3NdzwA2VPjvtKvFdIqy deYPkQFVhW/m/sEzbFJB8ieaj1dibNMW6BsBsESp4zpbqH5Ris/WNXOgD/Tnp58tUfO+eTZC PBUNTqRfPTwDWPgeovdFif/6Y2BKhNgZFYYH8i4QO16hTMxjumIS6sRRIDIvi7vTDCFCQzk/ G4RFqVKTMBm+Xmw//BLEyM8ai0JjLeNUVzr+0jgtwYg1zGvE1tlmUCPQcrz1WdhsTGxeg7bh oUu71dJYrY9fuQoPJkCmj7Lbj7TW/UjrePxIH7vot8j7SuqA8B/1zuTSmRyN7LB3Jntnsncm 1TiThi7bmzQP15sUB/5Rd1IWf5+aP1muC70/2fuT0vxJd82ddI/Hm+zdyN6N7N3I3o3coxs5 esIxSWHYH3UiJXG39yF7H7L3IWW6cavzYm+RRQN0N4/wOwN0i98s//WicFCkJIUrI9/DdOZH yaDy6Lw68Wn5RvX7ABvG8oOFfz2gfXDID7QXjhfk6F+DDM1S4kyUP68adwzyNPiC19YomaYD rJWFHxT156pXlWUb5NTXwp/289oHfRC31I7a4ZwijOLwD8FNXb3Hadk6s8sZqHM5p7Zeupzr eiXT57z89PHi3U8S3E4GtA5Ga2C0ldk4PteaAaOLMZoEIzGGXZ3IMQY5rEFii99VnNgCYl8V 7wjLBa2rMK8wTKuEWa7HXQUaYKA2BvrQHekqXrw7+Ow08HZ7dhFG62K0pTPZVZRTjHJcKit2 kbuJ0tJ14ioQz6jeC3QVqEGAEqdotdfpoF9k6SbBSRyjxkauk0CHBOiQAl3tUrsqvSMClnhI jV14V7FaBCtxk6q4Qldxkj2pYa8sUrfR0j0p8ZGO9ryHASTZlBrENSpDYJ3ESPakxpjaXRLf O2h5XVZk4u/0lBhTJJX4E40UKpLYLzGk2cwvlqfloV/4Vz6mr1d9i9uc5B9ikjM47LYlNq+3 P1A4/Fj8MpZexdCrIHwdksc+cyk5q9iipmG5QZl2db/8cB/wlh/wttTHu43RQca7EapSLDoe eEFTt4x0dzvgortPINZtuFWsu8OHFiTziezi0KEHWpaOE/nBuykzVyonisV5Itawd6CeugNV dkEsRaM++j9qRwieanr2/uefX717LccTUqIdRySwlA7pUeGR4OcttlT0+3ovj5VPKLBHSmVH mm06plES5Tf8LTqYSZGeKOTN5koTOi6Xoq1aNdUXC2g/X1Dt4mzTBGgA5d3NuO7jerwbEW3L cxf48wedkchbqpsiHUZ/JsqRmuEPnqd+W+TjLP2I8qJDj3qwEy0v/KzQ6ItT7XP9R1IHf/mV J2a+JOGH4XL8RRCgfLqI43sNv413mdUvlgx8ocUoOdWg5kslHqnzAWFWiaNmmTHiMvl+liMP /+vPSMo5fkW0qnxNjNfkcx77UlhVXhnNpaRMDy1xlvkeHTTHJYn/wjiW88vlO29fP4g157aS fQu5hru1xxZyAp30x1vIkX5mfQs5pS3kqFhtbyEnsHvgzlLN0Vqp5khNqeY0aF+qSYzcHso0 LUOXvncu2XMohwiHXKZpGZayMwRMqy/TPLQyTctwVZZpYs3syzT7Ms1jKdPc36EAh2Hef5mm ZYyllmlyGCuuQDGHj9IHihu+d8tA8aYteRHnKXj7Un6o0Ty/fKMe88UaJc4m+tsfO0PX6A4w 7MW7N+8n9EPbW/7DHra6TeDhuN9Noxh9VwaIEAnMRzndr2N9GGjXWbqYazNyxkaDB1FOFrGW tzU8PAKAsoeR6/gzReaDThYo4+vPPcJ7Tgkhjuk09q+9KPSu7unua6K9wW9o5EfK9EUc/3sf cGp3HKLsjoiNj1BLtpfHwdWDB8lj4Q/ieVUgltywMvPnE3q/L2E6YfRnKsWkupPcwKJhQ1c+ pSFGewkZko5c+tYcysZgGcSMusk4zPIoToHD0s88ZpHb3L7yVHR3d1QPWXsNFovrVvR4sNgy wj5YrDhYTMRqe7CYzEofLN4RLCb2bx/BYnMoam76YHH7YLEp7Gae3cFi09X7YPGhBYvNKznh vV3BYvsJB4uFYX80WCyJu32wWFmwGG6YDyBYbIpMe98QLIYbK75gMdxH6YPFDd+by6s8gFjQ rrgIT5yBIXwRzQJoWBN/RFzsYn2wUNQFuebU51OjPozy1MIofc7dIYZRBObcPRbJIA1ONkUy mqX05KBlgK0bfja6fmJzhT2FdLaPBrGWOZWd6lax5FCiF6M91MsbJmv4Ygi6gr1d+GJY94ft bq28Nay7wna5Vt4a1n1hiWk5vvgTA8C6Jyw1m0c5i+v7/yQtt4NibJDsrf/SRSf1L7RnYng1 WT3tCgWBRQmoiyvALeZBFPpyLLyHsqvsowJCUsg2b8lhe2eGLIXWA27a4adzwhmIolATUn1M bO7SAZUgb2caukPguAj5TINd5OWDnEDxzxlMrxdFFINnt/5c43nxenDj5zceyeLTrqNblAzq ND36C226SKiS4UcowJ73t/QqONo8S6/8q4gMqhm6NkdZgBLwirckkN/c+hkl4WGX/gvtpIe/ aX6W+fdYnv7APr7N+/R0WEoBj1sZ0/Ilkdn8xs+QNsNWFuQVPDYhdYSunnYUDrR5FGrVB8Wa Hg5BWo4aYBWmw+LH9fB0Bnn98MRp+tciwlwxsT4UmU9mO0B5zhevoo9PLDy1wROyUhfrJtkY taMwje48Pygtn4ZfUFWbetWY3sy/m34NvRvkhygbaCeoCFbmqP7hJeblZGg4oujnsUdiFHgZ n8f3O4hy+ikbiEZzj2bMbSdocpXDbyIYYe6i4iYNdxAE6+6qlL0cnwhn+QN28UxTh7qk+I1Z fk0SwfGTL+bVqHWEFusnjdZXFD5/+PXHtxeXfxtc/vrj5dnHix/PT1xHB5fTiJANU5hs4Kma I5SRQ+VoGqEdMzY0FYvIcChURAyZEqJ9xrvny1c/nZ+YFvjcvDWjxkIZ5Url08fzny4uP51/ PDFMvrWvpfqMLFFESY416fFbbCfIV7C1I5M7QFnxIIubSz13kKkieOuEoGqJP7ySDcqwiVa+ V3NycPL67PTZ5/87+f0vz3f++PI/B7+NXv42fPmb+fI3Y8CDmj6ERxUgm2jplwH+ECm4aOaC BCLNLIsWW1xp+Mdq7ua3HpE0IhFzFFTVL8vTydLHjLFnq30u4mqZwrP2TxQUXgAOKSsT9ZbQ 9mEPLS6MLeTcFrusu1C1gfl99XI1uHj3PxefzvGqNVa9vAtm2IEbhhYrrc21tB/GSptm134S /UFb3D4g94JrYQDTo4GPWUuq5FScEKRWzqMnR5O6VRc1fOUZfJO69jUqbogUgXfaMhwLSf7E yOW7XnmTNsShP68md4c+cO2xj01Q9xKgcYTNJoSosCANFaHymGwHSS4veJdJ9ZMAxUX+QHy4 0Ckk1XL2wI5KW7+BrynG436DTK+h9q6EuQw3fu4VKblyXAKPNhFEybV/TRgXRj6JM9/tEgeu oE0LcRhzuS0dEYc98ej4XG1m52IsLI4GsKFjYUrDTnSkK192R3x9hnZ5Ul8TlClx2VaElG4q CNnVbqKjLBR3NMiq6iO+XspPiZUAayKOKNuaNuI72u3SmlawzAvfgTQ/OWErGZunOxoKW6+x duWovAV5B0lhon6LLXxIEv3LRu/byfIlp7bQsJFYDYNyDaRfP/7j/ETcuSsjgyyxDJKa66F9 XqV4WIYpklU0i5vewSyDXS3mxxa77TmTeiKDJXjw6uzvJwLnpvCCGxR8IYlSSb6DVcKOy8gy Efs7lgm+EC43OUdxjGrEF9LsSFAC4DWCc3LaTowrOD9P5sScvXp3dv72ZC/2wBV2+sCkoOLi lQCMfFExfuGzwOv7duF7pTRFYPD+w6eL9+8uTwxbnKlg3atbujALzm6dLH0PsUBLF7aDYg3L WQbX4r8jPrG8OVtBLGSdlsrgXE15FZ/bw/TJOGGs+5momL51Wiqnr6a8nD5x6QzzIMNWmzQU 3zF7MrIZDmb2+Ph5LKZFnLKzrg6qw6yWKTZL75Xccpalz7JyVvQ9hDo4udZmmgSHomzVdUcD cmvDm3+cjB2B9ROszOPa7HTpKIGRUYIrcsCLA4hPtQkYittAsx4RWHyh8xYzMxIb14A+Pmhi SJRzHyWG1khYUINxVizBeTcyS9iaq2dtYoauuHnKEP5VyKI8qks3LEuw/T+qaC0jjxyuWEiX ijHJ/iC8Kvsh7eCVsG0BO01XmNLk/u0OBeULDu9qu2iG7lTfXzdPSl4SsVXBhI/d276b54Zu nrbL2QWJTay2d/MksyII6c5LUdy1S1FcJZei+Na0/aUotAMl/tUeLkbxHWHX9j7WWrRiEay1 6MgZwaX26C9G8R1hVwjtbNeIafW3aK8x3+VLohZ5MYrvCjOXDBejEM2sLkYxdB1cpgy9G2XE cDeK74IL5UTcjSIS/qPXo8jj8a4bUqRxddcNKRw6xdImtVwd9nFDCoeFXiO2lxtSfJcvsZb1 hhQOq7U+PmM7VoHOyk5n0tDXvMn65Z7cyeVhOHVVan+xciXrX55+Fy5ms3uPvO5dyd6V3IMr uTzTlehFdrb5d1dWNXX9uTlMThk8PcDm2DxhmjbNsUlkhvPKrFbRVBlVlnVPW/QwLUdYmiHp fIk5i5LCu5luRzgWlujEztWxsCROllo0ayysyCCPS3oeyrJ0e2NdeOJEe8baujCk/nxODlOL lIHBNl8kgnc+bb7M2NmXsm3FRAtTQur1u0ut7GPH3SS+zVTto62PbYq0MAynhTZfGWhHTlRX dn47k3hvANwkCgjNdxATZntL5dlBTZhBYhS44VM+wi/IfpgUvGznkbgCYiZzPdpDyYa9j04q jrjll9zfN/MT/3pH+35HF7aMMKizw9cpYxM1cuuIh1VlBz1hlVmzMkqzg5yw5ZFFMRyhLgCr X+qIyxxnAikuAxoCUtx9D2w21RG3rEJg8l0hsBlmmnhTP4oXu5SEb4XlrQh1xDXZABjykejE rRDFaEe6owMuSa76w5bOS0lootFXE+0/8Otn9J8oCdHdc67YyY44Bh35QQhD2GxVjGOw2uAs tE7zbfcWgDMKuWWSyKVoO0hCFarTc8QcJXDGwgz8zAsXsx2CIa7nIbvZc8EV3Z0WDcZtLl9q fGe2uYy+ii2u0xCLr2Lz1Q+0EANbbCOJ4xID1lCAyJZGTPEVcV2GIOcNjuIuJrbgShBTl1su WVWanrjGmK8QUP2VPjCKs/u29NqdaLjCBPDGT0JyRefiCqPb3jbBdlUfafAVvXSr2V81QeRe kCCLrnaswuL2G+zn2o4tbOlnu53HkXIbSeDHMfai8yJKaA5ddaXrA++TSyKhlPEoiyxS0Wpj K2mVXWEeeZBVkxjOrcv08Rt9TvBnJs9e/uX5yW/GCQ+03Xf1oNFU3K0QTGF8+wkLKFhGBEQN +BzQHaBz9E2+khTmruioVHVCdaXXwjwZSBqNw+fBH/q07YuZMnrZdYiZ6Zy+ZmKlUFeKyYS5 fIlDO9g6Q3lOLjFCd/MIu5EPZlLx4bY7ErYKsxxuu3w9SHjPfV2xobfd5ASean/1c6+8WC3e kbrl8qVfzLP0ivQEvPPyNPhCauCmE+0aFeQV1suJlgW3xGcjxewR9jXusd6Phw5fa59NtIrs nkCdaObQ4L1AY9O4OSpoASF+fvritBx/gAeLpvenpm3ilzJQDEd8iycrCjK+fBSWxdcmkRUF GV8+Csey+cocGFGQ8eWjGNt8DTlZUZDxpaMYGTZfHIQRBR1fPoohZyIYKwoyvnwUlsN5XMOI gowvH4XD2XeAFQUZXz6KsWvJ1G46vnQUljHmu7uPEQUdXz6K4ZizPR4jCjK+fBQ2/PgKhIKM Lx+Fq/PtSlhRkPGlo8Cs4iv5YkRBx5ePAo8rU7vp+JJQ1NTwK3J/G6lORtMpCiA1whfv3rzf QqI87SIbpaqTRzrF8mtpX66k7Mhycuba3JEZ9tAVNz3LaR+ajgTvGT99Oet0+HrSbcviq8/Z DkHssN9AoMPXEIyhoQvc+S0xCB73GxDl+EdqQ5YoDt6GMM/20JCw827MNhlf9mwbQ8uQaTvK 8eWjcEwJO+8GCjK+fBRjU8LOu4GCjC8dxQjbKZlWkI4vH8VwKGHn3UBBxpePwuK8Np0VBRlf PgpnJGHn3UBBxpePYmxJ2Hk3UJDxpaOwDN7G9Gwo6PjyUQw5W22woiDjy0dh2RJ23g0UZHz5 KBxbws67gYKMLx/F2JHpNZfjS0dhGw7fxZaMKOj48lHgXbZM7abjy0dhuZytvxhRkPHlo3DG Mjf25fjyUYzHAgM3G1CQ8aWjcEx9KFO76fjyUWCXU6Z20/Hlo7ANvo6yrCjI+PJRuIbADJMN KMj40lG4uikhn2WFgo4vH4VpSo0+0vHloxgNpUbV6PjyUdhDqVE1Or58FO5IalSNji8dxVgf SY2q0fHlozAtqVE1Or58FCNLalSNji8fhc3ZvZIVBRlfPgrXlhpVo+NLP63SdUdmVK0cXz4K 05EZVSvHl49i5MqMqpXjy0dhc2bZs6Ig48tH4boyo2rl+NJRGPpY6lk0HV8+CnMsM6pWji8f haXLjKqV48tH4egyo2rl+PJRjA2ZUbVyfOkoTMOQGVUrx5ePYmjKjKqV48tHYZkyo2rl+PJR OEOZUbVyfPkohNZtbUBBxpdfDSOlSmyF4pirxBoojrhKrIHiiKvEGiiOuEqsgeKIq8RWKI65 SqyB4oirxBoojrhKrIHiiKvEGiiOuEpsheKYq8QaKI64SqyB4oirxBoojrhKrFEbccRVYsdT 4cFUJUaKt8hrziqxFQ1S/lUO/wWhuR9H5EbGFy+0T2cftOU7GkrIfd2hliYa+Vu+mzFJR09C boKHo3dICWN7X9bGBaEva2M4KOzL2lQYPebZ7svaWFD0ZW3sKPqyNgYUfVkbAEVf1saCoi9r Y0bRl7UxoejL2thR9GVtLCj6sjZ2FH1ZGwuKvqyNHUVf1saAoi9rA6Doy9pYUPRlbewo+rI2 FhR9WRs7ir6sjQFFX9YGQNGXtbGg6MvamE+r+rI2JhR9WRs7ir6sjQVFX9bGjqIva2NB0Ze1 saPoy9oYUPRlbQAUfVkbC4q+rI0ZRV/WxoSiL2tjR9GXtbGg6Mva2FH0ZW0sKPqyNnYUfVkb A4q+rA2Aoi9rY0HRl7Wxo3jiFR6dLWvLCz8rvFkaLmLkYWwBuXg7zegd7eQlynPtT+f/e36m +fl9EtxkaZIucnqj+oLc0/2nE53e5V6OQN/neYyI1NQlfuwR2qsnSNBXtqeQBv3nC+3NxZv3 D2DOIm8aTVNZSGuissb/9fUHLUMBwlKUHRIRR18nEtHp8YKbKMaGorifo9MPH9+feT+/f/3r 2/OBlvnJl9MX5qCaltNidohgitmEIqDlo17gx3GE0dTfv3N8yx7rKBzZOkIhMl7Qz/5gjM2X hu2+NF4axvg7NfwDiXVbYoss4iEUXnlhWlXiBmmSYDuODYCm3znT0LVMfzT1bRfb+AJP5IJU 0ybaPE1jRsEYV6SIZaH/eNTgUPOAVxJiMbDFpe9VNqgWka9RcUMxaoye1xIWRjRP8+I6Q3nz Zw8LoLdCONHw76JQO30AVRKxBpEr1z2df7nGa14cp8Ezx3wuiSb5MNG85nvLD56c3OGvCfnn h4qc+RLd+bN5jF4G6eykJs34cMZO6T3728Xb15XcGmAbsyTAo/4Gn/rzYoLpPS8VZoVXY54N iFWxDN/Vea3KkhS3plPykog1iFz5Op+mQ2kq1XQTJK9wb2JJgEfTTT5N58UE03ReKuxLu6lO CU2VSgglJkIJoTSVKuEQJEpDuBIOWyjhkE8JeTHBlJCXCrsSDtUp4VClEkKJiVBCKE2VSgj3 q4pohmgMSmKcgNBgdtpGIGUYwc3IqIUZGfGZEV5MMDPCS4XdjIzUmZGRSjMCJSbCjEBpHrYZ ubxYbc9IEJtV260moWyReNRWeNW43j8jckZxS+Z1oBk6/tKw2J4a+NVsgb8xUrG/DQqv0cEc rBuyRX8QbPS3h8Yre51QUBou+qjk8YMMzVBCz0HIL0oMWP/4Rn8s1vfp4ufzj3WojyNmYrew vjaf9W2HDGaD29Fit8S2Oktsq7TEUGIiLDGUptJdlQNa1C24QjotFNLhUkh1FpOXeTCd56XC ru2OOm13VGo7lJgIbYfS7Kbf5YJk1oabFbeFWXH51nleTDBt56XCru2uOm13VWo7lJgIbYfS PGxtJ9lBMz9iTYZxxiBZdeBaPm6h5WM+LefFBNNyXirsWj5Wp+VjlVoOJSZCy6E0VWq5uzuJ pilKbutUp0ezdF5dvKuI6PxEODTd5lvPW+Fqlb4HosSZ8yA3yan1ug5IPAITE5B45LbIvHP5 Mu/AMI/CyID0hJsKs464oETAVqui2zo5D7AqgokJWBXBNJUK7O4UszJQevahaXZfwM/73BZZ ei5fll57cHxpuqwT/eGXHBXh1dv0Okqe6XfGeBgMdR2a8wlYxqIED0XSaisN1fz8wSqgKCE5 z7AKqaGVoesoLzKf8RipLbkwJRtDNbTi0J+r0gT2pQOU7dnKvXJbZ3sC3CswMRHu1UFne9bS S8SQ/lM/ykT7jP/IDwI8pUWO/+rt61cftKsIz2++CEgIZbqItWf0Izf46bTPdIiTk4rOsPlU v3PZQw7Fjfw4vZZje1Hgrsv3vgwvnhMZCC1dH+uHgXCG8ETOs/TuXhFHb+cpWGMYmWpaUsRm N+GRyR/kau/OE/Kya20s3RpxBrnUuvNfsvt5Aa0X4XdAr4whswNKqJ1//Pj+IzO9y8u3Gsqy NCv9fVLfpU0XSSl/9+lCy2/SRRxS2SN/8GfdMN+8+vTq7UQjtcQ3/r22SHwt/u8E+RrCYnnt 3Vz5mE/JVJv7ma/99a9r+4Tvvx9oi3zhZ1GKf7XISWB/hsi7V36OtBD/5xdpjn9XAyO/I08Z JT5+qtuUPIE0dgQx8qloLOabNprTDKFn8MnYoOM1T/0wbGp8kWrFDYKW15RUsD9I/id0rio6 C1olTUataNQEMJN9wnA+KA9t8tSPiOTgsddSxap6YfxMpZHWDD5yxH334jSdl6loJdWaKClM JhVQMd5SoIQ1NW29ACpHSejlhV8sciwNISJl89jKvjC0/9ayAFtCQxsQLUnS08vSW9pNpTH8 V59UtDeHz5BPph1Le4MGB4lV1Xzoo1maRH/gwecZelG+XB6PobuIZr/ROs0XrNMAralot3nm qIbZunmmWiu71geyawYCDPxtroYKdNB9Oi8d0Aadlwj7zhycB9NuzXb6NbsdO0Su2Y6SNdtR sWY7YtZsi49cEcy91WKdoaS5duOXFX3A4Ku1Lo+uPWx58SodXSd+rBnDOtELMh776v9itfz/ mKVfiMZEc85p2MCX1UxQuuWTUO8AaBIPJOrDvQxAwj2wxdTU976Yssd5gNBMZ1ucRwU0cICH m4eQyA6QjaOhFAnZTdjW91nWbTJf7NqirNt0zKMo6wZFdqDFru28RI4yZWG7I+4ibMjuCAhQ 3O6IFx10d8RLB7Q74iUC2B0ND8vb4GYrxNuACadAb4MXHbu3AYQmztvgbiAB9Ta4eQjxNoBs FOdtAAm38Tba968AeBv8/Sv4vQ21/StA3ga0ErNdLJajhlaYt9GyThjicwBhivM52mGEeh7t qIH8j3akAF4ItEdEO33g6O4hTB+4e5dANAEIUJwm8KKD6gAvHZD08xLhkPsD8b652QrxvmHC KdD75kXH7n0DoYnzvrn7LkG9b24eQrxvIBvFed9Awm287/ZtnwDeN3/bJ37v2z4s09bSa4IY OJgfKtDAtcPIbuaAAMWZuZYNjqDGriU/ISYPyFJxJg9IuI3Ja99fCWDy+PsrtTd5BxhwUNuE D/Ro0HLTdns/jp4jwvZ+3B1VIHs/IEBxez9edNC9Hy8d0N6PlwigYkxpMSNPvbEoueevpgbI PRSgMLnnRgeUe246ELnnJgKIeUB7mLQ7aefoPiPM3nP31oHYeyBAcfaeFx3U3vPSAdl7XiLs cg9uq9FK7nl6sIgqXm/XZQYg+1CQgagaylYIgfLfihZEB1oR4tADLjw8NcT8CucavpxuEWUF 6PaFhhRQ8tCGl9jOMTdQErAmKBNq795/ujg7n9SfbDQcWavq+vzC/F3T5ngbX31SDjPtkeg6 3o3ASkwvTPwnVfJ+83nIOKgZw4wVVUjXz+rdzaA1xM2PrkEVMnFwKHcBsxsJFBHXOJD6eTwO Nv6sygZd4pCoivZWZpo5lAyDZ+m6eQgrODSQ3I6XgDByK0KwVYCSYl0F9IYtwR+UIxsGEi36 WxYBXfAaIGTm2BeAbyB+uwBwzRnUKo/DA+nbMsujGNqFjH5mjWm0xO7PL0zthLLur/Svv5fD OrxRF8y6b/EQKOEhuTrRTFJ7ndAWLYj4UZU5jyKLKdcY90gxpS6klpJQatRSbrzDvmUxZSuz yu6MQpeq4dUhuDEyPVG8e3UOwRMF2PUlncfsut4w67bLaNahbHNGokVjg1nXxVr1VjPEbNKh nBzrogVws0kX7Qqu1uOyN+qE/FNf4DZZuyeBNoCZ0yQJ+kEtyJBfgE19TQh/p5NHCZYfmWhv Lt68r8fVftBOitl82ceQp3frVmLkxQYSFTOpzKBT27alOAHGSE6MYDdhS5QbvK4jMldvSmlz Vyexi/aNn4TYIcD+DBb+aqxTzbZM1pbUdLiVh7Q2XqnBtTqRmTNodyVEWoNkJAHoflARPTUt xuYZe31+p/3zLw+BDyN1k//gG3BYAEwfEJe0yY2OOcYGhSYsXZO/Vz8wvsbPQ0BsDcpGYSma UMItUjQFXBXAnqLZ4qoA/hTN8UGZNv7cBsg5KCxDRGA+Oi869kx0IDRxmejcl3NBc9C5eQjJ PgeyUVz2OZBwm+zz9neDAbLP+e8G4zdt7mGZNu40XYhpg4UEBJo2XnTspg0ITZxp475dFGra uHkIMW1ANoozbUDCbUxb+8tNAaaN/3JTbtO2bQdcoGwWJT7thxwuaKPNy4ufzv729jUjHmv7 +YkFPD+xx2LHo0VFIscbCR5vx/kTeDxT8HhD5vH+rf/qv/qv/qv/6r/6r/6r/+q/+q/+q//q v1i//h/0osy1AOgDAA== --------------090309030509080608060300 Content-Type: text/plain; charset=UTF-8; name="system-info.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="system-info.txt" cm9vdEBzZXJ2ZXIwMTp+IyB1bmFtZSAtYQpMaW51eCBzZXJ2ZXIwMSAzLjIuMC00LWFtZDY0 ICMxIFNNUCBEZWJpYW4gMy4yLjY4LTErZGViN3UzIHg4Nl82NCBHTlUvTGludXgKCnJvb3RA c2VydmVyMDE6fiMgZHBrZyAtLWxpc3QgJ29wZW5zaXBzKicKRGVzZWFkbz1EZXNjb25vY2lk by9JbnN0YWxhci9FbGltaW5hci9QdXJnYXIvUmV0ZW5lcgp8IEVzdGFkbz1Oby9JbnN0YWxh ZG8vQ29uZmlnLWZpbGVzL0Rlc2VtcGFxdWV0YWRvL01lZGlvLWNvbmYvTWVkaW8taW5zdC9l c3BlcmEtZGlzcGFyby9wZW5kaWVudGUtZGlzcGFybwp8LyBFcnI/PShuaW5ndW5vKS9SZXF1 aWVyZS1yZWluc3QgKEVzdGFkbyxFcnI6IG1hecO6c2MuPW1hbG8pCnx8LyBOb21icmUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFZlcnNpw7NuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJxdWl0 ZWN0dXJhICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZXNjcmlwY2nDs24KKysrLT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0tPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PS09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09LT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQppaSAgb3BlbnNpcHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dmVyeSBmYXN0IGFuZCBjb25maWd1cmFibGUgU0lQIHNlcnZlcgp1biAgb3BlbnNpcHMtYjJi dWEtbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtYmVya2VsZXktbW9kdWxlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtY2FycmllcnJvdXRlLW1vZHVsZSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtY29u c29sZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtY3BsLW1vZHVsZSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtZGJodHRwLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtZGlh bHBsYW4tbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtZ2VvaXAtbW9kdWxlICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtaHR0cC1tb2R1bGVzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtaWRl bnRpdHktbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2Ny aXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtamFiYmVyLW1vZHVsZSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxl KQp1biAgb3BlbnNpcHMtanNvbi1tb2R1bGUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5v IGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQppaSAgb3BlbnNpcHMtbGRh cC1tb2R1bGVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFtZDY0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTERBUCBtb2R1bGVzIGZvciBPcGVu U0lQUwp1biAgb3BlbnNpcHMtbHVhLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMt bWVtY2FjaGVkLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRl c2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtbXlzcWwtbW9kdWxlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25p YmxlKQp1biAgb3BlbnNpcHMtcGVybC1tb2R1bGVzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQppaSAgb3BlbnNpcHMt cG9zdGdyZXMtbW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFtZDY0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUG9zdGdyZVNRTCBkYXRhYmFz ZSBjb25uZWN0aXZpdHkgbW9kdWxlIGZvciBPcGVuU0lQUwppaSAgb3BlbnNpcHMtcHJlc2Vu Y2UtbW9kdWxlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAxLjExLjUtMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFtZDY0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0lNUExFIHByZXNlbmNlIG1vZHVsZXMg Zm9yIE9wZW5TSVBTCnVuICBvcGVuc2lwcy1yYWJiaXRtcS1tb2R1bGUgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuaW5ndW5hPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7NuIGRpc3BvbmlibGUpCnVuICBv cGVuc2lwcy1yYWRpdXMtbW9kdWxlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxuaW5ndW5hPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5p bmd1bmEgZGVzY3JpcGNpw7NuIGRpc3BvbmlibGUpCnVuICBvcGVuc2lwcy1yZWRpcy1tb2R1 bGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxu aW5ndW5hPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7Nu IGRpc3BvbmlibGUpCmlpICBvcGVuc2lwcy1yZWdleC1tb2R1bGUgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEuMTEuNS0xICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQQ1JFIHJlZ2V4cCBtb2R1bGVzIGZvciBPcGVuU0lQUwp1biAgb3BlbnNpcHMt c25tcHN0YXRzLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRl c2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMtdW5peG9kYmMtbW9kdWxlICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25p YmxlKQp1biAgb3BlbnNpcHMteG1scnBjLW1vZHVsZSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgb3BlbnNpcHMt eG1wcC1tb2R1bGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRl c2NyaXBjacOzbiBkaXNwb25pYmxlKQoKcm9vdEBzZXJ2ZXIwMTp+IyBkcGtnIC0tbGlzdCAn cG9zdGdyZXMqJwpEZXNlYWRvPURlc2Nvbm9jaWRvL0luc3RhbGFyL0VsaW1pbmFyL1B1cmdh ci9SZXRlbmVyCnwgRXN0YWRvPU5vL0luc3RhbGFkby9Db25maWctZmlsZXMvRGVzZW1wYXF1 ZXRhZG8vTWVkaW8tY29uZi9NZWRpby1pbnN0L2VzcGVyYS1kaXNwYXJvL3BlbmRpZW50ZS1k aXNwYXJvCnwvIEVycj89KG5pbmd1bm8pL1JlcXVpZXJlLXJlaW5zdCAoRXN0YWRvLEVycjog bWF5w7pzYy49bWFsbykKfHwvIE5vbWJyZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmVyc2nDs24gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBcnF1aXRlY3R1cmEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIERlc2NyaXBjacOzbgorKystPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PS09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09LT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0tPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp1biAgcG9zdGdy ZXNxbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8bmluZ3VuYT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5h IGRlc2NyaXBjacOzbiBkaXNwb25pYmxlKQp1biAgcG9zdGdyZXNxbC05LjEgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmluZ3Vu YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKG5vIGhheSBuaW5ndW5hIGRlc2NyaXBjacOzbiBkaXNw b25pYmxlKQppaSAgcG9zdGdyZXNxbC1jbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5LjErMTM0d2hlZXp5NCAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFsbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZnJvbnQtZW5kIHByb2dyYW1zIGZvciBQb3N0Z3JlU1FMIChzdXBwb3J0ZWQgdmVyc2lv bikKaWkgIHBvc3RncmVzcWwtY2xpZW50LTkuMSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgOS4xLjE4LTArZGViN3UxICAgICAgICAgICAgICAg ICAgICAgICAgICBhbWQ2NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZy b250LWVuZCBwcm9ncmFtcyBmb3IgUG9zdGdyZVNRTCA5LjEKaWkgIHBvc3RncmVzcWwtY2xp ZW50LWNvbW1vbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMTM0d2hlZXp5NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hbmFnZXIgZm9yIG11bHRpcGxlIFBv c3RncmVTUUwgY2xpZW50IHZlcnNpb25zCnVuICBwb3N0Z3Jlc3FsLWNvbW1vbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuaW5ndW5h PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7NuIGRpc3Bv bmlibGUpCnVuICBwb3N0Z3Jlc3FsLWRvYy05LjEgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuaW5ndW5hPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNpw7NuIGRpc3BvbmlibGUpCgoKCnJvb3RAc2Vy dmVyMDI6fiMgdW5hbWUgLWEKTGludXggc2VydmVyMDIgMy4yLjAtNC1hbWQ2NCAjMSBTTVAg RGViaWFuIDMuMi42OC0xK2RlYjd1MyB4ODZfNjQgR05VL0xpbnV4Cgpyb290QHNlcnZlcjAy On4jIGRwa2cgLS1saXN0ICdwb3N0Z3JlcyonCkRlc2VhZG89RGVzY29ub2NpZG8vSW5zdGFs YXIvRWxpbWluYXIvUHVyZ2FyL1JldGVuZXIKfCBFc3RhZG89Tm8vSW5zdGFsYWRvL0NvbmZp Zy1maWxlcy9EZXNlbXBhcXVldGFkby9NZWRpby1jb25mL01lZGlvLWluc3QvZXNwZXJhLWRp c3Bhcm8vcGVuZGllbnRlLWRpc3Bhcm8KfC8gRXJyPz0obmluZ3VubykvUmVxdWllcmUtcmVp bnN0IChFc3RhZG8sRXJyOiBtYXnDunNjLj1tYWxvKQp8fC8gTm9tYnJlICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBW ZXJzacOzbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFycXVpdGVjdHVyYSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVzY3JpcGNpw7NuCisrKy09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09LT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0tPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PS09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09CmlpICBwb3N0Z3Jlc3FsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkuMSsxMzR3aGVlenk0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgYWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBvYmplY3QtcmVsYXRpb25hbCBTUUwgZGF0YWJhc2UgKHN1cHBvcnRlZCB2ZXJzaW9u KQppaSAgcG9zdGdyZXNxbC05LjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA5LjEuMTgtMCtkZWI3dTEgICAgICAgICAgICAgICAg ICAgICAgICAgIGFtZDY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2Jq ZWN0LXJlbGF0aW9uYWwgU1FMIGRhdGFiYXNlLCB2ZXJzaW9uIDkuMSBzZXJ2ZXIKaWkgIHBv c3RncmVzcWwtOS4xLXBsc2ggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMS4zLTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhbWQ2NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBML3NoIHByb2Nl ZHVyYWwgbGFuZ3VhZ2UgZm9yIFBvc3RncmVTUUwgOS4xCnVuICBwb3N0Z3Jlc3FsLWNsaWVu dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxuaW5ndW5hPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobm8gaGF5IG5pbmd1bmEgZGVzY3JpcGNp w7NuIGRpc3BvbmlibGUpCmlpICBwb3N0Z3Jlc3FsLWNsaWVudC05LjEgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkuMS4xOC0wK2RlYjd1MSAg ICAgICAgICAgICAgICAgICAgICAgICAgYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBmcm9udC1lbmQgcHJvZ3JhbXMgZm9yIFBvc3RncmVTUUwgOS4xCmlpICBw b3N0Z3Jlc3FsLWNsaWVudC1jb21tb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDEzNHdoZWV6eTQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYW5hZ2VyIGZv ciBtdWx0aXBsZSBQb3N0Z3JlU1FMIGNsaWVudCB2ZXJzaW9ucwppaSAgcG9zdGdyZXNxbC1j b21tb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxMzR3aGVlenk0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsbCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUG9zdGdyZVNRTCBkYXRhYmFzZS1j bHVzdGVyIG1hbmFnZXIKaWkgIHBvc3RncmVzcWwtY29udHJpYiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOS4xKzEzNHdoZWV6eTQgICAg ICAgICAgICAgICAgICAgICAgICAgICBhbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGFkZGl0aW9uYWwgZmFjaWxpdGllcyBmb3IgUG9zdGdyZVNRTCAoc3VwcG9y dGVkIHZlcnNpb24pCmlpICBwb3N0Z3Jlc3FsLWNvbnRyaWItOS4xICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkuMS4xOC0wK2RlYjd1MSAgICAg ICAgICAgICAgICAgICAgICAgICAgYW1kNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhZGRpdGlvbmFsIGZhY2lsaXRpZXMgZm9yIFBvc3RncmVTUUwKdW4gIHBvc3Rn cmVzcWwtZGV2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPG5pbmd1bmE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChubyBoYXkgbmluZ3Vu YSBkZXNjcmlwY2nDs24gZGlzcG9uaWJsZSkKdW4gIHBvc3RncmVzcWwtZG9jLTkuMSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG5pbmd1 bmE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChubyBoYXkgbmluZ3VuYSBkZXNjcmlwY2nDs24gZGlz cG9uaWJsZSkKdW4gIHBvc3RncmVzcWwtcGxweXRob24tOS4xICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG5pbmd1bmE+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChubyBoYXkgbmluZ3VuYSBkZXNjcmlwY2nDs24gZGlzcG9uaWJsZSkKCg== --------------090309030509080608060300 Content-Type: application/x-compressed-tar; name="postgres.log.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="postgres.log.tgz" H4sIANdi+lUAA+1azW7jNhD2uU/BnnxRDJGS7djwbhBsfy5Be8jegkCgKdohKolaks4mfZs+ wz5CXqxD/ThO0CKkncgKEMKwSA4pfvNxZvhjl1KbteJ6lMn14I1SCGkSx/aJp2O8+4REwiia DjAZTyfxBJMJGYQ4nuLpAIVvBWg3bbShCqGBWPKM5rxIBf3Pdi/J32m65CXCYxSezuPZfIyR 5uqWq5CgsjGMq3GIx9dzdEVO8DUiUDgJZye7Xb78evkVyZIXWpQaXfz5+xzBawrDCyboHLIZ ZwYZusx4Au/WQhZopWSO2sL3G65406AAjj8N9WapmQLK1fAnJ4STrhGmMqei8EEXHYauHrCG 1eTdBp92To2gEEwcqZm+BjXZOhFpwGiWwcOiSzZK1BlD14GRVRketmT93SRG5NxmDQ9sVm5M 1Z+rhGn+rc7znbxKFLThieamFT6rgJ6yMJRt5U+KKtGS/dWKqvwtVToolVyJjOvA2ntpklVG 17rtUopi/QTPY0XdLqfFOuNpstW5rahVbqylmg9Haznt2looY46mMusaWgkDwxuEufdBeKAx e5JnxC1PvlPDQKZ9YMYdwtwH3/gwfI9zV/kFvysF1AT8FirrbxsyrJsABPusY2rQQK2qLfht RSNvgkwTS7YhJpMgqD1T8Vwa3uaZVGkdKQLr9ByGLVYyaGND068pNQxWcWmjoTfVLbnPZtrR mysmJ4cxuWWiYaChsCUUtK8RPjKOECjNFVrebzt7wJ3uCTcFuIbXWFqanIYlYdeB5Y7R0s0X CO586yUy6YiNvAK2Xcuya1pAM0F1DVLkDFxH5o7WTqKuubLea0DkyFf0CstD61A1tBZAg60V wh5sk+f3VRBzxBa/zN1VyjVEKslEKq8bgIWE16Fyk0oEsU4shUIpNVJbb0QsExb/HH2RBb8T ZwW0EYUAdTLxN00pAFAooyg/+7YRBUVV5KRueH12tb+dfz2/qMHeUIhJMFR2VnCKeIHKdXKz pCPQa4VKqihaLPCMjPDkdIRHGM8+fw6A1g1VQoKoJdjWLilonvJG38WiHc7KLi8vEGhkY7Z0 0ifyP2L5UP/w43+5f/jHm/warKchA9l2mVMPP9AKzi5AHFXsBvgBorguuaKgCEwIYGJbzDuq uJmF//b1eDTWYHtJ43uyRtJfa/Q/sRyRxn0OL53QGDvsz15Ymyjjpb3ms6GftYsRBOm3WJoi /y3bEUM57uusRw7O06NZjx02wz2CG/nv3Y9opKSvRkr8752PGOH3uYbuxtf9T+BHtMawtzT6 H4CPSOM+p+Fu9hsOC3ifQrnDUbhPcB2OaH2C+54ifNTfCO9wv+R2tfv8Iry++Wquoxc4jgmZ zU5J6AFr3yu5XVjPbuJaPMOnrx2Hc4KH6PyPX9oWP38a4tk0PAkxfFCI52EIH7dLuxq91w85 R7TNeI9fdQ62zWP/veIjfaSP9JF6m/4F21qIqAAoAAA= --------------090309030509080608060300-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: Where CustomerContext like '%$fu%' That way If I have multiple customercontext it can dynamically select the c= orrect PBX From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips= .org] On Behalf Of Rodrigo Pimenta Carvalho Sent: Tuesday, September 29, 2015 10:17 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Questions in opensips Hi. I'm new to OpenSIPS too and I have received good help from experts that acc= ess this forum. But, one point that you have to do is access a database to get the informat= ion about the PBX, haven't you? For this, you can use the module AVPOP: modparam("avpops","db_url","sqlite:///usr/local/opensips_proxy/sqlite") # C= USTOMIZE ME That is, you can use a module that allows you to access the database. In th= is example, I use SQLite. Are you familiar with the database handling actions via such module? To get data from database, you can do something like this: avp_db_query(put sql query here, "$avp(myAvp)"); # the avp will contain th= e query result. About the others details, like forwarding calls, someone expert might reply= to you. You SQL will be similar to: select PBX from table where Exten =3D 'extensio= n' and CustomerContext =3D 'the customer context'; {exten} & {CustomerContext}, the query returns a value of which PBX Tell me if this information is useful for you, please. 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 Travis Manson-Drake > Enviado: ter=E7a-feira, 29 de setembro de 2015 13:54 Para: Users at lists.opensips.org Assunto: [OpenSIPS-Users] Questions in opensips Hello everyone, I wanted to pick your brains and see if any of you have done something like= this before, or might eb able to send me in the right direction. Here's what I'm trying to accomplish. Thought process Sip packet comes into proxy - Proxy parses sip message, and checks from_uri (for example {exte= n}{CustomerConetxt}@proxyIPaddr) - once the proxy parses the data, we query a database. - based on the value of {exten} & {CustomerContext}, the query returns a va= lue of which PBX this {exten}&{CustomerContext} belongs to. - once this info has been returned to the proxy it then manipulates the des= t_uri to something like {exten}&{CustomerContext}@PBX DNS At this point the sip message is forwarded onto the appropriate PBX, and we= simply Record_Route for future communications. I know I can hard code the PBX's value in the sip server of the UAC, and ju= st have the proxy do what it does. But what I'm really trying to go for is to simply hardcode the info for a s= ip proxy, have the UAC send its request to it, then it forwards on traffic = to the appropriate PBX based upon the value of the from_uri With that being said: How would I do this? I had looked at sipmsgops and some of its functions however I can't seem to= find one that will enable me to pull just the dest uri, & extract info fro= m it Is there also a function in sipmsgops for manipulating the dest_uri? Any input is greatly appreciated! Thank you for your time, Travis Manson-Drake Voice Systems Analyst L1 Simply Bits, LLC Now You're Thinkin' Smart! 5225 N. Sabino Canyon Road Tucson, AZ 85750 Phone: 520-545-0311 Fax: 520-545-7252 Support Hotline: 5205450333 www.simplybits.com Internet - Phone - Business Technology Solutions | Simply Bits Providing buisnesses with qualtiy solutions for Internet Service, VoIP Phon= e Service, Fax to email, Website Design, Internet Marketing and much more. Leia mais... --_000_CY1PR0601MB161168100E656E180BEDBBC0CD4E0CY1PR0601MB1611_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Rodrigo,

 

Thank you for this! This helps out a = lot in relation to pulling the info from a database.

 

I think I may be able to do something= with variable $fu

 

Select PBX

From table

Where CustomerContext like ‘%$f= u%’

 

That way If I have multiple customerc= ontext it can dynamically select the correct PBX

 

 

From: users-bounces at lists.opensips.o= rg [mailto:users-bounces at lists.opensips.org] On Behalf Of Rodrigo Pimenta Carvalho
Sent: Tuesday, September 29, 2015 10:17 AM
To: OpenSIPS users mailling list <Users at lists.opensips.org> Subject: Re: [OpenSIPS-Users] Questions in opensips

 

Hi.
I'm new to OpenSIPS too and I have received good help from experts that acc= ess this forum.
But, one point that you have to do is access a database to get the informat= ion about the PBX, haven't you? For this, you can use the module AVPOP:

modparam("avpops","db_url","sqlite:///usr/local/op= ensips_proxy/sqlite") # CUSTOMIZE ME

That is, you can use a module that allows you to access the database. In th= is example, I use SQLite.

Are you familiar with the database handling actions via such module?

To get data from database, you can do something like this:

avp_db_query(put sql query here, "$avp(myAvp)");  # the avp = will contain the query result.

About the others details, like forwarding calls, someone expert might reply= to you.

You SQL will be similar to: select PBX from table where Exten =3D 'extensio= n' and CustomerContext =3D 'the customer context';

{exten} & {CustomerContext}, the query returns a value   of w= hich PBX 

Tell me if this information is useful for you, please.

Regards.

 

 

RODRIGO PIME= NTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979

&nb= sp;


De: users-bounces at l= ists.opensips.org <users-bounces at lists.opensips.org<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:black">> em nome de Travis Manson-Drake <travism at simplybits.com>
Enviado: ter=E7a-feira, 29 de setembro de 2015 13:54
Para:
Users at list= s.opensips.org
Assunto: [OpenSIPS-Users] Questions in opensips

 

Hello everyone,

 

I wanted to pick your brains and= see if any of you have done something like this before, or might eb able t= o send me in the right direction.

 

Here’s what I’m tryi= ng to accomplish.

 

Thought process

 

Sip packet comes into proxy=

-        &nb= sp; Proxy parses sip message, and checks f= rom_uri (for example {exten}{CustomerConetxt}@proxyIPaddr)

-  once the proxy parses th= e data, we query a database.

- based on the value of {exten} = & {CustomerContext}, the query returns a value   of which PBX= this {exten}&{CustomerContext} belongs to.

- once this info has been return= ed to the proxy it then manipulates the dest_uri to something like {exten}&= amp;{CustomerContext}@PBX DNS

 

At this point the sip message is= forwarded onto the appropriate PBX, and we simply Record_Route for future = communications.

 

I know I can hard code the PBX&#= 8217;s value in the sip server of the UAC, and just have the proxy do what = it does.

But what I’m really trying= to go for is to simply hardcode the info for a sip proxy, have the UAC sen= d its request to it, then it forwards on traffic to the appropriate PBX based upon the value of the from_uri=

 

With that being said:=

 

How would I do this?<= /span>

 

I had looked at sipmsgops and so= me of its functions however I can’t seem to find one that will enable= me to pull just the dest uri, & extract info from it=

 

Is there also a function in sipm= sgops for manipulating the dest_uri?

 

Any input is greatly appreciated= !

 

Thank you for your time,

 

 

Simply Bits, LLC

Now You’re Thinkin= 217; Smart!

52= 25 N. Sabino Canyon Road
Tucson, AZ 85750

Phone: 520-545-0311

Fax: 520-545-7252

Support Hotline: 5205450333

www.simplybits.com=

Internet - Phone - Busines= s Technology Solutions | Simply Bits

Providing buisnesses with qualtiy so= lutions for Internet Service, VoIP Phone Service, Fax to email, Website Des= ign, Internet Marketing and much more.

 

--_000_CY1PR0601MB161168100E656E180BEDBBC0CD4E0CY1PR0601MB1611_-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: Where CustomerContext like =91%$fu%=92 That way If I have multiple customercontext it can dynamically select the c= orrect PBX From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips= .org] On Behalf Of Rodrigo Pimenta Carvalho Sent: Tuesday, September 29, 2015 10:17 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Questions in opensips Hi. I'm new to OpenSIPS too and I have received good help from experts that acc= ess this forum. But, one point that you have to do is access a database to get the informat= ion about the PBX, haven't you? For this, you can use the module AVPOP: modparam("avpops","db_url","sqlite:///usr/local/opensips_proxy/sqlite") # C= USTOMIZE ME That is, you can use a module that allows you to access the database. In th= is example, I use SQLite. Are you familiar with the database handling actions via such module? To get data from database, you can do something like this: avp_db_query(put sql query here, "$avp(myAvp)"); # the avp will contain th= e query result. About the others details, like forwarding calls, someone expert might reply= to you. You SQL will be similar to: select PBX from table where Exten =3D 'extensio= n' and CustomerContext =3D 'the customer context'; {exten} & {CustomerContext}, the query returns a value of which PBX Tell me if this information is useful for you, please. 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 Travis Manson-Drake > Enviado: ter=E7a-feira, 29 de setembro de 2015 13:54 Para: Users at lists.opensips.org Assunto: [OpenSIPS-Users] Questions in opensips Hello everyone, I wanted to pick your brains and see if any of you have done something like= this before, or might eb able to send me in the right direction. Here=92s what I=92m trying to accomplish. Thought process Sip packet comes into proxy - Proxy parses sip message, and checks from_uri (for example {exte= n}{CustomerConetxt}@proxyIPaddr) - once the proxy parses the data, we query a database. - based on the value of {exten} & {CustomerContext}, the query returns a va= lue of which PBX this {exten}&{CustomerContext} belongs to. - once this info has been returned to the proxy it then manipulates the des= t_uri to something like {exten}&{CustomerContext}@PBX DNS At this point the sip message is forwarded onto the appropriate PBX, and we= simply Record_Route for future communications. I know I can hard code the PBX=92s value in the sip server of the UAC, and = just have the proxy do what it does. But what I=92m really trying to go for is to simply hardcode the info for a= sip proxy, have the UAC send its request to it, then it forwards on traffi= c to the appropriate PBX based upon the value of the from_uri With that being said: How would I do this? I had looked at sipmsgops and some of its functions however I can=92t seem = to find one that will enable me to pull just the dest uri, & extract info f= rom it Is there also a function in sipmsgops for manipulating the dest_uri? Any input is greatly appreciated! Thank you for your time, Travis Manson-Drake Voice Systems Analyst L1 Simply Bits, LLC Now You=92re Thinkin=92 Smart! 5225 N. Sabino Canyon Road Tucson, AZ 85750 Phone: 520-545-0311 Fax: 520-545-7252 Support Hotline: 5205450333 www.simplybits.com Internet - Phone - Business Technology Solutions | Simply Bits Providing buisnesses with qualtiy solutions for Internet Service, VoIP Phon= e Service, Fax to email, Website Design, Internet Marketing and much more. Leia mais... --_000_BLUPR02MB168378193302527951A92F93B54E0BLUPR02MB1683namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I think so.
Good lucky.



RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: users-bounces at lists.op= ensips.org <users-bounces at lists.opensips.org> em nome de Travis Manso= n-Drake <travism at simplybits.com>
Enviado: ter=E7a-feira, 29 de setembro de 2015 14:42
Para: OpenSIPS users mailling list
Assunto: Re: [OpenSIPS-Users] Questions in opensips
 

Rodrigo,

 

Thank you for this! This helps out a lot in relation to pu= lling the info from a database.

 

I think I may be able to do something with variable $fu

 

Select PBX

From table

Where CustomerContext like =91%$fu%=92

 

That way If I have multiple customercontext it can dynamic= ally select the correct PBX

 

 

From: users-bounces at lists.opensips.org [mailto:users-boun= ces at lists.opensips.org] On Behalf Of Rodrigo Pimenta Carvalho
Sent: Tuesday, September 29, 2015 10:17 AM
To: OpenSIPS users mailling list <Users at lists.opensips.org> Subject: Re: [OpenSIPS-Users] Questions in opensips

 

Hi.=
I'm new to OpenSIPS too and I have received good help from experts that acc= ess this forum.
But, one point that you have to do is access a database to get the informat= ion about the PBX, haven't you? For this, you can use the module AVPOP:

modparam("avpops","db_url","sqlite:///usr/local/op= ensips_proxy/sqlite") # CUSTOMIZE ME

That is, you can use a module that allows you to access the database. In th= is example, I use SQLite.

Are you familiar with the database handling actions via such module?

To get data from database, you can do something like this:

avp_db_query(put sql query here, "$avp(myAvp)");  # the avp = will contain the query result.

About the others details, like forwarding calls, someone expert might reply= to you.

You SQL will be similar to: select PBX from table where Exten =3D 'extensio= n' and CustomerContext =3D 'the customer context';

{exten} & {CustomerContext}, the query returns a value   of w= hich PBX 

Tell me if this information is useful for you, please.

Regards.

 

 

RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979

&nb= sp;


Hello everyone,

 

I wanted to pick your brains a= nd see if any of you have done something like this before, or might eb able= to send me in the right direction.

 

Here=92s what I=92m trying to = accomplish.

 

Thought process

 

Sip packet comes into proxy

-       &nbs= p;  Proxy parses sip message, and check= s from_uri (for example {exten}{CustomerConetxt}@proxyIPaddr)

-  once the proxy parses = the data, we query a database.

- based on the value of {exten= } & {CustomerContext}, the query returns a value   of which P= BX this {exten}&{CustomerContext} belongs to.

- once this info has been retu= rned to the proxy it then manipulates the dest_uri to something like {exten= }&{CustomerContext}@PBX DNS

 

At this point the sip message = is forwarded onto the appropriate PBX, and we simply Record_Route for futur= e communications.

 

I know I can hard code the PBX= =92s value in the sip server of the UAC, and just have the proxy do what it= does.

But what I=92m really trying t= o go for is to simply hardcode the info for a sip proxy, have the UAC send = its request to it, then it forwards on traffic to the appropriate PBX based upon the value of the from_uri

 

With that being said:

 

How would I do this?

 

I had looked at sipmsgops and = some of its functions however I can=92t seem to find one that will enable m= e to pull just the dest uri, & extract info from it

 

Is there also a function in si= pmsgops for manipulating the dest_uri?

 

Any input is greatly appreciat= ed!

 

Thank you for your time,

 

 

Travis Manson-Drake

Voice Systems Analyst L1<= /span>

Simply Bits, LLC

Now You=92re Thinkin=92 S= mart!

Phone: 520-545-0311

Fax: 520-545-7252

Support Hotline: 5205450333

ww= w.simplybits.com

Internet - Phone - Business Technology Solution= s | Simply Bits

Providing buisnesses with qualtiy solutions for Internet = Service, VoIP Phone Service, Fax to email, Website Design, Internet Marketi= ng and much more.

 

--_000_BLUPR02MB168378193302527951A92F93B54E0BLUPR02MB1683namp_-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 62.1.1.10:5060;branch=z9hG4bKd091.937a047.0 Via: SIP/2.0/UDP 172.17.1.1:5060 ;rport=5060;received=172.17.1.1;branch=z9hG4bKac393424402 From: ;tag=1c393411873 To: ;tag=gK08c71cc5 Call-ID: 39341083229920151062 at 172.17.1.1 CSeq: 1 INVITE Record-Route: Record-Route: Contact: Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Require: 100rel RSeq: 433990 Content-Length: 266 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 176482 50736 IN IP4 210.200.100.100 s=SIP Media Capabilities c=IN IP4 210.200.100.243 t=0 0 m=audio 61348 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 a=silenceSupp:off - - - - After the firewall + Opensips have processed this message to the call center SIP/2.0 180 Ringing Via: SIP/2.0/UDP 172.17.1.1:5060;branch=z9hG4bKac393424402 From: ;tag=1c393411873 To: ;tag=gK08c71cc5 Call-ID: 39341083229920151062 at 172.17.1.1 CSeq: 1 INVITE Record-Route: Record-Route: Contact: Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Require: 100rel RSeq: 433990 Content-Length: 295 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 176482 50736 IN IP4 210.200.100.100 s=SIP Media Capabilities t=0 0 m=audio 4845 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 a=silenceSupp:off - - - - a=nortpproxy:yes c=IN IP4 210.200.100.100 a=rtcp:4848 ---- The RTP "acceptor" is created under the IP 210.200.100.100 instead of the IP 210.200.243 as the SIPproxy is changing the SDP connection information. This is the logic we are using in our script for the INVITE and for the onreply_route if (is_method("INVITE")){ if (has_body("application/sdp")) { $var(trustconnectionip) = "%TRUSTCONNECTIONIP%"; $var(ciptrusted) = "no"; if ($var(trustconnectionip)=="yes") { $var(ciptrusted) = "yes"; } else if ($var(trustconnectionip)=="auto") { $var(sdpc) = $(rb{sdp.line,c}{s.substr,9,0}); if($td == $fd && $td != $var(sdpc)) { $var(ciptrusted) = "yes"; } } if ($var(ciptrusted)=="yes") { rtpproxy_offer("focnr"); } else { rtpproxy_offer("focn"); } } } And on the onreply if (has_body("application/sdp")) { $var(trustconnectionip) = "%TRUSTCONNECTIONIP%"; $var(ciptrusted) = "no"; if ($var(trustconnectionip)=="yes") { $var(ciptrusted) = "yes"; } else if ($var(trustconnectionip)=="auto") { $var(sdpc) = $(rb{sdp.line,c}{s.substr,9,0}); if($td == $fd && $td != $var(sdpc)) { $var(ciptrusted) = "yes"; } } if ($var(ciptrusted)=="yes") { rtpproxy_answer("fr"); } else { rtpproxy_answer("f"); } } Where TRUSTONNECTIONIP = "no" so basically we are doing rptproxy_offer("focn") and rtpproxy_answer("f"). Kind regards: Jose Palma --001a114188125fe8460520f67511 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Recently the maintainer of the SIPs= proxy in our company quit, and well I'm the new in charge of this proj= ect, the bad new is I had 0 experience with SIP.=C2=A0 After some week I go= t my first case related to our "SIP proxy".

<= div>We are using OpenSIP 1.8 within our Firewall to handle the protocol and= the NAT that it will imply within a Firewall. The script my ex coworker di= d is working in 99% of cases but this specific case.=C2=A0

The customer has one setup like this


=
PhoneA
PhoneB
PhoneC --- Call Manager --- Fi= rewall --- SBC --- Farm of RTP Media servers
....
Phone= N

The opensips instance is running within the fire= wall. The next IPs are fake but follow the "rules" of internal/ex= ternal it is just to avoid problems

Call Manager: = 172.17.1.1
Firewall: Internal Network 192.168.0.10
Fire= wall: Extenal Network 62.1.1.10
SBC: 210.200.100.100
Fa= rm of Media Servers: 210.200.100.128/= 25

So the invite works as Expected but on the = 180 Ringing either 200 OK the moment the messages traverse the SIP proxy, d= oesn't contain the "farm" IP but the SBC IP.

This are the 180 Ringing:

From SBC to the= Firewall

SIP/2.0 180 Ringing
Via: = SIP/2.0/UDP=C2=A062.1.1.10:5060;branch=3Dz9hG4bKd091.937a047.0
Vi= a: SIP/2.0/UDP=C2=A0172.17.1.1:5060;rport=3D5060;received=3D172.17.1.1;bran= ch=3Dz9hG4bKac393424402
From: <sip:5000 at 210.200.100.100>;tag=3D1c393411873
To: <sip:5001 at 210.200.100= .100;user=3Dphone>;tag=3DgK08c71cc5
Call-ID: 39341083229920151062 at 172.17.1.1
CSeq: 1 INVITE
Record-Route: <sip:62.1.1.10:5060;r2= =3Don;lr;did=3D6d8.933abaa6>
Record-Route: <sip:192.168.0.1= 0:5060;r2=3Don;lr;did=3D6d8.933abaa6>
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIF= Y,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: 100rel
= RSeq: 433990
Content-Length: =C2=A0 266
Content-Disposi= tion: session; handling=3Drequired
Content-Type: application/sdp<= /div>

v=3D0
o=3DSonus_UAC 176482 50736 IN IP4 = 210.200.100.100
s=3DSIP Media Capabilities
c=3DIN IP4 2= 10.200.100.243
t=3D0 0
m=3Daudio 61348 RTP/AVP 8 101
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:101 telephone-event/800= 0
a=3Dfmtp:101 0-15
a=3Dsendrecv
a=3Dptime:20=
a=3DsilenceSupp:off - - - -

After= the firewall + Opensips have processed this message to the call center

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP= =C2=A0172.17.1.1:5060;branch=3Dz9hG4bKac393424402
From: <sip:5000 at 210.200.100.100>;t= ag=3D1c393411873
To: <sip:5001 at 210.200.100.100;user=3Dphone>;tag=3DgK08c71cc5
<= div>Call-ID: 39341083229= 920151062 at 172.17.1.1
CSeq: 1 INVITE
Record-Route: &= lt;sip::62.1.1.10:5060;r2=3Don;lr;did=3D6d8.933abaa6>
Record-R= oute: <sip:192.168.0.10:5060;r2=3Don;lr;did=3D6d8.933abaa6>
Contact: <sip:5001 at 210.20= 0.100.100>
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INF= O,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: = 100rel
RSeq: 433990
Content-Length: 295
Conte= nt-Disposition: session; handling=3Drequired
Content-Type: applic= ation/sdp

v=3D0
o=3DSonus_UAC 176482 507= 36 IN IP4 210.200.100.100
s=3DSIP Media Capabilities
t= =3D0 0
m=3Daudio 4845 RTP/AVP 8 101
a=3Drtpmap:8 PCMA/8= 000
a=3Drtpmap:101 telephone-event/8000
a=3Dfmtp:101 0-= 15
a=3Dsendrecv
a=3Dptime:20
a=3DsilenceSupp:= off - - - -
a=3Dnortpproxy:yes
c=3DIN IP4 210.200.100.1= 00
a=3Drtcp:4848

----
The RTP "acceptor" is created under the IP 210.200.1= 00.100 instead of the IP 210.200.243 as the SIPproxy is changing the SDP co= nnection information.


This is the l= ogic we are using in our script for the INVITE and for the onreply_route

if (is_= method("INVITE")){
if (has_body("application/sdp")) {
$var(trustconnectionip) = =3D "%TRUSTCONNECTIONIP%";
$var(ciptrusted) =3D "no";
if ($var(trustconnectioni= p)=3D=3D"yes") {
$var(ciptrusted) =3D "yes";
} else if ($var(trustconnectionip= )=3D=3D"auto") {
$var(sdpc) =3D $(rb{sdp.line,c}{s.substr,9,0});
<= span class=3D"" style=3D"white-space:pre"> if($td =3D=3D $fd &= ;& $td !=3D $var(sdpc)) {
$var(ciptrusted) =3D "yes";
}
}
if ($var(ciptrusted)=3D=3D"yes") {
rtpproxy_offer= ("focnr");
= } else {
= rtpproxy_offer("focn");
}
}
}



And on the o= nreply

= if (has_body("application/sdp")) { $var(trustconnectionip) =3D "%TRUSTCONNECTIONIP%"; $var(ciptrusted) =3D "no"; if ($var(trustconnectionip)=3D=3D"yes") { $var(ciptrusted) =3D "yes"; } else if ($var(trustconnectionip)=3D=3D"auto") { $var(sdpc) =3D $(rb{sdp.line,c}{s.substr,9,0}); if($td =3D=3D $fd && $td !=3D $var(sdpc)) { $var(ciptrusted) =3D "yes"; } } if ($var(ciptrusted)=3D=3D"yes") { rtpproxy_answer("fr"); } else { rtpproxy_answer("f"); } }


Where TRUSTONNECTIONI= P =3D "no" so basically we are doing

rpt= proxy_offer("focn") and rtpproxy_answer("f").

Kind regards:

Jose Palma


--001a114188125fe8460520f67511-- From bogus@does.not.exist.com Thu Mar 26 14:29:42 2015 From: bogus@does.not.exist.com () Date: Thu, 26 Mar 2015 13:29:42 -0000 Subject: No subject Message-ID: Mine is as I sent it before subscribe_event("UL_AOR_INSERT", "rabbitmq:myrabbitserver/sip1dev"); I think the issue lies when appending params as everything except the params are sent to the queue. I am appending params in a wrapper like this raise_event("UL_AOR_DELETE", $avp(param)); On Mon, Oct 12, 2015 at 8:27 PM, R=C4=83zvan Crainea = wrote: > Hi, Tito! > > So you're saying that the exact logic works in 1.11, but not in 2.2? > Starting from 2.1 the socket syntax was changed a bit, to be able to > specify both the routing key and the exchange used. This was not possible > in 1.11. Are you sure you are specifying both? > > Best regards, > > R=C4=83zvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 10/12/2015 10:09 PM, Tito Cumpen wrote: > >> Any idea what has broken in the current dev version ? >> >> >> Thanks, >> Tito >> >> On Thu, Oct 1, 2015 at 9:17 PM, Tito Cumpen > > wrote: >> >> Razvan, >> >> >> The connection looks fine check this output from the logs >> >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding int param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:destroy_avp_list: destroying list (nil) >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding int param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:destroy_avp_list: destroying list (nil) >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding int param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:destroy_avp_list: destroying list (nil) >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding int param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:destroy_avp_list: destroying list (nil) >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding int param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:destroy_avp_list: destroying list (nil) >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_raise_event_msg: found subscriber E_UL_AOR_DELETE >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:event_route:scriptroute_fetch: Fetching parameters for event >> E_UL_AOR_DELETE >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:event_route:scriptroute_fetch: Successfully fetched 1 parameters >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:buf_init: initializing... >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: deleting this >> user patientdemo2.gmail and sending it to the queue for processing >> as patientdemo2.gmail >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_param_set: adding string param >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:evi_raise_event_msg: found subscriber MyrabbitserverIP >> >> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: >> DBG:core:destroy_avp_list: destroying list 0x7fafc8510150 >> >> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: >> DBG:core:tcp_read_req: Using the global ( per process ) buff >> >> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: >> DBG:core:tcp_handle_req: content-length=3D 0 >> >> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: >> DBG:core:async_tsend_stream: Async successful write from first try >> on 0x7fafc850e418 >> >> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: >> DBG:core:tcp_read_req: tcp_read_req end >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:probe_max_sock_buff: getsockopt: snd is initially 425984 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:print_ip: tcpconn_new: new tcp connection to: 50.56.XX.xXX >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:tcpconn_new: on port 56177, proto 2 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:tcpconn_add: hashes: 835, 62 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:handle_new_connect: new connection: 0x7fafc8510408 63 >> flags: 0006 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> INFO:core:send2child: no free tcp receiver, connection passed to the >> least busy one (1) >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:send2child: to tcp child 0 0(15039), 0x7fafc8510408 rw 1 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:handle_io: We have received conn 0x7fafc8510408 with rw 1 >> on fd 44 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:io_watch_add: [TCP_worker] io_watch_add op (44 on 7) >> (0x876720, 44, 19, 0x7fafc8510408,1), fd_no=3D3/2111 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:tcp_read_req: Using the global ( per process ) buff >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:tcp_read: EOF on 0x7fafc8510408, FD 44 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:tcp_read_req: EOF received >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 1 44 >> (0x876720, 44, 1, 0x10,0x3) fd_no=3D4 called >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:tcpconn_release: releasing con 0x7fafc8510408, state -1, >> fd=3D-1, id=3D62 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: >> DBG:core:tcpconn_release: extra_data (nil) >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:handle_tcp_worker: reader response=3D 7fafc8510408, -1 from= 0 >> >> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: >> DBG:core:tcpconn_destroy: destroying connection 0x7fafc8510408, >> flags 0006 >> >> >> >> Within the transmission to the queuing server I only the queue >> being(sip1dev) declared and nothing else. >> >> >> T opensips:57646 -> rabbitmqserver:5672 [AP] >> >> ........<.(....sip1dev.. >> >> # >> >> T opensips:57646 -> rabbitmqserver:5672 [AP] >> >> ........<............. >> >> # >> >> T opensips:57646 -> rabbitmqserver:5672 [AP] >> >> ......... >> >> # >> >> T rabbitmqserver:5672 ->opensips:57646 [A] >> >> >> >> I am using the exact same logic as far as raising events with the >> rabbit module goes in opensips 1.11.1-notls >> >> >> On Tue, Sep 29, 2015 at 4:54 AM, R=C4=83zvan Crainea > > wrote: >> >> So you are not seeing even the xlog() you are printing? Or >> you're not seeing anything on the rabbitmq server. >> Can you check the logs to see if there are any errors related to >> the rabbitmq connection? >> >> Best regards, >> >> R=C4=83zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 09/29/2015 01:10 PM, Tito Cumpen wrote: >> >>> Razvan, >>> >>> As I am not seeing anything when transmitting to my rabbitmq >>> server. I've ran traces locally and neither the title of the >>> published item is sent nor the params that are being declared >>> in the event route. >>> >>> Thanks, >>> Tito >>> >>> On Mon, Sep 28, 2015 at 5:37 AM, R=C4=83zvan Crainea >>> > wrote: >>> >>> Hi, Tito! >>> >>> So you can detect the event, but you do not see any >>> information attached to it? >>> >>> Best regards, >>> >>> R=C4=83zvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com < >>> http://www.opensips-solutions.com> >>> >>> On 09/22/2015 11:09 PM, Tito Cumpen wrote: >>> >>>> Group, >>>> >>>> >>>> I am noticing issues with 2.2 dev in reference to sending >>>> params when raising an event route. I am not seeing >>>> params being sent nor the name of the event when sending >>>> event to a rabbitmq server declared in the startup route. >>>> >>>> Here is out I have implemented and wrapped the event. >>>> >>>> >>>> event_route[E_UL_AOR_DELETE] { >>>> >>>> fetch_event_params("aor=3D$avp(aor)"); >>>> >>>> >>>> $avp(param) =3D "myip"; >>>> >>>> $avp(param) =3D $avp(aor); >>>> >>>> >>>> xlog("deleting this user $avp(aor) and sending it to the >>>> queue for processing as $avp(param)\n"); >>>> >>>> >>>> raise_event("UL_AOR_DELETE", $avp(param)); >>>> >>>> >>>> } >>>> >>>> >>>> startup_route { >>>> >>>> >>>> subscribe_event("UL_AOR_DELETE", >>>> "rabbitmq:rabbitmq/myqueue"); >>>> >>>> } >>>> >>>> Please advise if logs or a trace are necessary. >>>> >>>> >>>> Thanks, >>>> >>>> Tito >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > --001a11c1ca2822e7b70521ff47d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
R=C4= =83zvan,

section 1.3?
F= rom section 2.1 it looks like the subscription syntax looks the same.=C2=A0=

Mine is as I sent it before=C2=A0

<= /div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0subscribe_event("UL_AOR= _INSERT", "rabbitmq:myrabbitserver/sip1dev");


I = think the issue lies when appending params as everything except the params = are sent to the queue. I am appending params in a wrapper like this=C2=A0


=C2=A0 =C2=A0=C2=A0raise_event("UL_AOR_DELETE", $a= vp(param));




<= /span>


On Mon, Oct 12, 2015 at 8:27 PM, R=C4=83zvan Crainea <razvan at opensi= ps.org> wrote:
Hi, Tito!
So you're saying that the exact logic works in 1.11, but not in 2.2? Starting from 2.1 the socket syntax was changed a bit, to be able to specif= y both the routing key and the exchange used. This was not possible in 1.11= . Are you sure you are specifying both?

Best regards,

R=C4=83zvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 10/12/2015 10:09 PM, Tito Cumpen wrote:
Any idea what has broken in the current dev version ?


Thanks,
Tito

On Thu, Oct 1, 2015 at 9:17 PM, Tito Cumpen <tito at xsvoce.com
<mailto:tito at xsvoce= .com>> wrote:

=C2=A0 =C2=A0 Razvan,


=C2=A0 =C2=A0 The connection looks fine check this output from the logs


=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding int param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:destroy_avp_list: destroying list (nil)

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding int param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:destroy_avp_list: destroying list (nil)

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding int param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:destroy_avp_list: destroying list (nil)

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding int param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:destroy_avp_list: destroying list (nil)

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding int param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:destroy_avp_list: destroying list (nil)

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_raise_event_msg: found subscriber E_UL_AOR_DELET= E

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:event_route:scriptroute_fetch: Fetching parameters for ev= ent
=C2=A0 =C2=A0 E_UL_AOR_DELETE

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:event_route:scriptroute_fetch: Successfully fetched 1 par= ameters

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:buf_init: initializing...

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: d= eleting this
=C2=A0 =C2=A0 user patientdemo2.gmail and sending it to the queue for proce= ssing
=C2=A0 =C2=A0 as patientdemo2.gmail

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_param_set: adding string param

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:evi_raise_event_msg: found subscriber Myrabbitserver= IP

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:34 cloud-server-06 /sbin/opensips[15024]: =C2=A0 =C2=A0 DBG:core:destroy_avp_list: destroying list 0x7fafc8510150

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: =C2=A0 =C2=A0 DBG:core:tcp_read_req: Using the global ( per process ) buff<= br>
=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: =C2=A0 =C2=A0 DBG:core:tcp_handle_req: content-length=3D 0

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: =C2=A0 =C2=A0 DBG:core:async_tsend_stream: Async successful write from firs= t try
=C2=A0 =C2=A0 on 0x7fafc850e418

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:39 cloud-server-06 /sbin/opensips[15042]: =C2=A0 =C2=A0 DBG:core:tcp_read_req: tcp_read_req end

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:probe_max_sock_buff: getsockopt: snd is initially 42= 5984

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 INFO:core:probe_max_sock_buff: using snd buffer of 416 kb

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 INFO:core:init_sock_keepalive: TCP keepalive enabled on socke= t 63

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:print_ip: tcpconn_new: new tcp connection to: 50.56.= XX.xXX

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:tcpconn_new: on port 56177, proto 2

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:tcpconn_add: hashes: 835, 62

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:handle_new_connect: new connection: 0x7fafc8510408 6= 3
=C2=A0 =C2=A0 flags: 0006

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 INFO:core:send2child: no free tcp receiver, connection passed= to the
=C2=A0 =C2=A0 least busy one (1)

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:send2child: to tcp child 0 0(15039), 0x7fafc8510408 = rw 1

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:handle_io: We have received conn 0x7fafc8510408 with= rw 1
=C2=A0 =C2=A0 on fd 44

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:io_watch_add: [TCP_worker] io_watch_add op (44 on 7)=
=C2=A0 =C2=A0 (0x876720, 44, 19, 0x7fafc8510408,1), fd_no=3D3/2111

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:tcp_read_req: Using the global ( per process ) buff<= br>
=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:tcp_read: EOF on 0x7fafc8510408, FD 44

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:tcp_read_req: EOF received

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index = 1 44
=C2=A0 =C2=A0 (0x876720, 44, 1, 0x10,0x3) fd_no=3D4 called

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:tcpconn_release:=C2=A0 releasing con 0x7fafc8510408,= state -1,
=C2=A0 =C2=A0 fd=3D-1, id=3D62

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15039]: =C2=A0 =C2=A0 DBG:core:tcpconn_release:=C2=A0 extra_data (nil)

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:handle_tcp_worker: reader response=3D 7fafc8510408, = -1 from 0

=C2=A0 =C2=A0 Oct=C2=A0 2 01:06:48 cloud-server-06 /sbin/opensips[15053]: =C2=A0 =C2=A0 DBG:core:tcpconn_destroy: destroying connection 0x7fafc851040= 8,
=C2=A0 =C2=A0 flags 0006



=C2=A0 =C2=A0 Within the transmission to the queuing server I only the queu= e
=C2=A0 =C2=A0 being(sip1dev) declared and nothing else.


=C2=A0 =C2=A0 T opensips:57646 -> rabbitmqserver:5672 [AP]

=C2=A0 =C2=A0 ........<.(....sip1dev..

=C2=A0 =C2=A0 #

=C2=A0 =C2=A0 T opensips:57646 -> rabbitmqserver:5672 [AP]

=C2=A0 =C2=A0 ........<.............

=C2=A0 =C2=A0 #

=C2=A0 =C2=A0 T opensips:57646 -> rabbitmqserver:5672 [AP]

=C2=A0 =C2=A0 .........

=C2=A0 =C2=A0 #

=C2=A0 =C2=A0 T rabbitmqserver:5672 ->opensips:57646 [A]



=C2=A0 =C2=A0 I am using the exact same logic as far as raising events with= the
=C2=A0 =C2=A0 rabbit module goes in opensips 1.11.1-notls


=C2=A0 =C2=A0 On Tue, Sep 29, 2015 at 4:54 AM, R=C4=83zvan Crainea <razvan at opensips.org
=C2=A0 =C2=A0 <mailto:razvan at opensips.org>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So you are not seeing even the xlog() you are p= rinting? Or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 you're not seeing anything on the rabbitmq = server.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Can you check the logs to see if there are any = errors related to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the rabbitmq connection?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 R=C4=83zvan Crainea
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OpenSIPS Solutions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 www.opensips-solutions.com <http://www.opensips-solutions.com>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 09/29/2015 01:10 PM, Tito Cumpen wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Razvan,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As I am not seeing anything when transmitting t= o my rabbitmq
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server. I've ran traces locally=C2=A0 and n= either the title of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 published item=C2=A0 is sent nor the params tha= t are being declared
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in the event route.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tito

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Mon, Sep 28, 2015 at 5:37 AM, R=C4=83zvan Cr= ainea
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi, Tito!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So you can detect the event, but = you do not see any
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 information attached to it?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 R=C4=83zvan Crainea
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OpenSIPS Solutions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 www.opensips-solutions.co= m <http://www.opensips-solutions.com>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 09/22/2015 11:09 PM, Tito Cump= en wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Group,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I am noticing issues with 2.2 dev= in reference to sending
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 params when raising an event rout= e. I am not seeing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 params being sent nor the name of= the event when sending
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 event to a rabbitmq server declar= ed in the startup route.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here is out I have implemented an= d wrapped the event.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 event_route[E_UL_AOR_DELETE] {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fetch_event_params("aor=3D$a= vp(aor)");


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 $avp(param) =3D=C2=A0 &quo= t;myip";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 $avp(param) =3D $av= p(aor);


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xlog("deleting this user $av= p(aor) and sending it to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 queue for processing as $avp(para= m)\n");


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 raise_event("U= L_AOR_DELETE", $avp(param));


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 startup_route {


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 subscribe_event("UL_AOR_DELE= TE",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "rabbitmq:rabbitmq/myqueue&q= uot;);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please advise if logs or a trace = are necessary.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tito



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________________= ______________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Users mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Users at lists.opensips.org <mailto:Users at lists.opensip= s.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tp://lists.opensips.org/cgi-bin/mailman/listinfo/users


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________________= ______________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Users mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Users at lists.opensips.org <mailto:Users at lists.opensip= s.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tp://lists.opensips.org/cgi-bin/mailman/listinfo/users




=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Users mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Users at lists.opensips.org <mailto:Users at lists.opensips.org><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://lists.ope= nsips.org/cgi-bin/mailman/listinfo/users


=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Users mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Users at lists.opensips.org <mailto:Users at lists.opensips.org><= span class=3D"">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://lists.ope= nsips.org/cgi-bin/mailman/listinfo/users





_______________________________________________
Users mailing list
Users at lists.o= pensips.org
http://lists.opensips.org/cgi-bin/mailman/li= stinfo/users


_______________________________________________
Users mailing list
Users at lists.o= pensips.org
http://lists.opensips.org/cgi-bin/mailman/li= stinfo/users

--001a11c1ca2822e7b70521ff47d3--