9 Mar
2009
9 Mar
'09
3:58 p.m.
As of today, I still haven't managed to make the following kamailio
modules compile:
cpl-c, dialog, dispatcher, domain, domainpolicy, enum, msilo,
nathelper, nat_traveral, osp, path, perl, perlvdb, presence, pv, qos,
ratelimit, registrar, rls, rtimer, seas, sipitrace, sl, snmpstats,
sst, texops, uac, uac_redirect, usrloc, utils
This does not necessarily mean that the modules above are difficult to
update, but only that they require manual changes and I haven't had
the time to do them yet.
Some of the modules require changes in the sip-router core which are
underway.
If you would like to help update one of the modules above and make
them work on the sip-router core, then, please, let me know. I would
especially appreciate help with the following modules:
perl, perlvdb, pv, snmpstas
because I don't know much about them.
And if you don't have the time or knowledge necessary to convert
modules, we would still appreciate if you could review changes we did
so far. Here is how you can review module changes:
1) Through gitweb
Go to
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=heads
and click on a module that interests you. You'll be presented with the
history of the module. Commits on the top of the list are those that I
made to make the module work with the sip-router core. The oldest
commit in most modules which is related to the update to sip-router is:
"Define OPENSER_MOD_INTERFACE in Makefile."
All modules contain that one, so you only need to look at commits that
are newer than this one. There are some exceptions though, such as the
acc module, where the above mentioned commit is not the last one.
2) With git
Clone the repository using:
$ git clone git://git.sip-router.org/kamailio-3.0
Checkout the branch of the module you are interested in:
$ git co -b acc origin/acc
And examine the history of the module with git log:
$ git log -u
Jan.
9 Mar
9 Mar
9:38 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
Thanks Jan!
Very impressive effort. I am going to cover many modules left, and I am
starting with:
- PV (which is pretty much done for quite some time:
http://sip-router.org/pub/tmp/miconda/ - just the AVPs and a few other
bits have to be sorted out).
- dispatcher
- sl
- textops
I will send soon other updates.
Cheers,
Daniel
On 03/09/2009 03:58 PM, Jan Janak wrote:
As of today, I still haven't managed to make the
following kamailio
modules compile:
cpl-c, dialog, dispatcher, domain, domainpolicy, enum, msilo,
nathelper, nat_traveral, osp, path, perl, perlvdb, presence, pv, qos,
ratelimit, registrar, rls, rtimer, seas, sipitrace, sl, snmpstats,
sst, texops, uac, uac_redirect, usrloc, utils
This does not necessarily mean that the modules above are difficult to
update, but only that they require manual changes and I haven't had
the time to do them yet.
Some of the modules require changes in the sip-router core which are
underway.
If you would like to help update one of the modules above and make
them work on the sip-router core, then, please, let me know. I would
especially appreciate help with the following modules:
perl, perlvdb, pv, snmpstas
because I don't know much about them.
And if you don't have the time or knowledge necessary to convert
modules, we would still appreciate if you could review changes we did
so far. Here is how you can review module changes:
1) Through gitweb
Go to
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=heads
and click on a module that interests you. You'll be presented with the
history of the module. Commits on the top of the list are those that I
made to make the module work with the sip-router core. The oldest
commit in most modules which is related to the update to sip-router is:
"Define OPENSER_MOD_INTERFACE in Makefile."
All modules contain that one, so you only need to look at commits that
are newer than this one. There are some exceptions though, such as the
acc module, where the above mentioned commit is not the last one.
2) With git
Clone the repository using:
$ git clone git://git.sip-router.org/kamailio-3.0
Checkout the branch of the module you are interested in:
$ git co -b acc origin/acc
And examine the history of the module with git log:
$ git log -u
Jan.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com
10 Mar
10 Mar
6:34 a.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
The snmpstats branch should be updated with the latest updates for the
usrloc module. This will get rid of some db related compile issues.
Also, OPENSER_OID needs to be defined inside config.h:
$ git diff
diff --git a/config.h b/config.h
index a18def8..9e0e5e5 100644
--- a/config.h
+++ b/config.h
@@ -210,6 +210,8 @@
#define MIN_SCTP_PACKET MIN_UDP_PACKET
+#define OPENSER_OID 1,3,6,1,4,1,27483
+
#define DEFAULT_RADIUS_CONFIG "/usr/local/etc/radiusclient/radiusclient.conf"
#define DEFAULT_DID "_default"
Regards,
Ovidiu Sas
On Mon, Mar 9, 2009 at 9:58 AM, Jan Janak <jan(a)iptel.org> wrote:
As of today, I still haven't managed to make the
following kamailio
modules compile:
cpl-c, dialog, dispatcher, domain, domainpolicy, enum, msilo,
nathelper, nat_traveral, osp, path, perl, perlvdb, presence, pv, qos,
ratelimit, registrar, rls, rtimer, seas, sipitrace, sl, snmpstats,
sst, texops, uac, uac_redirect, usrloc, utils
This does not necessarily mean that the modules above are difficult to
update, but only that they require manual changes and I haven't had
the time to do them yet.
Some of the modules require changes in the sip-router core which are
underway.
If you would like to help update one of the modules above and make
them work on the sip-router core, then, please, let me know. I would
especially appreciate help with the following modules:
perl, perlvdb, pv, snmpstas
because I don't know much about them.
And if you don't have the time or knowledge necessary to convert
modules, we would still appreciate if you could review changes we did
so far. Here is how you can review module changes:
1) Through gitweb
Go to
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=heads
and click on a module that interests you. You'll be presented with the
history of the module. Commits on the top of the list are those that I
made to make the module work with the sip-router core. The oldest
commit in most modules which is related to the update to sip-router is:
"Define OPENSER_MOD_INTERFACE in Makefile."
All modules contain that one, so you only need to look at commits that
are newer than this one. There are some exceptions though, such as the
acc module, where the above mentioned commit is not the last one.
2) With git
Clone the repository using:
$ git clone git://git.sip-router.org/kamailio-3.0
Checkout the branch of the module you are interested in:
$ git co -b acc origin/acc
And examine the history of the module with git log:
$ git log -u
Jan.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2:43 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
On 10-03 00:34, Ovidiu Sas wrote:
The snmpstats branch should be updated with the latest
updates for the
usrloc module. This will get rid of some db related compile issues.
Oh yes, this is something I forgot to mention in my initial email. Modules
that include headers from other modules won't compile because every module
branch only contains only changes related to that particular module.
Modules that other depend on are: alias_db, usrloc, and presence. I haven't
put the changes in the git repository because I had a script that did the
updates, but now I realized that others might have troubles with that so I'll
fix it in the public repository.
Thanks for pointing this out.
Also, OPENSER_OID needs to be defined inside config.h:
Given that there is only one module (snmpstats) using OPENSER_OID, shouldn't
we rather put the define in the module? What do you think?
Jan.
3:32 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
Having the OPENSER_OID defined inside the snmstats module should work.
I think that all k module (except tm) should be part of a single
branch. Like this, one fix in a module can be visible for other
modules that relay on it. It will make compile fixes to be solved
faster.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 8:43 AM, Jan Janak <jan(a)iptel.org> wrote:
On 10-03 00:34, Ovidiu Sas wrote:
The snmpstats branch should be updated with the
latest updates for the
usrloc module. This will get rid of some db related compile issues.
Oh yes, this is something I forgot to mention in my initial email. Modules
that include headers from other modules won't compile because every module
branch only contains only changes related to that particular module.
Modules that other depend on are: alias_db, usrloc, and presence. I haven't
put the changes in the git repository because I had a script that did the
updates, but now I realized that others might have troubles with that so I'll
fix it in the public repository.
Thanks for pointing this out.
Also, OPENSER_OID needs to be defined inside
config.h:
Given that there is only one module (snmpstats) using OPENSER_OID, shouldn't
we rather put the define in the module? What do you think?
Jan.
3:40 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
On 10-03 09:32, Ovidiu Sas wrote:
Having the OPENSER_OID defined inside the snmstats
module should
work.
OK.
I think that all k module (except tm) should be part
of a single
branch. Like this, one fix in a module can be visible for other
modules that relay on it. It will make compile fixes to be solved
faster.
Eventually yes, I'll see if I can setup another branch which will have
all module specific branches merged.
The reason why I setup the repository this way, having one branch per
module, is that I wanted to have module changes separated. This way I
can always do/undo changes to a particular module and still keep
others unaffected.
The primary purpose of the kamailio-3.0 repository is to generate
patches, when we eventually get to the state where all modules
compile, work, and people are happy with the changes, we will generate
a set of patches and apply it to the svn repository when/if the code
in the svn repository switches to the sip-router core.
After that the kamailio-3.0 repository can be decomissioned because it
will no longer be necessary.
Jan.
3:59 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
I started a new section on the wiki to keep track of what needs to be
done for modules that are not compiling:
http://sip-router.org/wiki/devel/kamailio-integration#module_integration_st…
Let me know if you think that this will help and what kind of
improvements are required.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 9:40 AM, Jan Janak <jan(a)iptel.org> wrote:
On 10-03 09:32, Ovidiu Sas wrote:
Having the OPENSER_OID defined inside the
snmstats module should
work.
OK.
I think that all k module (except tm) should be
part of a single
branch. Like this, one fix in a module can be visible for other
modules that relay on it. It will make compile fixes to be solved
faster.
Eventually yes, I'll see if I can setup another branch which will have
all module specific branches merged.
The reason why I setup the repository this way, having one branch per
module, is that I wanted to have module changes separated. This way I
can always do/undo changes to a particular module and still keep
others unaffected.
The primary purpose of the kamailio-3.0 repository is to generate
patches, when we eventually get to the state where all modules
compile, work, and people are happy with the changes, we will generate
a set of patches and apply it to the svn repository when/if the code
in the svn repository switches to the sip-router core.
After that the kamailio-3.0 repository can be decomissioned because it
will no longer be necessary.
Jan.
4:10 p.m.
New subject: [SR-Dev] [Kamailio-Devel] Status of kamailio modules on sip-router core
On 03/10/2009 03:59 PM, Ovidiu Sas wrote:
I started a new section on the wiki to keep track of
what needs to be
done for modules that are not compiling:
http://sip-router.org/wiki/devel/kamailio-integration#module_integration_st…
Let me know if you think that this will help and what kind of
improvements are required.
it is very good. I added extra columns to underline the dependency part
and description of that, plus status where to map: done, discarded, etc...
Cheers,
Daniel
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 9:40 AM, Jan Janak <jan(a)iptel.org> wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
On 10-03 09:32, Ovidiu Sas wrote:
_______________________________________________
Kamailio (OpenSER) - Devel mailing list
Devel(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
Having the OPENSER_OID defined inside the
snmstats module should
work.
OK.
I think that all k module (except tm) should be
part of a single
branch. Like this, one fix in a module can be visible for other
modules that relay on it. It will make compile fixes to be solved
faster.
Eventually yes, I'll see if I can setup another branch which will have
all module specific branches merged.
The reason why I setup the repository this way, having one branch per
module, is that I wanted to have module changes separated. This way I
can always do/undo changes to a particular module and still keep
others unaffected.
The primary purpose of the kamailio-3.0 repository is to generate
patches, when we eventually get to the state where all modules
compile, work, and people are happy with the changes, we will generate
a set of patches and apply it to the svn repository when/if the code
in the svn repository switches to the sip-router core.
After that the kamailio-3.0 repository can be decomissioned because it
will no longer be necessary.
Jan.
4:11 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
On Mar 10, 2009 at 09:59, Ovidiu Sas <osas(a)voipembedded.com> wrote:
I started a new section on the wiki to keep track of
what needs to be
done for modules that are not compiling:
http://sip-router.org/wiki/devel/kamailio-integration#module_integration_st…
Let me know if you think that this will help and what kind of
improvements are required.
Great! It will help a lot.
Andrei
4:53 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
On 10-03 09:32, Ovidiu Sas wrote:
I think that all k module (except tm) should be part
of a single
branch. Like this, one fix in a module can be visible for other
modules that relay on it. It will make compile fixes to be solved
faster.
For your convenience there is a new branch 'all' which contains the
sip-router core, likcore, and all module branches merged:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=shortlog…
Jan.
7:03 p.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
Hello Jan,
Here's a small patch that will fix the OPENSER_OID issue.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 9:32 AM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
Having the OPENSER_OID defined inside the snmstats
module should work.
I think that all k module (except tm) should be part of a single
branch. Like this, one fix in a module can be visible for other
modules that relay on it. It will make compile fixes to be solved
faster.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 8:43 AM, Jan Janak <jan(a)iptel.org> wrote:
On 10-03 00:34, Ovidiu Sas wrote:
The snmpstats branch should be updated with the
latest updates for the
usrloc module. This will get rid of some db related compile issues.
Oh yes, this is something I forgot to mention in my initial email. Modules
that include headers from other modules won't compile because every module
branch only contains only changes related to that particular module.
Modules that other depend on are: alias_db, usrloc, and presence. I haven't
put the changes in the git repository because I had a script that did the
updates, but now I realized that others might have troubles with that so I'll
fix it in the public repository.
Thanks for pointing this out.
Also, OPENSER_OID needs to be defined inside
config.h:
Given that there is only one module (snmpstats) using OPENSER_OID, shouldn't
we rather put the define in the module? What do you think?
Jan.
11 Mar
11 Mar
1:58 a.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
Ovidiu,
Thanks a lot, it is in the repository:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=shortlog…
I also added the original kamailio statistics interface into libkcore
and snmpstats module now compiles.
Jan.
On 10-03 13:03, Ovidiu Sas wrote:
Hello Jan,
Here's a small patch that will fix the OPENSER_OID issue.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 9:32 AM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
> Having the OPENSER_OID defined inside the snmstats module should work.
>
> I think that all k module (except tm) should be part of a single
> branch. Like this, one fix in a module can be visible for other
> modules that relay on it. It will make compile fixes to be solved
> faster.
>
>
> Regards,
> Ovidiu Sas
>
> On Tue, Mar 10, 2009 at 8:43 AM, Jan Janak <jan(a)iptel.org> wrote:
>> On 10-03 00:34, Ovidiu Sas wrote:
>>> The snmpstats branch should be updated with the latest updates for the
>>> usrloc module. This will get rid of some db related compile issues.
>>
>> Oh yes, this is something I forgot to mention in my initial email. Modules
>> that include headers from other modules won't compile because every module
>> branch only contains only changes related to that particular module.
>>
>> Modules that other depend on are: alias_db, usrloc, and presence. I haven't
>> put the changes in the git repository because I had a script that did the
>> updates, but now I realized that others might have troubles with that so
I'll
>> fix it in the public repository.
>>
>> Thanks for pointing this out.
>>
>>> Also, OPENSER_OID needs to be defined inside config.h:
>>
>> Given that there is only one module (snmpstats) using OPENSER_OID,
shouldn't
>> we rather put the define in the module? What do you think?
>>
>> Jan.
>>
>
2:08 a.m.
New subject: [SR-Dev] Status of kamailio modules on sip-router core
Perfect. All the kamailio modules are now listed under:
http://sip-router.org/wiki/devel/kamailio-integration#module_integration_st…
I marked the snmpstats module as being in "OK" status.
We should update all the other modules that are compiling with the
"OK" status and fill in the blocking items for the modules that are
not compiling.
As soon as I have new patches, I will submit them to you for integration.
Thank you for your work,
Ovidiu Sas
On Tue, Mar 10, 2009 at 7:58 PM, Jan Janak <jan(a)iptel.org> wrote:
Ovidiu,
Thanks a lot, it is in the repository:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=shortlog…
I also added the original kamailio statistics interface into libkcore
and snmpstats module now compiles.
Jan.
On 10-03 13:03, Ovidiu Sas wrote:
Hello Jan,
Here's a small patch that will fix the OPENSER_OID issue.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 9:32 AM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
> Having the OPENSER_OID defined inside the snmstats module should work.
>
> I think that all k module (except tm) should be part of a single
> branch. Like this, one fix in a module can be visible for other
> modules that relay on it. It will make compile fixes to be solved
> faster.
>
>
> Regards,
> Ovidiu Sas
>
> On Tue, Mar 10, 2009 at 8:43 AM, Jan Janak <jan(a)iptel.org> wrote:
>> On 10-03 00:34, Ovidiu Sas wrote:
>>> The snmpstats branch should be updated with the latest updates for the
>>> usrloc module. This will get rid of some db related compile issues.
>>
>> Oh yes, this is something I forgot to mention in my initial email. Modules
>> that include headers from other modules won't compile because every module
>> branch only contains only changes related to that particular module.
>>
>> Modules that other depend on are: alias_db, usrloc, and presence. I haven't
>> put the changes in the git repository because I had a script that did the
>> updates, but now I realized that others might have troubles with that so
I'll
>> fix it in the public repository.
>>
>> Thanks for pointing this out.
>>
>>> Also, OPENSER_OID needs to be defined inside config.h:
>>
>> Given that there is only one module (snmpstats) using OPENSER_OID,
shouldn't
>> we rather put the define in the module? What do you think?
>>
>> Jan.
>>
>
2:57 a.m.
New subject: [SR-Dev] [Kamailio-Devel] Status of kamailio modules on sip-router core
On 10-03 20:08, Ovidiu Sas wrote:
Perfect. All the kamailio modules are now listed
under:
http://sip-router.org/wiki/devel/kamailio-integration#module_integration_st…
I marked the snmpstats module as being in "OK" status.
We should update all the other modules that are compiling with the
"OK" status and fill in the blocking items for the modules that are
not compiling.
I added what I remember. By the way, it would be really great to have
such a table (or maybe extend this one) for the 2nd step, which is to
verify that modules marked as OK really load.
Are there any volunteers who would be willing to verify which modules
can be loaded and which not? I suspect that some of the modules marked
as OK would not load because some symbols will be missing in the core
and/or libraries. This would be of tremendous help.
thanks, Jan.
3:13 a.m.
New subject: [SR-Dev] [Kamailio-Devel] Status of kamailio modules on sip-router core
I will see what I can do ...
On Tue, Mar 10, 2009 at 8:57 PM, Jan Janak <jan(a)iptel.org> wrote:
On 10-03 20:08, Ovidiu Sas wrote:
Perfect. All the kamailio modules are now listed
under:
http://sip-router.org/wiki/devel/kamailio-integration#module_integration_st…
I marked the snmpstats module as being in "OK" status.
We should update all the other modules that are compiling with the
"OK" status and fill in the blocking items for the modules that are
not compiling.
I added what I remember. By the way, it would be really great to have
such a table (or maybe extend this one) for the 2nd step, which is to
verify that modules marked as OK really load.
Are there any volunteers who would be willing to verify which modules
can be loaded and which not? I suspect that some of the modules marked
as OK would not load because some symbols will be missing in the core
and/or libraries. This would be of tremendous help.
thanks, Jan.
5739
days inactive
5741
days old
14 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
Ovidiu Sas