Age | Commit message (Collapse) | Author |
|
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)
........
Merged revisions 387134 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue ASTERISK-21103)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2481/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Use comedia_string() to display correctly the symmetric rtp setting when
running "sip show settings"
........
Merged revisions 386486 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Change "ForcerPort" to "Forcerport" to match everywhere else it is displayed
........
Merged revisions 386483 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 386484 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When we reload Asterisk or chan_sip, the flags force_rport and comedia that are
turned on and off when using the auto_force_rport and auto_comedia nat settings
go back to the default setting off. These flags are turned on when needed or
off when not needed at the time that a peer registers, re-registers or initiates
a call. This would apply even when only the default global setting
"nat=auto_force_rport" is being used, which in this case would only affect the
force_rport flag.
Everything is good except for the following: The nat setting is set to
auto_force_rport and auto_comedia. We reload Asterisk and the peer's
registration has not expired. We load in the settings for the peer which turns
force_rport and comedia back to off. Since the peer has not re-registered or
placed a call yet, those flags remain off. We then initiate a call to the peer
from the PBX. The force_rport and comedia flags stay off. If NAT is involved,
we end up with one-way audio since we never checked to see if the peer is behind
NAT or not.
This patch does the following:
* Moves the checking of whether a peer is behind NAT into its own function
* Create a function to set the peer's NAT flags if they are using the auto_* NAT
settings
* Adds calls in sip_request_call() to these new functions in order to setup the
dialog according to the peer's settings
(closes issue ASTERISK-21374)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
asterisk-21374-auto-nat-outgoing-fix_v2.diff Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2421/
........
Merged revisions 385473 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385474 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
........
Merged revisions 385170 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 385173 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385174 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.
This issue is also present in Asterisk 1.8 and a separate patch will be applied
to it.
(issue ASTERISK-21225)
Reported by: Alexandre Vezina
Tested by: Alexandre Vezina, Michael L. Young
Patches:
asterisk-21225-handle-options-default-prob_v4.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2385/
........
Merged revisions 384827 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 384162 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 384163 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384164 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)
........
Merged revisions 384003 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384019 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.
Note that this issue was already fixed in Asterisk 11.
* Holding the private lock 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
........
Merged revisions 383863 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383878 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Remove MWI's dependency on the event system by moving it to
Stasis-core. This also introduces forwarding topic pools in Stasis-core
which aggregate many dynamically allocated topics into a single primary
topic.
Review: https://reviewboard.asterisk.org/r/2368/
(closes issue ASTERISK-21097)
Patch-by: Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383284 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)
........
Merged revisions 383165 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383166 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383167 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)
........
Merged revisions 383124 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383125 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383126 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)
........
Merged revisions 382847 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 382848 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Added an option "discard_remote_hold_retrieval" (default "no") that if set does
not trigger the music on hold event. This essentially stops telling the peer
to start music on hold.
(issue ABE-2899)
Reported by: Denis Alberto Martinez
Review: https://reviewboard.asterisk.org/r/2336/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this change, certain conditions for sending the message would
result in an address of '(null)' being used in the via header of the
SIP message because a NULl value of pvt->ourip was used when initially
generating the via header. This is fixed by adding a call to build_via
when the address is set before sending the message.
(closes issue ASTERISK-21148)
Reported by: Zhi Cheng
Patches:
700-sip_msg_send_via_fix.patch uploaded by Zhi Cheng (license 6475)
........
Merged revisions 382739 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
After r382670, get_ip_and_port_from_sdp was no longer used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Originally, way back in r201583, we added the alternate RTP address so
that the RTP engine would expect to receive audio from a new source
when a glare re-INVITE occurred. In r382589, we remove the alternate
RTP source, as the 'secret' probation mode allows for switching to a new
RTP source when a previous source stops sending RTP. At the time, it
seemed appropriate to set the RTP source based on the information in the
glared re-INVITE.
Unfortunately, that doesn't work so well - in a glared re-INVITE that occurs
with no SDP - such as in a connected line update that glances - we'll set
the RTP source to an invalid address. In subsequent re-INVITE requests from
this Asterisk instance, we'll then send an invalid media address, which will
result in the remote side sending a 488. Whoops.
There isn't any need to reset the RTP source - if we're using strictrtp, we'll
simply synchronize to a new source when we stop getting packets from the old
one. If we aren't using strictrtp, then again there shouldn't be a problem.
Note that the Asterisk Test Suite's connectedline test caught this error.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Often, Asterisk may realize that a change in the source of an RTP stream is
about to occur and ask that the RTP engine reset it's lock on the current RTP
source. In certain scenarios, it may take awhile for the new remote system to
send RTP packets, while the old remote system may continue providing RTP during
that time period. This causes Asterisk to re-lock onto the old source, thereby
rejecting the new source when the old source stops sending RTP and the new
source begins.
This patch prevents that by having a constant secondary, 'secret' probation
mode enabled when an RTP source has been chosen. RTP packets from other sources
are always considered, but never chosen unless the current RTP source stops
sending RTP.
Review: https://reviewboard.asterisk.org/r/2364
(closes issue AST-1124)
Reported by: John Bigelow
Tested by: John Bigelow
(closes issue AST-1125)
Reported by: John Bigelow
Tested by: John Bigelow
........
Merged revisions 382573 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds support for RFC 3327 "Path" headers. This can be enabled in
sip.conf using the 'supportpath' setting, either on a global basis or on a
peer basis. This setting enables Asterisk to route outgoing out-of-dialog
requests via a set of proxies by using a pre-loaded route-set defined by the
Path headers in the REGISTER request. This patch also adds Realtime support
for dynamically updating the Path information for a peer.
A huge thank-you to Klaus Darillion and Olle E Johansson for their efforts
in writing this patch.
Review: https://reviewboard.asterisk.org/r/2235/
Review: https://reviewboard.asterisk.org/r/991/
(closes issue ASTERISK-16884)
Reported by: klaus3000
Tested by: klaus3000, oej, mjordan
patches:
path-1.8.0-patch.txt uploaded by klaus3000 (License 5054)
oolong-path-support-trunk in team branch by oej (License 5267)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382440 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The original report had to do with a realtime peer behind NAT being pruned and
the peer's private address being used instead of its external address. Upon
debugging, it was discovered that this was being caused by the addition of
the auto_force_rport and auto_comedia settings.
This patch does the following:
* Adds a missing note to the CHANGES file indicating that the default global nat
setting is auto_force_rport
* Constify the 'req' parameter for check_via()
* Add calls to check_via() in a couple of places in order for the auto_*
settings to do their job in attempting to determine if NAT is involved
* Set the flags SIP_NAT_FORCE_RPORT and SIP_PAGE2_SYMMETRICRTP if the auto_*
settings are in use where it was needed
* Moves the copying of peer flags up in build_peer() to before they are used;
this fixes the realtime prune issue
* Update the contrib/realtime schemas to allow the nat column to handle the
different nat setting combinations we have
This patch received a review and "Ship It!" on the issue itself.
(closes issue ASTERISK-20904)
Reported by: JoshE
Tested by: JoshE, Michael L. Young
Patches:
asterisk-20904-nat-auto-and-rt-peersv2.diff Michael L. Young (license 5026)
........
Merged revisions 382322 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382323 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
is forked.
(closes issue ASTERISK-20638)
Reported by: eelcob
Patches:
pedantic-call-pickup-from-tag.patch uploaded by eelcob (license 6442)
........
Merged revisions 382171 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 382174 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Parsing Remote-Party-ID will now succeed if display-name is of the
*(token LWS) kind and not just the quoted-string kind.
Review: https://reviewboard.asterisk.org/r/2341/
........
Merged revisions 382107 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 382108 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382109 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Previously, presencestate information was sent whenever the state was not
NOT_SET. When r381594 actually returned INVALID presence state in all the
places it was supposed to, it caused chan_sip to start adding presence
state information to NOTIFY requests that it previously would not have
added. chan_sip shouldn't be adding presence state information when the
provider is in an invalid state; users can't set the state to invalid and
an invalid state always implies that the provider is in an error condition.
(issue AST-1084)
........
Merged revisions 381613 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381615 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Reference counting for the channel and its tech_pvt got messed up at
some point between 1.8 and 11. The result was that if a BYE for a dialog
that had been replaced (via an INVITE with Replaces) was received, Asterisk
would crash due to trying to access data on a channel that was no longer there.
The fix I introduced is to remove code that both unrefs the sip_pvt and sets
the channel's tech_pvt to NULL when an INVITE with Replaces is handled. This
way when a BYE is received, the tech_pvt will be non-NULL and so the BYE can
be processed and not cause a crash.
(closes issue ASTERISK-20929)
reported by Kristopher Lalletti
patches:
ASTERISK-20929.patch uploaded by Mark Michelson (License #5049)
........
Merged revisions 381566 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381568 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Some bad copy/pasting resulted in using the audio crypto attribute for both
text and video RTP. Also the audio crypto isn't set until after these, so it
was really just bad all around.
(closes ASTERISK-20905)
Reported by: Kristopher Lalletti
patches:
rtp_crypto_video_text.diff uploaded by Jonathan Rose (license 6182)
........
Merged revisions 381553 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381556 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When sip_ref_peer and sip_unref_peer were exported to be usable in
channels/sip/security_events.c, modifications to those functions when
building under REF_DEBUG were not taken into account. This change
moves the necessary defines into sip.h to make them accessible to
other parts of chan_sip that need them.
........
Merged revisions 381282 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381285 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381086 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)
........
Merged revisions 380973 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 380974 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380977 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/
........
Merged revisions 380696 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 380698 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A user in #asterisk ran into a problem where a configuration error prevented
the chan_sip module from being loaded. Upon fixing their configuratione error,
they could no longer load the chan_sip module. This was because the
configuration checking happened after the SIP provider was registered with the
Asterisk core, and subsequent attempts to load the SIP module failed as the
provider was already registered.
Since we want to detect any failure in registering chan_sip as early as
possible (as that could be emblematic of a deeper mismatch between module
and Asterisk core), this patch does not change the registration location, but
does ensure that if a module load is declined, we unregister the module as
the SIP api provider.
........
Merged revisions 380480 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380500 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.
Review: https://reviewboard.asterisk.org/r/2298/
(closes issue ASTERISK-20897)
Reported by: Eric Hill
Tested by: Eric Hill
patches:
-- uploaded by Eric Hill
........
Merged revisions 380458 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 380465 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In r369028, chan_sip's processing of media streams in an SDP was modified to
better handle multiple offered media streams. Part of that change modified
how streams were declined. Previously, declined media streams were not
handled in an RFC compliant manner; now, we set the port number to 0 in the
media stream definition and proceed on with the next media stream.
Unfortunately, the formatting of the declined media stream forgot to append a
'\r\n' to the end of the media stream. This is normally added to the accepted
media streams later on in the processing of the SDP. Since the declined media
stream uses a different buffer than the accepted media streams (and is a
malloc'd buffer as opposed to a struct ast_str), it's easier to just slap the
'\r\n' on the declined media stream buffer rather than attempt to append it
later on.
So, that's what we do. And now some devices (and probably some providers) will
be a bit happier (but probably not terribly happy, since we just rejected
something they offered).
Review: https://reviewboard.asterisk.org/r/2297/
(closes issue ASTERISK-20908)
Reported by: Dennis DeDonatis
Tested by: Dennis DeDonatis
........
Merged revisions 380331 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380332 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)
........
Merged revisions 379392 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379393 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379394 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
........
Merged revisions 379001 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379020 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379021 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
........
Merged revisions 378933 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378934 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378935 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/
........
Merged revisions 378554 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378559 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378565 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)
........
Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 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)
........
Merged revisions 378269 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378286 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378287 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378288 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/
........
Merged revisions 378217 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378218 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378219 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
configured codecs to take precedence on an outgoing call.
This change introduces a new peer configuration property named
'ignore_requested_pref' that causes the requested codec to be ignored when
determining the preferred codec for an outgoing call leg. The consequence is
that Asterisk's usual efforts to prefer avoiding transcoding can be overridden
on a peer-by-peer basis where appropriate.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377971 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
........
Merged revisions 377946 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 377947 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 377948 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The issue comes from the fact that transfers may perform
a redirecting update on a channel. The issue is that lock
inversion between the channel and its tech_pvt occurs since
the channel lock is released during the transfer process.
The fix is to move when the redirecting update occurs to a
place where neither the tech_pvt or the channel is locked so
that the two can be locked in the proper order.
(closes issue ASTERISK-20708)
reported by Mark Michelson
patches:
ASTERISK-20708-3.patch uploaded by Mark Michelson (License #5049)
Tested by:
Tim Ringenbach at Asteria Solutions Group
........
Merged revisions 377910 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377911 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
........
Merged revisions 377623 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 377624 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 377625 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377626 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
........
Merged revisions 377257 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 377258 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 377259 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
It was a mess. The first part of chan_sip.c is constants, declarations, structures and stuff,
then forward declarations and then actual code. It's still a mess, but a bit less messy ;-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Found a large amount of missing {} in the code before patching in another branch
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376998 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
........
Merged revisions 376901 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376916 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376917 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue ASTERISK-20724)
........
Merged revisions 376864 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376865 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376866 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|