https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r309445 | rmudgett | 2011-03-04 09:22:04 -0600 (Fri, 04 Mar 2011) | 46 lines
Get real channel of a DAHDI call.
Starting with Asterisk v1.8, the DAHDI channel name format was changed for
ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
There were several reasons that the channel name had to change.
1) Call completion requires a device state for ISDN phones. The generic
device state uses the channel name.
2) Calls do not necessarily have B channels. Calls placed on hold by an
ISDN phone do not have B channels.
3) The B channel a call initially requests may not be the B channel the
call ultimately uses. Changes to the internal implementation of the
Asterisk master channel list caused deadlock problems for chan_dahdi if it
needed to change the channel name. Chan_dahdi no longer changes the
channel name.
4) DTMF attended transfers now work with ISDN phones because the channel
name is "dialable" like the chan_sip channel names.
For various reasons, some people need to know which B channel a DAHDI call
is using.
* Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
in use by the channel. Use CHANNEL(no_media_path) to determine if the
channel even has a B channel.
* Added AMI event DAHDIChannel to associate a DAHDI channel with an
Asterisk channel so AMI applications can passively determine the B channel
currently in use. Calls with "no-media" as the DAHDIChannel do not have
an associated B channel. No-media calls are either on hold or
call-waiting.
(closes issue #17683)
Reported by: mrwho
Tested by: rmudgett
(closes issue #18603)
Reported by: arjankroon
Patches:
issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: stever28, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pass a MCID request to the bridged channel so the bridged channel can send
it to the network.
The ability to send the MCID request on an ISDN span is enabled with the
new chan_dahdi.conf mcid_send option.
JIRA SWP-2845
JIRA ABE-2736
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add and extend the see-also sections to the documentation for applications
and functions in an effort to expand the online documentation of the wiki.
Also check for and update any links to moved documentation in the doc folder.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@304913 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For each component, the set of valid BNF expansions defines exactly
which characters may appear unescaped. All other characters MUST be
escaped.
This patch modifies ast_uri_encode() to encode strings in line with this recommendation. This patch also adds an ast_escape_quoted() function which escapes '"' and '\' characters in quoted strings in accordance with section 25.1 of RFC 3261. The ast_uri_encode() function has also been modified to take an ast_flags struct describing the set of rules it should use when escaping characters to allow for it to escape SIP URIs in addition to HTTP URIs and other types of URIs or variations of those two URI types in the future.
The ast_uri_decode() function has also been modified to accept an ast_flags struct describing the set of rules to use when decoding to enable decoding '+' as ' ' in legacy http URLs.
The unit tests for these functions have also been updated.
ABE-2705
Review: https://reviewboard.asterisk.org/r/1081/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Discussion on #asterisk on 2011-01-19:
(02:07:03 PM) boch: i wonder how to cycle all entries in a tree
(02:07:11 PM) leifmadsen: use While()
(02:07:17 PM) leifmadsen: you need to know the tree structure already though
(02:07:36 PM) boch: what you mean?
(02:09:02 PM) leifmadsen: you need to know the structure prior to looping, because you can't just return the structure from the dialplan
(02:09:43 PM) leifmadsen: the only way I can think of doing that is via something like writing the output of: asterisk -rx "database show" to a file, then looping through that to know the structure of the database and check everything
(02:09:59 PM) leifmadsen: but at that point you're better off just using either a relational database or an external script
(02:10:13 PM) boch: for example i need to know all entries in the tree
(02:10:15 PM) boch: got it
(02:10:20 PM) leifmadsen: exactly
(02:10:22 PM) leifmadsen: that's the problem
(02:10:22 PM) boch: thank you
(02:13:09 PM) mateu: yeah, i'm surprised there isn't something from the dialplan like 'database show family' so one can get all keys in a family to loop over.
(02:15:35 PM) leifmadsen: database shows everything
(02:16:22 PM) mateu: i mean something from the dial plan that mimics 'database show <family>'
(02:16:41 PM) leifmadsen: guess no one has found that important enough to program :)
(02:16:52 PM) leifmadsen: at that point you should probably just use a relational database...
(02:17:10 PM) mateu: i dunno
(02:17:16 PM) mateu: seems pretty basic to me.
(02:17:16 PM) leifmadsen: me either
(02:17:19 PM) leifmadsen: sure does
(02:17:24 PM) leifmadsen: no one has programmed it though
(02:17:28 PM) ***leifmadsen shrugs
(02:17:43 PM) mateu: ok, well at least we know how it currently stands. thanks leifmadsen
(02:28:52 PM) Corydon76-home: leifmadsen: something like HASHKEYS() ?
(02:30:11 PM) leifmadsen: Corydon76-home: ummm, I was thinking more like DUNDI_QUERY() and DUNDI_RESULT()
(02:30:31 PM) leifmadsen: although HASHKEYS() might work
(02:30:58 PM) leifmadsen: actually ya, looking at it, similar to HASHKEYS()
(02:31:01 PM) leifmadsen: DBKEYS() I guess?
(02:31:45 PM) Corydon76-home: So with no argument, retrieves families, with an argument, retrieves keys of that family?
(02:34:02 PM) leifmadsen: ya
(02:34:16 PM) leifmadsen: how would you iterate through layers of them?
(02:34:30 PM) leifmadsen: i.e. family/key/key/key ?
(02:34:43 PM) Corydon76-home: Essentially, yes
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
Addition of the FrameHook API (AKA AwesomeHooks)
So far all our tools for viewing and manipulating media streams
within Asterisk have been entirely focused on audio. That made
sense then, but is not scalable now. The FrameHook API lets us
tap into and manipulate _ANY_ type of media or signaling passed
on a channel present today or in the future. This tool is a step
in the direction of expanding Asterisk's boundaries and will help
generate some rather interesting applications in the future.
In addition to the FrameHook API, a simple dialplan function
exercising the api has been included as well. This function
is called FRAME_TRACE(). FRAME_TRACE() allows for the internal
ast_frames read and written to a channel to be output. Filters
can be placed on this function to debug only certain types of frames.
This function could be thought of as an internal way of doing
ast_frame packet captures.
Review: https://reviewboard.asterisk.org/r/925/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286189 | twilson | 2010-09-10 17:04:53 -0500 (Fri, 10 Sep 2010) | 30 lines
Merged revisions 286115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286115 | twilson | 2010-09-10 15:35:25 -0500 (Fri, 10 Sep 2010) | 23 lines
Merged revisions 286059 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286059 | twilson | 2010-09-10 14:25:08 -0500 (Fri, 10 Sep 2010) | 16 lines
Inherit CHANNEL() writes to both sides of a Local channel
Having Local (/n) channels as queue members and setting the language in the
extension with Set(CHANNEL(language)=fr) sets the language on the Local/...,2
channel. Hold time report playbacks happen on the Local/...,1 channel and
therefor do not play in the specified language.
This patch modifies func_channel_write to call the setoption callback and pass
the CHANNEL() write info to the callback. chan_local uses this information to
look up the other side of the channel and apply the same changes to it.
(closes issue #17673)
Reported by: Guggemand
Review: https://reviewboard.asterisk.org/r/903/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
People expressed an interest in having access to the exact length of calls to a finer degree than seconds. See the CHANGES and UPGRADE.txt for usage also updated the sample configs to note the change.
Patch by snuffy.
(closes issue #16559)
Reported by: cianmaher
Tested by: cianmaher, snuffy
Review: https://reviewboard.asterisk.org/r/461/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This directs users to documents which can help explain the
concepts and configuration options settable with the function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258345 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows for multiple SRV queries to be done
from the dialplan for the same service on a single call while
still allowing one to bypass the call to SRVQUERY if they so
please.
Taking action since no comments had been left for a while.
This can easily be reverted if needed. External tests
still pass.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@257851 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Change copyright date
* Place channel in autoservice when doing SRV lookup
* Get rid of trailing whitespace
* Change logic in load_module function
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@257025 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Tilghman Lesher
David Vossel
Andrew Latham
Matthew Nicholson
Jeff Peeler
Terry Wilson
Russell Bryant
Bradley Latus
Mark Michelson