[asterisk-dev] unexpected behavior between chan_sip and chan_iax2 configuration files

[Tilghman Lesher]

On Wednesday, September 07, 2011 09:24:16 PM Tilghman Lesher wrote:
> On Wednesday, September 07, 2011 06:02:52 PM Paul Belanger wrote:
> > On 11-09-03 05:47 PM, Tilghman Lesher wrote:
> > > On Saturday, September 03, 2011 12:58:57 PM Paul Belanger wrote:
> > >> My question is, does chan_iax2 actually support binding to
> > >> multiple interfaces? Making it different then chan_sip or should
> > >> the binding happen like chan_sip, after parsing the complete
> > >> configuration file?
> > > 
> > > It does, but not in the way that you might expect.  It only
> > > supports setting a particular peer's sourceaddress in the peer
> > > definition to one of the alternate bind addresses.  If a packet
> > > is received on the "wrong" socket, the connection will likely
> > > not work correctly, because IAX depends upon receiving a
> > > response from the same IP as to which it sent the original
> > > packet.
> > 
> > Thanks for the information, personally I don't like it but I'll
> > have to live with it.
> > 
> > However, since I am on the topic of 'overwriting' settings in a
> > configuration file, is the following example in asterisk supported?
> > 
> > foo.conf
> > ---
> > bar = yes
> > bob = smith
> > bar = no
> > 
> > I would assume bar is 'no', am I correct in thinking this is how
> > configuration files should work?  Excluding the original example
> > with bindaddr and chan_iax2.
> 
> No, the configuration file, after being parsed, will contain two
> entries, one with yes and one with no, separated by another entry
> named bob. It's up to the particular module to determine what to do
> with these values.  Consider another example:
> 
> iax.conf
> ---
> disallow=all
> allow=ulaw
> allow=gsm
> 
> Now, to repeat your question back to you, is allow in the
> configuration file ulaw or gsm?  It's both, right?

Just to reiterate the point that context matters, let's look at the
general context in queues.conf, a nice standard module, and we'll look
at the very first declaration in the sample file:

queues.conf
---
[general]
persistentmembers=yes
persistentmembers=no

This is a field that has a single global value; it isn't a tricky set
like allow, disallow, permit, and deny.  You would think that once this
configuration file was parsed, that persistentmembers would have the
value "no".  But you'd be wrong.  The problem here is that app_queue
doesn't iterate over the entire list of variables retrieved within the
[general] context.  Instead, it summons each value with
ast_variable_retrieve(), which means that it will only ever see the first
value, ever.  Adding a second, third, fourth value will not affect this
global value.

It's not just queues.conf which does this, either.  Voicemail.conf is
another that is parsed this way, as are most of the CDR modules, most
of the CEL modules, the PostgreSQL and LDAP realtime modules,
cdr.conf, cel.conf, and manager.conf.

I hope this convinces you that the IAX driver is not an anomoly when it
comes to whether or not one value will override another.  What unites
most of these modules is the lack of a need for more than one variable
of the same name (in a particular context).  On the opposite side,
consider extensions.conf.  Nearly every line in this file is exactly the
same variable name!  Do any of them override the previous value?

-- 
Tilghman