#67 Adding Polycom VVX as a valid IP phone in remote_types

closed
Feature (13)
2014-01-09
2013-06-10
R.P. Aditya
No

There are more IP phones that are not being classified as such in the device_port.remote_type field that we would like to add. The simplest place seems to be to do it here (specifically for the "Polycom VVX" series):

https://github.com/netdisco/netdisco/blob/master/netdisco#L1602

< if (defined $remote_type and $remote_type =~ /(mitel.5\d{3})/i) {
> if (defined $remote_type and $remote_type =~ /((polycom\svvx)|(mitel.5\d{3})/i)) {

however the better longterm solution would be to create a new table with known phone types and update the code to be built from that table.

Discussion

  • Oliver Gorwits
    Oliver Gorwits
    2013-06-10

    Perhaps this is something which should go into SNMP::Info...

    when it returns the remote_type field, it can do this check and amend the content.

     
  • R.P. Aditya
    R.P. Aditya
    2013-06-10

    SNMP::Info is retrieving the values on the devices without changing
    them, whereas in this case we want to change what is stored in
    remote_type and that should be done in the "end" system where the info
    is stored, hence the suggestion to do it where we already have one such
    process.

    It might be even cleaner to just do it in the search form:

    https://github.com/netdisco/netdisco/blob/master/html/device_search.html#L327

    and change it to:

    < 'p.remote_type' => \ ' ILIKE \'%ip_phone%\'',

    'p.remote_type' => \ ' ILIKE \'%ip_phone%\' or p.remote_type ILIKE
    \'%polycom_vvx%\'',

    or something like that.

    But the problem of extending what remote devices match which categories
    continues.

    Adi

     
    Last edit: R.P. Aditya 2013-06-10
  • Oliver Gorwits
    Oliver Gorwits
    2013-06-11

    It's not always the case that SNMP::Info returns the values without changing. This is why we now have the *_raw() accessors, to bypass any "munge" of the data, in case the user wants the unaltered value.

     
  • IMHO, the *_raw() accessors in SNMP::Info exist mainly to get raw data and not a copy that is munged to a more human readable representation. For example, PortList objects are normally munged, so the return value is an array of ones and zeroes. The *_raw() method returns the actual binary string received from the device before unpacking etc.

    I think we shouldn't modify which CDP or LLDP neighbors are returned by SNMP::Info. It's a design choice in Netdisco that some neighbors are "devices" and some are not and that they are treated differently in the web interface; I don't think that's something to solve at the level of SNMP::Info, because it would also affect other SNMP::Info based tools.

    A better solution would be to use two methods in Netdisco to determine how a neighbor is displayed in the web interface (and possibly stored in the DB):

    1) String matching like we do now (but perhaps not hard code the matches but put them in a DB table so it's easier to extend?)

    2) Fetch more details on the neighbor, like device capabilities indicated by LLDP. Store these capabilities in the database and if a neighbor identifies itself as having "telephone" capabilities (or the Cisco equivalent), mark it as an IP phone in the web interface. This way Netdisco should automatically do 'the right thing' with phones, without us having to match brand or description etc.

    My suggestion is to put this in Netdisco 2.x: it's relatively simple to solve, but requires an extra column in the DB and an extra object to fetch upon discover/refresh of a device. And a few lines in the logic for the UI of course.

     
  • Eric A. Miller
    Eric A. Miller
    2014-01-09

    Ticket moved from /p/netdisco/bugs/95/

    Can't be converted:

    • _milestone: 0.95
    • _priority: 5
     
  • Eric A. Miller
    Eric A. Miller
    2014-01-09

    I believe this issue is addressed in this commit.

    The CDP/LLDP capabilities are not stored in the database since the capabilities advertised by CDP and LLDP differ substantially making it difficult to normalize for storage. Instead if a device advertises it's phone we tag remote_type as 'IP Phone: ' and if as an AP via LLDP (CDP doesn't support AP capability) we tage remote_type as 'AP: '.

    Marking the ticket closed based upon the commit.

     
  • Eric A. Miller
    Eric A. Miller
    2014-01-09

    • labels: --> Feature
    • status: open --> closed
    • assigned_to: Eric A. Miller