Hello I have tried the following: [jitter] jbenable = yes jbmaxsize = 1000 jbresyncthreshold = 1000 jbimpl = adaptive I am getting bad / chopped sound and error messages: [2011-02-08 22:09:06] WARNING[31505]: abstract_jb.c:468 create_jb: Failed to put first frame in the jitterbuffer on channel 'SS7/siuc/30' [2011-02-08 22:09:06] WARNING[31505]: chan_iax2.c:1011 jb_warning_output: Resyncing the jb. last_delay 0, this delay -247066746, threshold 1000, new offset 247066746 [2011-02-08 22:09:06] WARNING[31505]: chan_iax2.c:1011 jb_warning_output: Resyncing the jb. last_delay 0, this delay -247066739, threshold 1000, new offset 247066739 [2011-02-08 22:09:08] WARNING[31505]: abstract_jb.c:428 jb_get_and_deliver: JB_IMPL_NOFRAME is returned from the adaptive jb when now=2563 >= next=2563, jbnext=2563! [2011-02-08 22:09:08] WARNING[31505]: abstract_jb.c:428 jb_get_and_deliver: JB_IMPL_NOFRAME is returned from the adaptive jb when now=2564 >= next=2563, jbnext=2563! [2011-02-08 22:09:08] WARNING[31505]: abstract_jb.c:428 jb_get_and_deliver: JB_IMPL_NOFRAME is returned from the adaptive jb when now=2565 >= next=2563, jbnext=2563! Note that though chan_iax2.c appears, I am not using IAX2 - just plain SIP: SIP -> asterisk --> ss7 After a few seconds (but any normal cust would have hung up by then), the sound quality improves and then goes... I've changed the buffer to fixed, but the 1000ms gives a clear 1 sec delay between the sip and the ISDN. I've reduced it to 160ms, and the sound quality is fine. I need now to see if this solves the write buffer issue. Any help on the adaptive mode setting would be welcomed, Regards, J. On Tue, Feb 8, 2011 at 3:35 PM, Jean C?rien <cerien.jean at gmail.com> wrote: > > Hello all chan_ss7 users > > I am facing this issue as well, using chan_ss7 1.4.3 and dahdi complete > 2.3.0 > > There seems to be a consensus to set the jitter buffer max size to 1000ms - > I am concerned as will this induce a 1 sec delay ? Or will the adaptative > mode allow to optimize this ? > > Is anyone using this parameters in production ? What feedback can you give > ? > > I am a bit cautious as this is happening in prod (not test), and dont want > to sc*w things up ! > > Regards, > > J. > > On Tue, Jan 26, 2010 at 5:45 PM, marek cervenka <cervajs at fpf.slu.cz>wrote: > >> > [Jan 26 19:40:39] NOTICE[9960]: l4isup.c:2434 ss7_write: Write buffer >> full >> > on CIC=122 (wrote only 0 of 160), audio lost (suppress 17). >> > [Jan 26 19:40:50] NOTICE[9960]: l4isup.c:2434 ss7_write: Write buffer >> full >> > on CIC=122 (wrote only 0 of 160), audio lost (suppress 0). >> > [Jan 26 19:41:02] NOTICE[9960]: l4isup.c:2434 ss7_write: Write buffer >> full >> > on CIC=122 (wrote only 0 of 160), audio lost (suppress 5). >> > [Jan 26 19:41:20] NOTICE[9960]: l4isup.c:2434 ss7_write: Write buffer >> full >> > on CIC=122 (wrote only 0 of 160), audio lost (suppress 7). >> > [Jan 26 19:41:38] NOTICE[9960]: l4isup.c:2434 ss7_write: Write buffer >> full >> > on CIC=122 (wrote only 0 of 160), audio lost (suppress 10). >> >> from chan_ss7 faq: >> >> ===text==== >> Write buffer full on CIC=4 (wrote only 0 of 160), audio lost. >> >> [Sep 19 18:41:08] NOTICE[10930] l4isup.c: Write buffer full on CIC=4 >> (wrote only 0 of 160), audio lost. >> [Sep 19 18:41:08] NOTICE[10930] l4isup.c: Write buffer full on CIC=4 >> (wrote only 0 of 160), audio lost. >> [Sep 19 18:41:08] NOTICE[10930] l4isup.c: Write buffer full on CIC=4 >> (wrote only 0 of 160), audio lost. >> >> Actually, the "Write buffer" is a kind of jitter-buffer. It is inside the >> zaptel driver and is initialized by chan_ss7 to 4 * 160 bytes (80ms). You >> can increase it to some other multiple of 160, but it requires a >> recompile, and will also increase the audio-delay. >> >> The "write-buffer full" problem often occur because of jitter on the >> IP-net. >> >> In IP-networks, there is allways a time-delay from the time a packet is >> sent to it get received at another host. This delay is unfortunately not >> allways the same. Sometimes, the packets will arrive too slow, and >> sometimes they will arrive too fast. When they arrive too fast, the >> send-buffer is filled, chan_ss7 writes the "Write buffer full" and then >> drop the packets. >> >> This problem does not occur in the conventional circuit-switched telephone >> network, since it is completely synchronous and a dedicated (logical) >> circuit is reserved between the sender and receiver. >> >> To get around this problem, you can setup trafic-shaping on the network, >> insert a bigger buffer in chan_ss7 (which will cause more delay), to >> even-out the difference in time-delay. Maybe it will helpl to configure >> the routers to "chop up" big packets in order to get the small RTP packets >> going smoothly. >> >> ===end text=== >> >> you can try: >> - newer version of chan_ss7 >> - jitter buffer option in ss7.conf >> [jitter] >> jbenable = yes >> jbmaxsize = 1000 >> jbresyncthreshold = 1000 >> jbimpl = adaptive >> >> >> --------------------------------------- >> Marek Cervenka >> ======================================= >> >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-ss7 mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-ss7 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110208/185e85fd/attachment-0001.htm>
|