Subject: RE: [Enum] Using ENUM for SIP Applications

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 16 Feb 2002 01:21:26 -0600

Hi Kevin, thanks for your comments. Let me just say to start with that
obviously we didn't base our notes on any anticipated operational model from
the fora - we just read the standards and tried to figure out the best way
to apply them. While I don't doubt that ENUM could be adopted to various
requirements it doesn't satisfy today, I'd like to believe that it is a
complete and specific tool, because even in its current incarnation I find
it quite serviceable.

To your first point, although I'm no DNS expert, I think that when I say
ENUM isn't designed to be 'real time', there's more to it than just how
often records are updated. For example:

- The SIP protocol has rules for evaluating a set of registrations and
handling requests in a location service - this is comparable to ENUM, it's
true. But SIP also has a whole method (REGISTER) for allowing an endpoint,
like an IP phone, to authenticate itself to a location service,
add/delete/modify contacts for itself or third parties as authorized, and so
forth. While there are dynamic protocols I've read about for updating DNS, I
don't think these are oriented towards this sort of end-user device
registration.

- SIP registrations all have an expiration interval after which they will be
removed by a location service. Expiration intervals can be brief, so that
effectively if a device fails it will automatically and promptly cease to be
registered for that identity. The language in the spec says that
registration intervals should be allowed to be as short as possible without
degrading registrar performance (which in many useful architectures could be
very brief indeed). Moreover it suggests a very different model for data
than one usually ascribes to DNS - one in which records themselves (as
opposed to caches) grow stale if not refreshed and purge themselves.

To your second point, we aren't making any sort of normative statement in
that sentence - it's a slightly tongue in cheek way of saying that the
selection of a NAPTR record is significantly easier if only one record is
present. In several places in the document, including the authoring section,
we discuss the use of ENUM for HTTP, SMTP, tel URLs, and so on.

That much said, though, I think there is a case to be made that ENUM is
especially useful for SIP. After all, ENUM is a technology that turns E.164
telephone numbers into URIs; it seems logical that it would have some
applicability to a protocol commonly used for Internet telephony that
expresses identities with URIs (neither HTTP nor SMTP meet both of those
stipulations). Another common use of telephone numbers is SMS - which is met
by SIP with SIMPLE. There's even been some SIP for fax work. I suppose VPIM
can also claim good applicability, but it would be tough to beat SIP's
match. Suffice it to say that I for one believe it will be SIP applications
that drive ENUM adoption.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Kevin McCandless [mailto:[email-masked]]
Sent: Friday, February 15, 2002 8:22 AM
To: [email-masked]'
Subject: [Enum] Using ENUM for SIP Applications

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. 

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
informationthat is listed on a business card.

 Cheers!

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Feb 2002 16:10:23 +0100

--On 2002-02-16 01.21 -0600 "Peterson, Jon" <[email-masked]>
wrote:

> especially useful for SIP. After all, ENUM is a technology that turns
> E.164 telephone numbers into URIs

Bingo!

I think it is important to know that this, and only this, is what ENUM does.

Given the requirements to converge towards a service identifier when doing
lookups in various systems, it is important that one do each lookup "fast"
and go to the next system needed. Or, the time a call setup takes does not
have an upper bound.

I.e. I try to explain that ENUM is a meta-signalling mechanism which is
used _before_ the traditional mechanisms are used. It is not a replacement
for anything done today.

ENUM do only one thing, turn an E.164 to a set of prioritized URIs. The
URIs in turn of course will be a selection of protocol, endpoint identifier
and other things a URI can help with.

But, still, I don't see any competition between SIP and ENUM.

Finding most efficient recommended way of using ENUM and SIP together is
one thing. Arguing about "competition" between SIP and ENUM is another.

So, as I wrote in my message about what documents I think are needed,
registrations of flag fields are needed. And, the registration for SIP has
to talk about how to handle this.

Should for example the flag in the NAPTR record differ between a SIP URI
used for presence and one used for gaming and one used for voice calls?

That MUST be resolved, I would say, before the registration document for
SIP-related flags is finished.

   paf