Re: [OpenSIPS-Devel] Unable to start opensips 2.1.1dev in UDP only mode
Hi Ovidiu, Just do a "loadmodule proto_udp.so" after setting the mpath. This is a temporary workaround and will be taken care of before the release. Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 02.03.2015 20:10, Ovidiu Sas wrote: Opensips cannot start in UDP only mode. Tested with the sample config, with "disable_tcp=yes" and "disable_tls=yes" commented out. ERROR:core:fix_all_socket_lists: listeners found for protocol udp, but no module can handle it ERROR:core:main: failed to initialize list addresses If I use only TCP, it works fine. -ovidiu ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Unable to start opensips 2.1.1dev in UDP only mode
Opensips cannot start in UDP only mode. Tested with the sample config, with "disable_tcp=yes" and "disable_tls=yes" commented out. ERROR:core:fix_all_socket_lists: listeners found for protocol udp, but no module can handle it ERROR:core:main: failed to initialize list addresses If I use only TCP, it works fine. -ovidiu -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [OpenSIPS/opensips] 31c472: opensipsdbctl: Fix DB creation in dev mode
Branch: refs/heads/master Home: https://github.com/OpenSIPS/opensips Commit: 31c472c88067dd67b10304dbbc050c7f2272d3b4 https://github.com/OpenSIPS/opensips/commit/31c472c88067dd67b10304dbbc050c7f2272d3b4 Author: Liviu Chircu Date: 2015-03-02 (Mon, 02 Mar 2015) Changed paths: M scripts/opensipsdbctl M scripts/opensipsdbctl.mysql Log Message: --- opensipsdbctl: Fix DB creation in dev mode * scripts/opensipsdbctl ... now works ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [OpenSIPS/opensips] 7fefe5: opensipsctl: Fix TLS certificate generation in dev...
Branch: refs/heads/master Home: https://github.com/OpenSIPS/opensips Commit: 7fefe50be5696dc740405a67edf868fd3546744a https://github.com/OpenSIPS/opensips/commit/7fefe50be5696dc740405a67edf868fd3546744a Author: Liviu Chircu Date: 2015-03-02 (Mon, 02 Mar 2015) Changed paths: M scripts/opensipsctl M scripts/opensipsctlrc Log Message: --- opensipsctl: Fix TLS certificate generation in dev mode * you can now run scripts/opensipsctl tls ... * no need to specify ETCDIR * do not throw error when giving no command * add template for explicit ETCDIR in opensipsctlrc Fixes #369 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] opensipsctl: cannot generate TLS certificates from sources (#369)
Closed #369 via 7fefe50be5696dc740405a67edf868fd3546744a. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/369#event-244457662___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
A follow up on this issue: If you set up the tcp and sips srv records but **not** the udp one, opensips will reply `SIP/2.0 476 Unresolvable destination (476/TM).` and give up. It does not cascade down to tcp and sips at all. Tested with a simple INVITE and t_relay(). For what its worth: using t_relay(tcp:somedomain:5060) works as intended and uses tcp without the transport header. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-76726438___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS leaks version (#417)
That is simply due to the *Server:* header from the OPTIONS reply. You can control the degree of information that is returned by your OpenSIPS in the scan replies on two levels: * No information at all (just turn off the [server_signature](http://www.opensips.org/Documentation/Script-CoreParameters-2-1#toc80) global parameter) * Some information, but not any specific version (specify the content using the [server_header](http://www.opensips.org/Documentation/Script-CoreParameters-2-1#toc79) global parameter) --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/417#issuecomment-76708930___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
Hi. I am pondering if Opensips might be enforcing some stuff that makes RFC compliancy a bit inconsistent. The problem is that the major video platform Cisco VCS does not by default consider an URI with and without transport=tcp the same. At first I figured that had to be RFC breaking, but the RFC actually states in RFC3261 19.1.4: ``` A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components. ``` As far as I can see, there is nothing in any of the RFCs that it is *disallowed* to send a tcp request *without* the transport=tcp header. Meaning that the Cisco VCS that uses TCP first and foremost will send an INVITE on tcp without the transport header, but anything going via an Opensips-instance will have transport=tcp added onto it. This makes the two systems very hard to keep in step. I figured that instead of having a philosophical debate on whether or not this and that is RFC compliant, if we could for opensips 2.1 have either a config that makes tcp (without the transport header) the first class citizen or a method similar to kamalios to_tcp() (which is implementation wise *not* what we want, since what it does is just to tack on transport=tcp) that makes opensips use the tcp srv record instead of the udp one. We would still like to keep a sort of cascading behavior so that for example we can prefer that (with no NAPTR records) it first tries TLS, then TCP and then UDP srv records. I know that if you have the right priorizations in the NAPTR records, opensips will go tcp before udp, but as an operator with a diverse client base we have no way of ensuring that our clients have NAPTR capable dns providers (not even Amazon Route53 currently supports NAPTR). Not to mention that NAPTR use is almost non-existent 'out in the wild' of external platforms our users will call that we have no control over at all. In general, this change of behavior would also encompass the changes in RFC5630 that has deprecated the use of transport=tls header (since tls should be transport-independant between sctp and tcp) if a to_tls() method was exposed. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] OpenSIPS leaks version (#417)
@bogdan-iancu For example when a scan is made by a tool like nmap, the openSIPS version is displayed. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/417#issuecomment-76681345___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] Problems when receiving binary content using SCTP (#419)
If sctp_server_rcv_loop() in sctp_server.c receives a 0-terminated packet it removes the 0. This causes problems with binary content when it ends with a 0. Enabling NO_ZERO_CHECKS would fix this issue but would also change the behaviour of bin_receive_loop() in bin_interface.c which also uses the define. I believe removing the section in sctp_server_rcv_loop() is the right move. If your interested, I've uploaded a patch at: https://gist.github.com/jamesabravo/c0e88a4af34c091c7b57 --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/419___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
