asterisk users - Feb 2011 - [Zaptel] "numberplan-local" context from nowhere?

Hello

Using Asterisk 1.4.20 and Zaptel 1.4.3-1, I notice that Asterisk sends
FXO calls to a context named "numberplan-local" that is not mentionned
in my configuration file, which prevents incoming calls to be
successfull:

======= /etc/asterisk/zapata.conf =================[trunkgroups]

[channels]
;Send incoming calls to this context in extensions.conf
context=from_fxo

switchtype=national
usecallerid=no
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=no
threewaycalling=yes
transfer=yes
canpark=yes
busydetect=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
immediate=no

signalling = fxs_ks
channel => 1

======= /etc/asterisk/extensions.conf =================[general]
writeprotect = yes
autofallthrough=yes
...
[from_fxo]
;Context set in zapata.conf
exten => s,1,Verbose(In fxo)

======= Console: zap show channels =================   Chan Extension  Context  
Language   MOH Interpret
 pseudo            numberplan-loca            default
      1            numberplan-loca            default

======= Console: incoming call on FXO =================    -- Starting simple
switch on 'Zap/1-1'
  == Starting Zap/1-1 at numberplan-local,s,1 failed so falling back
to exten 's'
  == Starting Zap/1-1 at numberplan-local,s,1 still failed so falling
back to context 'default'
[Jan  1 01:06:08] WARNING[628]: pbx.c:2483 __ast_pbx_run: Channel
'Zap/1-1' sent into invalid extension 's' in context
'default', but no
invalid handler
    -- Hungup 'Zap/1-1'
========================================================
Has someone seen this before and knows why Asterisk comes up with that
"numberplan-local" context?

Thank you.

On Sat, 12 Feb 2011 10:14:42 +0100, Gilles <codecomplete at free.fr>
wrote:
>Using Asterisk 1.4.20 and Zaptel 1.4.3-1, I notice that Asterisk sends
>FXO calls to a context named "numberplan-local" that is not
mentionned
>in my configuration file, which prevents incoming calls to be
>successfull:
Found what it was: This context was used in the samples, and I missed
user.conf. Renaming this file and rebooting the host solved the
problem.