Hi,<br><br>From Asterisk 1.2.15 announcement, I could read "<font size="2">The Zaptel channel driver can now support echo cancellers that provide 64ms or 128ms of echo cancellation per channel."<br>How do Bristuffed Asterisk compare to this ?
<br><br>Regards<br></font>
0.2.0-RC8s
- fixed "no-automatical-bchannel-restarts" bugs in chan_zap
0.2.0-RC8r
- added support for Junghanns.NET GSM cards (libgsmat)
- hangup cause fix (libpri)
0.2.0-RC8q
- chan_sip fix for attended xfers
(thanks to friendly help provided by snom)
- callerid support for extension states
(useful for snoms version 4 firmware)
- libpri layer 2 fix
0.2.0-RC8o
- chan_zap NT mode fix (segfault on PRI_EVENT_DCHAN_DOWN)
- qozap rmmod fix
- cwain synchronization fixes
0.2.0-RC8n
- small chan_sip fixes (thanks to Christian Stredicke)
- chan_sip support for INVITES with "Replaces:" (call pickup)
- PickupSIPuri() application
<snip>
Could it be possible to get more detailed fix description somewhere ?
So that, we could make a better use from messages like "libpri layer 2
fix" and avoid non necessary software upgrades.
Beside running a diff between 2 successive versions, how would you
deal with that ?
<pre><span style="font-family: mon;">Hi,<br><br>From a bristuffed Asterisk 1.0.8, I've got an outgoing call to PSTN which is hangup during setup.<br>I checked bristuff changelog (from <a href="http://www.junghanns.net/downloads/bristuff-0.2.0-RC8s.tar.gz">
http://www.junghanns.net/downloads/bristuff-0.2.0-RC8s.tar.gz</a>) to see:<br><br></span> <span style="font-family: mon;"><br></span>0.2.0-RC8s<br> - fixed "no-automatical-bchannel-restarts" bugs in chan_zap<br>
<br>0.2.0-RC8r<br> - added support for Junghanns.NET GSM cards (libgsmat)<br> - hangup cause fix (libpri)<br> <br>0.2.0-RC8q<br> - chan_sip fix for attended xfers<br> (thanks to friendly help provided by snom)
<br> - callerid support for extension states<br> (useful for snoms version 4 firmware)<br> - libpri layer 2 fix<br><br>0.2.0-RC8o<br> - chan_zap NT mode fix (segfault on PRI_EVENT_DCHAN_DOWN)<br> - qozap rmmod fix
<br> - cwain synchronization fixes<br><br>0.2.0-RC8n<br> - small chan_sip fixes (thanks to Christian Stredicke)<br> - chan_sip support for INVITES with "Replaces:" (call pickup)<br> - PickupSIPuri() application
<br><snip><br><span style="font-family: mon;"><br></span><span style="font-family: mon;">Could it be possible to get more detailed fix description somewhere ?<br>So that, we could make a better use from messages like "
</span>libpri layer 2 fix" <span style="font-family: mon;"></span>and avoid non necessary software upgrades.<br><br>Beside running a diff between 2 successive versions, how would you deal with that ?<br><br>Regards<br>
</pre>
Posted: Mon Feb 19, 2007 2:40 pm Post subject: No subject
2140 < Informational frame:
2141 < SAPI: 00 C/R: 1 EA: 0
2142 < TEI: 064 EA: 1
2143 < N(S): 000 0: 0
2144 < N(R): 001 P: 0
2145 < 8 bytes of data
2146 -- ACKing all packets from 0 to (but not including) 1
2147 -- Since there was nothing left, stopping T200 counter
2148 -- Stopping T203 counter since we got an ACK
2149 -- Nothing left, starting T203 counter
2150 < Protocol Discriminator: Q.931 (8) len=8
2151 < Call Ref: len= 1 (reference 153/0x99) (Terminator)
2152 < Message type: RELEASE COMPLETE (90)
2153 < [08 02 87 a2]
2154 < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0
Location: International network (7)
2155 < Ext: 1 Cause: Circuit/channel congestion
(34), class = Network Congestion (2) ]
2156 Sending Receiver Ready (1)
2157 > [ 02 81 01 02 ]
2158 > Supervisory frame:
2159 > SAPI: 00 C/R: 1 EA: 0
2160 > TEI: 064 EA: 1
2161 > Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
2162 > N(R): 001 P/F: 0
2163 > 0 bytes of data
2164 -- Restarting T203 counter
2165 -- Restarting T203 counter
2166 -- Channel 0/1, span 2 got hangup
2167 Feb 19 16:21:03 VERBOSE[10990]: -- Zap/4-1 is circuit-busy
2168 Feb 19 16:21:03 DEBUG[10990]: Set option AUDIO MODE, value:
ON(1) on Zap/4-1
2169 Feb 19 16:21:03 DEBUG[10990]: Hangup: channel: 4 index = 0,
normal = 18, callwait = -1, thirdcall = -1
2170 Feb 19 16:21:03 DEBUG[10990]: Already hungup... Calling hangup
once, and clearing call
2171 Feb 19 16:21:03 DEBUG[10990]: disabled echo cancellation on
channel 4
2172 Feb 19 16:21:03 DEBUG[10990]: Set option TDD MODE, value: OFF(0)
on Zap/4-1
2173 Feb 19 16:21:03 DEBUG[10990]: Updated conferencing on 4, with 0
conference users
2174 Feb 19 16:21:03 DEBUG[10990]: Set option AUDIO MODE, value:
OFF(0) on Zap/4-1
2175 Feb 19 16:21:03 DEBUG[10990]: disabled echo cancellation on
channel 4
2176 Feb 19 16:21:03 VERBOSE[10990]: -- Hungup 'Zap/4-1'
2177 Feb 19 16:21:03 VERBOSE[10990]: == Everyone is busy/congested
at this time
2178 Feb 19 16:21:03 DEBUG[10990]: Exiting with
DIALSTATUS=CONGESTION.
My feeling (not based on hard facts yet), is that all 4 channels were not
all busy.
How can I can check this reading PRI INTENSE DEBUG SPAN (enormous) output ?
I guess this information should be somehow readable from Channel D .
As PRI INTENSE DEBUG shows both Supervisory and Informational frames, I
guess channel occupation should be in Supervisory frames which I don't know
yet how to read.
Hi,<br><br>My setup is:<br>SIP hardphone ------------- <LAN> ----------- Asterisk server ---------<ISDN><br>Asterisk server is :<br>Gentoo enabled with 1.0.8 bristuffed Asterisk<br>equipped with Junghanns Quad BRI with 2 BRI ports connected to ISDN
<br><br>From log files (with line numbering enabled) I've got :<br><br>
<br>My feeling (not based on hard facts yet), is that all 4 channels were not all busy.<br>How can I can check this reading PRI INTENSE DEBUG SPAN (enormous) output ?<br><br>I guess this information should be somehow readable from Channel D .
<br>As PRI INTENSE DEBUG shows both Supervisory and Informational frames, I guess channel occupation should be in Supervisory frames which I don't know yet how to read.<br><br>How can I check this ?d<br>
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum