This feature allows ftmod_libpri to ignore calls with non-matching destination number.

You may want to use this on BRI PTMP lines (Point-to-MultiPoint),
to avoid conflicts between your FreeSWITCH server and other devices connected to the line.

The filter is disabled by default (all calls will be accepted),
setting one (or more) "local-number" parameters on the span configuration enables it.

Example configuration snippet:

   <libpri_spans>
      <span name="example01">
         <!-- ... other span settings omitted ... -->
         <param name="local-number" value="123456"/>
         <param name="local-number" value="654321"/>
      </span>
   </libpri_spans>
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>

Signed-off-by: Stefan Knoblich <stkn@openisdn.net>

FS-4349 try this, it should be a minimal wait since this will poll the socket for 20ms only when there are no events at all and no log data at all

If updating the base image fails, retry a few times.  If that doesn't
work, simply move on; the update usually fails because Debian is
updating its mirrors; it's not important that we be absolutely up to
date.

Don't use the SET_STATUS1 macro as it will always produce this
warning.  It's a rather 'interesting' macro that's probably best
avoided anyway.

readfile returns a value of type ssize_t (signed) and returns -1 if an
error occurs.  In auth_readdb_internal, however, we were assigning the
return value of readfile to a variable of type size_t (unsigned), but
then testing this unsigned value to see if it was < 0, a
contradiction.  We would thus simultaneously fail to report the error
in readfile and would end up with a corrupted length value.

sres_cached_answers_sockaddr is supposed to return ENOENT if no cached
records are found.  Because of the missing return statement, however,
it would never do this and would instead return something very likely
to be garbage.

base64_d returns a value of size_t, which is unsigned.  The value
therefore cannot be less than zero.  The second check testing whether
it is >= INT_MAX is not a contradiction, but it doesn't make any sense
to check for this (as far as I can tell).

SU_LOG->log_level is declared as unsigned, hence it will always
be >= 0.

Converting these macros to functions declared static inline allow the
C type-checker to work and avoid warnings about unused expression
values.  These warnings break the build with clang.

This avoid warnings about expressions with unused values.  These
warnings break the build with clang.

An optimizing compiler should still inline these calls.  If that turns
out not to happen on some platform, we could rename the functions used
internally and declare them static inline.

These calls were zeroing only a pointer's worth of memory rather than
the actual size of the objects.

clang warns:

  warning: returning 'const char *' from a function with result type
    'char *' discards qualifiers [-Wincompatible-pointer-types]

The implementation clears the context / state data from memory when it
is finished with it.  Prior to this commit, however, it was actually
only clearing the first 4 bytes on x86 or 8 bytes on x86_64.

clang warns:

  warning: argument to 'sizeof' in 'memset' call is the same
  expression as the destination; did you mean to dereference it?
      [-Wsizeof-pointer-memaccess]

On some compilers this fixes the build.

gcc reports:

  error: format not a string literal and no format arguments

clang reports:

  error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]

This causes a warning that breaks the build with clang.

This adds the .version file to nightlies produced with debian/util.sh.

Debian nightlies created with debian/util.sh now have the version set
in the same format as Makefile.am produces.  Unlike Makefile.am,
however, we show the orig packaging date rather than the date of the
latest commit, as the latter could legitimately regress and we need
this to always increment.

When we're terminating ZRTP to an IVR or to a leg which is not
ZRTP-capable, there's no way for us to make an intelligent decision
about whether this flag should be set.  For a client to consider the
SAS as verified, however, both sides need to set this flag.  By always
setting this flag on our side, we leave the decision completely in the
hands of the client where we hope there is a careful human.
Signed-off-by: Travis Cross <tc@traviscross.com>