[thirdparty-commits] rmudgett: tag mISDNuser/1.1.2 r128 - /mISDNuser/tags/1.1.2/
SVN commits to the Digium third-party software repository
thirdparty-commits at lists.digium.com
Tue Aug 4 15:35:57 CDT 2009
Author: rmudgett
Date: Tue Aug 4 15:35:54 2009
New Revision: 128
URL: http://svn.asterisk.org/svn-view/thirdparty?view=rev&rev=128
Log:
Importing files for 1.1.2 release.
Added:
mISDNuser/tags/1.1.2/.version (with props)
mISDNuser/tags/1.1.2/ChangeLog (with props)
Added: mISDNuser/tags/1.1.2/.version
URL: http://svn.asterisk.org/svn-view/thirdparty/mISDNuser/tags/1.1.2/.version?view=auto&rev=128
==============================================================================
--- mISDNuser/tags/1.1.2/.version (added)
+++ mISDNuser/tags/1.1.2/.version Tue Aug 4 15:35:54 2009
@@ -1,0 +1,1 @@
+1.1.2
Propchange: mISDNuser/tags/1.1.2/.version
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: mISDNuser/tags/1.1.2/.version
------------------------------------------------------------------------------
svn:keywords = none
Propchange: mISDNuser/tags/1.1.2/.version
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: mISDNuser/tags/1.1.2/ChangeLog
URL: http://svn.asterisk.org/svn-view/thirdparty/mISDNuser/tags/1.1.2/ChangeLog?view=auto&rev=128
==============================================================================
--- mISDNuser/tags/1.1.2/ChangeLog (added)
+++ mISDNuser/tags/1.1.2/ChangeLog Tue Aug 4 15:35:54 2009
@@ -1,0 +1,107 @@
+2009-08-04 Richard Mudgett <rmudgett at digium.com>
+
+ Digium modifications release version 1.1.2 to mISDNuser version 1.1.9.1.
+
+2009-07-14 21:57 +0000 [r123] Richard Mudgett <rmudgett at digium.com>
+
+ * i4lnet/net_l3.c: Fixed mISDNuser to handle Q.931 section 5.2.5.3.
+ This issue is related to Mantis 10457, which I think was never
+ actually fixed. If you look closely you'll see that it's the same
+ as described here. If there is more than one phone or one which
+ occupies more than one TEI (e.g. Gigaset CX475) connected to an
+ NT-PTMP port, the NT does not handle the DISCONNECT messages from
+ a phone correctly as required in Q.931 section 5.2.5.3. Instead
+ of releasing the call processes only for the TEI that answered
+ with DISCONNECT and retaining the cause until all TEIs have
+ finished their call processes, the L3 of mISDNuser passes it
+ directly to the call control (chan_misdn), which then hangs up
+ the caller. The call processes to any other TEIs are not cleared
+ and so the other phones all keep ringing. The case described in
+ Mantis 10475 is with a Gigaset. Gigasets use separate TEIs for
+ each handset, and if one handset answers the call, the other TEIs
+ are actively DISCONNECTed by the Gigaset, which then directly
+ leads to the hangup described in Mantis 10475. The wireshark
+ trace there shows two TEIs, one connecting, the other one
+ disconnecting the call. Another symptom of this issue is if two
+ (real) phones are connected to the NT, the call (leg A) is hungup
+ when just one of them rejects or is simply busy. The other one
+ keeps ringing. The this patch adds call clearing during call
+ establishment according to Q.931 section 5.2.5.3 to mISDNuser,
+ which fixes both symptoms above. JIRA ABE-1917 Patches:
+ disconnect.patch (Modified to fix a potential memory leak and
+ compiler warning.)
+
+2009-05-11 Richard Mudgett <rmudgett at digium.com>
+
+ Digium modifications release version 1.1.1 to mISDNuser version 1.1.9.1.
+
+2009-05-13 16:21 +0000 [r112-113] Richard Mudgett <rmudgett at digium.com>
+
+ * i4lnet/tei.c: Improve TEI recovery as described in Q.921 section
+ 5.3 when all TEI's are exhausted. tei-check2.patch This patch
+ will only send an identity check request for the group-TEI (127)
+ instead of 63 separate messages, which is more efficient. How it
+ works: all L2 entity TEI state machines change to ST_TEI_IDVERIFY
+ without sending a check request msg, so they can react to the id
+ check responses. Then the id check request is started for the L2
+ entity with TEI 127. TE's may answer with more than one Ai in the
+ id check response, so take care of this too. tei-check3.patch It
+ is not necessary to actually send an ID remove for the TEI's that
+ get no check response. Sending this is left out when the check
+ request is done for TEI 127. Patches: tei-check2.patch file
+ uploaded by customer (with minor cosmetic changes).
+ tei-check3.patch file uploaded by customer (with minor cosmetic
+ changes). JIRA ABE-1865
+
+ * i4lnet/net_l2.h, i4lnet/tei.c, i4lnet/net_l2.c: Add TEI recovery
+ as described in Q.921 section 5.3 when all TEI's are exhausted.
+ When all possible automatic TEI values are assigned once, a
+ subsequent TEI request by a TE never succeeds and not even a
+ reply "ID denied" is sent. Telephony is no longer possible on
+ this ISDN NT port. The problem is that the TEI manager does not
+ implement TEI recovery. This patch adds a simple but slightly
+ inefficient way to recover unused TEI's. First, we reply with ID
+ denied message. Second, all L2 entities with an assigned TEI will
+ start a TEI check sequence of their own. They all send an
+ identity check request with their specific TEI value. This way
+ when all TEIs are exhausted there will be 63 id check messages
+ sent on the S0 bus. All TEI's which do not get a response will
+ have their TEI removed and the corresponding L2 entity will be
+ destroyed. (Otherwise the L2 entity would eat up memory, because
+ new TEI requests will always create new L2 entities.) Patches:
+ tei-check1.patch file uploaded by customer (with minor cosmetic
+ changes). JIRA ABE-1865
+
+2009-05-11 19:44 +0000 [r108] Richard Mudgett <rmudgett at digium.com>
+
+ * i4lnet/net_l3.c: NT PTMP mode can cause TE's to ring endlessly if
+ NT hangs up before they respond. Incomplete state machine in
+ mISDNuser net_l3.c. A CC_DISCONNECT request changes L3 state to
+ 22 (Call Abort), sends a RELEASE to all child call processes,
+ (i.e. to all TE's that have responded up to this point). All
+ other TE's which respond subsequently never get a RELEASE because
+ the master call process is deleted too early, (before T312 times
+ out). Those TE's will ring endlessly. (See Q.931 ch. 5.3.2.e.1)
+ The patch implements 5.3.2.e.1. It keeps the master call process
+ alive as long as T312 is pending, and the additional
+ (m)datastatelist transitions allow the master call process to
+ send a RELEASE to the TEs that respond during T312. Patches:
+ misdnuser-l3state22.patch uploaded by customer (modified by me).
+ JIRA ABE-1862
+
+2009-03-16 Richard Mudgett <rmudgett at digium.com>
+
+ Digium modifications release version 1.1.0 to mISDNuser version 1.1.9.1.
+
+2009-03-16 15:19 +0000 [r87] Richard Mudgett <rmudgett at digium.com>
+
+ * CHANGES: Updated CHANGES file.
+
+2009-03-12 23:11 +0000 [r64-85] Richard Mudgett <rmudgett at digium.com>
+
+ * debugtool/mISDNdebugtool.c, bridge/isdnbridge, Makefile,
+ mktarball.sh (added): Upgraded to mISDN 1.1.9.1
+
+2009-03-12 Richard Mudgett <rmudgett at digium.com>
+
+ Digium modifications release version 1.0.0 to mISDNuser version 1.1.8.
Propchange: mISDNuser/tags/1.1.2/ChangeLog
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: mISDNuser/tags/1.1.2/ChangeLog
------------------------------------------------------------------------------
svn:keywords = none
Propchange: mISDNuser/tags/1.1.2/ChangeLog
------------------------------------------------------------------------------
svn:mime-type = text/plain
More information about the thirdparty-commits
mailing list