[asterisk-ss7] chan_ss7 error - Write buffer full on CIC

Tue Feb 8 20:22:55 CST 2011

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>