21 Feb
2019
21 Feb
'19
5:39 p.m.
Current kamailio package (checked via RPM) is contains lot of modules. Some
of this is not important to include in every kamailio installation. May be
create own packages for this modules and other in next 5.3 branch?
Modules examples:
benchmark.so
db_cluster.so
db_text.so
rtpengine.so
rtpproxy.so
sipcapture.so
siptrace.so
sipt.so
sms.so
smsops.so
ss7ops.so
https://github.com/kamailio/kamailio/issues/1862
21 Feb
21 Feb
8:31 p.m.
Hello,
On 21.02.19 07:39, Sergey Safarov wrote:
Current kamailio package (checked via RPM) is contains
lot of modules.
Some of this is not important to include in every kamailio
installation. May be create own packages for this modules and other in
next 5.3 branch?
Modules examples:
benchmark.so
db_cluster.so
db_text.so
rtpengine.so
rtpproxy.so
sipcapture.so
siptrace.so
sipt.so
sms.so
smsops.so
ss7ops.so
https://github.com/kamailio/kamailio/issues/1862
use of such modules is a matter of deployment type and for example, for
residential services, rtpengine or rtpproxy are like a must. I also use
often benchmark module to track execution of some operations (like http
queries). Also, siptrace is rather common in what I deal with.
IMO, it is hard to make a selection on usage or personal preferences.
The rule was that was has same dependencies as core, they should be
packaged together.
Actually there was a discussion to add more to the main package, from
those with additional dependencies, but very used (like tls, ...) -- it
might be on issue tracker as well.
Then, Victor Seva mentioned at some point in time that in debian is
better to keep modules groupped as many as possible, because introducing
a new package in the official distro requires a complex process of
review for license, etc...
Overall, if there is a decision to regroup some modules in different
packages, I would like to follow the same for both debs and rpms,
otherwise installation guidelines can end up to be different and can
become confusing.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC,
USA -- www.asipto.com
8:44 p.m.
Thanks Daniel for response
Sure packaging rules must be same for all dists.
Could you make same comment at
https://github.com/kamailio/kamailio/issues/1862
This will allow track this request
чт, 21 февр. 2019 г. в 12:31, Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
On 21.02.19 07:39, Sergey Safarov wrote:
Current kamailio package (checked via RPM) is contains lot of modules.
Some of this is not important to include in every kamailio installation.
May be create own packages for this modules and other in next 5.3 branch?
Modules examples:
benchmark.so
db_cluster.so
db_text.so
rtpengine.so
rtpproxy.so
sipcapture.so
siptrace.so
sipt.so
sms.so
smsops.so
ss7ops.so
https://github.com/kamailio/kamailio/issues/1862
use of such modules is a matter of deployment type and for example, for
residential services, rtpengine or rtpproxy are like a must. I also use
often benchmark module to track execution of some operations (like http
queries). Also, siptrace is rather common in what I deal with.
IMO, it is hard to make a selection on usage or personal preferences. The
rule was that was has same dependencies as core, they should be packaged
together.
Actually there was a discussion to add more to the main package, from
those with additional dependencies, but very used (like tls, ...) -- it
might be on issue tracker as well.
Then, Victor Seva mentioned at some point in time that in debian is better
to keep modules groupped as many as possible, because introducing a new
package in the official distro requires a complex process of review for
license, etc...
Overall, if there is a decision to regroup some modules in different
packages, I would like to follow the same for both debs and rpms, otherwise
installation guidelines can end up to be different and can become confusing.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC,
USA -- www.asipto.com
9:30 p.m.
I thought you want to get the feedback from users perspective. The
tracker is mainly for developers.
Once the discussion here is concluded or nothing happens with it for a
while, then someone can summarize what was suggested from users
perspective and put it on the tracker. I don't think duplicating
everything on the tracker makes sense, it is not a bug, but a feature
request.
As you started on both places, you should cross reference there, as you
pointed the link to issue tracker here.
In general is not good to have the discussion about same topic on
different places. Of course, we crosspost announcements and general
information messages, otherwise is better to focus on debating something
in a single place. I think this is a topic more for users than for
developers, to see if there is interest. Then the developers can decide
if it is feasible with the constraints we have from distros (as I
mentioned debian in the previous message).
Cheers,
Daniel
On 21.02.19 10:44, Sergey Safarov wrote:
Thanks Daniel for response
Sure packaging rules must be same for all dists.
Could you make same comment
at https://github.com/kamailio/kamailio/issues/1862
This will allow track this request
чт, 21 февр. 2019 г. в 12:31, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
On 21.02.19 07:39, Sergey Safarov wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC,
USA -- www.asipto.com
Current kamailio package (checked via RPM) is
contains lot of
modules. Some of this is not important to include in every
kamailio installation. May be create own packages for this
modules and other in next 5.3 branch?
Modules examples:
benchmark.so
db_cluster.so
db_text.so
rtpengine.so
rtpproxy.so
sipcapture.so
siptrace.so
sipt.so
sms.so
smsops.so
ss7ops.so
https://github.com/kamailio/kamailio/issues/1862
use of such modules is a matter of deployment type and for
example, for residential services, rtpengine or rtpproxy are like
a must. I also use often benchmark module to track execution of
some operations (like http queries). Also, siptrace is rather
common in what I deal with.
IMO, it is hard to make a selection on usage or personal
preferences. The rule was that was has same dependencies as core,
they should be packaged together.
Actually there was a discussion to add more to the main package,
from those with additional dependencies, but very used (like tls,
...) -- it might be on issue tracker as well.
Then, Victor Seva mentioned at some point in time that in debian
is better to keep modules groupped as many as possible, because
introducing a new package in the official distro requires a
complex process of review for license, etc...
Overall, if there is a decision to regroup some modules in
different packages, I would like to follow the same for both debs
and rpms, otherwise installation guidelines can end up to be
different and can become confusing.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
<http://www.kamailioworld.com>
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington,
DC, USA -- www.asipto.com <http://www.asipto.com>
22 Feb
22 Feb
4:30 a.m.
Hi,
for residential services the rtp* modules are a must have and for
homer/sipcapture is also very handy.
What's the issue with a few modules laying around? Diskspace?
Changing packaging had the potential to break upgrades imho.
Kind regards
Karsten Horsmann
Sergey Safarov <s.safarov(a)gmail.com> schrieb am Do., 21. Feb. 2019, 07:40:
Current kamailio package (checked via RPM) is contains
lot of modules.
Some of this is not important to include in every kamailio installation.
May be create own packages for this modules and other in next 5.3 branch?
Modules examples:
benchmark.so
db_cluster.so
db_text.so
rtpengine.so
rtpproxy.so
sipcapture.so
siptrace.so
sipt.so
sms.so
smsops.so
ss7ops.so
https://github.com/kamailio/kamailio/issues/1862
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:05 a.m.
I prefer organize packages when optional modules are packaged in their
packages.
This allows you to keep on the server only the necessary components. For
example, I use kamailio in the kazoo solution and now many installed
components on the server that are not needed.
To enable the installation of a group of packages, it is possible to use a
"virtual" package. For example kamailio-rtp-modules depend of
kamailio-rtpproxy and kamailio-rtpengine. When installed "virtual" package
then installed depend packages.
чт, 21 февр. 2019 г. в 20:31, Karsten Horsmann <khorsmann(a)gmail.com>om>:
Hi,
for residential services the rtp* modules are a must have and for
homer/sipcapture is also very handy.
What's the issue with a few modules laying around? Diskspace?
Changing packaging had the potential to break upgrades imho.
Kind regards
Karsten Horsmann
Sergey Safarov <s.safarov(a)gmail.com> schrieb am Do., 21. Feb. 2019, 07:40:
Current kamailio package (checked via RPM) is
contains lot of modules.
Some of this is not important to include in every kamailio installation.
May be create own packages for this modules and other in next 5.3 branch?
Modules examples:
benchmark.so
db_cluster.so
db_text.so
rtpengine.so
rtpproxy.so
sipcapture.so
siptrace.so
sipt.so
sms.so
smsops.so
ss7ops.so
https://github.com/kamailio/kamailio/issues/1862
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:53 p.m.
New subject: Parallel Forking
Hi Daniel
thank you for your reply.
The first code-example is supposed to be parallel forking (although it is located in the
serial-forking section):
As an example, consider the following simple
configuration file. When the server receives an INVITE, it creates four branches with
usernames A through D and then forwards the request using t_relay():
request_route {
seturi("sip:a@example.com");
append_branch("sip:b@example.com");
append_branch("sip:c@example.com");
append_branch("sip:d@example.com");
t_relay();
break;
}
With this configuration the server forwards the request to all four branches at once,
performing parallel forking as described above.
I would like to ring two (or more) phones of different people at once. As I understand so
far, this should be done with the append_branch command. Unfortunately I cannot find an
example of the append_branch command in the default-config-file.
Regards
Jan-Hendrik
2175
days inactive
2176
days old
6 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Jan-Hendrik Dörner -
Karsten Horsmann -
Sergey Safarov