Subject: [Enum] Using ENUM for SIP Applications

From: Kevin McCandless <[email-masked]>
Date: Fri, 15 Feb 2002 08:21:57 -0800

Comments on "Using ENUM for SIP Applications"
4.4 Provisioning multiple NAPTR records ENUM records are not designed to be
updated in real time, 
and therefore ENUM is not a good mechanism for managing particular devices.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Comment:  This makes an assumption oh how ENUM will be deployed.  There is
no reason that ENUM
could not be updated by a user in real time and the zone files updated more
frequency then the usual 24 hours.  
There has been discussion of zone file updates as often as every fifteen
minutes.  Lets leave the provisioning of NAPTR 
records to the market place to decide how real time the records can be.
5. Processing ENUM records 
Ideally, the recommendations above for authoring NAPTR records will be
followed to the letter; each NAPTR
 record set will contain a SIP URI (and if possible nothing else).   
Comment:  Once again we are making the assumption for the market place.
ENUM is not just for SIP.  
ENUM can be a DNS directory service.  It could easily contain, in the
correct format, all of the usual contact information
that is listed on a business card.

 Cheers!

Kevin McCandless 
Senior Network Planner 
Illuminet (A VeriSign Company)
913-814-6397 
[email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 18 Feb 2002 13:15:14 -0600

Thanks for your comments, Mr. Walter. A few notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Robert H. Walter [mailto:[email-masked]]
> Sent: Monday, February 18, 2002 9:21 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: RE: [Enum] Using ENUM for SIP Applications
> 
[snip]
> This approach simply moves the "awkward and slow mechanism" of selecting
the
> appropriate communications service into the SIP protocol or limits the
> ability of SIP to support multiple service providers for a single
telephone
> number.

Yes, it does move this mechanism back into SIP. I do not believe that doing
so in any way limits or degrades SIP's abilities. On the contrary, it
reinvests SIP with powers that would be lost if we were attempting to
negotiate capabilities from within ENUM.

> 
> Certainly the requesting application knows the type of communications
session
> it wishes to establish (i.e. Voice, Instant Messaging, etc.) prior to
sending
> the SIP request.  

I do not find this at all certain. In fact, what I see in the SIP/SDP
protocol suite is a system that allows me to express my capabilities to a
target user, and subsequently to negotiate common ways to communicate, one
or more of which will be used in a session.

Those who are looking to paint ENUM in a favorable light for SIP usage must,
I would hope, be aware of the services that SIP/SDP provides. SIP has a user
location system. SIP has a capability negotiation system. These are not
add-ons to SIP, these are the core things that SIP does. It locates a target
user and finds the best way to communicate with them in a session (which is
carried out by some other protocol). Providing rudimentary competition to
these services within ENUM will not improve on the capabilities of a
combined ENUM/SIP system, it will just make it unclear to implementers where
ENUM leaves off and SIP begins. ENUM provides a way to turn E.164 numbers
into URIs, ones that might be used as an input to SIP's process. I'm not
sure why we need to somehow expand ENUM's scope beyond that - I like it just
the way it is.

IMHO, this is really somewhat academic. If the advocates of ENUM insist on a
view of ENUM that mindfully limits the capabilities of SIP, then in the long
term SIP usage will not drive the adoption of ENUM. If on the other hand a
case is made for ENUM that is genuinely beneficial to SIP, then this will be
a win for both the ENUM and SIP camps down the road.

> Bob Walter
> NetNumber, Inc.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Feb 2002 07:53:29 -0600

Interesting questions. Some lengthy notes below. Those interested only in
the conclusions can just read the last paragraph.

Jon Peterson
NeuStar, Inc.

> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Monday, February 18, 2002 12:29 PM
> To: Peterson, Jon
> Cc: [email-masked]'
[snip]
> 
> I only have one input to your text: I think it will be impossible to tell
> people to only have one SIP URI in ENUM. Reason for that is because one
> will probably have access to more than one SIP server (one private and one
> in the office for example) and I bet that some operators refuse to add
> information about the other.
> 

First of all, I agree that we cannot mandate absolutely that authors of
records will place only one SIP URI in ENUM. What we can do, though, is
acknowledge that there are currently two lines of thought on this matter,
show what the strengths and weaknesses are of the two positions and, if
possible, recommend one practice or the other. That is what we set out to do
in the sipping-e164 draft.

Now, I want to be careful here - this is a complicated point. Clearly, users
of SIP can and probably should have multiple identities, just as today we
have multiple identities for email. However, SIP identities (which are
expressed in URIs as addresses-of-record or AoRs) do not have capabilities.
SIP devices (like user agents) have specific capabilities (corresponding to
specific communications services, like, G.711 mu-law audio at 10ms
interval). A device may register under one or more identities, and an
identity may have multiple devices registered under it simultaneously.
However, registration is not a permanent association, and the protocol
effects of a SIP registration should be managed in SIP, not in the DNS.

Complications arise when we begin to postulate that particular service
providers will want to restrict the traditional capabilities of SIP. So for
example, imagine you have have a 'home' identity and a 'work' identity, and
then a SIP device, a wireless phone. SIP traditionally allows devices to
roam between administrative domains: while you're at work, your wireless
phone is registered under your work identity, while at home it registers
under your home identity. But then in some possible administrative models,
as you suggest, user agents might only be able to register in a particular
domain (and consequently under a particular identity). In fact, some
restrictive service providers could create a rigid one-to-one correspondence
between an identity and a single device - however, if they do so, as an
aside I'd like to point out that the value of using a URI (and much of the
value of SIP) is largely lost, and you might as well just use an IPv4
address instead.

