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
Record-Route parsing copied the header into a char[256] array, which can
be a problem if the header is longer than that. This patch parses the
header in place, without the copy, avoiding the issue.
In addition to the original patch, I added a unit test for the new
get_in_brackets_const function.
(closes issue ASTERISK-20837)
Reported by: Corey Farrell
Patches:
chan_sip-build_route-optimized-rev1.patch uploaded by Corey Farrell (license 5909)
(with minor changes by dlee)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The chan_misdn channel driver will send a channel with an invalid destination
to the 'i' extension itself if said extension can be reached. It forgot,
however, to set the INVALID_EXTEN channel variable when it bounces the channel
to this extension. Dialplan writers everywhere moaned at yet another
inconsistency.
This is yet another example of why duplicating logic in multiple places results
in bugs that stick around in Jira for just under three years.
Yes: ASTERISK-15456 was created on January 18th, 2010. Patch committed on
January 15th, 2013. Ouch.
(closes issue ASTERISK-15456)
Reported by: Thomas Omerzu
patches:
chan_misdn_invalid.patch2 uploaded by Thomas Omerzu (license 5927)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When r378933 was merged into 1.8, it should have also escaped
remote_display, since it will have the same XML encoding problem when
the caller/callee roles are reversed.
(closes issue ABE-2902)
Reported by: Guenther Kelleter
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
XML encoding in chan_sip is accomplished by naively building the XML
directly from strings. While this usually works, it fails to take into
account escaping the reserved characters in XML.
This patch adds an 'ast_xml_escape' function, which works similarly to
'ast_uri_encode'. This is used to properly escape the local_display
attribute in XML formatted NOTIFY messages.
Several things to note:
* The Right Thing(TM) to do would probably be to replace the
ast_build_string stuff with building an ast_xml_doc. That's a much
bigger change, and out of scope for the original ticket, so I
refrained myself.
* It is with great sadness that I wrote my own ast_xml_escape
function. There's one in libxml2, but it's knee-deep in
libxml2-ness, and not easily used to one-off escape a
string.
* I only escaped the string we know is causing problems
(local_display). At least some of the other strings are
URI-encoded, which should be XML safe. Rather than figuring out
what's safe and escaping what's not, it would be much cleaner to
simply build an ast_xml_doc for the messages and let the XML
library do the XML escaping. Like I said, that's out of scope.
(closes issue ABE-2902)
Reported by: Guenther Kelleter
Tested by: Guenther Kelleter
Review: http://reviewboard.digium.internal/r/365/
........
Merged revision 378919 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On a multihomed server when sending a NOTIFY message, we were not figuring out
which network should be used to contact the peer.
This patch fixes the problem by calling ast_sip_ouraddrfor() and then
build_via() so that our NOTIFY message contains the correct IP address.
Also, a debug message is being added to help follow the call-id changes that
occur. This was helpful for confirming that the IP address was set properly
since the call-id contains the IP address. It also will be helpful for
troubleshooting purposes when following a call in the debug logs.
(closes issue ASTERISK-20805)
Reported by: Bryan Hunt
Tested by: Bryan Hunt, Michael L. Young
Patches:
asterisk-20805-notify-ip-v2.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2255/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made agent_cont_sleep() and agent_ack_sleep() stop waiting if the wrapup
time expires. agent_cont_sleep() had tried but returned the wrong value
to stop waiting.
* Made agent_ack_sleep() take a struct agent_pvt pointer instead of a void
pointer for better type safety.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix off-nominal path resource cleanup in agent_request().
* Create agent_pvt_destroy() to eliminate inlined versions in many places.
* Pull invariant code out of loop in add_agent().
* Remove redundant module user references in login_exec().
* Remove unused struct agent_pvt logincallerid[] member.
* Remove some redundant code in agent_request().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk had several places where messages received over various network
transports may be copied in a single stack allocation. In the case of TCP,
since multiple packets in a stream may be concatenated together, this can
lead to large allocations that overflow the stack.
This patch modifies those portions of Asterisk using TCP to either
favor heap allocations or use an upper bound to ensure that the stack will not
overflow:
* For SIP, the allocation now has an upper limit
* For HTTP, the allocation is now a heap allocation instead of a stack
allocation
* For XMPP (in res_jabber), the allocation has been eliminated since it was
unnecesary.
Note that the HTTP portion of this issue was independently found by Brandon
Edwards of Exodus Intelligence.
(issue ASTERISK-20658)
Reported by: wdoekes, Brandon Edwards
Tested by: mmichelson, wdoekes
patches:
ASTERISK-20658_res_jabber.c.patch uploaded by mmichelson (license 5049)
issueA20658_http_postvars_use_malloc2.patch uploaded by wdoekes (license 5674)
issueA20658_limit_sip_packet_size3.patch uploaded by wdoekes (license 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This ensures that Asterisk rejects encrypted media streams (RTP/SAVP
audio and video) that are missing cryptographic keys and ensures that
the incoming SDP is consistent with RFC4568 as far as having a crypto
attribute present for any SAVP streams.
Review: https://reviewboard.asterisk.org/r/2204/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The chan_local module references were manually tied to the existence of
the ;1 and ;2 channel links.
* Made chan_local module references tied to the existence of the local_pvt
structure as well as automatically take care of the module references.
* Tweaked the wording of the local_fixup() failure warning message to make
sense.
Review: https://reviewboard.asterisk.org/r/2181/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378088 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk now includes Min-SE in outbound INVITEs when the value is not
90 (the default) and session timers are not disabled. This has the
effect of Asterisk following RFC4028 more closely with regard to 422
responses and preventing situations in which Asterisk would be forced
to temporarily accept a call to tear it down based on a Session-Expires
below the locally configured Min-SE.
(issue SWP-5051)
Review: https://reviewboard.asterisk.org/r/2222/
Reported-by: Kinsey Moore
Patch-by: Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@377946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ensure that a call is immediately torn down if a Session-Expires value
received in a 200 OK is less than the local Min-SE. This also prevents
Asterisk from allowing calls with Session-Expires below the
RFC4028-mandated minimum (90s).
(closes issue ASTERISK-20653)
Review: https://reviewboard.asterisk.org/r/2237/
Patch-by: Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@377623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix code to send in both rx and tx open stream messages correct codecs. Found that on phase 0/1 phones wrong codecs cause to no audio in some situations.
(issue ASTERISK-20183)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@377591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During the TLS re-work in chan_sip some TLS specific code was moved
into a separate function. This function operates on a copy of the
incoming SIP request. This copy was never deinitialized causing a
memory leak for each request processed.
This function is now given a SIP request structure which it can use
to copy the incoming request into. This reduces the amount of memory
allocations done since the internal allocated components are reused
between packets and also ensures the SIP request structure is
deinitialized when the TLS connection is torn down.
(closes issue ASTERISK-20763)
Reported by: deti
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@377257 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The principal behind this patch is simple. During a transfer,
we manipulate channels that are owned by a separate thread than
the one we currently are running in, so it makes sense that we
need to grab a reference to the channels so that they cannot
disappear out from under us.
In the wild, crashes were sometimes seen when the transferring
party would hang up the call before the transfer target answered
the call. The most common place to see the crash occur was when
attempting to send a connected line update to the transferer
channel.
(closes issue ASTERISK-20226)
Reported by Jared Smith
Patches:
ASTERISK-20226.patch uploaded by Mark Michelson (License #5049)
Tested by: Jared Smith
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@376901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For 1.8, 10, 11 and trunk we are are improving the code readability.
For 11 and trunk, auto nat detection was added. The natdetected flag was being
set to 1 when the host address in the VIA header did not specifiy a port. This
patch fixes this by setting the port on the temporary sock address used to
SIP_STANDARD_PORT in order for the sock address comparison to work properly.
(closes issue ASTERISK-20724)
Reported by: Michael L. Young
Patches:
asterisk-20724-set-port-v2.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2206/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@376834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
