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
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
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
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
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
* 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
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.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2190 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Add the Q931_IE_TIME_DATE with the current date/time of the system to the
Q.931 CONNECT message when in network mode. The date/time IE allows
attached equipment to synchronize their clock with the network. Most
notably, ISDN phones can display the current date/time.
See issue #18047 about a concern with non-conforming Siemens terminals.
(closes issue #18047)
Reported by: wuwu
Patches:
timedate.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA SWP-2955
JIRA ABE-2747
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2187 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Removed the conditional LIBPRI_COUNTERS to include the code
unconditionally.
Patches:
enable_LIBPRI_COUNTERS_LIBPRI-61.diff uploaded by jbigelow
JIRA LIBPRI-61
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2183 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* The PTMP redirection signaling (NOTIFY redirection number and
notification code, SETUP redirecting number) is also sent in PTMP/TE mode.
It should only apply in PTMP/NT mode. The call setup proceeds but the
network (Deutsche Telekom) reacts with ugly ISDN STATUS messages.
* Don't send the redirecting number ie when PTP is also sending the
DivertingLegInformation2 facility. The redirecting number ie is redundant
and the network (Deutsche Telekom) complains about it.
JIRA LIBPRI-53
JIRA SWP-2543
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2175 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Resend standard facility ies when the SETUP is retried by Q.931. However,
one time facility ies are no longer available to add to a retried SETUP
message.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2174 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Add the ability to exchange subaddresses for ETSI PTMP, ETSI PTP, and
Q.SIG for call transfer.
* Fix ETSI PTMP to send the correct messages depending on the call state
for call transfer. NOTE: Some ISDN phones only handle the NOTIFY message
that the EN 300-369 spec says should be sent only if the call has not
connected yet.
JIRA LIBPRI-47
JIRA SWP-2363
Review: https://reviewboard.asterisk.org/r/1051/
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2172 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The upper layer is now initiating HOLD/RETRIEVE signaling. These changes
are needed to help preserve the correct channel id after a collision.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2170 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Incoming calls with CC enabled will not automatically clear the CC offer
record when the call is aborted by T309 processing. All CC agent FSM's
have this problem (PTMP, PTP, and Q.SIG).
To reproduce:
1) Place incoming call to Asterisk/libpri
2) Either before or after the call is answered, bring the ISDN link down.
3) T309 processing, T309 timeout, or TEI removal will leave the CC agent
FSM in the CC available state.
The problem is indicated by the "cc report status" CLI command showing a
status of CC offered to caller but it will never timeout.
The FSM's can be manually cleared by using the "cc cancel all" or "cc
cancel core" CLI commands.
JIRA LIBPRI-46
JIRA SWP-2241
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2079 2fbb986a-6c06-0410-b554-c9c1f0a7f128
This completes the layer 2 link and Q.931 call control restructuring.
Some code is now simplified since there is only one D channel control
structure and the amount of allocated memory is reduced.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2077 2fbb986a-6c06-0410-b554-c9c1f0a7f128
This is in anticipation of extracting a layer 2 link structure out of
struct pri.
Also completes fixing timer value access for the rest of libpri. The
timer access must always be on the D channel control structure (Master).
May have fixed some events from timeouts not being passed to the upper
layer. The timeout events must always be on the D channel control
structure (Master).
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2070 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Fix double free of a call record and the subsequent continued use of the
freed call record when receiving an unsupported/unknown message type.
(closes issue #17968)
Reported by: gelo
Patches:
issue_17968_v1.4.patch uploaded by rmudgett (license 664)
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2021 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Validate the given call pointer in libpri API calls. If the call pointer
is not an active call record then a complaint message is issued and the
API call aborts. The call pointer is likely stale.
This patch is defensive. More information is needed to figure out why
Asterisk still has a call pointer during its hangup sequence.
(closes issue #17522)
(closes issue #18032)
Reported by: schmoozecom
Patches:
issue_18032_v1.4.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2015 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The DL-ESTABLISH confirm event was not passed from Q.921 to Q.931 so Q.931
never cancelled the T309 timer.
Refactored q931_dl_tei_removal() and q931_dl_indication() into
q931_dl_event() to allow the DL-ESTABLISH confirm/indication and
DL-RELEASE confirm/indication events to be passed to Q.931.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1991 2fbb986a-6c06-0410-b554-c9c1f0a7f128
If the connection to the terminal is lost while there are open channels
on the interface, red alarm is reported, but the open channels are never
cleared. Additionally, if you manually try to channel request hangup,
Asterisk crashes.
For PTMP, the T309 processing was not searching the call pool on the
master control record. Additionally, for NT PTMP, the timeout events were
not passed to the upper layer because the events were not put on the
master control record where timer processing expects them.
(closes issue #17865)
Reported by: wimpy
Patches:
issue17865_v1.4.patch uploaded by rmudgett (license 664)
Tested by: rmudgett, wimpy
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1982 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Q.921 was passing a q931_dl_indication(up) event to Q.931 before it was
finished processing the frame. The q931_dl_indication(up) event could
immediately send STATUS messages in the Q.921 intermediate state that
would then get stuck in the tx queue with an invalid N(S).
Q.921 was passing i-frames to Q.931 before it was finished processing the
frame. The i-frames could cause Q.931 to immediately generate a response
message that may cause the peer to see the P/F bit as incorrect.
Delayed passing q931_dl_indication(up) events and i-frames to Q.931 until
Q.921 has completed processing the frame event. (The Q.921 SDL diagrams
were designed with this assumption.)
(closes issue #17360)
Reported by: shawkris
Patches:
issue17360_v1.4.patch uploaded by rmudgett (license 664)
Tested by: shawkris, rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1962 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Filter the processing of the CONNECT message to prevent libpri from
sending a CONNECT ACKNOWLEDGE when the call is in an inappropriate state.
This can happen when we hang up an outgoing call after the other end has
sent a CONNECT but before we have processed the CONNECT.
(issue #17360)
Reported by: shawkris
Patches:
issue17360_con_ack_v1.4.patch uploaded by rmudgett (license 664)
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1961 2fbb986a-6c06-0410-b554-c9c1f0a7f128
