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 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.
- Change the OID - maybe with a config option if people depend on
the old
- 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
- 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
27 sep 2009 kl. 22.10 skrev Olle E. Johansson:
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.
- Change the OID - maybe with a config option if people depend on
the old
- 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
- 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.
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
On 01.10.2009 13:56 Uhr, Olle E. Johansson wrote:
[...]
SNMPstats currently lives in modules_k. As we've got an OID for Kamailio.org it's time to update the module.
- Change the OID - maybe with a config option if people depend on
the old
- 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
- 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.
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.
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 LDAPRight 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
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.
Anyone else in the developer community with any insights/opinions?
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 :-) .
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?
/O
On Donnerstag, 1. Oktober 2009, Olle E. Johansson wrote:
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.
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.
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 :-) .
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
On Thu, Oct 1, 2009 at 2:46 PM, Olle E. Johansson oej@edvina.net wrote:
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?
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.
1 okt 2009 kl. 19.06 skrev Jan Janak:
On Thu, Oct 1, 2009 at 2:46 PM, Olle E. Johansson oej@edvina.net wrote:
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?
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!
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
On Fri, Oct 2, 2009 at 7:30 AM, Olle E. Johansson oej@edvina.net wrote:
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.
- Move the snmpstats module from modules_k to core modules.
- 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.
Jan.
On 04.10.2009 14:19 Uhr, Jan Janak wrote:
On Fri, Oct 2, 2009 at 7:30 AM, Olle E. Johansson oej@edvina.net wrote:
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.
- Move the snmpstats module from modules_k to core modules.
- 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.
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
4 okt 2009 kl. 15.44 skrev Daniel-Constantin Mierla:
On 04.10.2009 14:19 Uhr, Jan Janak wrote:
On Fri, Oct 2, 2009 at 7:30 AM, Olle E. Johansson oej@edvina.net wrote:
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.
- Move the snmpstats module from modules_k to core modules.
- 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.
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!
Jan - is there a similar statistics framework for ser or any snmp support?
/O
On 04.10.2009 18:10 Uhr, Olle E. Johansson wrote:
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.
- Move the snmpstats module from modules_k to core modules.
- 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.
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
On Sun, Oct 4, 2009 at 6:10 PM, Olle E. Johansson oej@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.
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.
-
Daniel-Constantin Mierla -
Henning Westerholt -
Jan Janak -
Olle E. Johansson