27 Sep
2009
27 Sep
'09
11:06 p.m.
SNMPstats currently lives in modules_k. As we've got an OID for Kamailio.org
it's time to update the module.
1. Change the OID - maybe with a config option if people depend on the
old
2. Change file names on all files starting with "openser". I don't see
why we need a name tag in these file names. Anyone else?
openserObjects.h could very well be snmpObjects.h
3. Update all MIBS so that we don't use the openser namespace or OID.
I would suggest that we change all "openser" tags to "siprouter" to
enable this module to move in to core at some point. Changing MIBs to
have "kamailio" in all names doesn't seem very long term for me.
Any comments?
I can start playing with this and upload patches to the tracker, but
would like some consensus on the road map before I proceed.
/O
27 Sep
27 Sep
11:10 p.m.
27 sep 2009 kl. 22.06 skrev Olle E. Johansson:
SNMPstats currently lives in modules_k. As we've
got an OID for Kamailio.org
it's time to update the module.
1. Change the OID - maybe with a config option if people depend on
the old
2. Change file names on all files starting with "openser". I don't
see why we need a name tag in these file names. Anyone else?
openserObjects.h could very well be snmpObjects.h
3. Update all MIBS so that we don't use the openser namespace or
OID. I would suggest that we change all "openser" tags to
"siprouter" to enable this module to move in to core at some point.
Changing MIBs to have "kamailio" in all names doesn't seem very long
term for me.
Maybe we should consider using the common SIP mib for where we follow
it and only use Kamailio/Sip-router specific mibs for extras. I think
our MIBS was created at a very early stage of the SIP mibs. Anyone
that knows more about this and have comments?
Looking from my newbie perspective I don't see any reason on why we
should in large parts copy the standard MIB and still use our own
definitions.
/O
1 Oct
1 Oct
2:56 p.m.
27 sep 2009 kl. 22.10 skrev Olle E. Johansson:
27 sep 2009 kl. 22.06 skrev Olle E. Johansson:
Daniel,
Thanks for the commits. I think you failed to read the part where I
said "I can start working on this" ;-)
I still want to have a discussion about the last part above - why are
we not using the standard SIP mib where we can?
Also, maybe we should reorganize the mib so that we suballocate for
future use outside of snmp
kamailiooid.10 SNMP
kamailiooid.20 LDAP
Right now I believe we're using the full OID directly for snmp
subclasses.
Anyone that has experience of organizing OID trees that can give some
input?
We can't change it in every release, as we will propably break
existing scripts and management platforms, so we will have to try to
do it right while we're messing with it :-)
/O
SNMPstats currently lives in modules_k. As
we've got an OID for Kamailio.org
it's time to update the module.
1. Change the OID - maybe with a config option if people depend on
the old
2. Change file names on all files starting with "openser". I don't
see why we need a name tag in these file names. Anyone else?
openserObjects.h could very well be snmpObjects.h
3. Update all MIBS so that we don't use the openser namespace or
OID. I would suggest that we change all "openser" tags to
"siprouter" to enable this module to move in to core at some point.
Changing MIBs to have "kamailio" in all names doesn't seem very
long term for me.
Maybe we should consider using the common SIP mib for where we
follow it and only use Kamailio/Sip-router specific mibs for extras.
I think our MIBS was created at a very early stage of the SIP mibs.
Anyone that knows more about this and have comments?
Looking from my newbie perspective I don't see any reason on why we
should in large parts copy the standard MIB and still use our own
definitions. 
3:13 p.m.
On 01.10.2009 13:56 Uhr, Olle E. Johansson wrote:
[...]
Daniel,
Thanks for the commits. I think you failed to read the part where I
said "I can start working on this" ;-)
I did miss it. Send me the ssh key
so you can apply changes. I am more
that happy if you can take over this work.
SNMPstats
currently lives in modules_k. As we've got an OID for
Kamailio.org it's time to update the module.
1. Change the OID - maybe with a config option if people depend on
the old
2. Change file names on all files starting with "openser". I don't
see why we need a name tag in these file names. Anyone else?
openserObjects.h could very well be snmpObjects.h
3. Update all MIBS so that we don't use the openser namespace or
OID. I would suggest that we change all "openser" tags to
"siprouter" to enable this module to move in to core at some point.
Changing MIBs to have "kamailio" in all names doesn't seem very long
term for me.
Maybe we should consider using the common SIP mib for where we follow
it and only use Kamailio/Sip-router specific mibs for extras. I think
our MIBS was created at a very early stage of the SIP mibs. Anyone
that knows more about this and have comments?
Looking from my newbie perspective I don't see any reason on why we
should in large parts copy the standard MIB and still use our own
definitions.
I still want to have a discussion about the last part above - why are
we not using the standard SIP mib where we can?
Well, I think we should use the standard SIP mibs where they are available.
Also, maybe we should reorganize the mib so that we suballocate for
future use outside of snmp
kamailiooid.10 SNMP
kamailiooid.20 LDAP
Right now I believe we're using the full OID directly for snmp
subclasses.
Anyone that has experience of organizing OID trees that can give some
input?
We can't change it in every release, as we will propably break
existing scripts and management platforms, so we will have to try to
do it right while we're messing with it :-)
OK, but since I haven't been using it heavily, I cannot say how is
better to have the OID trees. Therefore I can help a bit more with
messing that with doing it right from first time :-) .
Cheers,
Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
3:46 p.m.
I still want to have a discussion about the last part above - why
are we not using the standard SIP mib where we can?
Well, I think we should use the standard SIP mibs where they are
available.
Also, maybe we should reorganize the mib so that we suballocate for
future use outside of snmp
kamailiooid.10 SNMP
kamailiooid.20 LDAP
Right now I believe we're using the full OID directly for snmp
subclasses.
Anyone that has experience of organizing OID trees that can give
some input?
We can't change it in every release, as we will propably break
existing scripts and management platforms, so we will have to try
to do it right while we're messing with it :-)
OK, but since I haven't been using it heavily, I cannot say how is
better to have the OID trees. Therefore I can help a bit more with
messing that with doing it right from first time :-) . 
7:49 p.m.
On Donnerstag, 1. Oktober 2009, Olle E. Johansson wrote:
Anyone else in the developer community with any insights/opinions?
Hi Olle,
i also think that using the existing standard SIP mibs would be better then
this custom tree.
My thinking is that we might at some point end up having to specify
our own LDAP schemas. Having a nicely build OID tree makes it more
simple to handle this, since LDAP schemas use OIDs as identifiers as
well. I guess that other developers can come up other protocols that
use OIDs too :-)
Any more input from the rest of the crowd before I move ahead and
start messing with this?
I did not used snmp that much, and even less ldap, so i can't really judge on
this question, sorry. ;)
Henning
I still want to have a discussion about the last part
above - why
are we not using the standard SIP mib where we can?
Well, I think we should use the standard SIP mibs where they are
available. Also, maybe we should reorganize the mib so that we
suballocate for
future use outside of snmp
kamailiooid.10 SNMP
kamailiooid.20 LDAP
Right now I believe we're using the full OID directly for snmp
subclasses.
Anyone that has experience of organizing OID trees that can give
some input?
We can't change it in every release, as we will propably break
existing scripts and management platforms, so we will have to try
to do it right while we're messing with it :-)
OK, but since I haven't been using it heavily, I cannot say how is
better to have the OID trees. Therefore I can help a bit more with
messing that with doing it right from first time :-) . 
8:06 p.m.
On Thu, Oct 1, 2009 at 2:46 PM, Olle E. Johansson <oej(a)edvina.net> wrote:
Some time ago I came up with a system for the iptel.org PEN. I
structured the space so that we can store RADIUS attributes and LDAP
attributes and objects there. You can find an example below.
24960 is the PEN for iptel.org. 24960.0 is reserved for RADIUS.
24960.1 is reserved for LDAP. 24960.1.0 are LDAP attributes, 2496.1.1
are LDAP objects, and so on. Following this pattern you can simply
allocate 24960.2 for everything related to SNMP.
By the way, I asked for this number to be reassigned to the sip-router
project. If approved it is possible that the number 24960 will become
a new enterprise number for the sip-router project.
|-------------------+----+-----+-----+-------------------------|
| 1.3.6.1.4.1.24960 | | | | iptel.org |
| | .0 | | | RADIUS |
| | | .1 | | SER-Uri-User |
| | | .2 | | SER-Group |
| | | .3 | | SER-Rpid |
| | | .4 | | SER-Attrs |
| | | .5 | | SER-From |
| | | .6 | | SER-Flags |
| | | .7 | | SER-Original-Request-ID |
| | | .8 | | SER-To |
| | | .9 | | SER-Digest-Username |
| | | .10 | | SER-Digest-Realm |
| | | .11 | | SER-Request-Timestamp |
| | | .12 | | SER-To-DID |
| | | .13 | | SER-From-UID |
| | | .14 | | SER-From-DID |
| | | .15 | | SER-To-UID |
| | | .16 | | SER-Response-Timestamp |
| | .1 | | | LDAP |
| | | .0 | | Attribute |
| | | | .0 | authUsername |
| | | | .1 | authRealm |
| | | | .2 | password |
| | | | .3 | sipUID |
| | | | | |
| | | | .5 | HA1 |
| | | | .6 | HA1B |
| | | | .7 | sipDID |
| | | | .8 | sipDomain |
| | | | .9 | forSER |
| | | | .10 | forSERWeb |
| | | | .11 | disabled |
| | | | .12 | sipFromURI |
| | | | .13 | sipToURI |
| | | | .14 | avp |
| | | | .15 | accountActive |
| | | | .16 | mailDrop |
| | | | .17 | mailSource |
| | | .1 | | Object |
| | | | .0 | sipAccount |
| | | | .1 | sipDomain |
| | | | .2 | sipUser |
| | | | .3 | mailAlias |
| | | | .4 | jabberUsername |
|-------------------+----+-----+-----+-------------------------|
Jan.
OK, but since
I haven't been using it heavily, I cannot say how is better
to have the OID trees. Therefore I can help a bit more with messing that
with doing it right from first time :-) .
My thinking is that we might at some point end up having to specify our own
LDAP schemas. Having a nicely build OID tree makes it more simple to handle
this, since LDAP schemas use OIDs as identifiers as well. I guess that other
developers can come up other protocols that use OIDs too :-)
Any more input from the rest of the crowd before I move ahead and start
messing with this?
2 Oct
2 Oct
8:30 a.m.
1 okt 2009 kl. 19.06 skrev Jan Janak:
On Thu, Oct 1, 2009 at 2:46 PM, Olle E. Johansson
<oej(a)edvina.net>
wrote:
Some time ago I came up with a system for the iptel.org PEN. I
structured the space so that we can store RADIUS attributes and LDAP
attributes and objects there. You can find an example below.
24960 is the PEN for iptel.org. 24960.0 is reserved for RADIUS.
24960.1 is reserved for LDAP. 24960.1.0 are LDAP attributes, 2496.1.1
are LDAP objects, and so on. Following this pattern you can simply
allocate 24960.2 for everything related to SNMP.
Ok, you just confirmed my thoughts
and added radius to this soup.
THANKS!
OK, but
since I haven't been using it heavily, I cannot say how is
better
to have the OID trees. Therefore I can help a bit more with
messing that
with doing it right from first time :-) .
My thinking is that we might at some point end up having to specify
our own
LDAP schemas. Having a nicely build OID tree makes it more simple
to handle
this, since LDAP schemas use OIDs as identifiers as well. I guess
that other
developers can come up other protocols that use OIDs too :-)
Any more input from the rest of the crowd before I move ahead and
start
messing with this?
By the way, I asked for this number to be reassigned to the sip-router
project. If approved it is possible that the number 24960 will become
a new enterprise number for the sip-router project.
Then we will have an interesting situation.
1) Move the snmpstats module from modules_k to core modules.
2) Have a party, get drunk and make a decision whether to use sip-
router OID or Kamailio or both
In the "both" alternative, we need to maintain two sets of MIBS. Since
a lot of the stuff we have in the Kamailio MIB today actually seems
copied from SIP MIB, it won't affect many settings.
Regardless of the outcome of the MIB/OID/PEN battle we can start
looking into migration to the SIP mib.
/Olle
4 Oct
4 Oct
3:19 p.m.
On Fri, Oct 2, 2009 at 7:30 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
Just to let you know, IANA just finished the update. The private
enterprise number 24960 is now officially assigned to the sip-router
project.
If you plan to use that number then we should probably create a wiki
page (or have a text file in the repository) which will list all
assignments.
Jan.
By the way, I asked for this number to be reassigned to the sip-router
project. If approved it is possible that the number 24960 will become
a new enterprise number for the sip-router project.
Then we will have an interesting situation.
1) Move the snmpstats module from modules_k to core modules.
2) Have a party, get drunk and make a decision whether to use sip-router OID
or Kamailio or both
In the "both" alternative, we need to maintain two sets of MIBS. Since a lot
of the stuff we have in the Kamailio MIB today actually seems copied from
SIP MIB, it won't affect many settings.
Regardless of the outcome of the MIB/OID/PEN battle we can start looking
into migration to the SIP mib.
4:44 p.m.
On 04.10.2009 14:19 Uhr, Jan Janak wrote:
On Fri, Oct 2, 2009 at 7:30 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
Just to let you know, IANA just finished the update. The private
enterprise number 24960 is now officially assigned to the sip-router
project.
If you plan to use that number then we should probably create a wiki
page (or have a text file in the repository) which will list all
assignments.
snmpstats module is dependent of K statistics framework and they are not
included in the core yet, subject to improved and totally different
implementation in the future. K 3.0 will get core statistics included
back (as they are in 1.5) after we branch for release during the next week.
Not sure it makes sense to move it to common dir since it is very K
specific right now.
Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
By the
way, I asked for this number to be reassigned to the sip-router
project. If approved it is possible that the number 24960 will become
a new enterprise number for the sip-router project.
Then we will have an interesting situation.
1) Move the snmpstats module from modules_k to core modules.
2) Have a party, get drunk and make a decision whether to use sip-router OID
or Kamailio or both
In the "both" alternative, we need to maintain two sets of MIBS. Since a lot
of the stuff we have in the Kamailio MIB today actually seems copied from
SIP MIB, it won't affect many settings.
Regardless of the outcome of the MIB/OID/PEN battle we can start looking
into migration to the SIP mib.
7:10 p.m.
4 okt 2009 kl. 15.44 skrev Daniel-Constantin Mierla:
On 04.10.2009 14:19 Uhr, Jan Janak wrote:
Thanks for that information!
Jan - is there a similar statistics framework for ser or any snmp
support?
/O
On Fri, Oct 2, 2009 at 7:30 AM, Olle E. Johansson
<oej(a)edvina.net>
wrote:
Just to let you know, IANA just finished the update. The private
enterprise number 24960 is now officially assigned to the sip-router
project.
If you plan to use that number then we should probably create a wiki
page (or have a text file in the repository) which will list all
assignments.
snmpstats module is dependent of K statistics framework and they are
not included in the core yet, subject to improved and totally
different implementation in the future. K 3.0 will get core
statistics included back (as they are in 1.5) after we branch for
release during the next week.
Not sure it makes sense to move it to common dir since it is very K
specific right now. By the
way, I asked for this number to be reassigned to the sip-
router
project. If approved it is possible that the number 24960 will
become
a new enterprise number for the sip-router project.
Then we will have an interesting situation.
1) Move the snmpstats module from modules_k to core modules.
2) Have a party, get drunk and make a decision whether to use sip-
router OID
or Kamailio or both
In the "both" alternative, we need to maintain two sets of MIBS.
Since a lot
of the stuff we have in the Kamailio MIB today actually seems
copied from
SIP MIB, it won't affect many settings.
Regardless of the outcome of the MIB/OID/PEN battle we can start
looking
into migration to the SIP mib.
7:57 p.m.
On 04.10.2009 18:10 Uhr, Olle E. Johansson wrote:
snmpstats module is dependent of K statistics framework and they are
not included in the core yet, subject to improved and totally
different implementation in the future. K 3.0 will get core
statistics included back (as they are in 1.5) after we branch for
release during the next week.
Not sure it makes sense to move it to common dir since it is very K
specific right now.
Thanks for that information! to be more clear, statistics framework from K is
available in SR, inside
kcore library. Missing parts are couple of core metrics:
rcv_requests
rcv_replies
fwd_requests
fwd_replies
drop_requests
drop_replies
err_requests
err_replies
bad_URIs_rcvd
unsupported_methods
bad_msg_hdr
So pretty small patch to have them added. All the other K statistics are
already there.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
> By the way, I asked for this number to be
reassigned to the
> sip-router
> project. If approved it is possible that the number 24960 will become
> a new enterprise number for the sip-router project.
>
Then we will have an interesting situation.
1) Move the snmpstats module from modules_k to core modules.
2) Have a party, get drunk and make a decision whether to use
sip-router OID
or Kamailio or both
In the "both" alternative, we need to maintain two sets of MIBS.
Since a lot
of the stuff we have in the Kamailio MIB today actually seems
copied from
SIP MIB, it won't affect many settings.
Regardless of the outcome of the MIB/OID/PEN battle we can start
looking
into migration to the SIP mib.
Just to let you know, IANA just finished the update. The private
enterprise number 24960 is now officially assigned to the sip-router
project.
If you plan to use that number then we should probably create a wiki
page (or have a text file in the repository) which will list all
assignments.
8:03 p.m.
On Sun, Oct 4, 2009 at 6:10 PM, Olle E. Johansson <oej(a)edvina.net> wrote:
Thanks for that information!
Jan - is there a similar statistics framework for ser or any snmp support?
No, SER does not have SNMP support.
Jan.
Just to let you know, IANA just finished the update.
The private
enterprise number 24960 is now officially assigned to the sip-router
project.
If you plan to use that number then we should probably create a wiki
page (or have a text file in the repository) which will list all
assignments.
snmpstats module is dependent of K statistics framework and they are not
included in the core yet, subject to improved and totally different
implementation in the future. K 3.0 will get core statistics included back
(as they are in 1.5) after we branch for release during the next week.
Not sure it makes sense to move it to common dir since it is very K
specific right now.
5528
days inactive
5535
days old
12 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Jan Janak -
Olle E. Johansson