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/
........
Merged revisions 387875 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@387880 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/
........
Merged revisions 387344 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@387345 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/
........
Merged revisions 387312 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@387319 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/11@387134 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385473 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385173 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384827 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/11@384003 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383878 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383166 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383125 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382848 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382739 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382322 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@381613 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@381566 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@381553 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@381282 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@380974 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@380698 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@380480 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@380465 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@380331 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@379393 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378934 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378559 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378321 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378287 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@377948 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@377910 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@377259 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376917 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/
........
Merged revisions 376834 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376835 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Websocket by default doesn't return an ast_str for the payload received. When
converting it to an ast_str on chan_sip the last character was being omitted,
because ast_str functions expects that the given length includes the trailing
0x00. payload_len only has the actual string length without counting the
trailing zero.
For most cases this passed unnoticed as most of SIP messages ends with \r\n.
(closes issue ASTERISK-20745)
Reported by: Iñaki Baz Castillo
Review: https://reviewboard.asterisk.org/r/2219/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk 11 follows RFC3265 that states that after every subscribe or resubscribe a notify should be sent.
Thus the console if filled continuously with the following after every subscribe;
== Extension Changed 8512[phones] new state IDLE for Notify User cisco1
In Asterisk 1.8 only changes would be sent. Thus only when a device state changed was anything emitted to the console.
fix:
Only print to console when device state isn't forced.
(closes issue ASTERISK-20706)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With ICE support enabled in chan_sip and a large number of interfaces on the system it was
possible for the produced SDP to be truncated due to some fixed size buffers. These buffers
have now been changed so they will dynamically grow as needed.
ICE support is now also enabled by default in res_rtp_asterisk to provide a smoother experience
for chan_motif users where it is required. To maintain the previous behavior in chan_sip it is
no longer enabled by default there.
(closes issue ASTERISK-20643)
Reported by: coopvr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at some debug logs, I noticed that it was being reported that the
SDP origin line was unsupported or failed. Upon looking into this on my local
machine, I found that I too was getting this debug message yet everything seemed
to be getting processed properly. What was discovered is, that, the variable to
determine what is displayed in the debug message for the SDP line that was
processed, was not being set for the origin line when the result was successful.
This patch fixes this and was tested on local machine.
........
Merged revisions 375594 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375601 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A regression was introduced in chan_sip by changes to sip reload introduced by
r349097. That patch moved peer purging from the beginning of the reload to
after the general configuration was finished. This patch fixes that by undoing
the repositioning of the original peer purging code and using a similar
function after performing general configuration that purges only autocreated
peers that were created when persist mode isn't enabled.
(closes issue ASTERISK-20611)
Reported by: Alisher
Review: https://reviewboard.asterisk.org/r/2171/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a "sip reload" is issued for a SIP peer, then his
IP address will be cleared, thus resulting in forgetting the
public IP address. Asterisk will then attempt to route SIP
traffic to the private IP address.
The fix here is to make "sip reload" ignore realtime peers
when "host = dynamic" is spotted. Realtime peers can now only
have their IP address reset if they have gone from being not
dynamic to being dynamic.
(closes issue ASTERISK-18203)
reported by daren ferreira
(closes issue ASTERISK-20572)
reported by JoshE
Patches:
fix_nat_realtime.diff uploaded by JoshE (license #6075)
........
Merged revisions 375415 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375417 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@375437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
