Distinguished Names (DNs) used by NetMeeting must always
end in "objectclass=rtperson".
The following LDAP attributes are used by NetMeeting:
Table A-1. NetMeeting LDAP attributes
| objectClass | must be "RTPerson" |
| cn | alias used for directory lookups; must be present |
| sappid | must be "ms-netmeeting" |
| sprotid | must be "h323" |
| sprotmimetype | typically "text/h323"; unused |
| smimetype | typically "text/iuls"; unused |
| sflags | must be 1 |
| sappguid | unknown |
| smodop | unknown |
| sipaddress | decimal IP address |
| sport | TCP port number; unused |
| ssecurity | unknown |
| sttl | entry timeout value in minutes |
| c | two digit country code |
| rfc822mailbox | email address |
| givenname | optional |
| surname | optional |
| comment | optional |
| location | optional |
| ilsa39321630 | 1 = personal; 2 = business; 4 = adult |
| ilsa32833566 | 0 = not audio capable; 1 = audio capable |
| ilsa32964638 | 0 = not video capable; 1 = video capable |
| ilsa26214430 | 0 = not in a call; 1 = currently in a call |
| ilsa26279966 | unknown |
NetMeeting uses a non-standard means of refreshing dynamic entries.
The Microsoft server maintains an "sttl" attribute, which is a
time to live for the entry in minutes. A search request for
attribute "sttl" resets the timer. If the timer goes to zero,
the entry is supposed to disappear from the database. Of course,
the sttl attribute doesn't actually exist in the database, and
the client doesn't bother to give us the whole DN it wants updated,
only supplying the "cn" component in the search request.
Take our 
