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
For PTP links, libpri generated the PRI_EVENT_DCHAN_DOWN event every time
it failed to bring layer 2 up because the physical layer is down.
For PTP links, made generate the PRI_EVENT_DCHAN_UP/PRI_EVENT_DCHAN_DOWN
only when it enters/exits the Q.921 superstate consisting of states
7(Q921_MULTI_FRAME_ESTABLISHED) and 8(Q921_TIMER_RECOVERY).
Also changed the PTP link restart delay to be link specific instead of D
channel specific because the GR-303 PTP switch types have more than one
Q.921 link.
(closes issue #17270)
Reported by: jmls
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2113 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Made delay restarting the PTP layer 2 link by the T200 time instead of
immediately. Q.921 does not specify any particular time to restart the
layer 2 link. Q.921 leaves it up to the upper layers to decide when or if
another attempt to bring layer 2 up is made. Earlier versions of libpri
used the T200 time to restart the link.
This is a reimplementaion of -r1878.
(closes issue #18255)
Reported by: bklang
JIRA SWP-2508
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2111 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Clear mdl_error in case we could not schedule the handler callback.
* Change MDL handlers to not return the handled state since the caller did
not care.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2109 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* We should send the TEI identity denied message with TEI=127 when the TEI
pool is exhausted.
* We should remove our TEI if we see a TEI identity assign message
assigning our TEI to someone else.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2104 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Remove all TEIs when a NT PTMP link is started and there are no other
links to make sure there are no devices that think they have a TEI. A
device may think it has a TEI if the upper layer program is restarted or
the system reboots.
This fixes the bug portion of JIRA LIBPRI-51/SWP-2453.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2101 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The Cisco 1751 with VIC 2-BRI ports sends out SETUP messages on the
broadcast TEI as if the BRI were PTMP even though it is configured for PTP
mode.
Make PTP mode also accept frames on SAPI=0, TEI=127 (Broadcast).
(closes issue #18232)
Reported by: lelio
Patches:
issue18232_v1.4.patch uploaded by rmudgett (license 664)
Tested by: lelio
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2088 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
To have some support for dynamic interfaces, the master NFAS D channel
control structure will always exist even if it is abandoned/deleted by the
upper layer. The master/slave pointers ensure that the correct master
will be used.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2078 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
This is in anticipation of extracting a layer 2 link structure out of
struct pri.
Also fixes Q.921 timer value access. The timer access must always be on
the D channel control structure (Master).
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@2063 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
The Q.931 message decode debug output now will follow the correct Q.921
header decode if Q.921 message dumping is enabled. Also the Q.931 message
decode will happen when the message actually goes out on the line instead
of when Q.931 passes the message to Q.921. Q.921 may have to request a
TEI, bring the connection up, or retransmit previous frames before it can
actually send the new message.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1928 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Handle sending and receiving DM response frames as needed.
* Added handling of received FRMR frames.
* Completed implementation of Q921_AWAITING_RELEASE state. (State is
currently unreachable since we have no API to initiate sending the DISC
message.)
* Better NT PTMP TEI allocation.
* Reduced more ERROR level severity messages so users will stop panicking
when they see ERROR. This is especially true for the Q.921 MDL-ERROR
messages.
* Added better Q.921 visibility when normal debug message level is enabled.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1923 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Q.921 was getting stuck in state 2 (Q921_ASSIGN_AWAITING_TEI). For some
reason the network was removing the TEI. Libpri then immediately tried to
get a new TEI assigned. The network did not reply to the N202(3) attempts
to get a new TEI. Libpri then just gave up trying but did not leave the
state. Some paths in Q.921 Figure B.3 were not implemented.
Q.921 now transitions to the Q921_TEI_UNASSIGNED state when the N202 count
is exceeded. Q.921 will wait there until an incoming or outgoing call is
attempted.
* Fixed initializing the n202_counter. Not initializing the n202_counter
would cause the Q921_TEI_IDENTITY_REQUEST to unexpectedly not go out and
due to how state transitions were done, Q.921 would get stuck in the
Q921_ASSIGN_AWAITING_TEI state.
* Fixed start T202 timer fail causing Q.921 to get stuck in the
Q921_ASSIGN_AWAITING_TEI state if the network did not respond to the
request.
* Fixed handling of Q921_TEI_IDENTITY_REMOVE to do the MDL-REMOVE
primitive (q921_mdl_remove()) instead of transitioning directly to the
Q921_TEI_UNASSIGNED state. Necessary state clean-up was not getting done.
* Minor tweaks to q921_mdl_remove(). The worst problem was erroneously
generating an error message.
* Fixed potential for sending I-frames with an invalid TEI. The I-frame
could have been queued when Q.921 did not have an assigned TEI.
* Fixed testing of the q931_receive() return value when a UI-frame is
received.
(closes issue #17570)
Reported by: jcovert
Patches:
issue17570_v1.4.11.3_v3.patch uploaded by rmudgett (license 664)
issue17570_v1.4_v3.patch uploaded by rmudgett (license 664)
Tested by: jcovert, rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1918 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Minor comment correction in q931_destroycall().
* Redundant logic removal q931_destroycall().
"W && X && (Y || W && Z)" is the same as "W && X && (Y || Z)"
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1912 2fbb986a-6c06-0410-b554-c9c1f0a7f128
NOTE: To add support to send the old style name messages will require
implementing them as new ROSE operation message types.
NOTE: To actually use them would likely require implementing another
version of the Q.SIG switch type. Like (NI1 & NI2) and (4ess & 5ess) for
example.
Patches:
libpri37.patch uploaded by rmudgett (license 664)
JIRA SWP-2100
JIRA LIBPRI-37
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1904 2fbb986a-6c06-0410-b554-c9c1f0a7f128
Incoming calls specifying the channel using a slot map could not negotiate
a B channel correctly. Libpri historically has handled this as an any
channel request. However, when chan_dahdi picked a new channel, libpri
sent out the recorded slot map and not the new channel selected. Thus the
two endpoints would be attached to different B channels and the parties
would not hear anything or would hear the wrong parties.
This patch restores the historical preference of sending out the channel
id using the channel number method if a channel number is available.
JIRA LIBPRI-35
Patches:
libpri-35_v1.4.11.3.patch uploaded by rmudgett (license 664)
libpri-35_v1.4.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1853 2fbb986a-6c06-0410-b554-c9c1f0a7f128
* Debug output for a sent Q.931 message in TE PTMP now uses the best
available TEI number instead of always using 127. It could still be wrong
if layer 2 does not have a TEI assigned.
* Q.921 debug output is grouped better so a decoded message is not split
by a blank line.
* The Q.921 state is also decoded to a name.
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1848 2fbb986a-6c06-0410-b554-c9c1f0a7f128
The context tagging for my editor is much happier now that the struct and
the variable do not have the same name. (At least for this file.)
git-svn-id: https://origsvn.digium.com/svn/libpri/branches/1.4@1842 2fbb986a-6c06-0410-b554-c9c1f0a7f128
