[asterisk-dev] Working in useful examples... and freenum/e.164 dialing in extensions.conf.example

[John Todd]

On Dec 16, 2009, at 8:22 AM, Klaus Darilion wrote:

> Philip A. Prindeville schrieb:
>> I've recently decided to spend idle cycles while waiting for various
>> Astlinux platform builds to complete on making the contents of
>> asterisk/config a little more complete, a little more useful, a
>> little more real-world...
>>
>> I started looking at the possibility of taking JTodd's ISN Freenum
>> cookbook example and updating it:
>>
>> http://freenum.org/cookbook/#ASTERISK_CONFIG
>>
>> but ran into some problems having to do with the following:  we use
>> SIP handsets in house, and those operate in the redfish-solutions.com
>> domain... but anonymous SIP (freenum) calls coming in off the
>> internet would also be in the same domain.  I can't figure out how to
>> separate calls in the same domain (but from different endpoints) in
>> two different contexts.
>
> Are you using different contexts? Usually, for your local attached SIP
> handsets, you have in sip.conf one peer/friend definition per SIP
> device, and use the context= option to handle calls from these  
> devices.
>
> Further, the sip.conf has a context defined in the general section -
> this one will be used for the unauthenticated incoming ENUM calls:
>
> e.g. sip.conf:
> [general]
> context=fromInternet
> ...
> [ext001]
> type=peer
> context=fromLocalSipPhone
> ...
> [ext002]
> type=peer
> context=fromLocalSipPhone
> ...
>
> then in extensions.conf you have (pseudo-code):
>
> [toPstn]
> exten => 00........Dial(DAHDI.....)
>
> [toLocalSipPhones]
> exten => 001,1,Dial(SIP/ext001)
> exten => 002,1,Dial(SIP/ext002)
>
> [fromLocalSipPhone]
> include => toPstn
> include => toLocalSipPhones
>
> [fromInternet]
> include => toLocalSipPhones
>
>
> regards
> klaus
>
>
>> And unfortunately, doc/ doesn't cover sip.conf, nor does the Asterisk
>> Reference Manual cover it in much detail... except for a couple of
>> related topics (shared line appearances and dahdi integration, I
>> think).
>>
>> So if anyone can contact me and work off-line on getting a reasonably
>> useful and real-world applicable example working, I'll file a
>> documentation defect and push for getting this checked in (as I did
>> for a few other examples).
>>
>> Thanks,
>>
>> -Philip


Philip, Klaus -
   Bringing in "anonymous" SIP calls into the dialplan is somewhat  
challenging if you need to know from where they're originating.  One  
solution I have seen for this is to differentiate based on the SIP  
identity that is dialed.  The beauty of the ISN (aka: Freenum) dialing  
method is that it uses the basics of ENUM, which include the ability  
to create a regular expression that ultimately is what is passed to  
the far-end receiver of a call request.

   For instance, if your ISN is 1234*256, and you have this regular  
expression as the wildcard for your ITAD 256 in the freenum.org tables:

   !^\\+*([^\\*]*)!sip:\\1 at loligo.com!

   ....then the final resulting URI that the REMOTE server would use  
would be sip:1234 at loligo.com.

Now, I've seen some people who have modified their regular expressions  
a bit so that they put a "prefix" in front of all of the SIP URIs that  
are formed by remote servers in the case of Freenum/ISN lookups, in  
order to differentiate where their calls are coming from.  They create  
something like this for their NAPTR regular expression in the  
Freenum.org wildcard table for their ITAD, or in their own DNS if  
they're delegating the zone to themselves:

   !^\\+*([^\\*]*)!sip:\\1-freenum at loligo.com!

...which for the ISN of 1234*256 would create a SIP URI of sip:1234-freenum at loligo.com 
.  At that point, all of the anonymous SIP calls are received by the  
loligo.com server (for both Freenum/ISN as well as normal SIP URI  
calls) and _all_ of those calls go to a single context.   Within that  
context, string-matching is trivially used to chop up the ${EXTEN} and  
then perform actions and re-route the calls to different places within  
the dialplan.  Here's an example:


[anonymous-sip]
; Do something with the full strings that contain "-freenum" as a  
suffix with
; four-digit numeric prefixes.
;
exten => _XXXX-freenum,1,Echo(Freenum.org call received!)
;
; Now, take only the first four digits of the ${EXTEN}, stripping off
; the "-freenum" suffix, and pass the call to my main context.
;
exten => _XXXX-freenum,n,Goto(my-main-context,1,${EXTEN:0:4})
;
;
exten => _XXXX,1,Echo(Normal four-digit call received!)
exten => _XXXX,n,Goto(my-main-context,1,${EXTEN})
;
; end

Also, see ITADs 674 and 260 for slightly different further examples.  
(dig @anyns.pch.net NAPTR 4.3.2.1.674.freenum.org)

Now, to kind of swing this back around to a -dev question instead of  
just a -users question (or even a question more appropriate for the  
Freenum/ISN mailing list (isn-discuss-request at freenum.org)) let's see  
what we should do for examples.   Should a more full-fledged Freenum  
example set exist in the sip.conf file and in extensions.conf?  I'm  
uncertain that most people actually want to differentiate between  
normal inbound numeric SIP URI dialing and Freenum.org-originated  
dialing, so this doesn't seem like much of a win in either place.   
There is a strong disincentive to turn OFF anonymous SIP dialing as  
the default, since apparently that is too sharp a knife to offer to  
new users who may not quite know the implications if including  
contexts into their anonymous inbound SIP contexts.  So is a better  
example warranted on the Asterisk configurations, or is this really  
something I should put on my freenum.org hat for and get off my  
comfortable chair and get better examples on the dusty freenum.org site?

JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/