Re: [OpenSIPS-Users] permission module
Hi, Sorry for delay. After stopping OpenSIPS (and before starting it again), could you check what you have in the file ? are all the records there ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.09.2014 02:03, discodo...@aol.com wrote: Yes I have checked and I see the added record in the file. If I stop and restart opensips then do a opensipsctl fifo address_dump I can then see the 2 records. For the record I am using DBTEXT for my database. -Original Message- From: Bogdan-Andrei Iancu bog...@opensips.org To: OpenSIPS users mailling list users@lists.opensips.org; discodog62 discodo...@aol.com Sent: Fri, Sep 19, 2014 1:59 am Subject: Re: [OpenSIPS-Users] permission module Hi, before doing the reload, can you check that you actually have the 2 records in the address table ? It seems there is only one, according to the reload logs: Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: number of rows in address table: 1 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.09.2014 03:00, discodo...@aol.com wrote: I am using opensips 1.11.2. When I add a new IP to the access list and then reload the newly added IP is not reloaded into memory. Here is what I am doing.. vma / # opensipsctl address show [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] vma / # opensipsctl address fifo address_dump Sep 18 16:51:51 [1738] DBG:mi_fifo:mi_fifo_server: entered consume Sep 18 16:51:51 [1738] DBG:mi_fifo:mi_fifo_server: done consume Sep 18 16:51:51 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree 97 192.168.2.5,1, 5068, 1, NULL, James vma / # opensipsctl address add 1 192.168.2.100 32 5060 udp Me Updated address, rows affected: 1 INFO: execute '/test/opensips/bin/opensipsctl address reload' to synchronize cache and database vma / # opensipsctl address show [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] [2, 1, '192.168.2.100', 32, 5060, 'udp', '', 'Me'] vma / # opensipsctl fifo address_dump Sep 18 16:52:28 [1738] DBG:mi_fifo:mi_fifo_server: entered consume Sep 18 16:52:28 [1738] DBG:mi_fifo:mi_fifo_server: done consume Sep 18 16:52:28 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree 97 192.168.2.5,1, 5068, 1, NULL, James vma / # opensipsctl address show [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] [2, 1, '192.168.2.100', 32, 5060, 'udp', '', 'Me'] vma / # opensipsctl fifo address_reload Sep 18 16:52:45 [1738] DBG:mi_fifo:mi_fifo_server: entered consume Sep 18 16:52:45 [1738] DBG:mi_fifo:mi_fifo_server: done consume Sep 18 16:52:45 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Sep 18 16:52:45 [1738] DBG:db_text:dbt_db_get_table: cache or mtime succeeded for [address] Sep 18 16:52:45 [1738] DBG:db_text:dbt_query: new res with 8 cols Sep 18 16:52:45 [1738] DBG:db_text:dbt_result_new: new res with 8 cols Sep 18 16:52:45 [1738] DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f39d69735d0 Sep 18 16:52:45 [1738] DBG:core:db_allocate_columns: allocate 224 bytes for result columns at 0x7f39d6974228 Sep 18 16:52:45 [1738] DBG:core:db_allocate_rows: allocate 272 bytes for result rows and values at 0x7f39d6974320 Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: number of rows in address table: 1 Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: Tuple 192.168.2.5, 1, 5068, 1, , James inserted into address hash table Sep 18 16:52:45 [1738] DBG:core:db_free_columns: freeing result columns at 0x7f39d6974228 Sep 18 16:52:45 [1738] DBG:core:db_free_rows: freeing 1 rows Sep 18 16:52:45 [1738] DBG:core:db_free_row: freeing row values at 0x7f39d6974330 Sep 18 16:52:45 [1738] DBG:core:db_free_rows: freeing rows at 0x7f39d6974320 Sep 18 16:52:45 [1738] DBG:core:db_free_result: freeing result set at 0x7f39d69735d0 Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: address table reloaded successfully. vma / # opensipsctl fifo address_dump Sep 18 16:52:53 [1738] DBG:mi_fifo:mi_fifo_server: entered consume Sep 18 16:52:53 [1738] DBG:mi_fifo:mi_fifo_server: done consume Sep 18 16:52:53 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree 97 192.168.2.5,1, 5068, 1, NULL, James vma / # opensipsctl address reloadshow [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] [2, 1, '192.168.2.100', 32, 5060, 'udp', '', 'Me'] vma / # opensipsctl fifo debug 0 Sep 18 16:53:08 [1738] DBG:mi_fifo:mi_parse_tree: adding node ; val 0 Sep 18 16:53:08 [1738] DBG:mi_fifo:mi_parse_node: end of input tree Sep 18 16:53:08 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree DEBUG:: 0 vma / # ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org
Re: [OpenSIPS-Users] Permission pattern
Hi The pattern field is used as an extra matching key - once the matching based on src IP is done, you can enforce a regular expression (the pattern) to match the message as text. In your scenario you do not need it. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.09.2014 16:09, Satish Patel wrote: We are looking for IP auth but with accounting so I are planing to use tech prefix so customer will send call with some prefix and we will use it identify customer and bill that according I'm planing to use permission module and its DB table has pattern column I don't know what that pattern means? Do it match dialed URI pattern like 163638...@example.com so if I want to filter it match to identify customer, should I use pattern field? Please clarify my doubt what that pattern column is and how I can full fill my requirement using it? -- Sent from my iPhone ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
Hi Ovidiu, We need to check once again if the mi_xmlrpc_ng can do a perfect replace for mi_xmlrpc - then we can obsolete in a blink of an eye. Are you aware of any pending issues in terms of backward compatibility ? PS: 1.12 is replaced by 2.1.0 - this is the version on trunk. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.09.2014 21:39, Ovidiu Sas wrote: Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? -ovidiu On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello all, Bringing some light here : none of the xmlrpc implementations offer a structured reply From the deprecation point of view, we need to be sure: 1) the new mi_xmlrpc-ng module is a perfect substitute to the old one (providing the same unstructured reply) 2) the new mi_xmlrpc-ng module can also provide a structured reply - this definitely is something good for the future 3) OpenSIPS CP must be migrated (there are some things that need to be changed) to be compatible with both modules. Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily working to achieve the 3 goals above (many thanks to both of them). As noticed, the old mi_xmlrpc module was not deprecated in 1.11 - there are small but many things to be done to 100% ensure a smooth transition. Still this is work on progress and it will be done for next release. Many thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.03.2014 21:55, Brett Nemeroff wrote: JSON+http sounds fantastic. It's like.. Starting to sound a like a RESTful server. I'm pretty sure others will jump on this. I know I would. -Brett On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas o...@voipembedded.com wrote: The new module is built on top of the httpd module which has a parameter to define the size of the buffer. If you need large replies, then you need to adjust the buffer size accordingly. http://www.opensips.org/html/docs/modules/devel/httpd That buffer is used by all modules that are sitting on top of the httpd module, and there's one single process dedicated to all http requests (no interference with SIP workers). Regards, Ovidiu Sas On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff br...@nemeroff.com wrote: I think there are some other issues with the size of the return data. I know for one that the mi_udp method has a buffer size limit. If you hit this limit I think it very quietly truncates the data. I can't 100% verify that since it's been a long time since I've used it. I believe you can paginate the data, but the problem is that you can't guarantee consistent results paginating data when the data is changing constantly. I'm not really sure on the background how this is handled; maybe a locked list or something.. but not sure if it'd affect performance at high velocity. Seems like something. somewhere would be affected.. either performance or accuracy. My point being, care needs to be taken that the method can produce consistent results; even for large datasets. If data is going to be truncated or we run out of SHM, there needs to not only be an error log, but I think the out put needs to say something as well. -Brett On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev goup2...@gmail.com wrote: I totally share Brett's feelings! For me dlg_list_ctx over the new module causes lots of headaches when dialogs go over 100 or so. Structured output would resolve such problems. I am totally in for structured SJON format too! 2014-03-19 21:07 GMT+02:00 Brett Nemeroff br...@nemeroff.com: I think the only reason for that is backwards compatibility with stuff written for the other mi interfaces. Honestly, my parsers for the MI output are ridiculous. It's really complicated and prone to failure. I'd like to know if others share my feeling here. For little things like dr_reload I don't really care. But for MI calls that return large amounts of user data, like dlg_list_ctx.. Parsing it is kind of ridiculous... Anyone else share this feeling? I personally would love to see it structured in JSON format. :) -Brett On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu Sas o...@voipembedded.com wrote: Hello Brett, It is true that the structured output mode was not implemented in the new module. It seems that having the output in one big chunk is the preferred method in the community. If there is a real demand for structured output, we can take a look into it. Regards, Ovidiu Sas On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff br...@nemeroff.com wrote: I'd like to see the new module to be a drop in replacement for the old one.. That being said... I was pretty surprised when I started down the path of the XMLRPC module that the reply isn't structured. It was just one big object. I'd like a selectable option on the module so that it either operates: 1. Legacy (one big output chunk) 2. Structured, parable for each output node. Really if we
Re: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
The trunk (development code) was switched from 1.12.x to 2.1.x and you can get the URL from http://www.opensips.org/Downloads/Downloads#toc4. The trunk version is not for production. See the available versions here: http://www.opensips.org/About/AvailableVersions Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 26.09.2014 16:48, Satish Patel wrote: Where is the trunk git URL to download latest 1.12.x? does it ready for production? On Thu, Sep 25, 2014 at 2:39 PM, Ovidiu Sas o...@voipembedded.com mailto:o...@voipembedded.com wrote: Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? -ovidiu On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hello all, Bringing some light here : none of the xmlrpc implementations offer a structured reply From the deprecation point of view, we need to be sure: 1) the new mi_xmlrpc-ng module is a perfect substitute to the old one (providing the same unstructured reply) 2) the new mi_xmlrpc-ng module can also provide a structured reply - this definitely is something good for the future 3) OpenSIPS CP must be migrated (there are some things that need to be changed) to be compatible with both modules. Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily working to achieve the 3 goals above (many thanks to both of them). As noticed, the old mi_xmlrpc module was not deprecated in 1.11 - there are small but many things to be done to 100% ensure a smooth transition. Still this is work on progress and it will be done for next release. Many thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.03.2014 21:55, Brett Nemeroff wrote: JSON+http sounds fantastic. It's like.. Starting to sound a like a RESTful server. I'm pretty sure others will jump on this. I know I would. -Brett On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas o...@voipembedded.com mailto:o...@voipembedded.com wrote: The new module is built on top of the httpd module which has a parameter to define the size of the buffer. If you need large replies, then you need to adjust the buffer size accordingly. http://www.opensips.org/html/docs/modules/devel/httpd That buffer is used by all modules that are sitting on top of the httpd module, and there's one single process dedicated to all http requests (no interference with SIP workers). Regards, Ovidiu Sas On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff br...@nemeroff.com mailto:br...@nemeroff.com wrote: I think there are some other issues with the size of the return data. I know for one that the mi_udp method has a buffer size limit. If you hit this limit I think it very quietly truncates the data. I can't 100% verify that since it's been a long time since I've used it. I believe you can paginate the data, but the problem is that you can't guarantee consistent results paginating data when the data is changing constantly. I'm not really sure on the background how this is handled; maybe a locked list or something.. but not sure if it'd affect performance at high velocity. Seems like something. somewhere would be affected.. either performance or accuracy. My point being, care needs to be taken that the method can produce consistent results; even for large datasets. If data is going to be truncated or we run out of SHM, there needs to not only be an error log, but I think the out put needs to say something as well. -Brett On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev goup2...@gmail.com mailto:goup2...@gmail.com wrote: I totally share Brett's feelings! For me dlg_list_ctx over the new module causes lots of headaches when dialogs go over 100 or so. Structured output would resolve such problems. I am totally in for structured SJON format too! 2014-03-19 21:07 GMT+02:00 Brett Nemeroff br...@nemeroff.com mailto:br...@nemeroff.com: I think the only reason for that is backwards compatibility with stuff written for the other mi interfaces. Honestly, my parsers for the MI output are ridiculous. It's really complicated and prone to failure. I'd like to know if others share my feeling here. For little things like dr_reload I don't really care. But for MI calls that return large amounts of user data, like dlg_list_ctx..
Re: [OpenSIPS-Users] Needs Script Help
Hello, Seehttp://www.opensips.org/Community/Business Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 26.09.2014 02:19, Levent Tinaz wrote: Hello, Our company needs some help on our opensips servers. We are looking for a contractor to assist us. Please let us know your rate and availability at supp...@sponsoracall.com mailto:supp...@sponsoracall.com Thanks. Levent ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] +sip.instance parameter is missing in 200 OK for REGISTER
Hello , A registrar server stores the registered contact URIs (the those URIs are the one returned in the 200 OK). The +sip.instance is not part of the contact URI - it is actually a parameter of the Contact header, not a parameter of the Contact URI. This is way it is not saved. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 08:35, simbad wrote: Hi Bogdan , Thank you for replying. Here is the the REGISTER request and its corresponding 200 OK. REGISTER sip:com.mydomain.net SIP/2.0 Call-Id: yl44SiUAAA@xxx.x.x.x CSeq: 2 REGISTER From: sip:+9197466xx...@com.mydomain.net;tag=rm44SiUBAA To: sip:+9197466xx...@com.mydomain.net Via: SIP/2.0/TLS xxx.x.x.x:;branch=z9hG4bK1411213658669;keep Max-Forwards: 70 Contact: sip:+9197466x@xxx.x.x.x:;transport=tls;+sip.instance=sip_intance_value;+g.oma.sip-im;+g.3gpp.cs-voice;+g.3gpp.iari-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopullft,urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-is;+g.gsma.rcs.ipcall;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel;video;expires=3600 Supported: path,gruu P-Preferred-Identity: sip:+9197466xx...@com.mydomain.net User-Agent: IM-client/OMA1.0 local-build/version-not-set P-Access-Network-Info: IEEE-802.11n Allow: INVITE, ACK, BYE, CANCEL, NOTIFY, OPTIONS, MESSAGE Authorization: Digest username=+9197466xx...@com.mydomain.net,uri=sip:com.mydomain.net,algorithm=MD5,realm=com.mydomain.net,nonce=541d697800a7adc6e6abeb6386e32a37d652a9562296,response=839c0f7372fadb82250943de21ceff0b Content-Length: 0 SIP/2.0 200 OK Call-Id: yl44SiUAAA@xxx.x.x.x CSeq: 2 REGISTER From: sip:+9197466xx...@com.mydomain.net;tag=rm44SiUBAA To: sip:+9197466xx...@com.mydomain.net;tag=da49f3d59ded0458f7cec35893ecbaba.2f5a Via: SIP/2.0/TLS xxx.x.x.x:;received=x.xx.xx.xxx;rport=54494;branch=z9hG4bK1411213658669;keep J-Via: SIP/2.0/TLS xxx.x.x.x:;branch=z9hG4bK1411213658669;keep=120 P-Associated-URI: tel:+9197466x, sip:+9197466xx...@com.mydomain.net Contact: sip:+9197466x@xxx.x.x.x:;transport=tls;expires=3600;received=sip:x.xx.xx.xxx:x;transport=TLS Server: My server SIP Proxy 1.10.1 Content-Length: 0 -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/sip-instance-parameter-is-missing-in-200-OK-for-REGISTER-tp7593626p7593809.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
There was a lot of work done right before releasing 1.11 to fix the compatibility issue. I didn't heard back anything, so I assume that it's fixed. Anyway, if there's no push for it, the transition will never happen :) -ovidiu On Oct 7, 2014 5:24 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi Ovidiu, We need to check once again if the mi_xmlrpc_ng can do a perfect replace for mi_xmlrpc - then we can obsolete in a blink of an eye. Are you aware of any pending issues in terms of backward compatibility ? PS: 1.12 is replaced by 2.1.0 - this is the version on trunk. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.09.2014 21:39, Ovidiu Sas wrote: Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? -ovidiu On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello all, Bringing some light here : none of the xmlrpc implementations offer a structured reply From the deprecation point of view, we need to be sure: 1) the new mi_xmlrpc-ng module is a perfect substitute to the old one (providing the same unstructured reply) 2) the new mi_xmlrpc-ng module can also provide a structured reply - this definitely is something good for the future 3) OpenSIPS CP must be migrated (there are some things that need to be changed) to be compatible with both modules. Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily working to achieve the 3 goals above (many thanks to both of them). As noticed, the old mi_xmlrpc module was not deprecated in 1.11 - there are small but many things to be done to 100% ensure a smooth transition. Still this is work on progress and it will be done for next release. Many thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.03.2014 21:55, Brett Nemeroff wrote: JSON+http sounds fantastic. It's like.. Starting to sound a like a RESTful server. I'm pretty sure others will jump on this. I know I would. -Brett On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas o...@voipembedded.com wrote: The new module is built on top of the httpd module which has a parameter to define the size of the buffer. If you need large replies, then you need to adjust the buffer size accordingly. http://www.opensips.org/html/docs/modules/devel/httpd That buffer is used by all modules that are sitting on top of the httpd module, and there's one single process dedicated to all http requests (no interference with SIP workers). Regards, Ovidiu Sas On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff br...@nemeroff.com wrote: I think there are some other issues with the size of the return data. I know for one that the mi_udp method has a buffer size limit. If you hit this limit I think it very quietly truncates the data. I can't 100% verify that since it's been a long time since I've used it. I believe you can paginate the data, but the problem is that you can't guarantee consistent results paginating data when the data is changing constantly. I'm not really sure on the background how this is handled; maybe a locked list or something.. but not sure if it'd affect performance at high velocity. Seems like something. somewhere would be affected.. either performance or accuracy. My point being, care needs to be taken that the method can produce consistent results; even for large datasets. If data is going to be truncated or we run out of SHM, there needs to not only be an error log, but I think the out put needs to say something as well. -Brett On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev goup2...@gmail.com wrote: I totally share Brett's feelings! For me dlg_list_ctx over the new module causes lots of headaches when dialogs go over 100 or so. Structured output would resolve such problems. I am totally in for structured SJON format too! 2014-03-19 21:07 GMT+02:00 Brett Nemeroff br...@nemeroff.com: I think the only reason for that is backwards compatibility with stuff written for the other mi interfaces. Honestly, my parsers for the MI output are ridiculous. It's really complicated and prone to failure. I'd like to know if others share my feeling here. For little things like dr_reload I don't really care. But for MI calls that return large amounts of user data, like dlg_list_ctx.. Parsing it is kind of ridiculous... Anyone else share this feeling? I personally would love to see it structured in JSON format. :) -Brett On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu Sas o...@voipembedded.com wrote: Hello Brett, It is true that the structured output mode was not implemented in the new module. It seems that having the output in one big chunk is the preferred method in the community. If there is a real demand for structured output, we can take a look into it. Regards, Ovidiu Sas On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff
Re: [OpenSIPS-Users] $T_fr_timeout and $T_fr_inv_timeout
Hi Gary,
The difference between the 2 timer is if a reply was received or not -
until the first reply you have T_fr_timeout, after that, it is
T_fr_inv_timeout.
So, use the t_local_replied(all)
(http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id295158) to
see if any rely was received.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.10.2014 04:58, Gary Nyquist wrote:
Hi,
Is it possible to know (inside a failure_route[] block), which timeout caused
to land up in the failure_route?
# E.g. in the main route, I have:
if(is_method(INVITE)){
...
...
$T_fr_timeout=8;
$T_fr_inv_timeout=30;
t_on_failure(1);
t_relay();
exit;
}
# And in failure_route:
failure_route[1] {
# How to know if $T_fr_timeout or $T_fr_inv_timeout caused this failure?
}
Any tips?
Thanks.
Best Regards,
- Gary
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] ERROR:tm:t_check: INVITE reply cannot be parsed
Hello Alec, The error means you received a reply with syntax errors (in this case you should have other error logs before) or with VIA or CSEQ hdr missing (not other errors in advance). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 03:24, Alec Doran-Twyford wrote: Hi all, I am getting this error ERROR:tm:t_check: INVITE reply cannot be parsed when someone makes a call though our system. I am not sure where it came from. I am just wondering if anyone know some common problem when this has happens? Alec Doran-Twyford | Support Engineer for IVSTel | | E-mail: a.dorantwyf...@ivstel.com mailto:a.dorantwyf...@ivstel.com | Skype: AlecDoranTwyford | | Phone: +61 2 9288 8890 | Mob: +61 423 694 742 | | LinkedIn https://www.linkedin.com/in/alectronic0 | ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
Ovidiu, we are still somewhere in the middle of a release cycle, so enough time to eventually fix potential problems. I agree with you, we need to take the step and face the outcome. We need to prepare a directly on the repo, like modules_old where to move the obsolete modules. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 15:43, Ovidiu Sas wrote: There was a lot of work done right before releasing 1.11 to fix the compatibility issue. I didn't heard back anything, so I assume that it's fixed. Anyway, if there's no push for it, the transition will never happen :) -ovidiu On Oct 7, 2014 5:24 AM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hi Ovidiu, We need to check once again if the mi_xmlrpc_ng can do a perfect replace for mi_xmlrpc - then we can obsolete in a blink of an eye. Are you aware of any pending issues in terms of backward compatibility ? PS: 1.12 is replaced by 2.1.0 - this is the version on trunk. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.09.2014 21 tel:25.09.2014%2021:39, Ovidiu Sas wrote: Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? -ovidiu On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hello all, Bringing some light here : none of the xmlrpc implementations offer a structured reply From the deprecation point of view, we need to be sure: 1) the new mi_xmlrpc-ng module is a perfect substitute to the old one (providing the same unstructured reply) 2) the new mi_xmlrpc-ng module can also provide a structured reply - this definitely is something good for the future 3) OpenSIPS CP must be migrated (there are some things that need to be changed) to be compatible with both modules. Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily working to achieve the 3 goals above (many thanks to both of them). As noticed, the old mi_xmlrpc module was not deprecated in 1.11 - there are small but many things to be done to 100% ensure a smooth transition. Still this is work on progress and it will be done for next release. Many thanks, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 19.03.2014 21:55, Brett Nemeroff wrote: JSON+http sounds fantastic. It's like.. Starting to sound a like a RESTful server. I'm pretty sure others will jump on this. I know I would. -Brett On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas o...@voipembedded.com mailto:o...@voipembedded.com wrote: The new module is built on top of the httpd module which has a parameter to define the size of the buffer. If you need large replies, then you need to adjust the buffer size accordingly. http://www.opensips.org/html/docs/modules/devel/httpd That buffer is used by all modules that are sitting on top of the httpd module, and there's one single process dedicated to all http requests (no interference with SIP workers). Regards, Ovidiu Sas On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff br...@nemeroff.com mailto:br...@nemeroff.com wrote: I think there are some other issues with the size of the return data. I know for one that the mi_udp method has a buffer size limit. If you hit this limit I think it very quietly truncates the data. I can't 100% verify that since it's been a long time since I've used it. I believe you can paginate the data, but the problem is that you can't guarantee consistent results paginating data when the data is changing constantly. I'm not really sure on the background how this is handled; maybe a locked list or something.. but not sure if it'd affect performance at high velocity. Seems like something. somewhere would be affected.. either
Re: [OpenSIPS-Users] ERROR:tm:t_check: INVITE reply cannot be parsed
Hi all, I am getting this error ERROR:tm:t_check: INVITE reply cannot be parsed when some make a call though our system. I am not sure where it came from I just wondering if anyone know some common problem when this has happens? it happen sometime after someone does an Invite from one of our clients systems but not from our own. Alec Doran-Twyford | Support Engineer for IVSTel | | E-mail: a.dorantwyf...@ivstel.com | Skype: AlecDoranTwyford | | Phone: +61 2 9288 8890 | Mob: +61 423 694 742 | | LinkedIn https://www.linkedin.com/in/alectronic0 | ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] menuconfig-tool
Hi Jaap, It is standard shell stuff - Crtl z puts the current app into background. You can see background apps with jobs and bring one back forward with fg [id] Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05.10.2014 21:46, Jaap van der Starre wrote: to Vlad Paiu I followed the video 2012-05-18.02 OpenSIPS Kick Start At one time you go out of Menuconfig-tool using ^z into bash. Then you go back from bash to Menuconfig-tool again. How do you do that? Which key do I use to go back to Menuconfig ? --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Flow stops when branch is dropped
Hi Mickael, If you do the drop in branch route, that branch will be discarded (not sent out at all). IF no branch is actually sent out, you will get the error logs from t_forward_nonack (as you have). In this case, the t_relay() will fail (nothing sent) - to get that error in script, set flag 0x02 (http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id294578), otherwise the error will be internally handled. A failure on sending does not trigger a failure route - failure route is triggered only if request sent out and the transaction completed with a negative code. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06.10.2014 11:59, Mickael Marrache wrote: Hi, What happens after drop() is called from a branch_route? In my case, I armed a failure route for the incoming INVITE in the request route and therefore, I would expect that the failure route would be called after drop() is called. However, I see the following error in the logs and the following reply is returned to the UAC. Oct 6 08:57:27 DBG:tm:pre_print_uac_request: dropping branch sip:x@x:;user=phone Oct 6 08:57:27 ERROR:tm:t_forward_nonack: failure to add branches SIP/2.0 500 Server error occurred (1/TM) I use the failure route to detect current transaction failure and try the next termination if there is. Thanks, Mickael ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_text for domain table
Hi Chen-Che, Which OpenSIPS version are you using ? maybe you have an old one where the domain module is not compatible with the db_text driver. In 1.11 definitely is. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06.10.2014 10:44, microx wrote: Dear all, I use the db_text module for the dispatcher and domain tables. For the dispatcher table, it works successfully. However, for the domain table, the OpenSIP server always fails to read the domain table on startup. Please help to take a look what listed below. Thanks for any comment. Best wishes, Chen-Che Related part of the OpenSIPS config loadmodule db_text.so loadmodule domain.so modparam(db_text, db_mode, 0) modparam(domain, db_url, text:///etc/opensips) modparam(domain, domain_table, domain) modparam(domain, db_mode, 1) # Use caching (file)/etc/opensips/domain id(int) domain(str) last_modified(str,null) 1:siptest.com:: Log message DBG:db_text:dbt_load_file: loading file [/etc/opensips/domain] DBG:db_text:dbt_table_new: mtime is 1412576125 DBG:db_text:dbt_load_file: column[0] is INT! DBG:db_text:dbt_load_file: column[1] is STR! DBG:db_text:dbt_load_file: column[2] is STR! DBG:db_text:dbt_query: new res with 1 cols DBG:db_text:dbt_result_new: new res with 1 cols DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f14717152c8 DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f14717155f8 DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f1471715480 DBG:domain:reload_domain_table: Number of rows in domain table: 1 *ERROR:domain:reload_domain_table: Database problem* -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE
Hi Kaan, The log you refer to is a DBG and not an ERR (error) - when a new request is received, opensips (inside the t_relay) tries to match it against existing transactions to see if it a retransmission on not. The fact your request does not match means it is not a retransmission, but rather a new request. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04.10.2014 11:18, Kaan Dandin wrote: Hi all, I am making registration to the Open IMS nodes(192.168.2.3 and 192.168.2.5) simultaneously from IMS bench(192.168.2.11). Registration messages are going through OpenSIPS load balancer(192.168.2.141). Registration messages which are going to first Open IMS node(192.168.2.5) completed succesfully. But registration to second IMS node(192.168.2.3) is not completed successfully since t_relay() function in OpenSIPS load balancer is giving DBG:tm:matching_3261: RFC3261 transaction matching failed error and not passing the Status: 401 Unauthorized - Challenging the UE(0 bindings) messages to IMS bench. Below please find wireshark log and opensips logs in debug level=6. Do you have any idea for this problem. BR, Kaan o. TimeSource Destination Protocol Info 55 1.186495192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 56 1.188443192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 57 1.189001192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 58 1.215792192.168.2.5 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE(0 bindings) 59 1.216974192.168.2.141 192.168.2.11 SIP Status: 401 Unauthorized - Challenging the UE(0 bindings) 60 1.217486192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 61 1.218516192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 62 1.218804192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 63 1.233561192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE(0 bindings) 64 1.241624192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE(0 bindings) 65 1.246112192.168.2.5 192.168.2.141 SIP Status: 200 OK - SAR succesful and registrar saved(1 bindings) 66 1.246919192.168.2.141 192.168.2.11 SIP Status: 200 OK - SAR succesful and registrar saved(1 bindings) Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog method: [REGISTER] totag: [null] sipid: [192.168.2.11] messageid: [68] callid: [56-6888@192.168.2.11] callsequence: [2] Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:uri:has_totag: no totag Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog_initialregister Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:comp_scriptvar: str 20 : 192.168.2.11 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_newtran: transaction on entrance=0x Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags= Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: content_length=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: found end of header Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=78 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:matching_3261: RFC3261 transaction matching failed Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: no transaction found Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 1 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 0 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_text for domain table
Hi Bogdan-Andrei, I use OpenSIPS 1.9.2. I hope the version is not too old for the domain table. Best wishes, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779p7593827.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensips-1.6 recv queue full
Dear Bogdan, I am using opensips-1.6 on CentOS-5.8. In certain conditions I am seeing lot of packets queued in recv queue and not getting processed. I am monitoring the same using netstat command. While observing the siptrace I found, opensips couldn't reply to incoming msgs, and if replied, it replies very late. What sort of params I should observe/optimize to handle this kinda situation(when getting very high traffic on switch) ?? thnx ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_text for domain table
Hello Chen-Che, 1.9 does not have that fix (to support db_text), neither 1.10 . Only 1.11 has it. That fix is combined with adding attr support for domains: https://github.com/OpenSIPS/opensips/commit/57ec0f399438b383b031535dc27a1e253ca78bec Of course, you can try and copy the whole module (+db schema) from 1.11 to 1.9. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 16:46, microx wrote: Hi Bogdan-Andrei, I use OpenSIPS 1.9.2. I hope the version is not too old for the domain table. Best wishes, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779p7593827.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips-1.6 recv queue full
Generally you can monitor for this with: netstat -nlp|grep opensips but I suspect you are already doing something similar. The statistics module also has a similar statistics. The command: opensipsctl fifo get_statistics all If you look near the bottom, you'll see the load in percent of the children for each listening interface. It looks like this: load:udp:1.2.3.4:5060-load = 18 ie: 1.2.3.4 is 18% busy. If this number reaches 100, your children are no longer capable of responding to UDP packets on that interface and the kernel will begin to queue if possible. -Brett On Tue, Oct 7, 2014 at 8:58 AM, Vandan Joshi vandan.jo...@panamaxil.com wrote: Dear Bogdan, I am using opensips-1.6 on CentOS-5.8. In certain conditions I am seeing lot of packets queued in recv queue and not getting processed. I am monitoring the same using netstat command. While observing the siptrace I found, opensips couldn't reply to incoming msgs, and if replied, it replies very late. What sort of params I should observe/optimize to handle this kinda situation(when getting very high traffic on switch) ?? thnx ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips-1.6 recv queue full
Dear Brett, I think this statistics option isn't avail in opensips-1.6 ver. plz tell me wt can I do in 1.6. thnx for the reply. - Original Message - From: Brett Nemeroff br...@nemeroff.com To: OpenSIPS users mailling list users@lists.opensips.org Sent: Tuesday, October 7, 2014 8:16:35 PM Subject: Re: [OpenSIPS-Users] opensips-1.6 recv queue full Generally you can monitor for this with: netstat -nlp|grep opensips but I suspect you are already doing something similar. The statistics module also has a similar statistics. The command: opensipsctl fifo get_statistics all If you look near the bottom, you'll see the load in percent of the children for each listening interface. It looks like this: load:udp:1.2.3.4:5060-load = 18 ie: 1.2.3.4 is 18% busy. If this number reaches 100, your children are no longer capable of responding to UDP packets on that interface and the kernel will begin to queue if possible. -Brett On Tue, Oct 7, 2014 at 8:58 AM, Vandan Joshi vandan.jo...@panamaxil.com wrote: Dear Bogdan, I am using opensips-1.6 on CentOS-5.8. In certain conditions I am seeing lot of packets queued in recv queue and not getting processed. I am monitoring the same using netstat command. While observing the siptrace I found, opensips couldn't reply to incoming msgs, and if replied, it replies very late. What sort of params I should observe/optimize to handle this kinda situation(when getting very high traffic on switch) ?? thnx ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips-1.6 recv queue full
I'd be surprised if it wasn't.. Either way, netstat will give you pretty good information. I regularly monitor the output values in netstat. On Tue, Oct 7, 2014 at 9:51 AM, Vandan Joshi vandan.jo...@panamaxil.com wrote: Dear Brett, I think this statistics option isn't avail in opensips-1.6 ver. plz tell me wt can I do in 1.6. thnx for the reply. -- *From: *Brett Nemeroff br...@nemeroff.com *To: *OpenSIPS users mailling list users@lists.opensips.org *Sent: *Tuesday, October 7, 2014 8:16:35 PM *Subject: *Re: [OpenSIPS-Users] opensips-1.6 recv queue full Generally you can monitor for this with: netstat -nlp|grep opensips but I suspect you are already doing something similar. The statistics module also has a similar statistics. The command: opensipsctl fifo get_statistics all If you look near the bottom, you'll see the load in percent of the children for each listening interface. It looks like this: load:udp:1.2.3.4:5060-load = 18 ie: 1.2.3.4 is 18% busy. If this number reaches 100, your children are no longer capable of responding to UDP packets on that interface and the kernel will begin to queue if possible. -Brett On Tue, Oct 7, 2014 at 8:58 AM, Vandan Joshi vandan.jo...@panamaxil.com wrote: Dear Bogdan, I am using opensips-1.6 on CentOS-5.8. In certain conditions I am seeing lot of packets queued in recv queue and not getting processed. I am monitoring the same using netstat command. While observing the siptrace I found, opensips couldn't reply to incoming msgs, and if replied, it replies very late. What sort of params I should observe/optimize to handle this kinda situation(when getting very high traffic on switch) ?? thnx ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] $T_fr_timeout and $T_fr_inv_timeout
Thank you Bogdan for the advice.
That's what I was looking for :-)
Best Regards,
- Gary
Sent: Tuesday, October 07, 2014 at 9:10 AM
From: Bogdan-Andrei Iancu bog...@opensips.org
To: OpenSIPS users mailling list users@lists.opensips.org, g...@gmx.us
Subject: Re: [OpenSIPS-Users] $T_fr_timeout and $T_fr_inv_timeout
Hi Gary,
The difference between the 2 timer is if a reply was received or not -
until the first reply you have T_fr_timeout, after that, it is
T_fr_inv_timeout.
So, use the t_local_replied(all)
(http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id295158) to
see if any rely was received.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.10.2014 04:58, Gary Nyquist wrote:
Hi,
Is it possible to know (inside a failure_route[] block), which timeout
caused to land up in the failure_route?
# E.g. in the main route, I have:
if(is_method(INVITE)){
...
...
$T_fr_timeout=8;
$T_fr_inv_timeout=30;
t_on_failure(1);
t_relay();
exit;
}
# And in failure_route:
failure_route[1] {
# How to know if $T_fr_timeout or $T_fr_inv_timeout caused this
failure?
}
Any tips?
Thanks.
Best Regards,
- Gary
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] OpenSIPS Las Vegas Summit - Speakers Workshops - part
Ever wonder how you can: * load balance your Asterisk servers * provide fail over protection for your Asterisk servers * distribute services to your Asterisk server clusters *On October 21st, 2014, Las Vegas will be the the OpenSIPS city!* *Vlad Paiu - OpenSIPS core developer - */OpenSIPS, a service enabler for Asterisk/// By using OpenSIPS as a front-end for the Asterisk-based system, additional/advanced SIP services can be enabled for the end-users. OpenSIPS can act as an enabler for SIP SIMPLE (presence and IM), XCAP, webRTC, TLS support, Parallel Registration, IRC-like chatting and other end-user oriented services. Aside the end-user service, OpenSIPS can address provider oriented services like LCR and Gateway failover for the outbound traffic, LNP and CNAME dipping, etc. *Razvan Crainea ***- OpenSIPS core developer *- */Scaling Asterisk with OpenSIPS/ There is a huge number of successful Asterisk-based platforms which need to grow beyond the one-instance stage. To grow/scale as capacity or as geographical coverage. OpenSIPS provides the solution for such platform - the typical OpenSIPS sandwich consists of a pool of Asterisk servers between two OpenSIPS instances, on inbound and outbound. On the inbound side, OpenSIPS can solve the problem of doing SIP wise balancing and redundancy for the Asterisk cluster, to ensure traffic validation and shaping. Aside complex authentication mechanisms (as digest, LDAP, IP based), the fronting OpenSIPS is responsible for provide fraud detection and other various security tools. On the outbound side, OpenSIPS takes care of complex routing logics to PSTN carriers / GW, LCR, CNAME or LNP dipping. Traffic to carriers can be CPS/CC controlled and accounted. The latest OpenSIPS version is able to provide Quality based Routing towards carriers And more speakers and even more topics to follow. See http://www.opensips.org/Community/Summit-2014LasVegas-Schedule To *register for the event*, see http://www.opensips.org/Community/Summit-Registration Participating the Astricon? Use the astricon2014 discount code ;). See you in Vegas, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
