chan_iax2: Prevent some needless breaking of the native IAX2 bridge.

* Clean up some twisted code in the iax2_bridge() loop.

* Add AST_CONTROL_VIDUPDATE and AST_CONTROL_SRCCHANGE to a list of frames
to prevent the native bridge loop from breaking.

* Passing the AST_CONTROL_T38_PARAMETERS frame should also allow FAX over
a native IAX2 bridge.

(issue ABE-2912)

Review: https://reviewboard.asterisk.org/r/2870/


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@399697 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Fix Realtime Peer Update Problem When Un-registering And Expires Header In 200ok

1st Issue
When a realtime peer sends an un-REGISTER request, Asterisk
un-registers the peer but the database table record still has regseconds and
fullcontact for the peer.  This results in calls attempting to be routed to the
peer which is no longer registered.  The expected behavior is to get
busy/congested when attempting to call an un-registered peer through the
dialplan.

What was discovered is that we are clearing out the peer's registration in the
database in parse_register_contact() when calling expire_register() but then
upon returning from parse_register_contact(), update_peer() is run which stores
back in the database table regseconds and fullcontact.

2nd Issue
The reporter pointed out that the 200 ok being returned by Asterisk
after un-registering a peer contains a Contact header with ;expires= and the
Expires header is not set to 0.  This is actually a regression.

Tests were created for this second issue (ASTERISK-22548).  The tests have been
reviewed and a Ship It! was received on those tests.

This patch does the following:

* Do not ignore the Expires header value even when it is set to 0.  The patch
  sets the pvt->expiry earlier on in the function so that it is set properly and
  used.

* If pvt->expiry is 0, do not call update_peer since that means the peer has
  already been un-registered and there is no need to update the database record
  again since nothing has changed.

(closes issue ASTERISK-22428)
Reported by: Ben Smithurst
Tested by: Ben Smithurst, Michael L. Young
Patches:
  asterisk-22428-rt-peer-update-and-expires-header.diff
                                              by Michael L. Young (license 5026)

Review: https://reviewboard.asterisk.org/r/2869/


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@399794 f38db490-d61c-443f-a65b-d21fe96a405b
chan_dahdi: CLI "core stop gracefully" has needless delay for PRI and SS7.

The PRI and SS7 link control threads are not stopped correctly when the
chan_dahdi.so module is unloaded.  The link control threads pri_dchannel()
and ss7_linkset() are not awakened from a poll() to cancel the thread.

* Added a SIGURG signal after requesting the thread cancel to break the
link control thread poll() immediately.

For SS7 it was slightly worse, the link poll() timeout would always be
whatever was the last libss7 scheduled event time used.  If no libss7
scheduled event was pending, the thread could run more often than
necessary.

* Set nextms to 60 seconds for the ss7_linkset() poll() if there is no
other libss7 scheduled event.


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@399818 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Reject calls on 200 OKs if no SDP has been received

When Asterisk receives a 200 OK in response to an invite, that peer should have
sent an SDP at some point by then. If the channel has never received an SDP,
media won't have been set and the remote address won't be known. Endpoints in
general should not be doing this. This patch makes it so that Asterisk will
simply hang up a call if it sends a 200 OK at this point. So far this odd
behavior for endpoints has only been observed in tests which involved manually
created SIP transactions in SIPp.

