List the current mapping of DAHDI B channels to Asterisk channel names and
which calls are on hold or call-waiting. Calls on hold or call-waiting
are not associated with any B channel.
JIRA LIBPRI-27
JIRA SWP-2547
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@307964 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r307879 | rmudgett | 2011-02-15 10:13:55 -0600 (Tue, 15 Feb 2011) | 37 lines
No response sent for SIP CC subscribe/resubscribe request.
Asterisk does not send a response if we try to subscribe for call
completion after we have received a 180 Ringing. You can only subscribe
for call completion when the call has been cleared.
When we receive the 180 Ringing, for this call, its call-completion state
is 'CC_AVAILABLE'. If we then send a subscribe message to Asterisk, it
trys to change the call-completion state to 'CC_CALLER_REQUESTED'.
Because this is an invalid state change, it just ignores the message. The
only state Asterisk will accept our subscribe message is in the
'CC_CALLER_OFFERED' state.
Asterisk will go into the 'CC_CALLER_OFFERED' when the SIP client clears
the call by sending a CANCEL.
Asterisk should always send a response. Even if its a negative one.
The fix is to allow for the CCSS core to notify a CC agent that a failure
has occurred when CC is requested. The "ack" callback is replaced with a
"respond" callback. The "respond" callback has a parameter indicating
either a successful response or a specific type of failure that may need
to be communicated to the requester.
(closes issue #18336)
Reported by: GeorgeKonopacki
Tested by: mmichelson, rmudgett
JIRA SWP-2633
(closes issue #18337)
Reported by: GeorgeKonopacki
Tested by: mmichelson
JIRA SWP-2634
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@307883 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@306755 f38db490-d61c-443f-a65b-d21fe96a405b
The display ie handling can be controlled independently in the send and
receive directions with the following options:
* Block display text data.
* Use display text in SETUP/CONNECT messages for name.
* Use display text for COLP name updates (FACILITY/NOTIFY as appropriate).
* Pass arbitrary display text during a call. Sent in INFORMATION
messages. Received from any message that the display text was not used as
a name.
If the display options are not set then the options default to legacy
behavior.
The arbitrary display text is exchanged between bridged channels using the
AST_FRAME_TEXT frame type.
To send display text from the dialplan use the SendText() application when
the arbitrary display text option is enabled.
JIRA SWP-2688
JIRA ABE-2693
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@306396 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r303771 | rmudgett | 2011-01-25 11:49:20 -0600 (Tue, 25 Jan 2011) | 54 lines
Merged revisions 303769 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303769 | rmudgett | 2011-01-25 11:42:42 -0600 (Tue, 25 Jan 2011) | 47 lines
Merged revisions 303765 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303765 | rmudgett | 2011-01-25 11:36:50 -0600 (Tue, 25 Jan 2011) | 40 lines
Sending out unnecessary PROCEEDING messages breaks overlap dialing.
Issue #16789 was a good idea. Unfortunately, it breaks overlap dialing
through Asterisk. There is not enough information available at this point
to know if dialing is complete. The ast_exists_extension(),
ast_matchmore_extension(), and ast_canmatch_extension() calls are not
adequate to detect a dial through extension pattern of "_9!".
Workaround is to use the dialplan Proceeding() application early in
non-dial through extensions.
* Effectively revert issue #16789.
* Allow outgoing overlap dialing to hear dialtone and other early media.
A PROGRESS "inband-information is now available" message is now sent after
the SETUP_ACKNOWLEDGE message for non-digital calls. An
AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
messages for non-digital calls.
* Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
inconsistent with the cause codes.
* Added better protection from sending out of sequence messages by
combining several flags into a single enum value representing call
progress level.
* Added diagnostic messages for deferred overlap digits handling corner
cases.
(closes issue #17085)
Reported by: shawkris
(closes issue #18509)
Reported by: wimpy
Patches:
issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
and SS7 because of backporting requirements.
Tested by: wimpy, rmudgett
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@303772 f38db490-d61c-443f-a65b-d21fe96a405b
Added the moh_signaling option to specify what to do when the channel's
bridged peer puts the ISDN channel on and off of hold.
Implemented as a FSM to control libpri ISDN signaling when the bridged
peer places the channel on and off of hold with the AST_CONTROL_HOLD and
AST_CONTROL_UNHOLD control frames.
JIRA SWP-2687
JIRA ABE-2691
Review: https://reviewboard.asterisk.org/r/1063/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@300212 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296167 | rmudgett | 2010-11-24 16:49:48 -0600 (Wed, 24 Nov 2010) | 57 lines
Merged revisions 296166 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296166 | rmudgett | 2010-11-24 16:42:45 -0600 (Wed, 24 Nov 2010) | 50 lines
Merged revisions 296165 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296165 | rmudgett | 2010-11-24 16:41:07 -0600 (Wed, 24 Nov 2010) | 43 lines
Oneway audio to SIP phone from FXS port after FXS port gets a CallWaiting pip.
The FXS connected phone has to have CW/CID support to fail, as it will
send back a DTMF 'A' or 'D' when it's ready to receive CallerID. A normal
phone with no CID never fails. Also the SIP phone does not hear MOH when
the CW call is answered.
The DTMF end frame is suppressed when the phone acknowledges the CW signal
for CID. The problem is the DTMF begin frame needs to be suppressed as
well. The DTMF begin frame is causing SIP to start sending the DTMF RTP
frames. Since the DTMF end frame is suppressed, SIP will not stop sending
those DTMF RTP packets.
* Suppress the DTMF begin and end frames when the channel driver is
looking for DTMF digits.
* Fixed a couple issues caused by not cleaning up the CID spill if you
answer the CW call while it is sending the CID spill.
* Fixed not sending CW/CID spill to the phone when the call is natively
bridged. (Fixed by not using native bridge if CW/CID is possible.)
* Suppress received audio when sending CW/CID spills. The other parties
involved do not need to hear the CW/CID spills and may be confused if the
CW call is for them.
(closes issue #18129)
Reported by: alecdavis
Patches:
issue_18129_v1.8_v3.patch uploaded by rmudgett (license 664)
Tested by: alecdavis, rmudgett
NOTE:
* v1.4 does not have the main problem fixed by suppressing the DTMF start
frames. The other three items fixed are relevant.
* If you really must restore native bridging between analog ports, you
need to disable CW/CID either by configuring chan_dahdi.conf
callwaitingcallerid=no or dialing *70 before dialing the number to
temporarily disable CW.
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@296168 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294823 | rmudgett | 2010-11-11 20:45:22 -0600 (Thu, 11 Nov 2010) | 25 lines
Merged revisions 294822 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r294822 | rmudgett | 2010-11-11 20:44:12 -0600 (Thu, 11 Nov 2010) | 18 lines
Merged revisions 294821 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294821 | rmudgett | 2010-11-11 20:41:13 -0600 (Thu, 11 Nov 2010) | 11 lines
Asterisk is getting a "No D-channels available!" warning message every 4 seconds.
Asterisk is just whining too much with this message: "No D-channels
available! Using Primary channel XXX as D-channel anyway!".
Filtered the message so it only comes out once if there is no D channel
available without an intervening D channel available period.
(closes issue #17270)
Reported by: jmls
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@294824 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282671 | rmudgett | 2010-08-18 10:27:51 -0500 (Wed, 18 Aug 2010) | 1 line
Use the correct operator when calculating the PRI span devstate.
........
r282672 | rmudgett | 2010-08-18 10:28:27 -0500 (Wed, 18 Aug 2010) | 1 line
Use the correct type for aoce_delayhangup bit field.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@282673 f38db490-d61c-443f-a65b-d21fe96a405b
Extract the SS7 specific code out of chan_dahdi like what was done to
ISDN/PRI and analog signaling. The new SS7 structures were modeled on
sig_pri.
The changes to sig_pri are an enhancement and a bug fix made possible
because SS7 was extracted.
1) The sig_pri TRANSFERCAPABILITY channel variable should have been set
unconditionally in sig_pri_new_ast_channel().
2) SS7/PRI transfer capability interaction in dahdi_new() fixed because of
SS7 extraction.
3) Module ref count error in dahdi_new() if startpbx failed to start the
PBX for some reason.
Review: https://reviewboard.asterisk.org/r/661/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@268774 f38db490-d61c-443f-a65b-d21fe96a405b
Add the ability to announce a call to an endpoint when there are no B
channels available. A call waiting call is a SETUP message with no B
channel selected.
Relevant specification: EN 300 056, EN 300 057, EN 300 058
For DAHDI/ISDN channels, the CHANNEL() dialplan function now supports the
"no_media_path" option.
* Returns "0" if there is a B channel associated with the call.
* Returns "1" if no B channel is associated with the call. The call is
either on hold or is a call waiting call.
If you are going to allow incoming call waiting calls then you need to use
CHANNEL(no_media_path) do determine if you must drop a call to accept the
new call.
Review: https://reviewboard.asterisk.org/r/568/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267261 f38db490-d61c-443f-a65b-d21fe96a405b
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@267096 f38db490-d61c-443f-a65b-d21fe96a405b
Added ability to send and receive ETSI Explicit Call Transfer (ECT)
messages to eliminate tromboned calls.
Note: Asterisk already supported initiating the transfer of calls to
eliminate tromboned calls to libpri so there was nothing to do for the
asterisk portion.
Review: https://reviewboard.asterisk.org/r/520/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@266926 f38db490-d61c-443f-a65b-d21fe96a405b
The CLI "dahdi show channel" command was not correctly reporting the
InAlarm status.
The inalarm flag is now consistently passed between chan_dahdi and
submodules.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@261007 f38db490-d61c-443f-a65b-d21fe96a405b
Created
SIG_PRI_MAX_CHANNELS, SIG_PRI_NUM_DCHANS
SIG_SS7_MAX_CHANNELS, SIG_SS7_NUM_DCHANS
SIG_MFCR2_MAX_CHANNELS
Also fixed the declaration of pollers[] in mfcr2_monitor(). It was
dimensioned to the number of bytes in struct dahdi_mfcr2.pvts[] and not to
the same dimension of the struct dahdi_mfcr2.pvts[].
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@260435 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@256528 f38db490-d61c-443f-a65b-d21fe96a405b
Rework HAVE_PRI_SERVICE_MESSAGES to not use the active values directly
from the database. Database access is likely expensive. Database access
now only happens on initialization, destruction, and when the B channel is
taken in or out of service.
This change is not related to call waiting but it would cause the search
for a call waiting interface to be very expensive and slow down D channel
message servicing.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@251538 f38db490-d61c-443f-a65b-d21fe96a405b
Changed areas in sig_pri to set the digital flag using a callback that will
also set the corresponding flag in chan_dahdi. Modified dahdi_request slightly
so that if a bearer is marked as digital, that information is available when
creating the new channel.
(closes issue #16151)
Reported by: alecdavis
Patch based on bug_16151.diff.txt uploaded by alecdavis (license 585)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@231058 f38db490-d61c-443f-a65b-d21fe96a405b
Since ISDN works like SIP and not analog ports in regard to devices, the
device state based on the ISDN channel number could not work. This has
not been an issue until the advent of PTMP NT mode. Previously, ISDN
lines were used as trunks and did not have to keep track of specific
devices.
As an interim solution until device states are properly implemented, the
channel name is being changed to the following format to use the generic
device state support:
DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
Dialplan hints would thus be:
exten => xxx,hint,DAHDI/i2/5551212
This will work with the following restrictions:
* The number of devices/phones cannot exceed the number of B channels.
(i.e., BRI has 2)
* Each device/phone can only have one number. No shared MSN's.
* The phones/devices probably should not use subaddressing.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@226882 f38db490-d61c-443f-a65b-d21fe96a405b
* Added handling of received HOLD/RETRIEVE messages and the optional ability
to transfer a held call on disconnect similar to an analog phone.
* Added CallRerouting/CallDeflection support for Q.SIG, ETSI PTP, ETSI PTMP.
Will reroute/deflect an outgoing call when receive the message.
Can use the DAHDISendCallreroutingFacility to send the message for the
supported switches.
* Added ability to send/receive keypad digits in the SETUP message.
Send keypad digits in SETUP message: Dial(DAHDI/g1[/K<keypad_digits>][/extension])
Access any received keypad digits in SETUP message by: ${CHANNEL(keypad_digits)}
* Added support for BRI PTMP NT mode.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@225692 f38db490-d61c-443f-a65b-d21fe96a405b
The PRI channels can no longer change the channel name if a different B
channel is selected during call negotiation. To prevent using the channel
name to infer what B channel a call is using and to avoid name collisions,
the channel name format is changed.
The new channel naming for PRI channels is:
DAHDI/ISDN-<span>-<sequence-number>
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@221701 f38db490-d61c-443f-a65b-d21fe96a405b
Add Connected Line Presentation (COLP) support to chan_dahdi/libpri as an
addition to issue 8824. This is the chan_dahdi/sig_pri portion. COLP
support is now available for any switch for which libpri supports COLP
(currently ETSI PTP, ETSI PTMP, and Q.SIG) with this patch.
(closes issue #14068)
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/340/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@213007 f38db490-d61c-443f-a65b-d21fe96a405b
Putting some DSP code back into sig_pri that was removed by the
chan_dahdi/sig_pri reorganization.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@211392 f38db490-d61c-443f-a65b-d21fe96a405b
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.
(closes issue #15452)
Reported by: alecdavis
Patches:
bug15452.patch uploaded by jpeeler (license 325)
Tested by: alecdavis
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@208267 f38db490-d61c-443f-a65b-d21fe96a405b
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.
(closes issue #15486)
Reported by: rmudgett
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@206767 f38db490-d61c-443f-a65b-d21fe96a405b
Also go back and wrap all of the places that use the specific reverse charge
APIs with preprocessor conditionals.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204919 f38db490-d61c-443f-a65b-d21fe96a405b
This is a continuation of revision 885 to LibPRI (Capture and expose the Reverse
Charging Indication IE on ISDN PRI) which added the ability to get/set Reverse
Charging Indication in LibPRI. This patch adds the ability to specify RCI on
the outbound leg of a PRI call from within Asterisk, by prefixing the dialed
number with a capital 'C' like:
...,Dial(DAHDI/g1/C4445556666)
And to read it off an inbound channel:
exten => s,1,Set(RCI=${CHANNEL(reversecharge)})
Thanks again to rmudgett for the thorough review.
(closes issue #13760)
Reported by: mrgabu
Review: https://reviewboard.asterisk.org/r/303/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204749 f38db490-d61c-443f-a65b-d21fe96a405b
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@203638 f38db490-d61c-443f-a65b-d21fe96a405b
