[Home]

Summary:ASTERISK-01696: [patch] ENUM support for ifax:mailto
Reporter:otmar (otmar)Labels:
Date Opened:2004-05-26 10:43:33Date Closed:2011-06-07 14:05:27
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_enumlookup.c.diff
( 1) app_enumquery.c
( 2) app_rxfax.c.diff
( 3) enum.c.diff
( 4) mailfax
( 5) patch_enum.c.txt
( 6) README.txt
Description:This set of patches enables asterisk to act as an ENUM compliant FAX gateway. On ENUM records with service type ifax:mailto, the FAX call is converted to email.

****** ADDITIONAL INFORMATION ******

Michael asked me to submit these patches for him.

Consider them disclaimed.
Comments:By: Olle Johansson (oej) 2004-05-27 04:32:19

Moving this to experimental features, since rxfax is not part of Asterisk cvs.

Could you please point me to more information regarding ifax:mailto? I'm curious, sounds like a userful solution.
By: Olle Johansson (oej) 2004-05-27 04:35:01

A big question is if we should continue inventing priority+something for every enum type... At some point, we need to solve this in another way, so let's try now. Any suggestions?
By: Mark Spencer (markster) 2004-05-31 22:38:34

Actually, i'm not really that opposed to this concept, although it might be handy to have a macro that would break it down by name:

[macro-enumexten]
exten => s,1,ENUMLookup(${MACRO_EXTEN})
.
.
.
exten => tel,1,...
exten => ifax,1,....

Is there some standards reference for this I can use to reference putting it in?
By: John Todd (jtodd) 2004-06-01 02:53:00

The Short Answer:

Well, this is opening a large can of worms.  I agree that the ENUM responses we have within Asterisk will quickly become a total jumble if we continue to use the kludge of number-based (+51, +100, whatever) responses based on various URI response-types.  Having a string-based reply would be much, much cleaner.  

To answer the problem with the minimum amount of information you asked for, the list of possible return URI-types is as long as there are URI types.  There is an IANA document that lists these type of URI types:

 http://www.iana.org/assignments/uri-schemes

I'll note that IAX2 isn't on that list, but it seems that would require an RFC.  Doesn't really matter that much, anyway if other people are just rejecting it if they don't know what it is...

I'm in favor (for the short term) of having ENUMLookup return not just ${ENUM}, but make an easy-to-parse value called ${ENUM-TECH} or something similar, which holds the service-type of the reply (h323, sip, ifax-mailto, iax2, whatever.)  No errors should be produced except in the case of a lookup failure.  The +51 jump now on "tel:" response seems a bit strange, since why should that be treated any differently?  If we could get the service-type delivered in an easy-to-digest variable reply from ENUMLookup, then simple chains of GotoIf statements can be used to match those service-types we know how to handle.  I could almost do this today with an additional step of parsing out the service-type out of the ${ENUM} variable, but that's ugly, and I'd still be stuck with the unpredictable jump to +51 on a "tel:" answer that I'd have to hotwire back into the dialplan.  Yuck.

So, to extend and modify Mark's hypothetical diaplan that he included above:

; Error-checking and loop detection removed from macro for simplicity of
;  description
;
[macro-enumexten]
exten => s,1,ENUMLookup(${MACRO_EXTEN})
exten => s,2,Goto(${ENUM-TECH},1)
;
; The ENUMLookup failed, so jump to the "normal" telephone handling
;  area...
;
exten => s,102,Goto(tel,1)
;
;
exten => tel,1,Dial(Zap/g1/${MACRO_EXTEN},20)
exten => tel,2,Hangup
;
;
exten => ifax-mailto,1,....
;
exten => iax2,1,Dial(${ENUM},40)
exten => iax2,2,Hangup



The Long Answer (doesn't deal with this ticket, but worth reading):

ENUM replies back with order and preference lists.  While we normally only see one type of reply to a query, since we are in our infancy in ENUM, it is the case that we as "good netizens" should be figuring out how to correctly parse ENUM replies that are more complex than the most simple, single-answer return.

ENUM can reply back with a large number of URI types.  There is the concept of "order" and "preference".  Let me tiringly paraphrase from RFC2915:

"
  Order
     A number specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules.  Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order.

  Preference
     A number that specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers.  This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols.  A client MAY look at records with higher preference values if it has a good reason to do so such as not understanding the preferred protocol or service.

     The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences.  I.e., Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
"

This implies an array that is passed back to the dialplan, containing the results of the ENUM lookup.  Somehow, either the dialplan or the ENUMLookup application needs to:

 1) determine what service type responses "match" the request (i.e. discard "mailto:" URI's, since we're a telephony server, or discard h323 responses if we don't have h323 loaded, or whatever the situation requires based on the media capabilities of the call)
 2) put all of the valid responses in a list, including URI types, to be processed by the dialplan in some future statements

Honoring Order and Preference is going to be a whopper of a problems.


References:

NAPTR record format:
  http://www.faqs.org/rfcs/rfc2915.html

General URI syntax:
  http://www.faqs.org/rfcs/rfc2396.html

E.164 number and DNS http://www.faqs.org/rfcs/rfc2916.html
By: khb (khb) 2004-06-03 00:14:01

I basically agree with Jtodd,
I've been experimenting with this and have been using a new enumquery application that drops the priority gotos and instead returns the following macros to the dialplan:

ENUM as before, for compatibility
ENUMTECH just the technology string
ENUMURI the entire URI
ENUMDEST just the destination string
ENUMNUM  just the extension of the destination
ENUMDOMAIN just the domain portion of the URI

Here is an example from my log files querying someone's e164.arpa entry (the FWD number in the results has been changed) displaying the strings with NOOPs

-- Executing NoOp("SIP10/2200-385d", "ENUM=SIP10/240123@fwd.pulver.com") in new stack
-- Executing NoOp("SIP10/2200-385d", "ENUMTECH=SIP10") in new stack
-- Executing NoOp("SIP10/2200-385d", "ENUMDEST=240123@fwd.pulver.com") in new stack
-- Executing NoOp("SIP10/2200-385d", "ENUMURI=sip:240123@fwd.pulver.com") in new stack
-- Executing NoOp("SIP10/2200-385d", "ENUMNUM=240123") in new stack
-- Executing NoOp("SIP10/2200-385d", "ENUMDOMAIN=fwd.pulver.com") in new stack


This driver also requires a change to enum.c eliminating the type specific parsing of the E2U identifier and simply removes the (+)E2U(+) part and returns the rest to the application. I don't think the generic query module in Asterisk main should know such specifics, but simply pass them on to further handing by applications.
Further, in the driver configuration file you can map any URI type to a custom driver name, as can be done for H323 in the old application.
The issue I have only begun to work on is how to handle the multiple URI types that a query can and will return.  Some servers now even duplicate each type by doing "E2U+sip" as well as "sip+E2U"  since the standard has been changed from the original RFC.
My first approach to this issue will likely be to simply take the highest priority URI from the query that matches a technology available in Asterisk or that is specified as an argument to the application invocation: EnumQuery(${EXTEN},${PREFERRED_TECH})

edited on: 06-02-04 23:16
By: khb (khb) 2004-06-03 01:39:55

Attached my files for jtodd, or anyone, who wants to play with it

app_enumquery.c (7,613 bytes) 06-03-04 01:37
patch_enum.c.txt (1,890 bytes) 06-03-04 01:38
By: twisted (twisted) 2004-07-13 11:40:55

Any status updates here?  This has been open for a month with no activity now.
By: Brian West (bkw918) 2004-07-17 18:28:08

Good idea but lets work on it and get the fax stuff working better.

bkw