Some switches have extended subaddress ie octet 3 encoding to be
multi-octet.
* Update dump and receive helper functions to search for the end of octet
3 encoding to determine where octet 4 starts.
ASTERISK-27342
Change-Id: I5b2706f668e1a4664b020a58de41dad4cbc5c7e6
Work around a bug in a Lucent switch implementation that sets the
extension bit in octet 3 even though octet 3a is present.
The same issue was seen in a NI2 switch implementation. It was probably a
Lucent switch configured for NI2 operation. To avoid further surprises,
I'm going to enable the work around for all North American switch types.
PRI-183
Reported by: Richard Mudgett
Change-Id: I7eedbf68b7c3d9c868d9533012e4cea5142af281
A bug in a Lucent switch implementation sets the Connected Number
information element octet 3 extension bit. When set that means octet 3 is
complete and thus there is no optional octet 3a. However, the buggy
switch still sends octet 3a. The unexpected octet 3a is interpreted as
the first octet 4 and thus the first character in the connected line
number is a garbage character.
* Work around the switch bug by checking octet 3 and the potential octet
3a extension bits. If they are both set then assume that octet 3a is
actually present for the buggy switch types.
PRI-183 #close
Reported by: Richard Mudgett
Change-Id: I378af37bfd852737a0bfe6263ef3473ea6acfbad
There are two scenarios that are exposed by DISCONNECT not initializing
the progress indicator value before processing the message when the
chan_dahdi.conf inbanddisconnect=yes option is set.
1) If a DISCONNECT comes in without a Progress Indicator ie and an earlier
message (such as SETUP-ACKNOWLEDGE or PROCEEDING) came in with the
indicator #8 (Inband audio present) then the DISCONNECT would not cause an
immediate hangup. We would be letting the user hear the inband audio even
though there isn't any.
2) If a DISCONNECT message comes in with the indicator #8 (Inband audio
present) and then later the DISCONNECT message is repeated without a
Progress Indicator ie we would still ignore the second DISCONNECT to let
the user hear inband audio even though it likely isn't there anymore.
PRI-180 #close
Reported by: Alexandr Dranchuk
Change-Id: Ic88aafb45053146b5701d666e6212f7555573624
When the pri_set_inbanddisconnect() option is enabled and the call has not
been answered when a DISCONNECT with progress indicator #8 (Inband audio
present) is received, then report the event as a PROGRESS with progress
indicator #8 (Inband audio present) instead. Substituting a PROGRESS
event allows the upper layer to open the media path if it isn't already
open so the user can hear the inband audio message.
PRI-180
Reported by: Alexandr Dranchuk
Change-Id: I62313bf9cc1d2f3b0231f0c07a784717ddba0415
Libpri was lax in checking if a missing channel identification ie is
mandatory for the SETUP ACKNOWLEDGE, PROCEEDING, ALERTING, and CONNECT
messages. That ie is mandatory when those messages are the first response
to a SETUP message sent by the CPE side.
* Made those messages check if a missing channel identification ie is
mandatory and send a STATUS with cause 96 "Mandatory information element
is missing" in response.
Libpri did not care if a mandatory ie had a coding error.
* Made coding errors in mandatory ie's send a STATUS with cause 100
"Invalid information element contents" in response.
* Fixed detection of coding errors in channel identification ie.
SWP-8721
SWP-8722
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2337 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The conditional is to only remove the Progress Indicator ie from being
added to select messages.
* Made so the ALERTING message can have the User-User ie if needed when
ALERTING_NO_PROGRESS is defined.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2335 2fbb986a-6c06-0410-b554-c9c1f0a7f128
An incoming SETUP message needs to reject the invalid ie 0x01 on switches
other than 4ESS, 5ESS, NI2, and DMS-100.
LIBPRI-74 #close
Reported by: Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2333 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Add checks to send STATUS messages when receiving SETUP ACKNOWLEDGE,
ALERTING, and CONNECT ACKNOWLEDGE messages when in the wrong call state.
LIBPRI-76 #close
Reported by: Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2331 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Q.931 Section 3.1.6 INFORMATION message. The keypad-facility or
called-party-number ie could be used to convey called party digits. The
keypad-facility ie can also be used to convey supplementary service
information.
PRI-173 #close
Reported by: Gerald Schnabel
Patches:
libpri_q931_keypad_digits.patch (license #6297) patch uploaded by Gerald Schnabel
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2327 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The minimum T202 time specified in Q.921 Section 5.9.7 is 2 seconds. It
makes sense to set the value to the minimum 2 seconds in order to more
likely get a TEI value before an outgoing call request aborts from T303
timeouts.
PRI-171 #close
Reported by: dcolombo
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2322 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Added support to the libpri API to control the inband audio available
progress indication ie on the SETUP_ACKNOWLEDGE message.
* Added the progress indication ie progressmask value to the struct
pri_event_setup_ack so the PRI_EVENT_SETUP_ACK event can indicate when a
SETUP_ACKNOWLEDGE comes in with inband audio (ie dialtone).
* Added pri_setup_ack() so when the SETUP_ACKNOWLEDGE message is sent it
can indicate if inband audio is present (ie dialtone).
This patch and a corresponding change in Asterisk work together to allow
Asterisk to control the inband audio available progress indication ie on
the SETUP_ACKNOWLEDGE message when dialtone is present.
AST-1338 #close
Reported by: Tyler Stewart
Review: https://reviewboard.asterisk.org/r/3520/
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2320 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Some BRI devices in France insist on checking TEI's when in point-to-point
mode. If they don't get a response for TEI 0 they drop layer 1 even
though libpri keeps trying to bring layer 2 up.
* Made q921_mdl_receive() handle TEI check request messages in TE-PTP
mode. Had to change q921_mdl_send()/Q921_INIT() because the PTP modes do
not setup a link structure specifically for MDL as the PTMP modes do.
* Fixed q921_tei_check()/t201_expire() to check TEI's even if the network
side doesn't have any assigned. This should make TE's that request the
TEI verify procedure (Q.921 Section 5.3.5) happy when the network side
doesn't have any TEI's allocated.
PRI-165
Reported by: Denis Alberto Martinez
Patches:
jira_pri_165_ptp_respond_tei_check.patch (license #5621) patch uploaded by rmudgett
Review: https://reviewboard.asterisk.org/r/3434/
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2318 2fbb986a-6c06-0410-b554-c9c1f0a7f128
If the network stops responding, according to Q.921 we are supposed to
remove the TEI. With the layer2_persistence option enabled, we are
supposed to keep trying to bring layer 2 back up. Unfortunately, when the
network stops responding, we stopped the restart timer and removed the
TEI. As a result, layer 2 does not immediately come back up.
* Made not stop the restart timer if we are removing the TEI on the CPE
side. Also handle the timer expiration in relevant unassigned TEI states.
(closes issue LIBPRI-72)
Reported by: Trey Blancher
Patches:
jira_dahdi_1001_libpri_v1.4.patch (license #5621) patch uploaded by rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2315 2fbb986a-6c06-0410-b554-c9c1f0a7f128
If the MSB of octet 3 is 0 then the optional Recommendation octet 3a is
present.
References: ITU-T Q.850 Section 2.1 and ETSI ETS 300 102-1 Section 4.5.12.
(closes issue PRI-151)
Reported by: Tzafrir Cohen
Patches:
0001-handle-optional-Recommendation-in-Cause-IE.patch (license #5035) patch uploaded by Tzafrir Cohen
Modified
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2310 2fbb986a-6c06-0410-b554-c9c1f0a7f128
ECMA-143 Section 10.1.7.2 indicates that PROGRESS is allowed when in the
Active state.
* Made Q.SIG ignore the PROGRESS message when in the Active call state.
(closes issue PRI-147)
Reported by: Nick Merrett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2308 2fbb986a-6c06-0410-b554-c9c1f0a7f128
With gcc 4.6.3 it's possible to get the following error:
$ make
gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g -fPIC -O2 -MD -MT pridump.o -MF .pridump.o.d -MP -c -o pridump.o pridump.c
pridump.c: In function \u2018pri_bridge\u2019:
pridump.c:117:1: error: no return statement in function returning non-void [-Werror=return-type]
cc1: all warnings being treated as errors
make: *** [pridump.o] Error 1
Changing the function return value to void fixes the issue since there
were no places in the code that used the return value.
(closes issue PRI-143)
Reported by: Birger "WIMPy" Harzenetter
Patches:
0001-Fix-no-return-statement-in-function-returning-non-vo.patch (license #5417) patch uploaded by Shaun Ruffell
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2298 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Made compile the pritest, rosetest, and testprilib utilities using the
static libpri library. No more forgetting to install the library after a
change and wondering why it still did not work. The pridump utility is
still dynamically linked.
* Made compile the utilities by default.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2294 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Some telco switches send out MDL messages even though they are configured
for PTP. Usually they are checking for assigned TEI's. Since these
switches periodically poll for assigned TEI's, the message needlessly
fills up log files.
* Changed message warning level to a normal debug message level and
reworded.
(closes issue PRI-137)
Reported by: Bart Coninckx
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2290 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Q.931 defines the T316 timer to retransmit RESTART messages if a RESTART
ACKNOWLEDGE message is not received before the timer expires. Q.931
defaults the time of T316 to 2 minutes with the default number of
consecutive RESTART failures as two.
* To support legacy behavior, the T316 timer is disabled by default. It
is also disabled because the user cannot configure it to disabled if it is
enabled.
* The N316 count is created to allow the number of RESTART attempts to be
configurable. Note you will need to recompile Asterisk to be able to
configure N316.
(issue ASTERISK-19608)
(issue AST-815)
(closes issue PRI-133)
Reported by: Mike Boylan
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2288 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Q.951 indicates that when the presentation indicator is "Number not
available due to interworking" for a number then the screening indicator
field should be "Network provided".
Released versions of Asterisk starting with v1.8 relesed before this patch
only recognized the PRES_NUMBER_NOT_AVAILABLE value as an unavailable
number. This patch improves compatibility as a result.
* Made mask the presentation value for names and numbers from the upper
layer.
* Made pri_mwi_indicate_v2() also call q931_party_id_fixup() for
completeness even though it is a noop in this case.
* Made pri_pres2str() deceoode better.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2284 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Sometimes ie values received from carriers contain nul octets in values
normally treated by libpri as nul terminated strings. A discussion on the
asterisk-users list determined that the best thing to do in the situation
is to delete the nul octets and unconditionally report/log when that
happens.
* Remove nul octets from the following ie's and generate an unconditional
log message to the upper layer when they are removed:
Connected Number
Connected Address
Redirecting Number
Original Called Number
Redirection Number
Called Party Number
Calling Party Number
Display
Keypad Facility
(closes issue PRI-128)
Reported by: phsultan
Patches:
jira_pri_128.patch (license #5621) patch uploaded by rmudgett (modified)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2278 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The channel id ie can supply a slotmap or list of channels. For a RESTART
message, this can be handy to indicate multiple channels that need to be
restarted at the same time.
An incoming RESTART request will now generate a PRI_EVENT_RESTART to the
upper layer for each channel indicated in the request. If the event is
successfully generated for all indicated channels then a
RESTART_ACKNOWLEDGE is sent back to the peer indicating all channels
restarted.
* Add the ability to process a channel id ie channel list with a RESTART
request.
* Add the ability to process slotmaps with a RESTART request.
(closes issue PRI-93)
Reported by: Marcin Kowalczyk
Patches:
jira_pri_93.patch (license #5621) patch uploaded by rmudgett
Tested by: zvision, rmudgett
(closes issue PRI-71)
Reported by: Torrey Searle
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2277 2fbb986a-6c06-0410-b554-c9c1f0a7f128
France Telecom brings layer 2 and layer 1 down on BRI lines when the line
is idle. When layer 1 goes down Asterisk cannot make outgoing calls and
the HA8 and HB8 cards also get IRQ misses.
The inability to make outgoing calls is because the line is in red alarm
and Asterisk will not make calls over a line it considers unavailable.
The IRQ misses for the HA8 and HB8 card are because the hardware is
switching clock sources from the line which just brought layer 1 down to
internal timing.
There is a DAHDI option for the B410P card to not tell Asterisk that layer
1 went down so Asterisk will allow outgoing calls: "modprobe wcb4xxp
teignored=1". There is a similar DAHDI option for the HA8 and HB8 cards:
"modprobe wctdm24xxp bri_teignored=1". Unfortunately that will not clear
up the IRQ misses when the telco brings layer 1 down.
* Add layer 2 persistence option to customize the layer 2 behavior on BRI
PTMP lines. The new option has three settings: 1) Use libpri default
layer 2 setting. 2) Keep layer 2 up. Bring layer 2 back up when the peer
brings it down. 3) Leave layer 2 down when the peer brings it down.
Layer 2 will be brought up as needed for outgoing calls.
(issue AST-598)
Reported by: Trey Blancher
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2273 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The NEC SV8300 rejects the Q931_IE_TIME_DATE for Q.SIG.
Add option to specify if and how much of the current time is put in
Q931_IE_TIME_DATE.
* Send date/time ie never.
* Send date/time ie date only.
* Send date/time ie date and hour.
* Send date/time ie date, hour, and minute.
* Send date/time ie date, hour, minute, and second.
* Send date/time ie default: Libpri will send date and hhmm only when in
NT PTMP mode to support ISDN phones.
(closes issue #19221)
Reported by: kenner
JIRA SWP-3396
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2266 2fbb986a-6c06-0410-b554-c9c1f0a7f128
1) The "controlling user number" is always the number of the voice mail box
which is identical with the subscriber number itself. This number which
is listed in the ISDN phone MWI menu cannot be called back to contact the
voice mail box. The controlling user number should be made configurable.
2) The MWI indication is not restricted to a user (broadcast facility with
dummy call reference). A called party IE should be added to address only
the relevant MSN. (ETSI 300-196 Section 8.3.2.4)
JIRA ABE-2738
JIRA SWP-2846
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2262 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Send the CallRerouting response on the next message instead of only on the
DISCONNECT message. The next message is either going to be a DISCONNECT
or RELEASE depending on who initiates disconnection first.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2258 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Fixed stopping T303 too early on a NT PTMP broadcast SETUP call if a
subcall just receives a RELEASE_COMPLETE(busy).
* Fixed a valgrind reported invalid read/write when hanging up a NT PTMP
broadcast SETUP call.
JIRA LIBPRI-32
JIRA SWP-2548
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2238 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Add BRI and PTMP strings to node type config when configured that way.
* Move Q.921 statistics to after configuration settings.
* Add call and cc_record debug statistics to pri_dump_info_str().
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2232 2fbb986a-6c06-0410-b554-c9c1f0a7f128
A phone's RELEASE_COMPLETE as a response to an initial broadcast SETUP
blocks one B channel permantly when the call is cancelled.
Scenario: A call to the ISDN Bus is acknowledged (ALERTING) by one
phone/endpoint and rejected by another phone/endpoint with a
RELEASE_COMPLETE. The call is then cancelled by the caller. If the whole
procedure is repeated once again then any further call attempt is rejected
(WARNING[5666]: app_dial.c:1546 dial_exec_full: Unable to create channel
of type 'DAHDI' (cause 34 - Circuit/channel congestion)). It seems that
receiving a RELEASE_COMPLETE in that state blocks one B channel
permanently when the call is cancelled by the caller.
Background: The ISDN phones (Siemens Gigaset 3035 or CX253) we use for
testing additionally contain a DECT base station, which operates as a
different endpoint on the ISDN Bus (TEI). If the DECT base station is not
in use then there are no DECT phones registered to the base station. The
DECT base station responds to an incoming call not directed toward it with
(RELEASE_COMPLETE, cause: no user responding).
* Made initiate_hangup_if_needed() also hangup the subcall if it is in the
NULL state.
* Simplified q931_set_subcall_winner().
JIRA ABE-2745
JIRA SWP-2954
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2207 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Looks like DMS-100 is using the same message as Q.SIG to receive the
caller name.
Add the ability to decode the ROSE calling name message defined for the
Q.SIG switch on the DMS-100 switch.
(closes issue #18822)
Reported by: cmorford
Patches:
issue18822_v1.4.patch uploaded by rmudgett (license 664)
Tested by: cmorford
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2206 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Reordered NI2 ROSE message table so any conflicts with the pirated Q.SIG
messages will be in favor of the NI2 specific messages. This is
precautionary only.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2204 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Sergey V. Lobanov