Kevin P. Fleming [Mon, 27 Jul 2009 21:43:36 +0000 (21:43 +0000)]
Cleanup T.38 negotiation changes.
Convert LOG_NOTICE messages about T.38 negotiation in debug level 1 messages,
clean up some looping logic, and correct an improper use of ast_free() for
freeing an ast_frame.
Kevin P. Fleming [Mon, 27 Jul 2009 21:21:43 +0000 (21:21 +0000)]
Make T.38 switchover in ReceiveFAX synchronous.
In receive mode, if the channel that ReceiveFAX is running on supports T.38,
we should *always* attempt to switch T.38, rather than listening for an incoming
CNG tone and only triggering on that. The channel may be using a low-bitrate
codec that distorts the CNG tone, the sending FAX endpoint may not send CNG
at all, or there could be a variety of other reasons that we don't detect it,
but in all those cases if T.38 is available we certainly want to use it.
Allow for UDPTL to use only even-numbered ports if desired.
There are some VoIP providers out there that will not accept SDP
offers with odd numbered UDPTL ports. While it is my personal opinion
that these VoIP providers are misinterpreting RFC 2327, it really is
not a big deal to play along with their silly little games. Of course,
since restricting UDPTL ports to only even numbers reduces the range
of available ports by half, so the option to use only even port numbers
is off by default. A user can enable the behavior by setting
use_even_ports=yes in udptl.conf.
Kevin P. Fleming [Mon, 27 Jul 2009 15:38:59 +0000 (15:38 +0000)]
Restore explicit export of ASTCFLAGS/ASTLDFLAGS and underscore-variants to sub-makes.
During the recent Makefile improvements I made, it seemed the 'make' was
automatically carrying down the ASTCFLAGS/ASTLDFLAGS settings to sub-makes,
so I removed the explict export of them. However, there are some circumstances
where make does this, and some where it does not, so I've brought them back
to ensure they are always exported. I also removed an extraneous double setting
of _ASTLDFLAGS on *BSD platforms.
pthread_self returns a pthread_t which is not an unsigned int on all
pthread implementations. Casting it to an unsigned int fixes compiler warnings.
........
Mostly trivial changes, but I did not know of any other way to fix the
"dereferencing type-punned pointer will break strict-aliasing rules" error
without creating a tmp variable in chan_skinny.
........
Russell Bryant [Fri, 24 Jul 2009 20:54:37 +0000 (20:54 +0000)]
Note that "reload" needs to be added back.
I keep getting annoyed at having to type "module reload" to reload everything,
so I'm adding a note that we need to add "reload" back. "module reload" doesn't
really make sense as the command to reload everything, including the core.
Don't impose an arbitrary limit on member lines in queues.conf
I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"
Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.
Only send a BYE when hanging up a channel that is up.
For cases where Asterisk sends an INVITE and receives a non 2XX final
response, Asterisk would follow the INVITE transaction by immediately
sending a BYE, which was unnecessary.
Kevin P. Fleming [Fri, 24 Jul 2009 15:02:53 +0000 (15:02 +0000)]
Resolve a T.38 negotiation issue left over from the udptl-updates merge.
The udptl-updates branch that was merged yesterday failed to properly send back
T.38 SDP responses with the correct error correction mode, if the incoming SDP
from the other end caused us to change error correction modes. This patch
corrects that situation.
Kevin P. Fleming [Thu, 23 Jul 2009 21:57:24 +0000 (21:57 +0000)]
Rework of T.38 negotiation and UDPTL API to address interoperability problems
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Fix a problem where a 491 response could be sent out of dialog.
This generalizes the fix for issue 13849. The initial fix corrected the
problem that Asterisk would reply with a 491 if a reinvite were received
from an endpoint and we had not yet received an ACK from that endpoint
for the initial INVITE it had sent us. This expansion also allows Asterisk
to appropriately handle an INVITE with authorization credentials if Asterisk
had not received an ACK from the previous transaction in which Asterisk had
responded to an unauthorized INVITE with a 407.
Jeff Peeler [Thu, 23 Jul 2009 15:59:44 +0000 (15:59 +0000)]
Fix sending of interface identifier unconditionally in sig_pri
The wrong logic was being used in chan_dahdi to convert a sig_pri_chan
to the proper libpri channel number. The most significant bit must only
be set only when trunk groups are being used.
Jeff Peeler [Wed, 22 Jul 2009 22:42:33 +0000 (22:42 +0000)]
Reset the fax buffers back to default settings regardless of signaling in use -
Pointed out by Matt F.
Also in the case of not using a signaling module, set the law back to the
default as well.
Jason Parker [Wed, 22 Jul 2009 21:43:57 +0000 (21:43 +0000)]
Restore an int declaration on PPC platforms.
This x is one crafty little bugger...
It was used for 2 different things (one of which was only done on PPC) in 1.4.
One of the uses were removed in trunk, and with it went the declaration.
Clarify documentation on 'realtime update2' to show more than one condition.
(closes issue #15357)
Reported by: snuffy
Patches:
bug_fix_doc_update2.diff uploaded by snuffy (license 35)
(slightly modified by me)
Force an error if a blank is passed to QUOTE (because the documentation states the argument is not optional).
This change makes URIENCODE and QUOTE behave similarly, since the documentation
states that the argument is not optional, for both.
(closes issue #15439)
Reported by: pkempgen
Patches:
20090706__issue15439.diff.txt uploaded by tilghman (license 14)
........
Wait for wink before dialing when using E&M wink signaling
There was already code for other signaling types in dahdi_handle_event to
handle dialing if a dial operation dial string was present. Simply add
SIG_EMWINK to the list.
Ensure that user-provided CFLAGS and LDFLAGS are honored.
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
........
David Vossel [Mon, 20 Jul 2009 20:45:26 +0000 (20:45 +0000)]
reg->username is parsed only once on sip reload
The registration string can contain an expanded user portion of the
form user@domain. This expanded user portion was stored in
reg->username and parsed each time there is a registration refresh.
Now, the domain portion of the user is parsed and stored separately
in the regdomain field.
(closes issue #14331)
Reported by: Nick_Lewis
Patches:
chan_sip.c.domainparse3.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis, dvossel
Answer video SDP offers properly when videosupport is not enabled.
Copied from Review board:
In issue 12434, the reporter describes a situation in which audio and video
is offered on the call, but because videosupport is disabled in sip.conf,
Asterisk gives no response at all to the video offer. According to RFC 3264,
all media offers should have a corresponding answer. For offers we do not
intend to actually reply to with meaningful values, we should still reply
with the port for the media stream set to 0.
In this patch, we take note of what types of media have been offered and
save the information on the sip_pvt. The SDP in the response will take into
account whether media was offered. If we are not otherwise going to answer
a media offer, we will insert an appropriate m= line with the port set to 0.
It is important to note that this patch is pretty much a bandage being
applied to a broken bone. The patch *only* helps for situations where video
is offered but videosupport is disabled and when udptl_pt is disabled but
T.38 is offered. Asterisk is not guaranteed to respond to every media offer.
Notable cases are when multiple streams of the same type are offered.
The 2 media stream limit is still present with this patch, too.
In trunk and the 1.6.X branches, things will be a bit different since Asterisk
also supports text in SDPs as well.
Only do the chan->fdno check in ast_read() in a developer build.
I changed this check to only happen in a dev-mode build. I also added a
comment explaining what is going on. I also made it so that detection of
this situation does not affect ast_read() operation.
Fixed incoming calls being matched to MSNs without type-of-number prefix added.
For an incoming ISDN call the dialed.number is incorrectly matched against
the configured MSNs in misdn.conf. The numbers passed to the dialplan
include the configured prefix for the dialed.number_type, whereas the
check against the configured MSNs (to decide if the call is accepted at
all), is executed without the configured prefix.
e.g., dialed.number = 241168020, TON = national, configured national
prefix is "0". (This is the TON which is used by ISDN providers in the
Netherlands.)
In chan_misdn.c:cb_events() in case EVENT_SETUP the call to
misdn_cfg_is_msn_valid() uses the unnormalized number 241168020, but 57
lines later the call to read_config() adds the prefix, and the
dialed.number is now 0241168020, which is then used in the dialplan.
misdn_cfg_is_msn_valid() must use the normalized number, too.
channels/chan_misdn.c
* Made bearer2str() use allowed_bearers_array[]
* Made use the causes.h defines instead of hardcoded numbers.
* Made use Asterisk presentation indicator values if either of the
mISDN presentation or screen options are negative.
* Updated the misdn_set_opt application option descriptions.
* Renamed the awkward Caller ID presentation misdn_set_opt
application option value not_screened to restricted.
Deprecated the not_screened option value.
channels/misdn/isdn_lib.c
* Made use the causes.h defines instead of hardcoded numbers.
* Fixed some spelling errors and typos.
* Added all defined facility code strings to fac2str().
channels/misdn/isdn_lib.h
* Added doxygen comments to struct misdn_bchannel.
channels/misdn/isdn_lib_intern.h
* Added doxygen comments to struct misdn_stack.
channels/misdn_config.c
configs/misdn.conf.sample
* Updated the mISDN presentation and screen parameter descriptions.
doc/misdn.txt (doc/tex/misdn.tex)
* Updated the misdn_set_opt application option descriptions.
* Fixed some spelling errors and typos.
................
r158010 | rmudgett | 2008-11-19 19:46:09 -0600 (Wed, 19 Nov 2008) | 9 lines
Merged revision 157977 from
https://origsvn.digium.com/svn/asterisk/team/group/issue8824
........
Fixes JIRA ABE-1726
The dial extension could be empty if you are using MISDN_KEYPAD
to control ISDN provider features.
................
Enhance configuration option for overlapdial allowing direction choice
Previously overlap dialing could only be turned on or off for both incoming and
outgoing calls. New parameters incoming, outgoing, and both have been added to
allow further control. There is no change in default behavior with these new
options and allows in band DTMF to be accepted in one direction if required.
Jeff Peeler [Fri, 17 Jul 2009 17:02:44 +0000 (17:02 +0000)]
Fix segfault in sig_analog when using callwaiting, respect callwaiting options
Sig_analog handles allocating the sub channel for callwaiting, so no longer try
to do it in chan_dahdi. Modified analog_alloc_sub to only mark the sub as
allocated upon success of the alloc_sub callback, which was responsible for the
segfault. Also, the callwaiting and callwaitingcallerid options were being
unconditionally set to true. Now, the options are properly set from
chan_dahdi.conf.
SIP incorrect From: header information when callpres is prohib
Some ITSP make use of the "Anonymous" display name to detect a
requirement to withhold caller id across the PSTN. This does
not work if the display name is "Unknown".
(closes issue #14465)
Reported by: Nick_Lewis
Patches:
chan_sip.c-callerpres.patch uploaded by Nick (license 657)
chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
........
If the CALLERPRES() dialplan function is set to nothing,
a segfault occurs. This is user error to begin with, but
I'd rather see a cli warning message than have Asterisk
crash on me.
........
Jeff Peeler [Wed, 15 Jul 2009 22:02:55 +0000 (22:02 +0000)]
The dialing flag was mistakingly removed from sig_pri.
This readds the proper setting of the flag and is really a continuation of
r205731. The flag was being set properly in sig_analog, but use of the
newly added set_dialing callback allowed for some simplification in
chan_dahdi.
Merged revision 206700 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
Fixed chan_misdn crash because mISDNuser library is not thread safe.
With Asterisk the mISDNuser library is driven by two threads concurrently:
1. channels/misdn/isdn_lib.c::manager_event_handler()
2. channels/misdn/isdn_lib.c::misdn_lib_isdn_event_catcher()
Calls into the library are done concurrently and recursively from
isdn_lib.c.
Both threads can fiddle with the master/child layer3_proc_t lists. One
thread may traverse the list when the other interrupts it and then removes
the list element which the first thread was currently handling. This is
exactly what caused the crash. About 60 calls were needed to a Gigaset
CX475 before it occurred once.
This patch adds locking when calling into the mISDNuser library.
This also fixes some cb_log calls with wrong port parameter.
David Vossel [Wed, 15 Jul 2009 20:20:01 +0000 (20:20 +0000)]
callerid(num) is wrong when username is missing
A domain only sip uri <sip:123.123.123.123> would return
123.123.123.123 as callid num. Now, if the username is
missing from a uri, the callerid num field is left empty.
Document all meetme realtime fields, and in the process, make some field lengths more consistent.
(closes issue #15493)
Reported by: lasko
Patches:
meetme.diff uploaded by lasko (license 833)
Jeff Peeler [Tue, 14 Jul 2009 20:01:10 +0000 (20:01 +0000)]
Restore some missing functionality to sig_analog.
The main purpose of this commit is to restore missing functionality present in
the ss_thread before all the sig related work was done. Two of the biggest
missing things were distinctive ring detection and cid handling for V23.
fxsoffhookstate and associated mwi variables have been moved inside sig_analog
as they were not being set properly as well.
Fixes several call transfer issues with chan_misdn.
* issue #14355 - Crash if attempt to transfer a call to an application.
Masquerade the other pair of the four asterisk channels involved in the
two calls. The held call already must be a bridged call (not an
applicaton) or it would have been rejected.
* issue #14692 - Held calls are not automatically cleared after transfer.
Allow the core to initate disconnect of held calls to the ISDN port. This
also fixes a similar case where the party on hold hangs up before being
transferred or taken off hold.
* JIRA ABE-1903 - Orphaned held calls left in music-on-hold.
Do not simply block passing the hangup event on held calls to asterisk
core.
* Fixed to allow held calls to be transferred to ringing calls.
Previously, held calls could only be transferred to connected calls.
* Eliminated unused call states to simplify hangup code.
* Eliminated most uses of "holded" because it is not a word.
Mark Michelson [Tue, 14 Jul 2009 16:09:38 +0000 (16:09 +0000)]
Reset the sentringing indication when redirects occur.
If a redirecting control frame is processed or a call forward occurs,
we need to reset the sentringing flag so that we can send another ringing
indication to the phone that may contain a connected line update.
Ensure apathetic replies are sent out on the proper socket.
chan_iax2 supports multiple address bindings. The send_apathetic_reply()
function did not attempt to send its response on the same socket that the
incoming message came in on.
........
................
Russell Bryant [Sat, 11 Jul 2009 19:15:03 +0000 (19:15 +0000)]
Add an API for reporting security events, and a security event logging module.
This commit introduces the security events API. This API is to be used by
Asterisk components to report events that have security implications.
A simple example is when a connection is made but fails authentication. These
events can be used by external tools manipulate firewall rules or something
similar after detecting unusual activity based on security events.
Inside of Asterisk, the events go through the ast_event API. This means that
they have a binary encoding, and it is easy to write code to subscribe to these
events and do something with them.
One module is provided that is a subscriber to these events - res_security_log.
This module turns security events into a parseable text format and sends them
to the "security" logger level. Using logger.conf, these log entries may be
sent to a file, or to syslog.
One service, AMI, has been fully updated for reporting security events.
AMI was chosen as it was a fairly straight forward service to convert.
The next target will be chan_sip. That will be more complicated and will
be done as its own project as the next phase of security events work.
For more information on the security events framework, see the documentation
generated from doc/tex/. "make asterisk.pdf"
David Vossel [Fri, 10 Jul 2009 21:42:10 +0000 (21:42 +0000)]
SIP register not using peer's outbound proxy
If callbackextension is defined for a peer it successfully causes
a registration to occur, but the registration ignores the
outboundproxy settings for the peer. This patch allows the
peer to be passed to obproxy_get() in transmit_register().
Ensure that outbound NOTIFY requests are properly routed through stateful proxies.
With this change, we make note of Record-Route headers present in any SUBSCRIBE
request that we receive so that our outbound NOTIFY requests will have the proper
Route headers in them.
If an endpoint sends two registration requests in a very short
period of time with the same nonce, both receive 401 responses
from Asterisk, each with a different nonce (the second 401
containing the current nonce and the first one being stale).
If the endpoint responds to the first 401, it does not match
the current nonce so Asterisk sends a third 401 with a newly
generated nonce (which updates the current nonce)... Now if
the endpoint responds to the second 401, it does not match the
current nonce either and Asterisk sends a fourth 401 with a
newly generated nonce... This loop goes on and on.
There appears to be a simple fix for this. If the nonce from
the request does not match our nonce, but is a good response
to a previous nonce, instead of sending a 401 with a newly
generated nonce, use the current one instead. This breaks
the loop as the nonce is not updated until a response is
received. Additional logic has been added to make sure no
nonce can be responded to twice though.
Kevin P. Fleming [Fri, 10 Jul 2009 16:00:44 +0000 (16:00 +0000)]
Eliminate extraneous LOG_DEBUG messages generated by app_fax.
The transmit_audio() and transmit_t38() functions in app_fax have processing
loops that are supposed to wait for frames to arrive on the channel and then
handle them, but they also have short timeouts so that the loops can have
watchdog timers and do other required processing. This commit changes the loops
to not actually call ast_read() and attempt to process the returned frame
unless a frame actually arrived, eliminating hundreds of LOG_DEBUG messages
and slightly improving performance.
Ensure that outbound NOTIFY requests are properly routed through stateful proxies.
With this change, we make note of Record-Route headers present in any SUBSCRIBE
request that we receive so that our outbound NOTIFY requests will have the proper
Route headers in them.
Kevin P. Fleming [Fri, 10 Jul 2009 15:28:11 +0000 (15:28 +0000)]
Fix some remaining T.38 negotiation problems in app_fax.
Revision 205696 did not quite fix all the issues with the T.38 negotiation
changes and app_fax; this patch corrects them, along with a couple of other
minor issues.
projects / thirdparty / asterisk.git / log
