*Attendees*

Samir Chatterjee CGU
Doug Sicker CU-Boulder
Ann West Educause/Internet2
Art Vandenberg GSU
Jeanette Fielden Internet2
Ken Klingenstein Internet2
Steve Olshansky Internet2
Ben Teitelbaum Internet2
Jonathon Tyman Internet2
Dennis Baron MIT
Tom Barton U. Chicago
Jill Gemmill UAB
Aditya Srinivasan UAB
Nadim El-Khoury UNC
Alisa Haggard UNC
Tyler Johnson UNC
Jeremy George Yale

*Discussion*
SIP Identity Specification Review:
Tyler provided an overview and background for the SIP identity attribute discussion. The group has created a set of specifications and architectures for directory enabling video and voice over IP. That set of architectures is an LDAP schema that represents endpoints in a directory. The representation of the endpoints is standardized, how to access that data is not. Many developers are integrating LDAP into their call servers but in different ways.

We want to enable
1. A standardized way to insert someone's video/voice address into a directory for searching.
2. Managing voice and video service through the management of an enterprise directory.
3. Simplified endpoint administration.

If the enterprise/campus directory goes down can a call still be placed? If you're already registered you can place a call. If the directory goes down there's a larger problem since people would not be able to log in etc. Jill suggested adding a definition of an enterprise directory. It should operate as a hardened production unit deployed in a manner that doesn't fail.

The purpose is to represent existing protocols and existing data elements in a directory. What it argues for is to use the absolute minimum number of attributes required to achieve functionality. The danger is mission creep through proliferation of attributes.

Study Group 16 is interested in including SIP specification because many vendors are looking at supporting it within their endpoints. Seven attributes have been identified:
1. the SIP URI itself,
2. registrar,
3. proxy,
4. the address of endpoint,
5. password,
6. user name and
7. service level.

Wherever you see password and user name it is implied there is a certificate attribute as well. It is not defined here since certificate has already been defined within LDAP and we can reuse that attribute.

Proxy is defined in section 5.1.4. of the base document. Proxy address, which means the IP address, is a fully qualified domain name of the SIP proxy. That is so an endpoint has available to it the address of the proxy to which it is supposed to register.

Many in the SIP community feel it would be appropriate to pull that information from the DNS SRV record. Should it continue to be defined in LDAP for those that want to manage it through commObject or LDAP or should we relegate that to DNS entirely? It would not be harmful to store that information in LDAP if it were decided that's how an endpoint would be configured.
From a self-configuration of a user agent standpoint perhaps it's not needed but from a system administration view that wants to see a complete picture of the system having a proxy attribute would be useful. The DNS would be the master location of data.

The attribute storing endpoint address was originally proposed to store the DNS name of the endpoint for direct user dialing by IP address. After discussion it was decided that could be represented with the SIP URI attribute. The SIP identity address attribute will be retained to store if an agent is registered or not. The URI would be used to store the canonical URI, and if the address attribute is empty then the agent is not registered. It might also be useful for reverse 911 announcements or other third party applications.

Service level attribute: Proxies like to keep lists of what users are allowed to do. This is an example of a user-associated attribute an endpoint would use. How do you capture the most basic level of presence? Presence is defined outside the main SIP RFC. There is a notion of SIP user agents that are registered and bound to a particular user. Where would a registrar store that state? This has been discussed with Radvision. Their feeling is that's the kind of info good to have in the local table. It might be very quickly changing info and not lend itself to being stored in LDAP. If the registration is stored in a local table, then it's not dependent on LDAP going down. The exception is 5.1.8, SIP identity service level. This is an example that deviates from the data practice of identifying new functionality. In this case every product in someway can define what services a user could or could not use. It's been included since the notion of directories is tied up with the notion of user authentication, roles and authorized usage, and is labeled accordingly.
It would be nice to have endpoints that automatically configure themselves. Endpoint configuration is the single biggest source of problems on the network, users have a hard time getting the information into computer, IP phones etc. Scenarios are described in the appendices to the H.350 base document. While it is not clear that automated configuration will be developed it is desirable to have the functionality available for other purposes such as a configuration information service. You'd have a web page where someone could log on with their campus user name, and a page could be printed that contains everything they need to put into their user agent in order to use services. It would be manual but wouldn't require vendor support.

In summary, using this architecture it's possible to make a SIP network that is totally dependent on the enterprise directory. It's also possible to keep its state locally so it's not dependent on the enterprise directory. The SIP proxy can be located through DNS rather than LDAP, however it's also noted that it would not be harmful to store that information in LDAP if it were decided that's how an endpoint would be configured. The SIP URI will be the primary location for address. The SIP identity address will be retained for other applications.

Tyler will incorporate these changes into the document. The document won't be released before the ITU meeting in May. He will notify the group as soon as it is posted.

Next call is Monday May 5, 2003.