H.LDAP for SIP

[Tyler Miller Johnson]

Dear SG16 Experts,

In Geneva we are hoping to obtain consent on the H.350 series of
documents describing how to represent various protocols in LDAP for
standardized directory services. These include h.323, h.235, h.320, SIP
and non-standard protocols.

H.323, H.235 and H.320 are well defined and have been vetted within the
group. I have received much valuable feedback. Thank you.

SIP is a somewhat different matter. SG16 acknowledged that it desired
greater SIP expertise. Toward that end, I have had a number of SIP
experts from the Internet2 and ViDe Middleware and Voice Over IP working
groups review the document. With the exception of a few minor
corrections, the technical architecture as it now stands is strong.
There are a couple of issues.

The IETF SIPPING working group would be the IETF group responsible for
operational aspects of SIP like directory services, although to our
knowledge there are no current efforts in that direction. There is some
concern that SIP developers will not adopt standards that are not from
the IETF. We should consider that.

Further, there is a technical issue to which I would like to draw your
attention. The SIP architecture relies on the use of DNS SRV records as
a place to hold/derive information such as registrar and proxy address.
H.350.4 puts that information in LDAP instead. Here are some points
related to this difference of approach:

1. The existence of H.350.4 in no way precludes the use of DNS SRV
records for SIP. It provides an alternative, which may be supplementary.

2. The existence of H.350.4 might confuse some developers as to which
way they should implement (SRV or LDAP).

3. In spite of the fact that the IETF SIP community relies heavily on
SRV records, there remains substantial resistance to deployment of this
in the marketplace. DNS administrators often do not want to extend the
functionality of their DNS servers, as these are serving an existing
critical purpose on the network. This is a problem for ENUM as well,
since while the solution works, it may never be adopted.

4. If a vendor uses H.350 to provide directory services and management
tools for H.323 and H.320, and then wants to add SIP to their service
offering, the use of H.350 for SIP provides a common and controlled
approach. That is to say, if you already have an h.320/h.323
codec/mcu/gateway using H.350, you can add directory services and
management for SIP with almost no additional work, and you have one
common tool to manage all of it.

5. It is possible to eliminate the attributes from H.350.4 that have
corresponding SRV functionality. This would essentially leave SIPuri as
the primary attribute. This might appease the IETF community somewhat.
It would support white pages lookups. It would have more limited
functionality, and not acheive what is described in #4 above.

So what should we do? I raise these issues to the group so that we can
have a discussion of them prior to the meeting Geneva. We can move
forward with consent on the existing architecture. We can limit the
architecture so as not to offend anyone, and consent. Or we could
investigate the possibility of joint ratification with IETF.

Best Regards,
Tyler Johnson
Editor, H.LDAP / SG16

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com