Subject: [Sipping] ITU H.350-related Directory Services Internet Draft

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2003 12:31:52 -0600

If you are interested in integrating directory services with SIP, please
review:

http://www.ietf.org/internet-drafts/draft-h350-directory-services-00.txt

Thanks!

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Nov 2003 15:29:15 -0800

I'm very unclear on what you are trying to do here.

If you are trying to provide configuration information for SIP UA's with
this - I think that approach is really lacking.

If you are trying to create a global LDAP directory with all subscribers in
it as a way of doing rendezvous between different domains, I think that all
you need in the directory is the SIP AOR for the user.

If I have the URL sip:[email-masked], Why would I want to find out the
address of the registrar?

ProxyAddress - not sure I would want this - again SIP uses DNS.

SIPIdentityAddress - again, isn't this just the URL

SIPIdenityPassword - surely you are joking. If the purpose of this directory
is as described in the draft, you would not need this. If the purpose was
provisioning, this would be a really bad approach.

ServiceLevel - well this is a nice field with no meaning. What would anyone
do with it. If no one does anything with, why is it here.

---

From: Tyler Johnson <[email-masked]>
Date: Sun, 30 Nov 2003 07:12:41 -0500

> I'm very unclear on what you are trying to do here.

The primary reason for the H.350 series is to allow an enterprise, 
carrier, or other service provider to manage primary identity data 
associated with multimedia conferencing in a way that is standardized 
and outside the call servers and endpoints themselves. For example, many 
large universities (like mine) offer SIP, H.323, H.320 as well as 
proprietary conferencing services. It is important that these 
universities be able to centrally manage all of their users, and their 
associated conferencing addresses. It is important that these 
universities be able to manage that data store (LDAP directory) 
independently from the particular call servers they happen to be using, 
so that they can migrate from one product and vendor to another without 
having to rebuild their internal data stores and management structures.

The white pages example you mention is one benefit of standardizing 
conferencing address representations in LDAP. It is important to be able 
to query an LDAP directory and ask the question 'What is the SIP URI for 
this user?' And you correctly point out that SIP URI is probably the 
only attribute (other than the data structures associated with managing 
the object classes themselves) necessary for that.

Using H.350 for endpoint configuration (i.e. provisioning) has been 
demonstrated as an academic exercise and is of interest to some, but the 
base H.350 architecture is not intended to cover the depth of that 
subject, as you correctly point out. To accomplish this in the real 
world would require extension of the object classes, or the use of 
another protocol.

You are correct that for the bulk of SIP applications, only a few of 
these attributes would normally be needed. In particular 
SIPIdentitySIPURI, SIPIdentityUserName, and SIPIdentityPassword. From 
SIPIdentitySIPURI (AOR) white pages can be built, and a user agent can 
determine its registrar using DNS (as you point out). A proxy can access 
SIPIdentityUserName and SIPIdentityPassword to achieve vendor neutrality 
with respect to identity.

The other attributes are there for trivial cases, which I would not 
expect to be used that often. For example, SIPIdentityAddress is 
intended for user agents that are connecting without the benefit of a 
proxy, i.e. dialing directly by IP address (not a common scenario). 
SIPIdentityProxyAddress could be used by user agents that don't support 
the SRV lookup. Sometimes, this information can be used not as a 
provisioning tool, but as a guide for end users, to create web pages 
that assist users in configuring endpoints. For example, a user may have 
access a web interface to ask 'What do I type in my endpoint 
configurations where it asks for proxy address?' Having this information 
in the directory can be an aid to service administrators in creating 
these kinds of tools.

SIPIdentityServiceLevel can be used by service administrators to group 
users (or user agents) into categories based on what services they are 
allowed to access, or other categories deemed useful to the service 
administrator.

---

From: "Christian Stredicke" <[email-masked]>
Date: Sun, 30 Nov 2003 14:39:31 +0100

Hi!

The problems that I have with LDAP are the following:

- The "lightweight" in LDAP is a euphemism. Implementing LDAP is like
implementing NFS or and other full blown file system. If you have 128 MB
main memory and COM objects it's probably a piece of cake. For an
embedded user agent is unsuitable. Not to mention ASN.1.

