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: https://origsvn.digium.com/svn/asterisk/trunk@307883 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
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: https://origsvn.digium.com/svn/asterisk/trunk@306396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r305343 | rmudgett | 2011-01-31 18:01:09 -0600 (Mon, 31 Jan 2011) | 21 lines
Merged revisions 305342 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r305342 | rmudgett | 2011-01-31 17:50:10 -0600 (Mon, 31 Jan 2011) | 14 lines
Merged revisions 305341 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r305341 | rmudgett | 2011-01-31 17:45:58 -0600 (Mon, 31 Jan 2011) | 7 lines
Obtain the pri lock for PRI queue counters.
Need to obtain the pri lock when calling pri_dump_info_str() to avoid a
reentrancy problem when calculating the Q.921 Q count statistic.
JIRA AST-484
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@305344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@303772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r301946 | rmudgett | 2011-01-14 15:09:57 -0600 (Fri, 14 Jan 2011) | 13 lines
Deadlock between dahdi_request() and pri_dchannel() processing an incomming call.
The sig_pri_new_ast_channel() is called with the channel private lock held
when pri_dchannel() calls it and no channel private lock held when
dahdi_request() calls it. The use of pri_grab() in
sig_pri_new_ast_channel() could leave the channel private lock held when
it returns if the lock was not held before calling it.
Make sig_pri_new_ast_channel() just lock the PRI span lock instead of
using pri_grab(). It is safe to do this because dahdi_request() does not
have the channel private lock and the deadlock potential with the PRI span
lock is only between pri_dchannel() and other threads.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r300714 | rmudgett | 2011-01-05 14:54:21 -0600 (Wed, 05 Jan 2011) | 21 lines
Merged revision 300711 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r300711 | rmudgett | 2011-01-05 13:43:55 -0600 (Wed, 05 Jan 2011) | 14 lines
A call retrieved from hold may wind up with no audio.
If the retrieved call is natively bridged then the call may not have any
audio path. The following warning message is given:
"Failed to add <dfd> to conference <chan>/<chan>: Invalid argument".
* Open the media on a B channel when pri_fixup_principle() moves the call
from a no_b_channel channel to a real channel.
* Added lock protection while pri_fixup_principle() moves a call from one
private structure to another.
* Made some pri_fixup_principle() messages more meaningful.
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@300716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@300212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r299405 | rmudgett | 2010-12-21 20:10:39 -0600 (Tue, 21 Dec 2010) | 17 lines
Chan_dahdi sends an empty COLP on the bridged channel.
Chan_dahdi always inserts a connected party IE when you call from one
dahdi channel to another dahdi channel, even if no such information was
received on the 2nd channel. This clears the display of many phones.
* Removed leftover artifact from before the valid flag was added.
* Updated all of the channel's caller id information with the new
connected line information instead of just the string parts.
(closes issue #18508)
Reported by: wimpy
Patches:
issue18508_trunk.patch uploaded by rmudgett (license 664)
Tested by: wimpy, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r298195 | rmudgett | 2010-12-13 11:11:43 -0600 (Mon, 13 Dec 2010) | 33 lines
Merged revisions 298194 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r298194 | rmudgett | 2010-12-13 11:04:41 -0600 (Mon, 13 Dec 2010) | 26 lines
Merged revisions 298193 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r298193 | rmudgett | 2010-12-13 10:56:07 -0600 (Mon, 13 Dec 2010) | 19 lines
Outgoing PRI/BRI calls cannot do DTMF triggered transfers.
Outgoing PRI/BRI calls cannot do DTMF triggered transfers if a PROCEEDING
message is not received. The debug output shows that the DTMF begin event
is seen, but the DTMF end event is missing. When the DTMF begin happens,
the call is muted so we now have one way audio (until a DTMF end event is
somehow seen).
* Made set the proceeding flag when the PRI_EVENT_ANSWER event is
received.
* Made absorb the DTMF begin and DTMF end events if we are overlap dialing
and have not seen a PROCEEDING message.
* Added a debug message when absorbing a DTMF event.
JIRA SWP-2690
JIRA ABE-2697
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@298201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@294824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294349 | rmudgett | 2010-11-09 10:55:32 -0600 (Tue, 09 Nov 2010) | 17 lines
Analog lines do not transfer CONNECTED LINE or execute the interception macros.
Add connected line update for sig_analog transfers and simplify the
corresponding sig_pri and chan_misdn transfer code.
Note that if you create a three-way call in sig_analog before transferring
the call, the distinction of the caller/callee interception macros make
little sense. The interception macro writer needs to be prepared for
either caller/callee macro to be executed. The current implementation
swaps which caller/callee interception macro is executed after a three-way
call is created.
Review: https://reviewboard.asterisk.org/r/996/
JIRA ABE-2589
JIRA SWP-2372
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r292704 | rmudgett | 2010-10-22 10:47:08 -0500 (Fri, 22 Oct 2010) | 19 lines
Connected line is not updated when chan_dahdi/sig_pri or chan_misdn transfers a call.
When a call is transfered by ECT or implicitly by disconnect in sig_pri or
implicitly by disconnect in chan_misdn, the connected line information is
not exchanged. The connected line interception macros also need to be
executed if defined.
The CALLER interception macro is executed for the held call.
The CALLEE interception macro is executed for the active/ringing call.
JIRA ABE-2589
JIRA SWP-2296
Patches:
abe_2589_c3bier.patch uploaded by rmudgett (license 664)
abe_2589_v1.8_v2.patch uploaded by rmudgett (license 664)
Review: https://reviewboard.asterisk.org/r/958/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r292489 | rmudgett | 2010-10-20 20:02:50 -0500 (Wed, 20 Oct 2010) | 7 lines
Send CONNECT_ACKNOWLEDGE for CIS calls too.
The originator of the Q.SIG call completion signaling link was not changed
to the active state when the CONNECT message came in. The T309 processing
would immediately kill the signaling link because it was not in the active
state.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286118 | rmudgett | 2010-09-10 15:55:37 -0500 (Fri, 10 Sep 2010) | 25 lines
Merged revisions 286116 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286116 | rmudgett | 2010-09-10 15:42:44 -0500 (Fri, 10 Sep 2010) | 18 lines
Merged revisions 286113 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286113 | rmudgett | 2010-09-10 15:33:16 -0500 (Fri, 10 Sep 2010) | 11 lines
An outgoing call may not get hung up if a pre-connect incoming ISDN call is disconnected.
If the ISDN link a pre-connect incoming call is using fails or is reset,
the outgoing leg may not hang up or be delayed in hanging up. (Causes:
PRI_CAUSE_NETWORK_OUT_OF_ORDER, PRI_CAUSE_DESTINATION_OUT_OF_ORDER, and
PRI_CAUSE_NORMAL_TEMPORARY_FAILURE.)
Just hang up the call if the incoming call leg hangs up before connecting
for any reason. It makes no sense to send a BUSY or CONGESTION control
frame to the outgoing call leg under these circumstances.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283050 | rmudgett | 2010-08-20 10:35:38 -0500 (Fri, 20 Aug 2010) | 36 lines
Merged revisions 283049 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r283049 | rmudgett | 2010-08-20 10:31:03 -0500 (Fri, 20 Aug 2010) | 29 lines
Merged revisions 283048 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r283048 | rmudgett | 2010-08-20 10:24:36 -0500 (Fri, 20 Aug 2010) | 22 lines
Q931 - Sending PROGRESS after sending ALERTING is a protocol error
The PRI layer in chan_dadhi will check if a PROGRESS message has already
been sent, and not allow sending another (although that is technically
allowed by the Q931 spec), however it does not protect against sending an
ALERTING and then sending a PROGRESS message, which is a violation of the
specification.
Most switches don't seem to care too deeply about this, but some do, and
will disconnect the call when receiving this invalid sequence.
Protocol specification reference: T-REC-Q.931-199805-I page 223, "Figure
A.5/Q.931 -- Overview protocol control (network side) point-point
(sheet 3 of 8)"
(closes issue #17874)
Reported by: nic_bellamy
Patches:
asterisk-1.4-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-1.6.2-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-trunk-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279916 | russell | 2010-07-27 14:50:56 -0500 (Tue, 27 Jul 2010) | 12 lines
Fix inband DTMF detection on outgoing ISDN calls.
This is a regression from the sig_pri split from chan_dahdi. When a call is
first initiated, the inband DTMF detector is not enabled if it's an outgoing
ISDN call. However, it needs to be turned on once the media path starts up.
This handling was put back in the open_media() callback of chan_dahdi. In
sig_pri, open_media() calls were added to a few places where it was needed,
including handling of PRI_EVENT_RINGING, PRI_EVENT_PROGRESS, and
PRI_EVENT_PROCEEDING.
Thanks to rmudgett for helping me with the patch!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279917 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
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: https://origsvn.digium.com/svn/asterisk/trunk@268774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem would manifest itself if your dialplan matching could accept
more digits to match than were actually dialed. The time out waiting for
overlap digits disconnected the call instead of matching any accumulated
digits to the dialplan.
Accidental conversion of a break out of loop as a break out of switch.
(closes issue #17401)
Reported by: avalentin
Patches:
issue17401_digit_timeout.patch uploaded by rmudgett (license 664)
Tested by: avalentin, rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@267261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@266926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision -r1489 of the libpri 1.4 branch corrected a deviation from Q.931
Section 5.3.2. However, this resulted in an unexpected behaviour change
to the upper layer (Asterisk).
This change uses pri_hangup_fix_enable() to follow Q.931 Section 5.3.2
call hangup better if the version of libpri supports it.
(issue #17104)
Reported by: shawkris
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pri_dchannel thread currently violates locking order by locking the private
and then attempting to queue a frame, which needs to lock the channel. Queueing
a frame is unneccesary though and is actually a regression since sig_pri.
All the places that currently use ast_softhangup_nolock now will just set the
softhangup value directly as before.
(closes issue #17216)
Reported by: lmsteffan
Patches:
bug17216.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made more places use pri_queue_control() instead of pri_queue_frame()
and a local frame variable.
* Made pri_queue_frame() use sig_pri_lock_owner(). pri_queue_frame() no
longer releases the libpri access lock unless it is required.
* Made the pri_queue_frame() and pri_queue_control() parameter list
similar to sig_pri_lock_owner().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@261007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@260435 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
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: https://origsvn.digium.com/svn/asterisk/trunk@251538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.
Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.
Verified that our local TELCO also does the same.
(issue #16789)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@249320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Allows CDR variables added in cdr.c:set_one_cid to become visable during the call,
by executing ast_cdr_update() early in __ast_pbx run.
Reverts sig_pri changes in trunk that are specific to isdn technology only.
(closes issue #16638)
Reported by: alecdavis
Patches:
cdr_update.diff3.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Allows CDR variables added in cdr.c:set_one_cid to become visable during the call.
(issue #16638)
Reported by: alecdavis
Patches:
cdr_update.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Allows CDR variables added in cdr.c:set_one_cid to become visable during the call.
(closes issue #16638)
Reported by: alecdavis
Patches:
cdr_update.diff.txt uploaded by alecdavis (license 585)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@231058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Dial(DAHDI/g1[/extension[/options]])
Current options:
K(<keypad_digits>)
R Reverse charging indication (Collect calls)
The earlier Dial(DAHDI/g1[/K<keypad_digits>][/extension] format was
variable and did not allow for the easy addition of more options.
The earlier 'C' prefix character for reverse charge indiation would
conflict with the a-d DTMF digits if ISDN uses them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@226882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Cleanup some flags on DAHDI PRI channel hangup. (sig_pri split)
* Make sure the outgoing flag is cleared if a new channel fails to get
created for outgoing calls.
* Remove some unused flags since sig_pri was split.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* 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: https://origsvn.digium.com/svn/asterisk/trunk@225692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Telecom Specs in NZ suggests that SUB ADDRESS is always on, so doing
"desk to desk" between offices each with an asterisk box over the ISDN
should then be possible, without a whole load of DDI numbers required.
(closes issue #15604)
Reported by: alecdavis
Patches:
asterisk_subaddr_trunk.diff11.txt uploaded by alecdavis (license 585)
Some minor modificatons were made.
Tested by: alecdavis, rmudgett
Review: https://reviewboard.asterisk.org/r/405/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224330 | jpeeler | 2009-10-16 20:32:47 -0500 (Fri, 16 Oct 2009) | 13 lines
Fix stale caller id data from being reported in AMI NewChannel event
The problem here is that chan_dahdi is designed in such a way to set
certain values in the dahdi_pvt only once. One of those such values
is the configured caller id data in chan_dahdi.conf. For PRI, the
configured caller id data could be overwritten during a call. Instead
of saving the data and restoring, it was decided that for all non-analog
channels it was simply best to not set the configured caller id in the
first place and also clear it at the end of the call.
(closes issue #15883)
Reported by: jsmith
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224260 | rmudgett | 2009-10-16 15:25:23 -0500 (Fri, 16 Oct 2009) | 18 lines
Never released PRI channels when using Busy() or Congestion() dialplan apps.
When the Busy() or Congestion() application is used towards ISDN (an ISDN
progress is sent), the responding ISDN Disconnect or Release may contain
the ISDN cause user busy or one of the congestion causes. In chan_dahdi.c
these causes will only set the needbusy or needcongestion flags and not
activate the softhangup procedure. Unfortunately only the latter can
interrupt the endless wait loop of Busy()/Congestion().
Result: PRI channels staying in state busy for the rest of asterisk life
or until the other end times out and forces the call to clear.
(issue #14292)
Reported by: tomaso
Patches:
disc_rel_userbusy.patch uploaded by tomaso (license 564)
(This patch is unrelated to the issue.)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@213007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
Dialplan starts execution before the channel setup is complete.
* Issue 15655: For the case where dialing is complete for an incoming
call, dahdi_new() was asked to start the PBX and then the code set more
channel variables. If the dialplan hungup before these channel variables
got set, asterisk would likely crash.
* Fixed potential for overlap incoming call to erroneously set channel
variables as global dialplan variables if the ast_channel structure failed
to get allocated.
* Added missing set of CALLINGSUBADDR in the dialing is complete case.
(closes issue #15655)
Reported by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Moved SUPPORT_USERUSER to sig_pri.c
* Fix PRI_DEADLOCK_AVOIDANCE parameter.
* Whitespace changes.
* Added missing unlock in pri_dchannel():PRI_EVENT_RING case.
* Balanced curly braces.
* ast_debug/ast_log changes from chan_dahdi.
* sig_pri_indicate() should default to return -1 if the indication is not
handled.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@208267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@206767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also go back and wrap all of the places that use the specific reverse charge
APIs with preprocessor conditionals.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204919 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@204749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203908 | rmudgett | 2009-06-26 19:55:12 -0500 (Fri, 26 Jun 2009) | 16 lines
The ISDN CPE side should not exclusively pick B channels normally.
Before this patch, Asterisk unconditionally picked B channels exclusively
on the CPE side and normally allowed alternative B channels on the network
side. Now Asterisk does the opposite.
Reasons for the CPE side to normally not pick B channels exclusively:
* For CPE point-to-multipoint mode (i.e. phone side), the CPE side does
not have enough information to exclusively pick B channels. (There may be
other devices on the line.)
* Q.931 gives preference to the network side picking B channels.
* Some telcos require the CPE side to not pick B channels exclusively.
(closes issue #14383)
Reported by: mbrancaleoni
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203909 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This merge splits the PRI/BRI signaling logic out of chan_dahdi.c into
sig_pri.c. Functionality in theory should not change (mostly). A few trivial
changes were made in sig_analog with verbose messages and commenting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Paul Belanger
Tilghman Lesher
Sean Bright
Russell Bryant
Jeff Peeler
Mark Michelson
Alec L Davis
Kevin P. Fleming
Joshua Colp