Subject: [Enum] The use of "service type" and "subtype" fieldsin ENUM record

From: "chenhui" <[email-masked]>
Date: Mon, 16 Jan 2006 18:19:13 +0800

Hi all,

We are considering how to implement ENUM resolver into current communication clients or service systems.

Now most of current communication applications do not support ENUM resolution, although ENUM records can be retieved by "nslookup" or "dig" query "NAPTR" resource records, different clients or service systems can not support all returned results. That is, some records are useless for specific services. Also, too many useless records will affect service performance.

Using filter is a useful method to resolve this problem. To use "service type" and "subtype", only valuable results can be returned. 

But, we are not sure how can make the ENUM resolver works more reasonable. Because exact "service type" and "subtype" will filter many results, including of old "service type". For example, there is an ENUM number having NAPTR records of "E2U+email:mailto", "E2U+sms:mailto", and "E2U+ems:mailto", if the filter is "E2U+sms:mailto", it just returns NAPTR records with exact "service type" and "subtype". Or if there is no any corresponding record, this call will be failed. Too much failure will affect service performance.

Another way is to support not exact filter, like only by "subtype". The ENUM resolver can return all relative records of "E2U+email:mailto", "E2U+sms:mailto", and "E2U+ems:mailto". Application clients or service systems can automatically choose its perferred results. However, this may introduce more service delay.

What is the best way? Do you have any suggestion on this problem?

BTW, We find that IANA has published ENUM services on Jan 10th,2006. The webpage is http://www.iana.org/assignments/enum-services
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Mon, 16 Jan 2006 11:36:34 +0000

Hi there,
  filter design depends on what you want to do. If the ENUM client is  
in a
voice gateway, then it's fairly simple.

NOTE: The following is just an "Implementation description". There are
many ways one could process the NAPTRs - this is just the way WE did it
in the U.K. trials.

----

In our systems, we used the "simple" pattern matching scheme  
mentioned in
the "Experiences" draft to handle both RFC2916-style and RFC3261- 
style NAPTRs.
[Tokenise services field on '+' character, expect (and remove) token  
"E2U",
then process the rest].

If the client has communication systems that can provide a given  
teleservice
(like voice) then that will be included in the filter - IMHO, this  
must be
more flexible that an explicit string match against "voice:tel".

We sub-tokenised each Enumservice on ':' character, "cheated" by  
creating a
protocol sub-token for those Enumservices where it is implicit (H323,  
SIP) and
re-wrote the RFC2916-style "ldap" and "mailto" services into  
"ldap:ldap" and
"email:mailto", then pattern matched the generated list of "published  
services"
against the capabilities of the client.

Our clients could handle voice, so we matched against {voice:tel,  
sip:sip}
(and voice:sip, as we were using TS 102 172 as well as the IETF/IANA  
services).

For messaging, we matched against {{email:mailto, sms:mailto,  
mms:mailto,
ems:mailto} and {sms:tel, mms:tel, ems:tel} and {fax:tel}}, which  
triggered
one of three external communications programs - we did not have a  
program
to support ifax:mailto, so just pattern matching against {*:mailto}  
would
not work.
For mobile clients with no email, SIP or fax support, we just matched  
against
{voice:tel} and {sms:tel, mms:tel, ems:tel} to run the voice or text  
features
of the phone.

This worked well, but as you say it does require some processing to  
get NAPTRs
and their services field into a single list of "all teleservices  
supported".
The capabilities of the client devices was fixed so we could have  
"hard wired"
the "local support" match lists - however, we wanted the user to be  
able to
"switch off" sending an SMS/MMS/EMS message - this just consisted of  
removing
those items {sms:tel,mms:tel, ems:tel} from the "locally supported"  
list.
----
To summarise the steps:
-  process the NAPTRs to generate one list of "published services" of  
the form
    <teleservice>:<protocol>

-  match this against a list of "locally supported services", ordered  
according
    to the user's choice (e.g. voice first, then message using  
mailto, then
    SMS/MMS/EMS message, then fax)

-  generate a list of "successful" matches, with a pointer to the  
NAPTR(s)
    that held the service and to the local program that needs to be run.
----
As a final note - we kept a "winning list" rather than a single  
answer so
that, if the first choice failed, the ENUM client could try the next  
without
re-processing. This worked as the TTLs on the NAPTRs were a few minutes
- if the NAPTRs had very short TTLs (e.g. 1 second), this would not have
been valid.

I hope this helps,
   Lawrence

On 16 Jan 2006, at 10:19, chenhui wrote:
> Hi all,
>
> We are considering how to implement ENUM resolver into current  
> communication clients or service systems.
>
> Now most of current communication applications do not support ENUM  
> resolution, although ENUM records can be retieved by "nslookup" or  
> "dig" query "NAPTR" resource records, different clients or service  
> systems can not support all returned results. That is, some records  
> are useless for specific services. Also, too many useless records  
> will affect service performance.
>
> Using filter is a useful method to resolve this problem. To use  
> "service type" and "subtype", only valuable results can be returned.
>
> But, we are not sure how can make the ENUM resolver works more  
> reasonable. Because exact "service type" and "subtype" will filter  
> many results, including of old "service type". For example, there  
> is an ENUM number having NAPTR records of "E2U+email:mailto", "E2U 
> +sms:mailto", and "E2U+ems:mailto", if the filter is "E2U 
> +sms:mailto", it just returns NAPTR records with exact "service  
> type" and "subtype". Or if there is no any corresponding record,  
> this call will be failed. Too much failure will affect service  
> performance.
>
> Another way is to support not exact filter, like only by "subtype".  
> The ENUM resolver can return all relative records of "E2U 
> +email:mailto", "E2U+sms:mailto", and "E2U+ems:mailto". Application  
> clients or service systems can automatically choose its perferred  
> results. However, this may introduce more service delay.
>
> BTW, We find that IANA has published ENUM services on Jan 10th, 
> 2006. The webpage is http://www.iana.org/assignments/enum-services