Re: [OpenSIPS-Users] Certificate Error for www.opensips.org
Just checked and it looks good now. On Thu, May 9, 2019 at 1:48 AM Răzvan Crainea wrote: > Hi, Ryan! > > You are right, we have changed the certificates to use letsencyrpt, and > did not add www.opensips.org. I've just done that now, can you check > again? > > Best regards, > Răzvan > > On 5/8/19 9:02 PM, Ryan Bullock wrote: > > Not sure the best place to report this. > > > > Looks like a new cert for opensips.org <http://opensips.org> is giving > a > > certificate error under Firefox: > > > > Websites prove their identity via certificates. Firefox does not trust > > this site because it uses a certificate that is not valid for > > www.opensips.org <http://www.opensips.org>. The certificate is only > > valid for opensips.org <http://opensips.org>. > > > > Error code: SSL_ERROR_BAD_CERT_DOMAIN > > > > Firefox seems to like adding the www prefix by default (at least for > > me). Via google the url is https://www.opensips.org/, which gives the > > error. If you visit https://opensips.org/ directly it works fine. > > > > Site works under Chrome (which seems to always strip the www prefix, > > even via a link). > > > > > > Regards, > > > > Ryan Bullock > > > > ___ > > Users mailing list > > Users@lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Răzvan Crainea > OpenSIPS Core Developer >http://www.opensips-solutions.com > Meet the OpenSIPS team at the next OpenSIPS Summit: >https://www.opensips.org/events > > ___ > 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] Certificate Error for www.opensips.org
Not sure the best place to report this. Looks like a new cert for opensips.org is giving a certificate error under Firefox: Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for www.opensips.org. The certificate is only valid for opensips.org. Error code: SSL_ERROR_BAD_CERT_DOMAIN Firefox seems to like adding the www prefix by default (at least for me). Via google the url is https://www.opensips.org/, which gives the error. If you visit https://opensips.org/ directly it works fine. Site works under Chrome (which seems to always strip the www prefix, even via a link). Regards, Ryan Bullock ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Announcing rtpproxy v2.0.0
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 john.mat...@divoxmedia.com wrote: Yes On Tuesday, 17 March 2015, Zheng Frank zhengyumingap...@gmail.com wrote: Do you mean ROHC ? 2015-03-14 12:39 GMT+08:00 Maxim Sobolev sobo...@sippysoft.com: Do you have any particular RFC in mind? On Mar 12, 2015 10:28 AM, John Mathew john.mat...@divoxmedia.com 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 sobo...@sippysoft.com 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+unsubscr...@googlegroups.com. To post to this group, send email to rtppr...@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 https://groups.google.com/d/msgid/rtpproxy/CA%2BSkwpUhu9fpwmqpRFiaXsQo9_%2B6M8MFtJ2sKi4kd5sr%3Ds%2BR5Q%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-us...@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Sent from iPhone 6 ___ 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] Message compression in OpenSIPS 1.12
I think all the items proposed in the first section would be great additions. The items in the second look more implementation specific, but I can see the uses. I think that items 1a and 1b should also have the reverse options present as well. Normalize everything to long form and expand all headers. I think this would be great for interoperability as some older platforms struggle with short form (or mixed form) and consolidated headers. Also, the ability to specify all the options in section 1 on a dialog direction would also be great. I.E create_dialog(sL) would compact all headers to short form for the caller side and normalize everything to long form for the callee side. create_dialog(lS) would do the opposite. The idea here is that support for a format is going to be endpoint specific, so being able to set it once at dialog creation would be helpful. Regards, Ryan Bullock On Tue, Sep 30, 2014 at 3:47 AM, Răzvan Crainea raz...@opensips.org wrote: Hi, Yavari! Of course, this will also impact the performance, but I don't think it will be something considerable, since we will not compress large amount of data. Our current tests show that for a 1024 bytes long buffer compression/decompression time takes less than 200us for compression and 25us for decompression on a comodity computer. Since this will only be done on edge nodes, I don't think it has such a big impact on the platform. Best regards, Răzvan Crainea OpenSIPS Solutionswww.opensips-solutions.com On 09/30/2014 10:26 AM, H Yavari wrote: Hi to all, This is an amazing idea, but I have a question about the performance, the compression/decompression process is not any bottleneck for the system performance? or any effect on process power? Regards, H.Yavari -- On 03.09.2014 11:59, Saúl Ibarra Corretgé wrote: Hi Razvan, On 02 Sep 2014, at 18:25, Răzvan Crainea raz...@opensips.org wrote: 2)Compressing the SIP message (using gzip). The idea is to take the SDP body and several headers that are not used in the routing logic, compress them, apply a base64 transformation and add to the message's body. A use case for this is a platform that has several edge servers (SBCs) and a few core instances - when entering the platform the message compression should be applied and then sent to the core servers. Inside the core networks, the messages should be carried in the compressed format to reduce the bandwidth. When leaving the network, the message has to be decompressed and forwarded to the next gateway without any compression, since the other equipments might not understand them. There will be several functions exported in the script: a) compress_msg(1,Header1|Header2); compresses the body of the message and listed headers b) decompress_msg(); decompress both headers and body What do you think about this approach? Is this something you find useful? Since we don't have a final decision for this topic, we are looking for more input from you guys.Anybody is welcome to throw any kind of useful feedback on this matter, so don't be shy! IIRC this is not standard, and Apple uses it somewhere on their FaceTime implementation. Kamailio has it and someone was working on a patch for PJSIP, but other than that I’m not sure how useful it is, servers could use TCP between them. It is not indeed, but the main idea is to first help you with better handling traffic inside your network (which may be up to 3 or 4 OpenSIPS boxes when you have a distributed platform) ; handling means bandwidth and processing as parsing SIP messages - like headers (maybe 20) or body you do not care about and you just want to carry through without a need to parse and look. And maybe in the future it will be some progress into standardizationfor now I see the real need for it (at least for me:) ). Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing listUsers@lists.opensips.orghttp://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-Devel] [RELEASE] OpenSIPS 1.11 beta major release is out
This is an exciting release! The new memory allocator looks really interesting. Are there any numbers showing how its performance compares to the current? Great work! ~Ryan Bullock On Thu, Mar 20, 2014 at 1:29 PM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: Hello everyone! The OpenSIPS Project is proud to announce the release of OpenSIPS version 1.11 (beta)! We would like to thank the OpenSIPS community for all of their hard and diligent work in making this release possible. We could never have done it without you! Special thanks go out to Ovidiu Sas, Walter Doekes, Damien Sandrs, Nick Altmann, Brett Nemeroff, Ryan Bullock (and many others) for your amazing contribution on this release. We truly appreciate you! Building on our industry ready platform, we're excited to introduce many new features and updates. But also we've continued to make inroads in developing an easier to use OpenSIPS. Version 1.11 brings with it enhancements to the core, script handling, and many important modules. The OpenSIPS core has received a new memory allocator to increase performance. It's tunable and provides fine-grained locking! We've also heard your requests on improving scripting capabilities. Say hello to the SCRIPT_HELPER module and to the for-each statement! The learning curve will not be so steep again! We've also introduced 4 new modules in this release... - B2B_SCA module providing new shared call appearance features - CALL_CENTER module that introduces call queue features - MI_JSON module to encode data in JSON format over HTTP for the MI Interface commands - SCRIPT_HELPER module to simplify the script/configuration for beginners In all, too many features to list. However you can view them all by visiting the version page at: http://www.opensips.org/About/Version-1-11-0 Again, we are excited about all the new changes version 1.11 delivers. We continue to appreciate all the feedback and help from the community. We still have many things to be done to get to the stable release (in ~1 month), like improving the documentation, keep working on fixing bugs, excessive testing and others. We're always listening to your requests, so never be shy in making one! Many thanks, The OpenSIPS Project Team -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Devel mailing list de...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.11.0 major release
List looks good. I think the B2B could use some work for its DB interaction. Similar to what was done for the dialog module (separate timer process, bulk deletes, etc). We notice that a B2B instance running a similar load as a proxy w/ dialogs hits the DB quite a bit harder. Regards, Ryan On Mon, Nov 4, 2013 at 10:09 AM, Saúl Ibarra Corretgé s...@ag-projects.comwrote: Hi Bogdan, Can we have async TLS added to the list? Nice list for Santa, btw :-P On Nov 4, 2013, at 6:58 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will list here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/About/Version-1-11-0#toc2 What is planned: http://www.opensips.org/About/Version-1-11-0#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.12 ?) Additional thinks (not listed on web) we are considering are: - new call queuing module - new SMPP module - async operations at script level (doing async db ops, exec, rest queries) - dropping avpops module (and replacing with dbops module) - simplify scripting/logic by dropping the usage of AVPs (defined as module params) in favor of explicit func. params - better handling of UAC transactions (being able to set failure routes for them, to fire new requests from script) - Quality routing in Dynamic Routing Also we target so work in the RTPProxy area (still under heavy planing) like restart persistence, replication and statistics . Planing --- Release candidate: second half of January 2014, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Devel mailing list de...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list de...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] [NEW] Dialog replication using a new core interface
This is pretty exciting! What are the plans for how this will work with features such as dialog pinging and accounting? Regards, Ryan On Mon, Jul 29, 2013 at 9:46 AM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: ** In long term we plan to use the BIN interface to replicate even more internal data between multiple OpenSIPS instances, like doing registration replication (instead of doing it from script via SIP). Theoretically it may be used for replicating even transaction state between 2 OpenSIPS instances - imagine having a call ringing on instance A and being accepted on instance B (after a failover) - 0% losses ! Aside realtime data replication, the BIN interface is to be used also for exchanging any other type of information between OpenSIPS instances, like federating multiple instances. The main advantages of the BIN interface over the MI interface : - BIN is binary encoded so much faster (as performance) - BIN interface has both sender and receiver in OpenSIPS (MI has only the receiver) - MI is for external usage, while BIN is internal (opensips2opensips) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com On 07/29/2013 06:22 PM, Liviu Chircu wrote: Hello all, OpenSIPS just got better with a *new core interface* and a *new failover mechanism*! The purpose of the new *Binary Internal Interface *is to offer a fast and efficient communication channel between OpenSIPS instances. OpenSIPS modules can now use this core interface to send/receive packets with specific information. A common usage case for this feature would be data replication between a primary instance and a backup one. This is especially useful in scenarios with OpenSIPS instances which handle large amounts of concurrent calls, so that failover through a database backend is not feasible anymore due to the significant time required in order to load the needed tables. As an example of using the interface, the dialog module now offers the possibility of *replicating dialogs* to another instance. The script writer may now configure a set of proxies which will receive dialog-related events: *creation*, *confirmation* and *deletion*, all in *realtime*. These messages are compact and they are sent over UDP. The dialog module now also exports several new statistics which show the total sent/received replication packets. Configuring UDP listeners for the new interface is trivial and explained in the OpenSIPS manuals [1]. [1]: http://www.opensips.org/Documentation/Interface-Binary Best regards, -- Liviu Chircu OpenSIPS Developerhttp://www.opensips-solutions.com ___ Users mailing listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list de...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RFC] New Release Policy for OpenSIPS project
On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: ** Hi Ali, Thanks for feedback - regarding the support for previous releases, Saul raised the same point as you, and I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year. So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com What about adding a long term support branch that is released every two years and supported for 2 years, and then a release every 6 months for 'standard' releases. Each standard release would be supported for 1 year. Something like this, assuming 1.10 is the first long term support: 1.10 - Long term support (2 years) 1.11 - Standard release (1 year) 1.12 - Standard release (1 year) 1.13 - Standard release (1 year) 1.14 - Long term support (2 years) Those wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases. It should strike a decent balance between getting features out the door and support. Just a thought. Regards, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Acc - Can't get db_extra_bye to work
I need these values to survive an opensips restart (we have dialog
persistence to db for failover), so that rules out the cachedb_local.
How slow is get_dialog_info() (I am going to guess it depends on the
number of active dialogs)? Would a call to cachedb_memcached still be
faster?
Regards,
Ryan
On Fri, May 4, 2012 at 4:33 AM, Vlad Paiu vladp...@opensips.org wrote:
Hello Ryan,
In your case, as a temporary solution, you'd better use cachedb_local , as
it would be much faster compared to get_dialog_info().
Regards
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com
On 05/03/2012 07:57 PM, Ryan Bullock wrote:
Thanks for the info Razvan.
Looks like I may be able to use get_dialog_info() as well to get what
I need before calling loose_route.
On Wed, May 2, 2012 at 3:58 AM, Razvan Crainearaz...@opensips.org
wrote:
Hi, Ryan!
Unfortunately calling loose_route twice won't do the trick. You'll
somehow
have to make sure that all AVPs are populated before calling loose_route
the
first time. My suggestion is to use CacheDB to keep info between INVITE
and
BYE and fetch the info before loose_route.
Regards,
--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com
On 05/01/2012 07:33 PM, Ryan Bullock wrote:
Thanks for the response.
I have not tried setting them before loose_route(). I guess my example
is bad, because I need to access some dialog values before I can set
the acc variables, and my understanding is that I cannot access dlg
variables until I call loose_route (or match_dialog).
Is their a way to do both? Would it hurt to call loose_route() twice?
Regards,
Ryan
On Tue, May 1, 2012 at 1:14 AM, Razvan Crainearaz...@opensips.org
wrote:
Hi, Ryan!
Have you tried to set the avp values before 'loose_route' call?
Regards,
--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com
On 04/28/2012 06:28 PM, Ryan Bullock wrote:
Without any success I have been trying to get some values accounted
using the 'db_extra_bye' parameter of the acc module. However,
opensips still appears to always account the values as if they were
taken from the original INVITE transaction and not the BYE.
I have cdr accounting enabled, as well as several db_extra values.
When a BYE is received I update a few avp variables. When I xlog these
variables I can see that they are properly set, however opensips
inserts empty values into the database. If I set these variables to
something in the original INVITE, then that value will be accounted
instead, but still not the updated value from the BYE.
Has anyone been able to get this to work? Am I missing something
obvious?
Example Config:
modparam(acc, db_extra_bye, call_val=$avp(call_val);
bye_val=$avp(bye_val))
.
..
if (loose_route()) {
if (is_method(BYE))
$avp(call_val) = set;
$avp(bye_val) = set;
}
}
Thanks.
Regards,
Ryan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
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] Acc - Can't get db_extra_bye to work
Thanks for the info Razvan.
Looks like I may be able to use get_dialog_info() as well to get what
I need before calling loose_route.
On Wed, May 2, 2012 at 3:58 AM, Razvan Crainea raz...@opensips.org wrote:
Hi, Ryan!
Unfortunately calling loose_route twice won't do the trick. You'll somehow
have to make sure that all AVPs are populated before calling loose_route the
first time. My suggestion is to use CacheDB to keep info between INVITE and
BYE and fetch the info before loose_route.
Regards,
--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com
On 05/01/2012 07:33 PM, Ryan Bullock wrote:
Thanks for the response.
I have not tried setting them before loose_route(). I guess my example
is bad, because I need to access some dialog values before I can set
the acc variables, and my understanding is that I cannot access dlg
variables until I call loose_route (or match_dialog).
Is their a way to do both? Would it hurt to call loose_route() twice?
Regards,
Ryan
On Tue, May 1, 2012 at 1:14 AM, Razvan Crainearaz...@opensips.org
wrote:
Hi, Ryan!
Have you tried to set the avp values before 'loose_route' call?
Regards,
--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com
On 04/28/2012 06:28 PM, Ryan Bullock wrote:
Without any success I have been trying to get some values accounted
using the 'db_extra_bye' parameter of the acc module. However,
opensips still appears to always account the values as if they were
taken from the original INVITE transaction and not the BYE.
I have cdr accounting enabled, as well as several db_extra values.
When a BYE is received I update a few avp variables. When I xlog these
variables I can see that they are properly set, however opensips
inserts empty values into the database. If I set these variables to
something in the original INVITE, then that value will be accounted
instead, but still not the updated value from the BYE.
Has anyone been able to get this to work? Am I missing something
obvious?
Example Config:
modparam(acc, db_extra_bye, call_val=$avp(call_val);
bye_val=$avp(bye_val))
.
..
if (loose_route()) {
if (is_method(BYE))
$avp(call_val) = set;
$avp(bye_val) = set;
}
}
Thanks.
Regards,
Ryan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Acc - Can't get db_extra_bye to work
Thanks for the response.
I have not tried setting them before loose_route(). I guess my example
is bad, because I need to access some dialog values before I can set
the acc variables, and my understanding is that I cannot access dlg
variables until I call loose_route (or match_dialog).
Is their a way to do both? Would it hurt to call loose_route() twice?
Regards,
Ryan
On Tue, May 1, 2012 at 1:14 AM, Razvan Crainea raz...@opensips.org wrote:
Hi, Ryan!
Have you tried to set the avp values before 'loose_route' call?
Regards,
--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com
On 04/28/2012 06:28 PM, Ryan Bullock wrote:
Without any success I have been trying to get some values accounted
using the 'db_extra_bye' parameter of the acc module. However,
opensips still appears to always account the values as if they were
taken from the original INVITE transaction and not the BYE.
I have cdr accounting enabled, as well as several db_extra values.
When a BYE is received I update a few avp variables. When I xlog these
variables I can see that they are properly set, however opensips
inserts empty values into the database. If I set these variables to
something in the original INVITE, then that value will be accounted
instead, but still not the updated value from the BYE.
Has anyone been able to get this to work? Am I missing something obvious?
Example Config:
modparam(acc, db_extra_bye, call_val=$avp(call_val);
bye_val=$avp(bye_val))
.
..
if (loose_route()) {
if (is_method(BYE))
$avp(call_val) = set;
$avp(bye_val) = set;
}
}
Thanks.
Regards,
Ryan
___
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
[OpenSIPS-Users] Acc - Can't get db_extra_bye to work
Without any success I have been trying to get some values accounted
using the 'db_extra_bye' parameter of the acc module. However,
opensips still appears to always account the values as if they were
taken from the original INVITE transaction and not the BYE.
I have cdr accounting enabled, as well as several db_extra values.
When a BYE is received I update a few avp variables. When I xlog these
variables I can see that they are properly set, however opensips
inserts empty values into the database. If I set these variables to
something in the original INVITE, then that value will be accounted
instead, but still not the updated value from the BYE.
Has anyone been able to get this to work? Am I missing something obvious?
Example Config:
modparam(acc, db_extra_bye, call_val=$avp(call_val);
bye_val=$avp(bye_val))
.
..
if (loose_route()) {
if (is_method(BYE))
$avp(call_val) = set;
$avp(bye_val) = set;
}
}
Thanks.
Regards,
Ryan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Reply Reason in failure route
Is there anyway to get the reply reason (e.g Service Unavailable) of the current reply in failure_route? $T_reply_code gets me the code, but I would like to log/check the reason for some specific responses we get. $rr does not seem to get populated for the failure route either. Thanks. Regards, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Reply Reason in failure route
Wow, how many times have I missed that line in the docs. Thank you very much, that was exactly what I needed. Regards, Ryan On Mon, Mar 5, 2012 at 3:20 PM, Vlad Paiu vladp...@opensips.org wrote: Hello, The reason for this is that, in the failure_route, you are working with the failed Request, and not with the reply. Please go to [1], and check the context part of a pseudovariable. In short, to access the reply code from within failure route, try $(replyrr) [1] http://www.opensips.org/Resources/DocsCoreVar Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com Pe 3/6/2012 1:13 AM, Ryan Bullock a scris: Is there anyway to get the reply reason (e.g Service Unavailable) of the current reply in failure_route? $T_reply_code gets me the code, but I would like to log/check the reason for some specific responses we get. $rr does not seem to get populated for the failure route either. Thanks. Regards, Ryan ___ 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
[OpenSIPS-Users] Distributed Dialog and CacheDB Persistence
Does the new distributed dialog with cached also allow for dialogs to persist through a restart of opensips? Or would that still require a database backend? Maybe a better question what actually gets distributed with the dialog (e.g. dialog flags, dialog variables, etc)? The new distributed system is very exciting. Can't wait to start building with it. Regards, Ryan Bullock ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] check_source_address not working with upgrade
I will chime into say that I ran into the same issue when attempting
to upgrade to the latest trunk. I just have not had time to open a bug
and get a test setup to do in-depth trouble shooting.
On Thu, Feb 2, 2012 at 8:38 AM, duane.lar...@gmail.com wrote:
I just upgraded my b2bua opensips server to the latest trunk version and now
my if statements using check_source_address from the permissions module
isn't working. I have the following set up
loadmodule permissions.so
modparam(permissions,db_url,mysql://adfasdf:dfasdf...@108.xxx.xxx.xxx/opensips)
if (check_source_address(2) || check_source_address(3) ||
check_source_address(4)) {
The INVITE comes from my SIP Proxy and worked before the upgrade without
issue
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:check_src_addr_3: Looking for : 2, 173.XXX.XXX.XXX, 5060,
1 in tables
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:hash_match: specified group does not exist in hash table
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:match_subnet_table: subnet table is empty
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:check_src_addr_3: Looking for : 3, 173.XXX.XXX.XXX, 5060,
1 in tables
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:hash_match: specified group does not exist in hash table
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:match_subnet_table: subnet table is empty
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:check_src_addr_3: Looking for : 4, 173.XXX.XXX.XXX, 5060,
1 in tables
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:hash_match: specified group does not exist in hash table
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
DBG:permissions:match_subnet_table: subnet table is empty
This is what I have in the database
Proxy01:/var/log# opensipsctl db show address
+-+-++--+--+---+-+--+
| id | grp | ip | mask | port | proto | pattern | context_info |
+-+-++--+--+---+-+--+
| 3 | 2 | 216.XXX.XXX.202 | 32 | 5060 | any | NULL | NULL |
| 258 | 4 | 64.XXX.XXX.15 | 32 | 5060 | any | NULL | NULL |
| 1 | 10 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL |
| 2 | 10 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL |
| 257 | 3 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL |
| 4 | 2 | 216.XXX.XXX.202 | 32 | 5060 | any | NULL | NULL |
+-+-++--+--+---+-+--+
I am not sure if OpenSIPS is really querying the mysql database because I
don't really see any connections from the server when a call is made. How
could this be possible? When I start OpenSIPS I see that it talks to the
database.
___
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] B2B with multiple IPs
We use an opensips B2BUA for topology hiding facing our carriers, and have a proxy that sits behind it and does our call routing/hunting through it. Some of our carriers require that we send from a different source IP to separate certain traffic. My thought is to have the B2BUA listen on two IPs and then have the proxy send to which ever IP we want to be seen facing the carrier. My question is, if I have IP1 and IP2 on the B2B and I send a call to IP2, will the B2B use IP2 for the outgoing leg as well? I want to avoid have a scenario where I send a call to IP2 and it sources the out going leg from IP1, and vice-versa. Will this work or should I be trying to use force_send_socket() on the B2B? Are there any gotchas I should be looking out for? Thanks. Regards, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips with Heartbeat
Opensips is trying to do a reverse dns on the IP address. You can try adding a reverse dns record for that ip or try disabling the dns and/or auto_aliases options. On Thu, Dec 15, 2011 at 2:52 PM, Schneur Rosenberg rosenberg11...@gmail.com wrote: I'm using opensips on a computer with 2 ip addresses one steady one and one is a floating ip address provided by heartbeat, when heartbeat is on and I have 2 ip addresses opensips takes a very long time to start and I get a error in the messages file, the error is opensips: WARNING:core:fix_socket_list: could not rev. resolve 64.69.47.245 where 64.69.47.245 is the floating ip when I remove the floating ip address everything works smooth. thanks in advance S. Rosenberg ___ 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] B2BUA Ripping/Truncating Callid
I think this is related to a bug that is already open:
http://sourceforge.net/tracker/?func=detailaid=3316230group_id=232389atid=1086410
On Fri, Dec 9, 2011 at 5:46 PM, Ovidiu Sas o...@voipembedded.com wrote:
Yeah, it's the first request after the modified INVITE that is
malformed (I reproduced this running a snapshot from trunk). Please
open a bug report.
Regards,
Ovidiu Sas
--
VoIP Embedded, Inc.
http://www.voipembedded.com
On Fri, Dec 9, 2011 at 1:52 PM, Logan voipmas...@me.com wrote:
I added the log and everything looks fine. It's only adding the PAI to the
initial invite which is what I want. The odd thing is there are no issues
with the invites, it just looks like the Cancel messages that are being
mangled. I posted a separate issue to the list prior to this report but no
one responded, I'm not sure it went through correctly but resulting cancel
coming out of the B2BUA looked like this:
Reference:
192.168.1.146 = Opensips Proxy
192.168.1.145 = Opensips B2BUA
10.2.3.245 = Carrier
U 2011/12/01 22:51:11.558887 192.168.1.146:5060 - 192.168.1.145:5090
CANCEL sip:9993512125551212@192.168.1.145:5090 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.146;branch=z9hG4bK2df7.78db1d81.0.
From: James Logan sip:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212 sip:12125551212@192.168.1.146.
CSeq: 102 CANCEL.
Max-Forwards: 70.
User-Agent: Opensips.
Content-Length: 0.
.
U 2011/12/01 22:51:11.559378 192.168.1.145:5090 - 192.168.1.146:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP 192.168.1.146;branch=z9hG4bK2df7.78db1d81.0.
From: James Logan sip:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212
sip:12125551212@192.168.1.146;tag=3330ae74b9cf9aed85afbc9203dd6238-715f
CSeq: 102 CANCEL.
Server: B2BUA.
Content-Length: 0.
.
U 2011/12/01 22:51:11.559527 192.168.1.145:5090 - 10.2.3.245:5060
CANCEL i...i.. SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK5421.22999dd2.0.
B2B.256.3572553sip:+12125551212@10.2.3.245sip:888444@192.168.1.1379120d3`.p..i...q.i
CANCEL.
User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)).
Max-Forwards: 70.
User-Agent: Opensips.
Init-CallID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
Contact: sip:192.168.1.145:5090.
.
On Dec 07, 2011, at 05:18 PM, Ovidiu Sas o...@voipembedded.com wrote:
Add a log and print out what are you adding before adding it and you
will see if it's good or not.
On Wed, Dec 7, 2011 at 5:13 PM, Logan voipmas...@me.com wrote:
This is the extent of my local route. If the $var is not present, I do not
add it. Do you see any issue with what I'm doing here?
local_route {
#xlog(L_INFO,* IN LOCAL ROUTE \n);
if (is_method(INVITE)) {
if($var(pai_userpart)) {
append_hf(P-Asserted-Identity:
\$var(pai_display)\ sip:$var(pai_userpart)@$Ri\r\n);
}else{
xlog(L_INFO,PAI is not present, not adding\n);
}
}
}
On Dec 07, 2011, at 04:57 PM, Ovidiu Sas o...@voipembedded.com wrote:
You need to be careful when you alter requests in B2B mode (the
received INVITE and the sent INVITE belong to different transactions).
Make sure that you have something valid in those vars before applying
any changes to the outgoing message.
Regards,
Ovidiu Sas
On Wed, Dec 7, 2011 at 4:49 PM, Logan voipmas...@me.com wrote:
I'm storing some $vars in route[0] prior to calling b2b_init_request(top
hiding);
Then in my local route Im appending a P-Asserted-Identity header.
I can't use the custom_headers modparam because it's going to preserve
the
PAI as it comes in. Most of the time it's not present, or is in the wrong
format so I'm adding it in local route.
On Dec 07, 2011, at 04:31 PM, Ovidiu Sas o...@voipembedded.com wrote:
Are you trying to perform any msg manipulations during b2b scenarios?
Also, keep in mind that the b2b server functionality must be kept
isolated from the proxy server functionality (proxy mode is not
compatible with b2b mode).
Regards,
Ovidiu Sas
-- VoIP Embedded, Inc.http://www.voipembedded.com
On Wed, Dec 7, 2011 at 3:41 PM, Logan voipmas...@me.com wrote:
Hello list this is the second odd thing I've seen with b2bua in opensips
1.7.1 It looks like the b2bua module is mangling the cancel message and
is
ripping out the callid when sending upstream:
U 2011/12/07 20:15:05.895915 192.168.1.143:5060 - 192.168.1.145:5090
CANCEL sip:9993518045551212@192.168.1.145:5090 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.143;branch=z9hG4bKac0e.5a3d2bf1.0.
From: 8669800222 sip:8669800222@192.168.1.1;tag=3532277698-944952.
Call-ID: 494823-3532277698-944947@192.168.1.1.
To: 18045551212 sip:18045551212@192.168.1.143.
CSeq: 1 CANCEL.
Re: [OpenSIPS-Users] cdr accounting on opensips restart
Awesome information. Dialogs seem to persist over a restart, however I am not sure if they are accounting. I will do a switch back to the defaults, better safe than sorry. Thanks, Ryan 2011/12/8 Razvan Crainea razvancrai...@opensips.org: Hi, Ryan! Unfortunately it won't work. The problem is that the mysql library detects both VARCHAR and VARBINARY as string types. Only BLOB and TEXT are mapped as binary objects. You can find more information here[1]. As far as I know, only the CDR accounting can generate binary data in dialog variables, so if you don't use this feature you can leave it as it is for now. But if you find any problems related to dialog persistence over restart I strongly advise you to change your columns type to the default ones. [1] http://dev.mysql.com/doc/refman/5.0/en/c-api-data-structures.html Regards, -- Răzvan Crainea OpenSIPS Developer On 12/07/2011 08:40 PM, Ryan Bullock wrote: Could a VARBINARY be used here instead? We actually use a memory table for the dialog table to reduce load on our disk and it does not support BLOB or TEXT, so instead we changed it to a large VARCHAR. The mysql docs suggest you can treat a TEXT the same as a VARCHAR, but obviously there are differences. Regards, Ryan On Wed, Dec 7, 2011 at 9:51 AM, Jayesh Nambiar jayesh.v...@gmail.com wrote: Hi Razvan, This actually solved the problem. Thank you very much. It was defined as VARCHAR instead of TEXT. Thank you very much for all the efforts. Really appreciate it. Need to get hold of my DB guy for the stupid mistake !! --- Jayesh On Wed, Dec 7, 2011 at 8:13 PM, Razvan Crainea razvancrai...@opensips.org wrote: Hi, Jayesh! Can you check in your mysql database if the vars column from the dialog table is declared as TEXT or BLOB and not CHAR? If not, please change your column into BLOB: ALTER TABLE dialog CHANGE vars vars BLOB; Regards, -- Răzvan Crainea OpenSIPS Developer On 12/07/2011 02:27 PM, Jayesh Nambiar wrote: Hi Razwan, This is the pastebin of logs after shutdown: http://pastebin.com/tvmrSqwB This is the pastebin of logs after start which is huge: http://pastebin.com/C6K4Jt5y --- Jayesh ___ 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] cdr accounting on opensips restart
Could a VARBINARY be used here instead? We actually use a memory table for the dialog table to reduce load on our disk and it does not support BLOB or TEXT, so instead we changed it to a large VARCHAR. The mysql docs suggest you can treat a TEXT the same as a VARCHAR, but obviously there are differences. Regards, Ryan On Wed, Dec 7, 2011 at 9:51 AM, Jayesh Nambiar jayesh.v...@gmail.com wrote: Hi Razvan, This actually solved the problem. Thank you very much. It was defined as VARCHAR instead of TEXT. Thank you very much for all the efforts. Really appreciate it. Need to get hold of my DB guy for the stupid mistake !! --- Jayesh On Wed, Dec 7, 2011 at 8:13 PM, Razvan Crainea razvancrai...@opensips.org wrote: Hi, Jayesh! Can you check in your mysql database if the vars column from the dialog table is declared as TEXT or BLOB and not CHAR? If not, please change your column into BLOB: ALTER TABLE dialog CHANGE vars vars BLOB; Regards, -- Răzvan Crainea OpenSIPS Developer On 12/07/2011 02:27 PM, Jayesh Nambiar wrote: Hi Razwan, This is the pastebin of logs after shutdown: http://pastebin.com/tvmrSqwB This is the pastebin of logs after start which is huge: http://pastebin.com/C6K4Jt5y --- Jayesh ___ 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] Accounting script rejected calls
I am using accounting opensips with cdr accounting and the failed_transaction_flag set. I was wondering if anyone knows a way to get calls that we reject from within our script (e.g. send_reply(503), etc) to be accounted into missed_calls? These don't currently seem to be recorded anywhere and we would like to keep them for statistical reasons. Regards, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] B2B Not routing 200 OK for BYE
I am use the B2B modules with the topology hiding scenario and periodically see the following error in my opensips log: ERROR:b2b_entities:b2b_tm_cback: No dialog found reply 200 for method BYE I did a capture to find out what was happening and it appears that after receiving a BYE opensips will correctly forward the BYE but not the subsequent 200 OK to the BYE (and I get the error message above). This causes the side that sent the BYE to retransmit and I can then see these retransmits in the main opensips route. Currently I have the main route sending a 200 OK for any BYE with a totag to catch these retransmits. I have also seen a few occurrence where if a 200 OK for an INVITE happens right before a BYE from the other side that the ACK for the 200 OK will also not be correctly routed using the B2B. It seems like the B2B is tearing down the session a bit to quickly, is there any way to adjust how long a B2B session will linger? Regards, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Dealing with a invalid uri in Contact
I am inter-oping with a device to do lookups on calls. This works by sending the device a sip invite and it then sends back a 302 redirect with the result as a user parameter in the contact uri. The problem I am having is that the device does not include a domain in the contact uri and opensips fails to parse it. An example of a uri: Contact: sip:+155;param=example@;user=phone In the failure route I attempt to call get_redirects to create new branchs and then attempt to extract the parameters from the user portion in the new branch. However because of the missing domain opensips reports that it cannot parse the contact header and no $ru is present in the created branch. $ct is also populated with the contact header of the original invite. Is there any way for me to access the contact header from the 302 directly in the failure route? Or some way to get access to it in the new branch? Unfortunately there seems to be no way to modify the results that are returned to us to include a proper contact uri. Thanks, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