(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@399939 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Increase some scratch buffer sizes dealing with caller id.

* Eliminated an unnecessary initialization in check_user_full().

(closes issue ASTERISK-22477)
Reported by: Michael Shepelev


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400013 f38db490-d61c-443f-a65b-d21fe96a405b
Add check for openSUSE when detecting bfd library

In ASTERISK-17842, some additional library checks were added to the configure
script so that the bfd library could be found on CentOS and Fedora systems.

As it turns out, openSUSE requires an additional library. This patch adds
another check to the configure script for openSUSE that will add that library.

Review: https://reviewboard.asterisk.org/r/2885/

(closes issue AST-1169)
Reported by: Guenther Kelleter


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400073 f38db490-d61c-443f-a65b-d21fe96a405b
res_rtp_asterisk: Correct erroneous lost packet information in RTCP reports

RTCP's calculation of the number of lost packets in an RTP stream is based on
that stream's sequence number count, the number of received packets, and how
many packets we expect to receive. When the SSRC for an RTP stream changes,
there can - and almost always will be - a large jump in the next packet's
timestamp and sequence number. If we don't reset the number of received
packets, sequence number count, and other metrics used by RTCP, the next RR/SR
report will use the previous SSRC's values to calculate the lost packet count
for the new SSRC - resulting in a very large number of lost packets.

This patch modifies res_rtp_asterisk such that, if it detects a SSRC change, it
will reset the various values used by the RTCP calculations. From the
perspective of RTCP, this appears as a new media stream - which is what it is.

Review: https://reviewboard.asterisk.org/r/2886/

(closes issue AST-1174)
Reported by: Thomas Arimont


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400089 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Allow Asterisk to retry after 403 on register

This adds a global option in chan_sip to allow it to continue
attempting registration if a 403 is received, clearing the cached nonce
and treating it as a non-fatal response. Normally, this would cause
registration attempts to that endpoint to stop.

(closes issue ASTERISK-17138)
Review: https://reviewboard.asterisk.org/r/2874/
Reported by: Rudi


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400137 f38db490-d61c-443f-a65b-d21fe96a405b
Cast Integer Argument To Unsigned Char

The member reg in the peercnt structure is an unsigned char and peercnt_modify()
is expecting an unsigned char argument which gets assigned to peercnt->reg.

This patch fixes that by casting the integer argument being passed to
peercnt_modify to unsigned char.


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400314 f38db490-d61c-443f-a65b-d21fe96a405b
res_rtp_multicast: Ensure SSRC is set properly

This fixes a bug where the SSRC field on multicast RTP can be stuck at
0 which can cause problems for endpoints trying to make sense of
incoming streams.

(closes issue ASTERISK-22567)
Reported by: Simone Camporeale
Patches:
    22567_res_mulitcast_ssrc.patch uploaded by Simone Camporeale (License 6536)


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400393 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Don't ignore expires value in contact header if it lacks semicolon

(closes issue ASTERISK-22574)
Reported by: Filip Jenicek
Patches:
    chan_sip_expires.patch uploaded by Filip Jenicek (license 6277)


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400469 f38db490-d61c-443f-a65b-d21fe96a405b
app_queue: Fix Queuelog EXITWITHKEY only logging two of four fields

Commit r62462 added two extra fields for logging "the original position the
caller entered the queue at, and the amount of time the caller was waiting in
the queue."  But when r75969 was merged from 1.4 into trunk (r75977), these two
fields disappeared. Those two extra fields were not logged in 1.4 and when the
patch was merged, those fields went away.

Therefore, this is a regression and was caught by the reporter because he was
reading the awesome "Asterisk: The Definitive Guide" book.

(closes issue ASTERISK-22197)
Reported by: Dalius M.
Tested by: Dalius M.
Patches:
    asterisk-22197-q-log-exitwithkey.diff
				     uploaded by Michael L. Young (license 5026)

Review: https://reviewboard.asterisk.org/r/2901/


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400622 f38db490-d61c-443f-a65b-d21fe96a405b
Fix func_config list entry allocation

The AST_CONFIG dialplan function defined in func_config.c allocates its
config file list entries using ast_malloc. List entry allocations
destined for use with Asterisk's linked list API must be ast_calloc()d
or otherwise initialized so that list pointers are set to NULL. These
uses of ast_malloc have been replaced by ast_calloc to prevent
dereferencing of uninitialized pointer values when traversing the list.

(closes issue ASTERISK-22483)
Reported by: Brian Scott


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400694 f38db490-d61c-443f-a65b-d21fe96a405b
Add warning when compiling with iODBC support

When running configure, libiodbc2 development headers will fulfill the
requirement for ODBC development headers, but will not function
properly. This adds a warning when libiodbc2 development headers are
detected instead of unixodbc development headers.

(closes issue ASTERISK-22459)
Reported by: Patrick Maille
Tested by: Walter Doekes
Patches:
    issueA22459_warn_when_using_iodbc.patch uploaded by Walter Doekes (License 5674)


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400767 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Do not increment the SDP version between 183 and 200 responses.

Bumping the SDP version number can cause interoperability problems
since receivers of the responses will expect that a 200 SDP will
be identical to a previous 183 SDP.

(closes issue ASTERISK-21204)
reported by NITESH BANSAL

Patches:
	dont-increment-session-version-in-2xx-after-183.patch uploaded by NITESH BANSAL (License #6418)



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400906 f38db490-d61c-443f-a65b-d21fe96a405b
chan_dahdi: Reflect the set software gain in the CLI "dahdi show channel" output.

* Remember the swgain setting from CLI "dahdi set swgain" command so the
CLI "dahdi show channel" output will reflect the current setting.

* Updated CLI "dahdi set hwgain" and "dahdi set swgain" documentation.

(issue ASTERISK-22429)
Reported by: Jaco Kroon
Patches:
      jira_asterisk_22429_v1.8_v2.patch (license #5621) patch uploaded by rmudgett


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400907 f38db490-d61c-443f-a65b-d21fe96a405b
Prevent chan_sip from sending duplicate BYEs.

When a 200 OK for an initial INVITE is received, we were doing
the right thing by ACKing and sending an immediate BYE. However,
we also were doing the wrong thing and queuing an answer frame,
thus causing the call to be answered. This would cause the call
to be hung up by the channel thread, thus resulting in a second
BYE being sent out.

In this fix, I also have set the hangupcause to be correct since
the initial BYE being sent by Asterisk had an unknown hangup
cause. I have changed to using "Bearer capabilty not available"
since the call was hung up due to an SDP offer/answer error.

(closes issue ASTERISK-22621)
reported by Kinsey Moore



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@400970 f38db490-d61c-443f-a65b-d21fe96a405b
Don't check all realtime queues when doing "queue show some_queue".

When using realtime queues, queues have to be fetched from the database
every now and then to see if any info has been changed or to see if the
queue has been removed. When fetching info for an individual queue, the
pruning of other queues is unnecessarily costly.

Review: https://reviewboard.asterisk.org/r/2907/


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@401049 f38db490-d61c-443f-a65b-d21fe96a405b
Reduce log level of a non-pubsub error message

Drop an error log message to debug level 1 since distributed device
state functions correctly when receiving this message and it spams the
logs.

(closes issue ASTERISK-22410)
Reported by: abelbeck
Patches:
    asterisk-1.8-res_jabber-log-nonpubsub-error-to-debug.patch uploaded by abelbeck (License 5903)


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@401119 f38db490-d61c-443f-a65b-d21fe96a405b
Properly copy/remove the device state cache flag over a masquerade.

In r378303 the AST_FLAG_DISABLE_DEVSTATE_CACHE flag was added that tells
the devstate system to not cache states for non-real devices. However,
when optimizing away channels (ast_do_masquerade), that flag wasn't
copied.

In my case, using Local devices as queue members created a situation
where the endpoint was considered in use, but the state change of the
device being available again was ignored (not cached). The endpoint
channel was optimized into the (previously) Local channel, but kept
the do-not-cache flag. The end result being that the queue member
apparently stayed in use forever.

(closes issue ASTERISK-22718)
Reported by: Walter Doekes

Review: https://reviewboard.asterisk.org/r/2925/


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@401178 f38db490-d61c-443f-a65b-d21fe96a405b