Re: questions
- Date: Tue, 25 Nov 2003 01:47:52 +0000
>>>>> "Amelia" == Amelia Effendi s9912645@localhost writes:
Amelia> Hi all, i wish to ask some simple question on ENUM that i
Amelia> should manage to answer but i didn't :(
You seem very confused. ENUM is a protocol for mapping E.164 telephone
numbers into domain names. That's all. The domain names resulting from
that mapping can be looked up in the DNS. The answers from the DNS
should (but don't have to be) a set of NAPTR records which describe
how to contact that user in a variety of ways. These needn't
necessarily be for telephony-like services such as the details of
someone's chosen SIP server or IP address of their VoIP phone. NAPTR
records could provide someone's email address or details of their web
server or...
Amelia> so here goes: 1. for PSTN users to be able to contact
Amelia> others that ENUM enabled, is that mean you have to be
Amelia> connected to the internet beforehand? what happen if it
Amelia> is a dial up internet, then you can't use normal phone.
No. It makes no difference whether someone/something that's "ENUM
enabled" is connected to the internet or not. Though it's kind of
difficult to lookup domain names or manipulate NAPTR records without
internet connectivity. :-) If you were on a dial-up line and were ENUM
enabled, you might change your SRV records so that any tel: URIs for
your E.164 number pointed to some voicemail service. That way,
incoming calls from ENUM-aware applications would get diverted
elsewhere when your phone line was busy. It simply doesn't matter
whether the line is busy because you're talking to your mother or
because your modem is talking to your ISP. The NAPTR records would say
"here's where to go when the line is busy" and the ENUM-aware
applications would do whatever those NAPTR records told them to do.
Now suppose you're ENUM enabled and I'm on the PSTN. My phone doesn't
do ENUM lookups. So all I can get when I call you is the conventional
telephone service. And I get that whether you're ENUM enabled or not.
ENUM is not about phone service per se, though it can certainly be
used for that and is an enabler for integrated messaging solutions as
well as other new, smarter telephony services. All that matters is
that users have sane DNS entries under e164.arpa for the E.164 numbers
they own. Those E.164 numbers don't have to be bound to conventional
telephone service. They usually are these days because almost everyone
gets their E.164 numbers from a phone company. This is changing.
Amelia> 2. the same question if you are using mobile phone, is
Amelia> that mean you have to connect to internet beforehand?
No. See my previous answer.
Amelia> 3. what happen when ENUM enabled application want to
Amelia> contact non ENUM enabled application, or vice versa?
The same way as any other applications that need to talk to each
other. They find some way to rendezvous and exchange data. This is
usually by doing some sort of name to address lookup in the DNS,
establishing a connection and speaking some mutually agreed
application-level protocol like SIP or SMTP or HTTP.
This is how things like web browsing and email works on the internet
today. It'll be no different for stuff that's ENUM-aware. The
applications involved in those activities don't need to know or care
about any extra features or capabilities that might be in the thing at
the other end of the connection. Like perhaps being ENUM-aware. All
that matters is both parties comply with the appropriate protocol(s)
for that application: for instance HTTP in the case of browsing and
serving web pages.
My hypothetical ENUM-aware application could do an ENUM lookup of your
E.164 number and find your NAPTR records say you're only reachable by
SMTP, the email transfer protocol. Or they say try SMTP whenever your
phone line is busy. Fine. So my application sends you email (if it's
smart enough to do that) and doesn't care whether your SMTP server --
the application at your end -- is ENUM-aware or not. As long as both
applications speak SMTP properly to each other, everything is fine and
my email to you just works. In fact, there's no way for either party
to find out if the other is ENUM-capable or not. Not that this matters
because by the time the SMTP connection is established, any ENUM
involvement would have been over and done with. In this example ENUM
was just a means to an end. It was a way of finding out how you can be
reached right now and by what services and how to contact the things
which provide those services. The application at your end doesn't care
or need to know how my application found out how to reach it. How do
you or your mail system know how I sent this mail to you? Did I just
hit the reply key or pick your name out my address book or look you up
in some LDAP database? Does it matter?
Where things could get interesting is with stuff like caller-ID and
telephony-like applications. If someone uses VoIP to talk to a SIP
gateway that then makes a call on the PSTN, what identifies the
original caller? Will it be the IP address of whatever made the VoIP
"call" or the E.164 number of the SIP gateway? What are the
implications of providing one or other or both of these? Is an IP
address meaningful to conventional telephone systems? And vice
versa... These questions are of course largely orthogonal to ENUM.
