da0b057536
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 |
||
---|---|---|
build_tools | ||
doc | ||
asn1_primitive.c | ||
asn1.h | ||
compat.h | ||
compiler.h | ||
copy_string.c | ||
libpri.h | ||
LICENSE | ||
Makefile | ||
pri_aoc.c | ||
pri_cc.c | ||
pri_facility.c | ||
pri_facility.h | ||
pri_internal.h | ||
pri_q921.h | ||
pri_q931.h | ||
pri.c | ||
pridump.c | ||
prisched.c | ||
pritest.c | ||
q921.c | ||
q931.c | ||
README | ||
rose_address.c | ||
rose_etsi_aoc.c | ||
rose_etsi_cc.c | ||
rose_etsi_diversion.c | ||
rose_etsi_ect.c | ||
rose_etsi_mwi.c | ||
rose_internal.h | ||
rose_other.c | ||
rose_q931.c | ||
rose_qsig_aoc.c | ||
rose_qsig_cc.c | ||
rose_qsig_ct.c | ||
rose_qsig_diversion.c | ||
rose_qsig_mwi.c | ||
rose_qsig_name.c | ||
rose.c | ||
rose.h | ||
rosetest.c | ||
testprilib.c | ||
TODO |
libpri: An implementation of Primary Rate ISDN Written by Mark Spencer <markster@digium.com> What is libpri? =============== libpri is a C implementation of the Primary Rate ISDN specification. It was based on the Bellcore specification SR-NWT-002343 for National ISDN. As of May 12, 2001, it has been tested work with NI-2, Nortel DMS-100, and Lucent 5E Custom protocols on switches from Nortel and Lucent. What is the license for libpri? =============================== libpri is distributed under the terms of the GNU General Public License, which permit its use and linking with other GPL'd software only. The GNU GPL is included in the file LICENSE in this directory. As a special exception, libpri may also be linked to the OpenH323 library, so long as the entirity of the derivative work (as defined within the GPL) is licensed either under the MPL of the OpenH323 license or the GPL of libpri. If you wish to use libpri in an application for which the GPL is not appropriate (e.g. a proprietary embedded system), licenses for libpri under more flexible terms can be readily obtained through Digium, Inc. at reasonable cost. How do I report bugs or contribute? =================================== For now, contact the author directly. In the future if there is sufficient interest, we will setup a mailing list. Does anything use this library so far? ====================================== Yes, the Asterisk Open Source PBX does. http://www.asterisk.org Also, the Zapata library has hooks for it. http://www.zapatatelephony.org Special thanks ============== Special thanks to Jim Dixon <jim@lambdatel.com> for his help in testing and fixing the implementation.