- I would like to stay with a simple SIP message exchange. We are
fighting very hard to get SIP through firewalls and people don’t want to
open other ports for LDAP for address book lookup (maybe a tunneling of
the lookup string could be an alternative).

- I am missing call list integration in the LDAP concept. Having an
address book is nice, but customers want to use their last calls as well
(number guessing). I don’t see how that can be achieved with LDAP.

I would prefer a mechanism that looks like this:

GET number_guessing?user=123%40abc.org&number=co&max_hits=3 HTTP/1.1
Accept: application/number-guessing

HTTP/1.1 200 Ok
Content-Type: application/number-guessing
Content-Length: 35

<sip:[email-masked]>
<sip:[email-masked]>

Works fine and eats very little additional code if you already have a
web client. The web server can be written for example with PHP as a
student half-time semester task.

Christian

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von
> Dean Willis
> Gesendet: Montag, 24. November 2003 19:32
> An: [email-masked]
> Cc: [email-masked]
> Betreff: [Sipping] ITU H.350-related Directory Services Internet Draft
> 
>

---

From: Tyler Johnson <[email-masked]>
Date: Sun, 30 Nov 2003 11:39:56 -0500

Christian,

I think what you propose is reasonable. A number of vendors with 
embedded systems have also considered using a non-LDAP approach to 
getting address information into the endpoint. This is because they 
either don't want the footprint/cost of adding LDAP to an embedded 
device, or they already have a proprietary way of communicating address 
book information from a management system into endpoints. In these 
cases, the approach I have seen folks investigate is having the 
management system (usually a more robust server) do H.350 lookups on 
behalf of the endpoints, and then transmit that information to the 
endpoints using a lightweight (no pun intended) or proprietary method.

While LDAP *can* be implemented on the endpoint (and is already in some 
cases), the goal of H.350 is more about how the enterprise stores, 
manages, and protects its master data store of endpoint information.

In general, I would say that it is much more desirable that a registrar 
be able to interface with an enterprise identity service, than an 
endpoint. At the last Internet2 meeting, we showed an H.350-enabled 
proxy by HCL handling calls for a variety of SIP user agents that had 
absolutely no knowledge of H.350. That the endpoints address and 
authentication information was being managed behind the scenes in 
accordance with enterprise policy, yet required no modification to the 
endpoint, was nice to see.

Cheers,
Tyler

Christian Stredicke wrote:
>>If you are interested in integrating directory services with SIP,
> 
> please
> 
>>review:
>>
>>
>

---

From: "Christian Stredicke" <[email-masked]>
Date: Sun, 30 Nov 2003 21:02:02 +0100

Hi Tyler,

I think that is a very good point! The proxy *has* the MB and can act as
an agent for the endpoint. So using H.350 is an option for the proxy or
whatever device needs to access the centralized data in a standardized
way.

Thanks, CS

von
> Tyler Johnson
> Gesendet: Sonntag, 30. November 2003 17:40
> Cc: [email-masked]
> Betreff: Re: AW: [Sipping] ITU H.350-related Directory Services
Internet
> Draft

---

From: Richard Shockey <[email-masked]>
Date: Sun, 30 Nov 2003 15:54:42 -0500

>In general, I would say that it is much more desirable that a registrar be 
>able to interface with an enterprise identity service, than an endpoint. 
>At the last Internet2 meeting, we showed an H.350-enabled proxy by HCL 
>handling calls for a variety of SIP user agents that had absolutely no 
>knowledge of H.350. That the endpoints address and authentication 
>information was being managed behind the scenes in accordance with 
>enterprise policy, yet required no modification to the endpoint, was nice 
>to see.

so how do you plan on solving the Inter-domain issues?

>>- The "lightweight" in LDAP is a euphemism.

more like oxymoron

>>Implementing LDAP is like

amen ..whenever anyone asks me  "Why SIP?" I instantly answer .."Its ASCII 
<fill in the blank>"

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<