All that said, I don't think the fact that users will have multiple SIP
identities in and of itself has much bearing on whether or not a single URI
or multiple URIs should go into ENUM. Differentiating between multiple
identities like 'work' and 'home' in ENUM would be quite difficult; I mean,
we can't use "SIP+E2HOME" and "SIP+E2WORK" to differentiate URIs (where
choosing between service fields requires human oversight). What has been
suggested for differentiation is that the capabilities associated with a URI
should be advertised in the service field (i.e "SIP+E2VOICE") so that a URI
can be programmatically chosen by the querying user agent. But this makes
the assumption that a URI has capabilities, and that's where things get a
little murky for me.

When you want to get in touch with a user with SIP, what's important is that
you can contact the devices at which the user is available. In the example
above, the wireless phone I described can register under both the 'home' and
'work' identity. If the phone is registered under a particular identity, and
that identity receives a call setup request, the phone can ring. Now, this
wireless phone might support voice (with a particular set of low-bandwidth
codecs), instant messaging, and maybe other capabilities. It's only when
such a device is registered with these identities that these identities are
able to participate in any kind of session. This registration automatically
causes changes in the state of a SIP service that will allow appropriate SIP
requests to be routed to the device.

I think it ultimately doesn't really matter, from a capability perspective,
which identity I put into ENUM, provided that the appropriate set of devices
are registered under the identity when someone tries to communicate with it
- I think this is my biggest disconnect with a lot of the arguments I hear
about how ENUM and SIP should work together. In vanilla SIP, nothing
precludes any device from registering under any identity. Ultimately, which
identity I associate with an ENUM record is probably more of a concern about
perception. ENUM records are accessed with a telephone number, and the usage
of that telephone number might suggest something about the identity you
should place in ENUM for SIP. For a work telephone number, a 'work' identity
might be more appropriate than a personal identity that highlights your love
of Star Trek. It also might not be important to you that certain devices are
reachable through certain ENUM records (like my work fax device being
available at the ENUM record corresponding to my home phone number).

But now let's look at the troublesome case in which a user insists on having
all devices associated with all of their identities available through a
single ENUM record. How can this work with the hypothetical restrictive
service provider who creates a rigid one-to-one mapping between a device and
an identity? Say for example that your 'work' identity is associated with a
particular device, an instant messaging client, that could only register
with your 'work' identity - but, some other devices that you use (like your
Quake client) are not allowed to register at your 'work' identity. That
seems to suggest that you need two identities in ENUM in order for all of
your devices to be reachable.

This would only be true if it were impossible to register an identity
beneath another identity. In order to make every device that you control
available through a single URI when some devices have restricted usage, you
could register your 'work' identity under your 'home' identity, and then
treat your home identity as a master AoR which you would then put into ENUM.
All you need are the proper credentials to register devices under your
'home' identity, and the URI of your 'work' identity - it does not require
the administrative domain responsible for your 'work' identity to be
complicit in any way (in fact, there's nothing they can do about it if they
try, probably). Your 'work' identity ostensibly becomes a contact address
for the instant messaging client that it manages; like any other contact
address it can register and deregister from the 'home' identity as needed
over time.

It is important to remember that sometimes (perhaps usually?), SIP services
will be requested without any prior ENUM query, presumably by a caller that
already knows the AoR of the target user. Thus, any service managing an AoR
will always have a way of reaching relevant devices associated with the
requested URI anyway. This suggests strongly to me that any identities and
devices will have to be composed in a SIP service somewhere, regardless of
how we slice up this problem in ENUM. If however we must replicate the
availability of identities/device in SIP and ENUM, the two run the risk of
getting out of sync, management becomes more difficult, and so on. I believe
that it is probably more reasonable to compose services in a single service;
namely in SIP, because (as I argued in a mail yesterday) SIP has deeper
capability negotiation and user location systems. Whether or not using ENUM
service fields to characterize services is 'faster' than what would happen
without the service fields really isn't material - SIP capability
negotiation still needs to take place even when E2VOICE-style service fields
are used, and I don't believe that even registering identities under other
identities will lead to substantial degradation in performance. Further
analysis on this point would probably take another (equally long) email,
though I'd be happy to detail this later if anyone finds my reasoning here
particularly contentious.

But returning to the troublesome cases, what if your 'home' identity doesn't
allow arbitrary registrations either, so you can't register your 'work'
identity under it? Why should I necessarily think that any service providers
will allow arbitrary registrations, or that such services will be commonly
available? Well, I own a couple of SIP devices today, and none of them are
bound inextricably to any particular service, but let's imagine for a moment
that dystopian future.

Ultimately, the answer is that identities in the Internet are not exactly at
a premium. I believe that SIP address-of-record URIs will be free and
plentiful, for the same reasons that email addresses are free and plentiful.
Like the web or email, in order to be a SIP 'service provider' you need
nothing more than a domain, some connectivity and a box; a SIP
registrar/redirect service would be a less intensive venture than, say,
hotmail.com. I believe that it will always be possible to acquire such an
AoR and to register any walled-garden 'home' and 'work' identities beneath
it, and then put this 'master' AoR in ENUM.

So, to sum up, I agree that SIP users can and will have multiple identities.
However, choosing which identity to place in ENUM is, I think, unrelated to
the 'E2VOICE'-style capability negotiation question. Devices register under
identities, and it is devices that have capabilities; registration is a SIP
protocol mechanism, and its effects should be managed in SIP, not in DNS.
Identities are, as you suggested, things like 'work' and 'home'. Although
there may also be identities that are bound by a service provider to a
specific service, these identities can be treated as contact addresses and
composed under other, 'master' identities. I think we can make a good case
that indexing multiple identities by capability in ENUM degrades the
capabilities of SIP. For that reason, I think we can argue that we should
recommend placing only a single SIP URI in an ENUM record.