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@lists.intel.com