If the SIP channel driver processes an invalid SDP that defines media
descriptions before connection information, it may attempt to reference
the socket address information even though that information has not yet
been set. This will cause a crash.
This patch adds checks when handling the various media descriptions that
ensures the media descriptions are handled only if we have connection
information suitable for that media.
Thanks to Walter Doekes, OSSO B.V., for reporting, testing, and providing
the solution to this problem.
(closes issue ASTERISK-22007)
Reported by: wdoekes
Tested by: wdoekes
patches:
issueA22007_sdp_without_c_death.patch uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A remote exploitable crash vulnerability exists in the SIP channel driver if an
ACK with SDP is received after the channel has been terminated. The handling
code incorrectly assumed that the channel would always be present.
This patch adds a check such that the SDP will only be parsed and applied if
Asterisk has a channel present that is associated with the dialog.
Note that the patch being applied was modified only slightly from the patch
provided by Walter Doekes of OSSO B.V.
(closes issue ASTERISK-21064)
Reported by: Colin Cuthbertson
Tested by: wdoekes, Colin Cutherbertson
patches:
issueA21064_fix.patch uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Review https://reviewboard.asterisk.org/r/2580/ tried to fix the mismatch
in memory pools but had a math error determining the buffer size and
didn't address other similar memory pool mismatches.
* Effectively reverted the previous patch to go in the same direction as
trunk for the returned memory pool of ast_bt_get_symbols().
* Fixed memory leak in ast_bt_get_symbols() when BETTER_BACKTRACES is
defined.
* Fixed some formatting in ast_bt_get_symbols().
* Fixed sig_pri.c freeing memory allocated by libpri when MALLOC_DEBUG is
enabled.
* Fixed __dump_backtrace() freeing memory from ast_bt_get_symbols() when
MALLOC_DEBUG is enabled.
* Moved __dump_backtrace() because of compile issues with the utils
directory.
(closes issue ASTERISK-22221)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2778/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In 1.8, r384779 introduced a regression by retrieving an old dialog and keeping
the old recv address since recv was already set. This has caused a problem when
a proxy is involved since responses to incoming requests from the proxy server,
after an outbound call is established, are never sent to the correct recv
address.
In 11, r382322 introduced this regression.
The fix is to revert that change and always store the recv address on incoming
requests.
Thank you Walter Doekes for helping to point out this error and Mark Michelson
for your input/review of the fix.
(closes issue ASTERISK-22071)
Reported by: Alex Zarubin
Tested by: Alex Zarubin, Karsten Wemheuer
Patches:
asterisk-22071-store-recvd-address.diff by Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397204 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a peer is used in a register line and TLS is defined as the transport, the
registration fails since the transport on the dialog is never set properly
resulting in UDP being used instead of TLS.
This patch sets the dialog's transport based on the transport that was defined
in the register line. If the register line does not specify a transport, the
parsing function for the register line always defaults back to UDP.
(closes issue ASTERISK-21964)
Reported by: Doug Bailey
Tested by: Doug Bailey
Patches:
asterisk-21964-set-reg-dialog-transport.diff
by Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@396240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The commit (r387133) for fixing ASTERISK-21466 accidentally removed an extra
line break between the peers returned by the AMI action SIPPeers. This
results in some parsers breaking because they expect this extra line break.
This patch restores that extra line break.
(closes issue ASTERISK-22239)
Reported by: Jacek Konieczny
Tested by: Jacek Konieczny, Michael L. Young
Patches:
asterisk-ami_sippeers_separator.patch by Jacek Konieczny (license 6298)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@396236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from mixing different variants or general MFC-R2 settings within the same E1 line.
Most users do not have a problem with this since MFC-R2 lines are usually fractional E1s, or
the whole E1 has the same country variant and R2 settings.
In Venezuela however is common to have inbound MFC-R2 and outbound DTMF-R2 within the same E1.
This fix now properly parses the chan_dahdi.conf file to generate a new openr2 context every
time a new channel => section is found and the configuration was changed.
(closes issue ASTERISK-21117)
Reported by: Rafael Angulo
Related Elastix issue: http://bugs.elastix.org/view.php?id=1612
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1). When touching the bridgecallno, we need to lock it.
2). Remove magic number '0' and replace with TRANSFER_NONE.
3). Exit early if no bridgecallno.
4). Reduce indentation.
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2613/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@391333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1). When touching the bridgecallno, we need to lock it.
2). stop_stuff() which calls iax2_destroy_helper()
Assumes the lock on the pvt is already held, when iax2_destroy_helper() is called.
Thus we need to lock the bridgecallno pvt before we call stop_stuff(iaxs[fr->callno]->bridgecallno);
3). When evaluating the state of 'callno->transferring' of the current leg,
we can't change it to READY unless the bridgecallno is locked.
Why, if we are interrupted by the other call leg before 'transferring = TRANSFER_RELEASED',
the interrupt will find that it is READY and that the bridgecallno is also READY so Releases the legs.
(closes issue ASTERISK-21409)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2594/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@391062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC6665 4.2.2: ... after a failed State NOTIFY transaction remove the subscription
The problem is that the State Notify requests rely on the 200OK reponse for pacing control
and to not confuse the notify susbsystem.
The issue is, the pendinginvite isn't cleared if a response isn't received,
thus further notify's are never sent.
The solution, follow RFC 6665 4.2.2's 'SHOULD' and remove the subscription after failure.
(closes issue ASTERISK-21677)
Reported by: Dan Martens
Tested by: Dan Martens, David Brillert, alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2475/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387875 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 4028 Section 10
if the side not performing refreshes does not receive a
session refresh request before the session expiration, it SHOULD send
a BYE to terminate the session, slightly before the session
expiration. The minimum of 32 seconds and one third of the session
interval is RECOMMENDED.
Prior to this asterisk would refresh at 1/2 the Session-Expires interval,
or if the remote device was the refresher, asterisk would timeout at interval end.
Now, when not refresher, timeout as per RFC noted above.
(closes issue ASTERISK-21742)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2488/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 4028 Section 7.2
"UACs MUST be prepared to receive a Session-Expires header field in a
response, even if none were present in the request."
What changed
After ASTERISK-20787, inbound calls to asterisk with no Session-Expires in the INVITE are now are offered
a Session-Expires (1800 asterisk default) in the response, with asterisk as the refresher.
Symptom:
After 900 seconds (asterisk default refresher period 1800), asterisk RE-INVITEs the device, the device
may respond with a much lower Session-Expires (180 in our case) value that it is now using.
Asterisk ignores this response, as it's deemed both an INBOUND CALL, and a RE-INVITE.
After 180 seconds the device times out and sends BYE (hangs up), asterisk is still working with the
refresher period of 1800 as it ignored the 'Session Expires: 180' in the previous 200OK response.
Fix:
handle_response_invite() when 200OK, remove check for outbound and reinvite.
(closes issue ASTERISK-21664)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2463/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387312 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Lower bound of a 16bit signed int is -32768 not -32767
(closes issue ASTERISK-21744)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When you have lots of SIP peers (according to the issue reporter, around 3500),
the 'sip show peers' CLI command or AMI action can crash due to a poorly placed
string duplication that occurs on the stack. This patch refactors the command
to not allocate the string on the stack, and handles the formatting of a single
peer in a separate function call.
(closes issue ASTERISK-21466)
Reported by: Guillaume Knispel
patches:
fix_sip_show_peers_stack_overflow_asterisk_11.3.0-v2.patch uploaded by gknispel (License 6492)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, a read error in snd_pcm_readi would still be treated as a
nominal result when constructing a voice frame from the expected data. Since
the value returned is negative, as opposed to the number of samples read,
this could result in a crash. With this patch, we now return a null frame
when a read error is detected.
Note that the patch on ASTERISK-21329 was modified slightly for this commit,
in that we bail immediately on detecting the read error, rather than bypassing
the construction of the voice frame.
(closes issue ASTERISK-21329)
Reported by: Keiichiro Kawasaki
patches:
chan_alsa.diff uploaded by kawasaki (License 6489)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On startup, it's possible for a frame to arrive before the processing threads were ready.
In iax2_process_thread() the first pass through falls into ast_cond_wait, should a frame arrive
before we are at ast_cond_wait, the signal will be ignored.
The result iax2_process_thread stays at ast_cond_wait forever, with deferred frames being queued.
Fix: When creating initial idle iax2_process_threads, wait for init_cond to be signalled
after each thread is started.
(issue ASTERISK-18827)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2427/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385402 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a BYE request is processed in chan_sip, the current SIP dialog is detached
from its associated Asterisk channel structure. The tech_pvt pointer in the
channel object is set to NULL, and the dialog persists for an RFC mandated
period of time to handle re-transmits.
While this process occurs, the channel is locked (which is good).
Unfortunately, operations that are initiated externally have no way of knowing
that the channel they've just obtained (which is still valid) and that they are
attempting to lock is about to have its tech_pvt pointer removed. By the time
they obtain the channel lock and call the channel technology callback, the
tech_pvt is NULL.
This patch adds a few checks to some channel callbacks that make sure the
tech_pvt isn't NULL before using it. Prime offenders were the DTMF digit
callbacks, which would crash if AMI initiated a DTMF on the channel at the
same time as a BYE was received from the UA. This patch also adds checks on
sip_transfer (as AMI can also cause a callback into this function), as well
as sip_indicate (as lots of things can queue an indication onto a channel).
Review: https://reviewboard.asterisk.org/r/2434/
(closes issue ASTERISK-20225)
Reported by: Jeff Hoppe
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385170 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The initial report was that the "nat" setting in the [general] section was not
having any effect in overriding the default setting. Upon confirming that this
was happening and looking into what was causing this, it was discovered that
other default settings would not be overriden as well.
This patch works similar to what occurs in build_peer(). We create a temporary
ast_flags structure and using a mask, we override the default settings with
whatever is set in the [general] section.
In the bug report, the reporter who helped to test this patch noted that the
directmedia settings were being overriden properly as well as the nat settings.
(closes issue ASTERISK-21225)
Reported by: Alexandre Vezina
Tested by: Alexandre Vezina, Michael L. Young
Patches:
asterisk-21225-handle-options-default-prob_1.8_v4.diff.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2386/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-20904, the focus was around the changes to NAT that took place in
Asterisk 11. Since the report stated that 1.8 was fine, we didn't take a look
at 1.8 at the time.
While working on ASTERISK-21225, I could see that 1.8 would benefit from having
some of those changes applied to it.
This patch does the following:
* The important part of this patch is that it sets the peer's flags earlier in
build_peer so that the code properly uses the peer's flags based on the peer's
configuration.
* constify req parameter in check_via()
* update realtime schemas under the contrib directory to handle properly the NAT
settings available in 1.8 as well as to handle the changes made in 11 to make
upgrading easier when installing newer versions of Asterisk
(closes issue ASTERISK-21243)
Reported by: Michael L. Young
Patches:
asterisk-20904-changes_for_1.8.diff Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2422/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new inband_on_proceeding option causes Asterisk to assume inband audio
may be present when a PROCEEDING message is received.
Q.931 Section 5.1.2 says the network cannot assume that the CPE side has
attached to the B channel at this time without explicitly sending the
progress indicator ie informing the CPE side to attach to the B channel
for audio. However, some non-compliant ISDN switches send a PROCEEDING
without the progress indicator ie indicating inband audio is available and
assume that the CPE device has connected the media path for listening to
ringback and other messages.
ASTERISK-17834 which causes this issue was dealing with a non-compliant
network switch.
(closes issue ASTERISK-21151)
Reported by: Gianluca Merlo
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When authenticating a SIP request with alwaysauthreject enabled, allowguest
disabled, and autocreatepeer disabled, Asterisk discloses whether a user
exists for INVITE, SUBSCRIBE, and REGISTER transactions in multiple ways. The
information is disclosed when:
* A "407 Proxy Authentication Required" response is sent instead of a
"401 Unauthorized" response
* The presence or absence of additional tags occurs at the end of "403
Forbidden" (such as "(Bad Auth)")
* A "401 Unauthorized" response is sent instead of "403 Forbidden" response
after a retransmission
* Retransmission are sent when a matching peer did not exist, but not when a
matching peer did exist.
This patch resolves these various vectors by ensuring that the responses sent
in all scenarios is the same, regardless of the presence of a matching peer.
This issue was reported by Walter Doekes, OSSO B.V. A substantial portion of
the testing and the solution to this problem was done by Walter as well - a
huge thanks to his tireless efforts in finding all the ways in which this
setting didn't work, providing automated tests, and working with Kinsey on
getting this fixed.
(closes issue ASTERISK-21013)
Reported by: wdoekes
Tested by: wdoekes, kmoore
patches:
AST-2013-003-1.8 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-10 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-11 uploaded by kmoore, wdoekes (License 6273, 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r373424, several reentrancy problems in chan_sip were addressed. As a
result, the SIP channel driver is now properly locking the channel driver
private information in certain operations that it wasn't previously. This
exposed two latent problems either in register_verify or by functions called
by register_verify. This includes:
* Holding the private lock while calling sip_send_mwi_to_peer. This can create
a new sip_pvt via sip_alloc, which will obtain the channel container lock.
This is a locking inversion, as any channel related lock must be obtained
prior to obtaining the SIP channel technology private lock.
* Holding the privat elock while calling sip_poke_peer. In the same vein as
sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing
the same locking inversion.
Note that this locking inversion typically occured when CLI commands were run
while a SIP REGISTER request was being processed, as many CLI commands (such
as 'sip show channels', 'core show channels', etc.) have to obtain the channel
container lock.
(issue ASTERISK-21068)
Reported by: Nicolas Bouliane
(issue ASTERISK-20550)
Reported by: David Brillert
(issue ASTERISK-21314)
Reported by: Badalian Vyacheslav
(issue ASTERISK-21296)
Reported by: Gabriel Birke
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CALLEDTON channel variable is set for incoming ISDN calls to the lower
7 bits of the Q.931 type-of-number/numbering-plan octet. The
CALLERID(dnid-num-plan) should have the same value.
(closes issue ASTERISK-21248)
Reported by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI, HTTP, and chan_sip all support TLS in some way, but none of them
support all the options that Asterisk's TLS core is capable of
interpreting. This prevents consumers of the TLS/SSL layer from setting
TLS/SSL options that they do not support.
This also gets tlsverifyclient closer to a working state by requesting
the client certificate when tlsverifyclient is set. Currently, there is
no consumer of main/tcptls.c in Asterisk that supports this feature and
so it can not be properly tested.
Review: https://reviewboard.asterisk.org/r/2370/
Reported-by: John Bigelow
Patch-by: Kinsey Moore
(closes issue AST-1093)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a session timer expires during a dialog that has re-negotiated to T.38
and Asterisk is the refresher, Asterisk will send a re-INVITE with an SDP
containing audio media only. This causes some hilarity with the poor fax
session under weigh.
This patch corrects that by sending T.38 parameters if we are in the middle of
a T.38 session.
(closes issue ASTERISK-21232)
Reported by: Nitesh Bansal
patches:
dont-send-audio-reinvite-for-sess-timer-in-t38-call.patch uploaded by nbansal (License 6418)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-17888, the AMI Registry event during SIP registrations was supposed
to include the Username field. Somehow, one of the events was missed. This
patch corrects that - the Username field should be included in all AMI Registry
events involving SIP registrations.
(issue ASTERISK-17888)
(closes issue ASTERISK-21201)
Reported by: Dmitriy Serov
patches:
chan_sip.c.diff uploaded by Dmitriy Serov (license 6479)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A deadlock can occur in chan_iax2 when it attempts to set the caller ID, as it
already holds the iax2 private lock and improperly fails to obtain the channel
lock before calling ast_set_callerid. By not safely obtaining the channel lock,
a locking inversion can take place, causing a deadlock.
This patch solves this by calling the required deadlock avoidance functions
that obtain the channel lock before setting the caller ID.
Thanks to Pavel for fixing my syntax errors and testing this patch out.
(closes issue ASTERISK-21128)
Reported by: Pavel Troller
Tested by: Pavel Troller
patches:
ASTERISK-21128-1.8.diff uploaded by mjordan (license 6283)
ASTERISK-21128-modified-1.8.diff uploaded by Pavel Troller (license 6302)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382233 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Somehow, chan_jingle has managed to operate for years without setting the
sin_family on its bindaddr socket. This patch properly sets the field during
initial module load to AF_INET.
Note that the patch on the issue was modified slightly to change the
initialization of the socket from allocation of a chan_jingle private to the
module initialization, as the bindaddr object (which is static) only needs to
have the address set once.
(closes issue ASTERISK-19341)
Reported by: andre valentin
patches:
0105-chan_jingle.patch uploaded by avalentin (License 6064)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When I added my extensive suite of session timer unit tests, apparently one of
them was failing and I never noticed. If neither Min-SE nor Session-Expires is
set in the header, it was responding with a Session-Expires of the global
maxmimum instead of the configured max for the endpoint.
(issue ASTERISK-20787)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, Asterisk only processed session timer information if both the
'Supported: timer' and 'Session-Expires' headers were present. However, the
Session-Expires header is optional. If we were to receive a request with a
Min-SE greater than our configured session-expires, we would respond with a
'Session-Expires' header that was too small.
This patch cleans the situation up a bit, always processing timer information
if the 'Supported: timer' header is present.
(closes issue ASTERISK-20787)
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/2299/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC5347 section 2.5.2 states the following:
...
The attribute "T38MaxBitRate" was once incorrectly registered with
IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38
examples and common implementation practice, the form "T38MaxBitRate"
SHOULD be generated by implementations conforming to this package.
In general, it is RECOMMENDED that implementations of this package
accept lowercase, uppercase, and mixed upper/lowercase encodings of
all the T.38 attributes.
...
Asterisk currently does not perform case insensitive matching on the T.38
attributes. This causes the T38MaxBitRate attribute to be negotiated at
2400 baud instead of 14400 (or whatever value you actually wanted).
This patch makes it so that when we compare T.38 attributes, we do so in a case
insensitive fashion.
Note that while the issue reporter did not directly write the patch, they
contributed to it (and would have provided one themselves if the license had
gone through a tad faster), and hence get attribution for it.
(closes issue ASTERISK-20897)
Reported by: Eric Hill
Tested by: Eric Hill
patches:
-- uploaded by Eric Hill
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Multiple channels logging in as the same agent can result in dead channels
waiting for a condition signal that will never come because another
channel thread stole it. A symptom is chan_sip repeatedly generating
warning messages about rescheduling autodestruction of dialogs with an
agent channel owner.
* Made only login_exec() (the app AgentLogin) clear the agent_pvt->chan
pointer to prevent multiple channels from logging in as the same agent.
agent_read(), agent_call(), and agent_set_base_channel() no longer
disconnect the agent channel from the agent_pvt. This also eliminates the
need to keep checking for agent_pvt->chan being NULL.
* Made agent_hangup() not wake up the AgentLogin agent thread until it is
done.
* Made agent_request() not able to get the agent until he has logged in
and any wrapup time has expired.
* Made agent_request() use ast_hangup() instead of agent_hangup() to
correctly dispose of a channel.
* Removed agent_set_base_channel(). Nobody calls it and it is a bad thing
in general.
* Made only agent_devicestate() determine the current device state of an
agent. Note: Agent group device states have never been supported.
Review: https://reviewboard.asterisk.org/r/2260/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original fix (r380043) for getting Asterisk to respond with the correct
tag overlooked some corner cases, and the fact that the same code is in 1.8.
This patch moves the building of the crypto line out of
sdp_crypto_process(). Instead, it merely copies the accepted tag. The call to
sdp_crypto_offer() will build the crypto line in all cases now, using a tag of
"1" in the case of sending offers.
(closes issue ASTERISK-20849)
Reported by: José Luis Millán
Review: https://reviewboard.asterisk.org/r/2295/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is currently an edge case where call number 32768 might be allocated for
a call, even though the IAX2 protocol requires call numbers be only 15 bits.
This resulted in some unpredictable behavior when call number 32678 is chosen.
This patch was mostly written by Richard Mudgett via ReviewBoard. I'm just
committing it.
Review: https://reviewboard.asterisk.org/r/2293/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
