Re: [asterisk-dev] M9645: provide zaptel master timing to spans

[Paul Cadach]

Tzafrir Cohen wrote:

I'd like to get your input regarding
http://bugs.digium.com/view.php?id=9645

The patch adds an extra span method:

 int (*sync_tick)(struct zt_span *span, int is_master);

The zaptel sync master span will call it to any span (in which it is not
NULL) at each of its ticks.


Is it better to have a call to such API every N (1000, 1) ticks? At 
least it will offload CPU processing, but still make channel driver to be 
able to adapt its slave clocks according to zaptel's master clocks.


To be clear, when zaptel detects master clock change, it will immediately 
call such callback to notify channel drivers about master change event. Of 
course, it should pass its own tick counter to allow channel drivers to 
adapt their clocks independedly on callback call frequency. IMHO this should 
offload CPU/etc. but provide the same behavior as Tzafrir suggests.


Also, to perform card's clock source manipulation, you should collect 
relatively high number of ticks to be accurate as possible, so I think 
calling the callback often than one time per second is overkill.



WBR,
Paul. 


___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Re: Kernel modules => mainline kernel

[Paul Cadach]

Latest versions of TE4xxP allows to daisy-chain timing from single source to 
other cards. And IMHO it should use single interrupt per all ports joined by 
this daisy-chain.



WBR,
Paul.

- Original Message - 
From: "Andrew Kohlsmith" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, February 13, 2007 4:02 AM
Subject: Re: [asterisk-dev] Re: Kernel modules => mainline kernel



On Tuesday 13 February 2007 3:00 am, Oron Peled wrote:

Q: What is the interrupt rate in this situation?
A: Assume a favorable condition: All PRI with one interrupt
   per port (with analog lines we would need many more cards).


Let's assume a realistic situation: a quad PRI card with one interrupt per 
4

ports.

   Number of required cards =~ 1000 / 30 = 34 (assume we have such a PC 
;-)

   Number of interrupts = 34 * 1000/sec = 34,000/sec (without counting
   the matching context switches on the transmit path).


1000 / (30 * 4) = 8.3 = 9000 interrupts/sec.

If we can use NFAS on each quad card, that gets us 8.1 cards, and if
Zaptel/libpri allows us to NFAS multiple cards (I don't see why it 
wouldn't),

we would have 8 cards, not 9.

I've long, long been wondering if it's possible to slave additional Zaptel
cards off of one card, but I haven't the real need for it to go about
actually implementing a test.  That would certainly eliminate some of your
arguments here.


For anyone interested, during kernel 2.2 everybody were talking about
zero-copy. Then came the reality check. Zero copy only helped Gigabit
ethernet and above. However, the NAPI api that enabled drivers to
dynamically switch to polling instead of interrupt per-packet was a
major win for many 100Mb drivers (the results were applied to kernel 
2.4).


Yes, and it shot latency right to hell by saving all these interrupts. 
While

it might be a solution if we used the high-resolution timers in the later
kernels, I don't think it would be feasible any other way.

-A.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev



___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] External TIming Source without zaptel

[Paul Cadach]

As I remember there is special device driver called something like 
/dev/zap/timer which have some special ioctl()s to handle timing for Asterisk. 
If your driver will provide the same interface - you won!


WBR,
Paul.
  - Original Message - 
  From: Paulo Garcia 
  To: Asterisk Developers Mailing List 
  Sent: Friday, January 26, 2007 5:12 PM
  Subject: [asterisk-dev] External TIming Source without zaptel


  Hi,

  I´m looking for more informations how to implement external timinig source 
within Asterisk. We are developing a E1 Pri card and I couldn ´t understand 
where I can use my hardware timing source into Asterisk, since we don´t use 
zaptel (or ztdummy). My focus is still in Asterisk 1.2 but I think these things 
are the same in 1.4 as well.

  Any path to research will be appreciated.


  Regards


  Paulo Garcia



--


  ___
  --Bandwidth and Colocation provided by Easynews.com --

  asterisk-dev mailing list
  To UNSUBSCRIBE or update options visit:
 http://lists.digium.com/mailman/listinfo/asterisk-dev
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] /dev/zap/(channel no) ends on 255 and unable tomake more

[Paul Cadach]

Hi,

/dev/zap/ used mostly for non-specific tools (like dd 
if=/dev/zap/1 of=/tmp/chan1_mon.alaw ;-) ). Real channel drivers and 
zaptel-specific tools should use /dev/zap/channel interface instead. You can 
easily update chan_ss7 to use /dev/zap/channel mechanism (just look how it 
is implemented in chan_zap already - it is additional ioctl() call to bind 
the descriptor to specific Zaptel channel).


As for DEVFS, it's not plays any role. Most limitation is by design of /dev/ 
filesystem in *nix-systems which uses one-byte major and minor numbers to 
identify device node. Zaptel uses its own major number, so it have limited 
to 256 only minor device numbers, and few of them are reserved for specific 
devices (like /dev/zap/channel, /dev/zap/timer, /dev/zap/pseudo).



WBR,
Paul.

- Original Message - 
From: "Anton VG" <[EMAIL PROTECTED]>

To: "Asterisk Developers Mailing List" 
Sent: Friday, December 22, 2006 11:49 AM
Subject: Re: [asterisk-dev] /dev/zap/(channel no) ends on 255 and unable 
tomake more




in fact chan_ss7 uses this method to access a channel which
provides the signalling link. And if I use that on the
span>8 ... so than I can't use chan_ss7. Matthew, looking
for a time when you'll sync your libss7 with 1.4 ;) Until
now have to stick with chan_ss7. Not sure, but is this a
limitation of DEVFS?

2006/12/23, Matthew Fredrickson <[EMAIL PROTECTED]>:


On Dec 22, 2006, at 11:49 AM, Anton wrote:

> Guys,
>
> In a system with more than 8xE1 it's impossible to access
> to /dev/zap/(channel no) channels higher than 255. ZAPTEL
> Makefile generates only 255 instances and adjusting
> Makefile to be generating more of them, makes any nodes
> over 255 to be anyway dead (attempt to access returns (for
> instance 256's node) "Cannot open "256" No such device or
> address (6)" error. If someone could please give a clue how
> to make them accessible, it will be highly appreciated. Is
> it a linux limitation or just a variable in Zaptel sources?
> Please help.

What do you need this for?  If this is for asterisk, then you don't
have anything to worry about.  A very cursory overlook of chan_zap
shows that it does not open the zap devices by those means.  There is
another mechanism for opening zap channels provided through
/dev/zap/channel that gets around the limitation with devices nodes.

Matthew Fredrickson

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev



___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] shutting down zaptel spans

[Paul Cadach]

Hello,

Shutdown (by ztcfg -s) is required for dynamic spans (ztd-eth, ztd-loc).


WBR,
Paul.

- Original Message - 
From: "Kevin P. Fleming" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" 
Sent: Thursday, September 28, 2006 10:25 PM
Subject: Re: [asterisk-dev] shutting down zaptel spans


> - Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
> > When is there a need to shut down zaptel spans from userspace?
> 
> I'm not aware of any benefit of doing so.
> 
> -- 
> Kevin P. Fleming
> Senior Software Engineer
> Digium, Inc.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Checking h323.h presence... no???

[Paul Cadach]

Hello,

Revision 4388 should also fix compiler warning.


WBR,
Paul.

- Original Message -
From: "Vlasis Hatzistavrou" <[EMAIL PROTECTED]>
To: "'Asterisk Developers Mailing List'" 
Sent: Thursday, September 28, 2006 8:36 PM
Subject: RE: [asterisk-dev] Checking h323.h presence... no???


> Hello Paul,
>
> I downloaded rev. 43863 as you instructed and it compiled without problems 
> this time.
>
> Although I had a few warnings (as during the previous revisions I tried) and 
> the first time I received the message
"Re-run 'make' to pick up H.323 parameters", after I tried "make" a second time 
everything compiled without problems.
>
> I will try the channel driver today.
>
> Thank you & best regards,
> Vlasis Hatzistavrou
>
>
> ___
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Trunk 43282 does not build

[Paul Cadach]

Hello,
 

  - Original Message - 
  From: 
  Morten Isaksen 
  To: Asterisk Developers Mailing List 

  Sent: Wednesday, September 20, 2006 12:31 
  AM
  Subject: Re: [asterisk-dev] Trunk 43282 
  does not build
  
  And I have some problems with rev 43284.
   
  When I run configure it fails with:
   
  configure: creating ./config.statusconfig.status: creating 
  build_tools/menuselect-depsconfig.status: creating 
  makeoptsconfig.status: error: cannot find input file: 
  channels/h323/Makefile.in
Please, be patient, trunk is in midde of merge process of mine 
chan_h323-live...
WBR,
Paul.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Trunk 43282 does not build

[Paul Cadach]

Hello,

Dan Austin wrote:
> I see that Mattf just commited some changes to the configure
> script with a comment "Hopes my branch doesn't break", so this
> might not be unexpected

There was try to merge my chan_h323-live. Because I uses different version of 
autoconf tools configure should be
re-build. I'll notify Matthew about this requirement.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] error in build on latest trunk

[Paul Cadach]

Hi,

Do
cd menuselect
./configure

or just run menuselect/configure

WBR,
Paul.

- Original Message - 
From: "Julian Lyndon-Smith" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" 
Sent: Sunday, September 17, 2006 4:07 PM
Subject: Re: [asterisk-dev] error in build on latest trunk


> I did - make clean;make update;./configure;make menuselect
> 
> Paul Cadach wrote:
> > Hi,
> > 
> > Do menuselect/configure too.
> > 
> > 
> > WBR,
> > Paul.
> > 
> > - Original Message - 
> > From: "Julian Lyndon-Smith" <[EMAIL PROTECTED]>
> > To: "Asterisk Developers Mailing List" 
> > Sent: Sunday, September 17, 2006 1:49 PM
> > Subject: [asterisk-dev] error in build on latest trunk
> > 
> > 
> >> Looks like something broke:
> >>
> >> just checked out latest trunk,
> >>
> >> make clean
> >> ./configure
> >> make menuselect
> >>
> >> [EMAIL PROTECTED] asterisk]# make menuselect
> >> make[1]: Entering directory `/usr/src/asterisk/menuselect'
> >> make[2]: Entering directory `/usr/src/asterisk/menuselect'
> >> gcc -Wall  -o menuselect.o -g -c -D_GNU_SOURCE menuselect.c
> >> gcc -Wall  -o menuselect_curses.o -g -c -D_GNU_SOURCE  menuselect_curses.c
> >> gcc -Wall  -o strcompat.o -g -c -D_GNU_SOURCE strcompat.c
> >> strcompat.c: In function `vasprintf':
> >> strcompat.c:159: warning: implicit declaration of function `va_copy'
> >> strcompat.c:161: warning: implicit declaration of function `va_end'
> >> strcompat.c: In function `asprintf':
> >> strcompat.c:197: warning: implicit declaration of function `va_start'
> >> strcompat.c: At top level:
> >> strcompat.c:221: error: syntax error before "strtoq"
> >> strcompat.c:222: warning: return type defaults to `int'
> >> strcompat.c:222: error: conflicting types for 'strtoq'
> >> /usr/include/stdlib.h:197: error: previous declaration of 'strtoq' was here
> >> strcompat.c:222: error: conflicting types for 'strtoq'
> >> /usr/include/stdlib.h:197: error: previous declaration of 'strtoq' was here
> >> strcompat.c: In function `strtoq':
> >> strcompat.c:224: error: `uint64_t' undeclared (first use in this function)
> >> strcompat.c:224: error: (Each undeclared identifier is reported only once
> >> strcompat.c:224: error: for each function it appears in.)
> >> strcompat.c:224: error: syntax error before "acc"
> >> strcompat.c:226: error: syntax error before "qbase"
> >> strcompat.c:273: error: `qbase' undeclared (first use in this function)
> >> strcompat.c:274: error: `cutoff' undeclared (first use in this function)
> >> strcompat.c:274: warning: integer constant is too large for "long" type
> >> strcompat.c:274: warning: integer constant is too large for "long" type
> >> strcompat.c:274: warning: integer constant is too large for "long" type
> >> strcompat.c:274: warning: integer constant is too large for "long" type
> >> strcompat.c:277: error: `acc' undeclared (first use in this function)
> >> strcompat.c:277: warning: left-hand operand of comma expression has no 
> >> effect
> >> strcompat.c:297: warning: integer constant is too large for "long" type
> >> strcompat.c:297: warning: integer constant is too large for "long" type
> >> strcompat.c:277: warning: value computed is not used
> >> make[2]: *** [strcompat.o] Error 1
> >> make[2]: Leaving directory `/usr/src/asterisk/menuselect'
> >> make[1]: *** [all] Error 2
> >> make[1]: Leaving directory `/usr/src/asterisk/menuselect'
> >> make: *** [menuselect/menuselect] Error 2
> >> [EMAIL PROTECTED] asterisk]#
> >>
> >> ___
> >> --Bandwidth and Colocation provided by Easynews.com --
> >>
> >> asterisk-dev mailing list
> >> To UNSUBSCRIBE or update options visit:
> >>http://lists.digium.com/mailman/listinfo/asterisk-dev
> >>
> > 
> > ___
> > --Bandwidth and Colocation provided by Easynews.com --
> > 
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >http://lists.digium.com/mailman/listinfo/asterisk-dev
> > 
> > 
> 
> ___
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] error in build on latest trunk

[Paul Cadach]

Hi,

Do menuselect/configure too.


WBR,
Paul.

- Original Message - 
From: "Julian Lyndon-Smith" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" 
Sent: Sunday, September 17, 2006 1:49 PM
Subject: [asterisk-dev] error in build on latest trunk


> Looks like something broke:
> 
> just checked out latest trunk,
> 
> make clean
> ./configure
> make menuselect
> 
> [EMAIL PROTECTED] asterisk]# make menuselect
> make[1]: Entering directory `/usr/src/asterisk/menuselect'
> make[2]: Entering directory `/usr/src/asterisk/menuselect'
> gcc -Wall  -o menuselect.o -g -c -D_GNU_SOURCE menuselect.c
> gcc -Wall  -o menuselect_curses.o -g -c -D_GNU_SOURCE  menuselect_curses.c
> gcc -Wall  -o strcompat.o -g -c -D_GNU_SOURCE strcompat.c
> strcompat.c: In function `vasprintf':
> strcompat.c:159: warning: implicit declaration of function `va_copy'
> strcompat.c:161: warning: implicit declaration of function `va_end'
> strcompat.c: In function `asprintf':
> strcompat.c:197: warning: implicit declaration of function `va_start'
> strcompat.c: At top level:
> strcompat.c:221: error: syntax error before "strtoq"
> strcompat.c:222: warning: return type defaults to `int'
> strcompat.c:222: error: conflicting types for 'strtoq'
> /usr/include/stdlib.h:197: error: previous declaration of 'strtoq' was here
> strcompat.c:222: error: conflicting types for 'strtoq'
> /usr/include/stdlib.h:197: error: previous declaration of 'strtoq' was here
> strcompat.c: In function `strtoq':
> strcompat.c:224: error: `uint64_t' undeclared (first use in this function)
> strcompat.c:224: error: (Each undeclared identifier is reported only once
> strcompat.c:224: error: for each function it appears in.)
> strcompat.c:224: error: syntax error before "acc"
> strcompat.c:226: error: syntax error before "qbase"
> strcompat.c:273: error: `qbase' undeclared (first use in this function)
> strcompat.c:274: error: `cutoff' undeclared (first use in this function)
> strcompat.c:274: warning: integer constant is too large for "long" type
> strcompat.c:274: warning: integer constant is too large for "long" type
> strcompat.c:274: warning: integer constant is too large for "long" type
> strcompat.c:274: warning: integer constant is too large for "long" type
> strcompat.c:277: error: `acc' undeclared (first use in this function)
> strcompat.c:277: warning: left-hand operand of comma expression has no 
> effect
> strcompat.c:297: warning: integer constant is too large for "long" type
> strcompat.c:297: warning: integer constant is too large for "long" type
> strcompat.c:277: warning: value computed is not used
> make[2]: *** [strcompat.o] Error 1
> make[2]: Leaving directory `/usr/src/asterisk/menuselect'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/src/asterisk/menuselect'
> make: *** [menuselect/menuselect] Error 2
> [EMAIL PROTECTED] asterisk]#
> 
> ___
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Need help for 4E1 config

[Paul Cadach]

Hello,

E1s usually uses HDB3 line coding (or AMI line coding) with optional CRC4
checking, so B8SZ coding is totally wrong.
span=1,1,0,ccs,hdb3,
span=2,2,0,ccs,hdb3,
span=3,3,0,ccs,hdb3,
span=4,4,0,ccs,hdb3,

>From top of /etc/zaptel.conf:
# The framing is one of "d4" or "esf" for T1 or "cas" or "ccs" for E1
# Note: "d4" could be referred to as "sf" or "superframe"
# The coding is one of "ami" or "b8zs" for T1 or "ami" or "hdb3" for E1
# E1's may have the additional keyword "crc4" to enable CRC4 checking


WBR,
Paul.

- Original Message - 
From: "Dome C." <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" ;
"Commercial and Business-Oriented Asterisk Discussion"

Sent: Saturday, September 16, 2006 12:25 PM
Subject: [asterisk-dev] Need help for 4E1 config


> Hi Martin and All,
>
> Can some one help me config for 4E1 Card (Order From
> e400p.pbxhardware.com) and Eurotech Multicell PRI Gateway.
> Now l can load driver but got alram YEL/RED/GREEN
> This is my zatel.conf
>
> span=1,1,0,esf,b8zs
> span=2,0,0,esf,b8zs
> span=3,0,0,esf,b8zs
> span=4,0,0,esf,b8zs
>
> # Span 1
> bchan=1-15
> dchan=16
> bchan=17-31
> # Span 2
> bchan=32-46
> dchan=47
> bchan=48-62
> # Span 3
> bchan=63-77
> dchan=78
> bchan=79-93
> # Span 4
> bchan=94-108
> dchan=109
> bchan=110-124
> loadzone = fr
> defaultzone = fr
>
>
>
> Best Regards.
>
> Dome C.
>
> ___
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] incoming diverted number

[Paul Cadach]

Hello,

libpri is able to parse it anyway. If you remove '0x' in pri_facility.h at line
#define ROSE_DIVERTING_LEG_INFORMATION2 0x15
and enable PRI_DEBUG_APDU debug option in libpri, you will be able to see
decoded content of this message.


WBR,
Paul.

- Original Message - 
From: "Roy Sigurd Karlsbakk" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" 
Sent: Tuesday, August 29, 2006 2:21 PM
Subject: Re: [asterisk-dev] incoming diverted number


> Hi
>
> Thanks, but I did not ask for the right thing.
> The two highlighted lines in http://karlsbakk.net/asterisk/pridebug.
> 1.html differ between a normal SETUP and a diverted SETUP, stuff
> asterisk seems unable to parse
>
> thanks
>
> roy
>
> On 29. aug. 2006, at 07.21, Paul Cadach wrote:
>
> > Hello,
> >
> > Your trace shows you don't have RDNIS number in FACILITY message
> > (probably
> > passing of RDNIS information is prohibited by network).
> >
> >
> > WBR,
> > Paul.
> >
> > - Original Message -
> > From: "Roy Sigurd Karlsbakk" <[EMAIL PROTECTED]>
> > To: "Asterisk Mailing List" 
> > Sent: Monday, August 28, 2006 10:03 PM
> > Subject: [asterisk-dev] incoming diverted number
> >
> >
> >> hi all
> >>
> >> if I divert my cell phone to a number on a PRI on my asterisk box,
> >> the PRI SETUP contains some data that asterisk/libpri seems unable to
> >> parse. Can someone please point me to somewhere to help me understand
> >> what's in there? it'd be great to see that.
> >>
> >> thanks
> >>
> >> roy
> >>
> >> PRI DEBUG
> >> ---
> >> < Call Ref: len= 2 (reference 5316/0x14C4) (Originator)
> >> < Message type: SETUP (5)
> >> < [04 03 80 90 a3]
> >> < Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer
> >> capability: Speech (0)
> >> <  Ext: 1  Trans mode/rate: 64kbps,
> >> circuit-mode (16)
> >> <  Ext: 1  User information layer 1: A-
> >> Law (35)
> >> < [18 03 a1 83 81]
> >> < Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0,
> >> Preferred Dchan: 0
> >> <ChanSel: Reserved
> >> <   Ext: 1  Coding: 0   Number Specified
> >> Channel Type: 3
> >> <   Ext: 1  Channel: 1 ]
> >> < [1c 15 91 a1 12 02 01 ac 02 01 0f 30 0a 02 01 01 0a 01 01 a1 02
> >> 81 00]
> >> < Facility (len=23, codeset=0) [ 0x91, 0xa1, 0x12, 0x02, 0x01, 0xac,
> >> 0x02, 0x01, 0x0f, '0', 0x0a, 0x02, 0x01, 0x01, 0x0a, 0x01, 0x01,
> >> 0xa1, 0x02, 0x81, 0x00 ]
> >> < [6c 0a 21 83 39 38 30 31 33 33 35 36]
> >> < Calling Number (len=12) [ Ext: 0  TON: National Number (2)  NPI:
> >> ISDN/Telephony Numbering Plan (E.164/E.163) (1)
> >> <   Presentation: Presentation allowed of
> >> network provided number (3) '98013356' ]
> >> < [70 09 a1 32 31 39 37 33 35 39 37]
> >> < Called Number (len=11) [ Ext: 1  TON: National Number (2)  NPI:
> >> ISDN/Telephony Numbering Plan (E.164/E.163) (1) '21973597' ]
> >> < [a1]
> >> < Sending Complete (len= 1)
> >> -- Making new call for cr 5316
> >> -- Processing Q.931 Call Setup
> >> -- Processing IE 4 (cs0, Bearer Capability)
> >> -- Processing IE 24 (cs0, Channel Identification)
> >> -- Processing IE 28 (cs0, Facility)
> >> Handle Q.932 ROSE Invoke component
> >> -- Processing IE 108 (cs0, Calling Party Number)
> >> -- Processing IE 112 (cs0, Called Party Number)
> >> -- Processing IE 161 (cs0, Sending Complete)
> >>> Protocol Discriminator: Q.931 (8)  len=10
> >>> Call Ref: len= 2 (reference 5316/0x14C4) (Terminator)
> >>> Message type: CALL PROCEEDING (2)
> >>> [18 03 a9 83 81]
> >>> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0,
> >> Exclusive Dchan: 0
> >>>ChanSel: Reserved
> >>>   Ext: 1  Coding: 0   Number Specified
> >> Channel Type: 3
> >>>   Ext: 1  Channel: 1 ]
> >>  -- Accepting call from '98013356' to '21973597' on channel 0/1,
> >> span 2
> >>  -- Executing Answer("Zap/32-1", "") in new stack
> >>&

Re: [asterisk-dev] incoming diverted number

[Paul Cadach]

Hello,

Your trace shows you don't have RDNIS number in FACILITY message (probably
passing of RDNIS information is prohibited by network).


WBR,
Paul.

- Original Message - 
From: "Roy Sigurd Karlsbakk" <[EMAIL PROTECTED]>
To: "Asterisk Mailing List" 
Sent: Monday, August 28, 2006 10:03 PM
Subject: [asterisk-dev] incoming diverted number


> hi all
>
> if I divert my cell phone to a number on a PRI on my asterisk box,
> the PRI SETUP contains some data that asterisk/libpri seems unable to
> parse. Can someone please point me to somewhere to help me understand
> what's in there? it'd be great to see that.
>
> thanks
>
> roy
>
> PRI DEBUG
> ---
> < Call Ref: len= 2 (reference 5316/0x14C4) (Originator)
> < Message type: SETUP (5)
> < [04 03 80 90 a3]
> < Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer
> capability: Speech (0)
> <  Ext: 1  Trans mode/rate: 64kbps,
> circuit-mode (16)
> <  Ext: 1  User information layer 1: A-
> Law (35)
> < [18 03 a1 83 81]
> < Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0,
> Preferred Dchan: 0
>  <   Ext: 1  Coding: 0   Number Specified
> Channel Type: 3
> <   Ext: 1  Channel: 1 ]
> < [1c 15 91 a1 12 02 01 ac 02 01 0f 30 0a 02 01 01 0a 01 01 a1 02 81 00]
> < Facility (len=23, codeset=0) [ 0x91, 0xa1, 0x12, 0x02, 0x01, 0xac,
> 0x02, 0x01, 0x0f, '0', 0x0a, 0x02, 0x01, 0x01, 0x0a, 0x01, 0x01,
> 0xa1, 0x02, 0x81, 0x00 ]
> < [6c 0a 21 83 39 38 30 31 33 33 35 36]
> < Calling Number (len=12) [ Ext: 0  TON: National Number (2)  NPI:
> ISDN/Telephony Numbering Plan (E.164/E.163) (1)
> <   Presentation: Presentation allowed of
> network provided number (3) '98013356' ]
> < [70 09 a1 32 31 39 37 33 35 39 37]
> < Called Number (len=11) [ Ext: 1  TON: National Number (2)  NPI:
> ISDN/Telephony Numbering Plan (E.164/E.163) (1) '21973597' ]
> < [a1]
> < Sending Complete (len= 1)
> -- Making new call for cr 5316
> -- Processing Q.931 Call Setup
> -- Processing IE 4 (cs0, Bearer Capability)
> -- Processing IE 24 (cs0, Channel Identification)
> -- Processing IE 28 (cs0, Facility)
> Handle Q.932 ROSE Invoke component
> -- Processing IE 108 (cs0, Calling Party Number)
> -- Processing IE 112 (cs0, Called Party Number)
> -- Processing IE 161 (cs0, Sending Complete)
>  > Protocol Discriminator: Q.931 (8)  len=10
>  > Call Ref: len= 2 (reference 5316/0x14C4) (Terminator)
>  > Message type: CALL PROCEEDING (2)
>  > [18 03 a9 83 81]
>  > Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0,
> Exclusive Dchan: 0
>  >ChanSel: Reserved
>  >   Ext: 1  Coding: 0   Number Specified
> Channel Type: 3
>  >   Ext: 1  Channel: 1 ]
>  -- Accepting call from '98013356' to '21973597' on channel 0/1,
> span 2
>  -- Executing Answer("Zap/32-1", "") in new stack
>  > Protocol Discriminator: Q.931 (8)  len=14
>  > Call Ref: len= 2 (reference 5316/0x14C4) (Terminator)
>  > Message type: CONNECT (7)
>  > [18 03 a9 83 81]
>  > Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0,
> Exclusive Dchan: 0
>  >ChanSel: Reserved
>  >   Ext: 1  Coding: 0   Number Specified
> Channel Type: 3
>  >   Ext: 1  Channel: 1 ]
>  > [1e 02 81 82]
>  > Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard
> (0) 0: 0   Location: Private network serving the local user (1)
>  >   Ext: 1  Progress Description: Called
> equipment is non-ISDN. (2) ]
>  -- Executing Echo("Zap/32-1", "") in new stack
> < Protocol Discriminator: Q.931 (8)  len=5
> < Call Ref: len= 2 (reference 5316/0x14C4) (Originator)
> < Message type: CONNECT ACKNOWLEDGE (15)
> < Protocol Discriminator: Q.931 (8)  len=9
> < Call Ref: len= 2 (reference 5316/0x14C4) (Originator)
> < Message type: DISCONNECT (69)
> < [08 02 82 90]
> < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0
> Location: Public network serving the local user (2)
> <  Ext: 1  Cause: Unknown (16), class = Normal Event
> (1) ]
> -- Processing IE 8 (cs0, Cause)
>  -- Channel 0/1, span 2 got hangup request
>== Spawn extension (zap_start, 21973597, 2) exited non-zero on
> 'Zap/32-1'
> NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect
> Indication, peerstate Disconnect Request
>
> --
> Roy Sigurd Karlsbakk
> [EMAIL PROTECTED]
> (+47) 98013356
> ---
> In space, loud sounds, like explosions, are even louder because there
> is no air to get in the way.
>
>
> ___
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>

___
--Bandwidth and Colocat

Re: [asterisk-dev] Re: [asterisk-commits] russell: branch 1.2r38288 - /branches/1.2/channels/chan_sip.c

[Paul Cadach]

Hello,

Russell Bryant wrote:
> > Alternatively, since we have ast_malloc/ast_calloc, should we have ast_free
(not in 1.2, of course)?
>
> I suppose.  However, I'm not sure how beneficial it would be other than
> for matching the naming convention of the allocation wrappers.  There is
> obviously no error checking we can do on a call to free(), so we can't
> inject an Asterisk log message or anything.

There is possible to provide some sort of memory checks in allocation wrappers,
like:
  -4: Some magic data to check if allocated block is not underbounded
  : Memory for data returned by ast_malloc()/ast_calloc() call;
  +n: Some magic data to check if allocated block is not overwritten;

For such memory check you should have special free() function which will check
magic data before and after allocated data, and call to real free() function
with modified pointer.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Queries regarding Echo Cancellation in Zaptel-1.2.6

[Paul Cadach]

Hello,

Chan Kwang Mien wrote:
> IP Phone A <--> Asterisk IP PBX <---> Analog Phone B
>
> In my tests, echos were generated by IP Phone A when I turned on the
> speaker. As was pointed out, zaptel could not cancel these echos because
> the echo was not received at the zaptel interface, rather on the SIP
> interface.

Correct.

> I have a question :
>
> Does it mean that the SIP interface has to cancel the echo from IP Phone
> A ?

No. VoIP part always uses different receive and transmit pathes, so there
(theoretically) is no way to mix receive and transmit signals to produce echo.

> This should be a real problem since it is possible that echo could be
> generated by IP Phones when they are in the handsfree mode (Speaker
> mode) or echo could be generated from an old IP Phone.

A phone (analog or VoIP) implementing speakerphone mode should care about strong
acoustic echo cancellation in this mode. Regular handset operation for best
results also requires some sort of acoustic echo cancellation (to resolve signal
"connections" between speaker and microphone embedded into single handset), but
with correct handset design it's not so important (residual echo through
accurate designed handset less than -20 dB).


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] asterisk sending connects when it shouldn't

[Paul Cadach]

Hello,

Simone Cittadini wrote:
> Eric "ManxPower" Wieling ha scritto:
> 
> > Playback, Background, and most any function that sends audio to the 
> > caller will issue an Answer first unless you tell it not to.  (see 
> > show application)
> >
> There is no Playback, Background or such, only a Dial to an IAX 
> registered asterisk client which then dials a SIP connected GSM gateway, 
> and...

Could you provide full trace of such call with options:
pri debug span 
set verbose 3
iax2 debug

 is a span number where you run ISDN PRI.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Zaptel channel lock bug?

[Paul Cadach]

Hi,


Anton wrote:
> Jul  3 09:31:45 WARNING[14626]: channel.c:787
> channel_find_locked: Avoided deadlock for '0x822cb08', 10
> retries!

Typical deadlock situation. Please, enable locking traces and check what is hold
the lock (where the lock was made).


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] RTP streams between H323 and SIP

[Paul Cadach]

Hello,

Johansson Olle E wrote:
> > Are you sure? All channels that supply 'ast_rtp_bridge' as their
> > bridge method should already support it.
>
> That was news to me. Cool if that's the case!
> Never seen or heard about it before.
>
> I stand corrected.

I just acknowledge we have H.323 native bridge code that support RTP "move" 
(like re-invites for SIP) and all works fine
between SIP and H.323 channels.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Native Bridge for H.323?

[Paul Cadach]

Hello,

Ken Chan wrote:
> Now I have more questions:
> a)  Any idea what type of H.323 devices (or softphone) support
> "Empty TCS" feature?

Standard OpenPhone (and other OpenH323-based solutions) supports for Empty TCS.

> b)  When are you going to release that native bridge for h.323?

Until another features will go into SVN tree or someone else elected to have
only one H.323 channel driver for Asterisk to provide adequate support for it.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Native Bridge for H.323?

[Paul Cadach]

Hello,

Ken Chan wrote:
> Currently, when the call is between SIP Phone and Netmeeting (H.323),
> all the RTP packets are going through Asterisk.

Netmeeting isn't support for "Empty TCS (Terminal Capability Set)" feature yet, 
so RTP traffic will go through Asterisk
anyway independedly on native bridge support for H.323.


We have implemented native bridge for chan_h323 but it is in very preliminary 
stage.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [PATCH] Silently drop non-conformingcirpack keep-alive packets

[Paul Cadach]

Hello,

Kevin P. Fleming wrote:
> > A packet is sent every 15s, causing Asterisk to write the same line in
> > the logs every 15s too. The following hack ignores those packets. I do
> > not know whether this should be included in the mainstream sources or
> > not. I will report this to Free Telecom, hoping that they can do
> > something about it (such as contacting Cirpack).
>
> No, this is completely invalid behavior on their part. We cannot make
> code changes to check for this stuff when it is completely outside the
> specs.

This is not compatibility but interoperability issue, so support of sorts of 
implementation-specific behaviours would be
very helpful.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Video, anyone?

[Paul Cadach]

Hi,

Olle E Johansson wrote:
[skipped]
> During my recent tests with video phones (thanks Grandstream and
> Foniris!) I have found out
> that we have a list of things to do. I have also found out that there
> are a lot of developers out there
> that have done it already - meetme with selectable video streams,
> chan_local with video and other
> patches that we need to incorporate into Asterisk. Smaller changes
> now, bigger changes for 1.6.

Don't forget H.323 also have generic support for video transmission... You can
include me into the AVTF list.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Corydon76

[Paul Cadach]

Hello,

Koopmann, Jan-Peter wrote:
> It is one thing to say "Hey this does not work, it is a bug" and another to
say "Hey this does not work as expected, I created a small enhancement, see the
patch attached" like it was in this case.

[skipped]

You forget to remember about just extending support of some sort of existing
specifications (for example, facilities in PRI, etc.) which is not usually
required to be used by every user but just better to have been implemented
without waiting for misworking reports.

Sortly, if feature/enhancement is not required by every user, it's not a case to
close/ignore the ticket with good working patch. Elsewhere someone needs to
implement it again some time later...


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] problem about musiconhold

[Paul Cadach]

Hello,
 
This is -user question. You should disable 
VAD (Voice Activity Detection) on your gateway - Asterisk is not 
VAD-friendly.
 
WBR,Paul.

  - Original Message - 
  From: 
  wei 
  lee 
  To: asterisk-dev@lists.digium.com 
  Sent: Monday, March 27, 2006 7:20 
AM
  Subject: [asterisk-dev] problem about 
  musiconhold
  
  hello everyone:
    I have a 
  problem about musiconhold.
    when i call 
  from a PSTN phone , if you don't give sound to mic , the music will stop 
  . 
    Is that 
  anyone have the answers?
    thank you very 
  much! 
      
  david 
  
  
  无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！ 
  
  

  ___--Bandwidth and 
  Colocation provided by Easynews.com --asterisk-dev mailing listTo 
  UNSUBSCRIBE or update options visit:   
  http://lists.digium.com/mailman/listinfo/asterisk-dev
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] rtp scalability improvement...

[Paul Cadach]

Hello,

Roy Sigurd Karlsbakk wrote:
[skipped]
> These IRQ storms are only happening on crappy network hardware. My
> testing was one with intel gigabit NICs with large buffers,
> effectively producing < 100 interrupts per second. kernel profiling
> showed time was indeed spent in system calls

The one solution I see is to move RTP _switching_ into the kernel level (like
zaptel conferencing doing), and optimize Asterisk core to do better codec
selection logic (i.e. to always minimize/eliminate transcoding when it is
possible).


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] rtp scalability improvement...

[Paul Cadach]

Hello,

Sergey Kuznetsov wrote:
[skipped]
> > OpenH323 have some deadlock issues I tried to solve about a year ago (you
can find those patches somewhere at
> > bugs.digium.com). I'm not sure my patches are applied to latest openh323
tree, but small fixes to pwlib already have
> > ones...
>
> What was cause of those deadlocks?

The reason for deadlocks was negotiation timeout handling. When timeout is
happends and you have waiting packet received at the same time, packet
processing code locks channel structure then tries to stop retry timeout handler
(which locks itself), while timeout handler (when timeout happends) locks itself
then tries to lock channel structure which is already locked by packet handling
process.

> In my case there is the issue with Master-Slave negotiation timeout,
> right after when my side receiving Alerting message.

That's the situation described above.

Check #3967 at bugs.digium.com (http://bugs.digium.com/view.php?id=3967).


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] t.38 passthrouth

[Paul Cadach]

Hello,

anthony thomas wrote:
>  We are testing the t38passthrough branch in our
> gateways and can not fully understand why the RTP
> stream has to go througth the * box disabling native
> RTP bridging.

This feature is not being developed/fully tested to be published. Be patient 
and some time it will appear... ;-)


WBR,
Paul.


___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Dialstate without Ringing

[Paul Cadach]

Hello,

In addition to Kevin P. Fleming message:
[skipped]
> If the final end party does not send ALERTING, and the network does not
> send SESSION PROGRESS with inband audio available, then there is no way
> for Asterisk to know that the call is ringing the endpoint.

If and only if in-band tone analysing is enabled at Asterisk.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] PLL-based ztdummy available at bugs.digium.com

[Paul Cadach]

Hello,
 
As decided by me and Tony Mountifield, I'd 
updated ztdummy to provide more accurate timing with minimal jitter - bug #6631 
at bugs.digium.com (http://bugs.digium.com/view.php?id=6631). 
Please, provide feedback if possible.
 
WBR,Paul.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] What to do with RTCP ????

[Paul Cadach]

Hello,

Olle E Johansson wrote:
> The RTCP branch includes improved support of RTCP, but also a
> reporting facility we do not use currently. Would it be useful to add
> this to a channel variable - or even better a CDR variable - so you
> can add it to CDRs and make reports based on it?

Mostly RTCP information can be used to adjust jitter buffering algorithms,
arrange clocks when peer stopped transmission, etc.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Re: TDMoE protocol

[Paul Cadach]

Hello,

James Harper wrote:
[skipped]
> > Paul Cadach mentioned something about a jitter buffer for TDMoE, but
> > I don't know whether he was talking about an idea or some real code.
> >
> > I'm also thinking about a jitter buffer, but it's tricky. I might
> > decide to combine ztdummy with ztdynamic/ztd_eth in order to make the
> > timing independent of incoming packets or other zaptel devices. The
> > jitter buffer only needs to be 1ms or 2ms in length.
>
> A jitter buffer adds delay though right? I guess 2ms fixed delay
> shouldn't cause a problem, but how would it work if tdmoe is your only
> source of timing? Is the 2.6 version of ztdummy widely held to be
> precise enough for our use?

See my previous mail - 2 ms fixed delay is the maximum required by TDMoE (to 
hold "very fast" packet and to pick a
packet when one is late).

> Assuming the source of TDMoE is an E1 line with exact timing, would
> there be value in using a statistical analysis of TDMoE data to correct
> ztdummy?

TDMoE could work as its own timing source (not so exact as E1 but for +/- some 
microseconds). Timing of non-synchronized
part is not needed to be exact, the problems comes when packets from this part 
is received by externally synchronized
(from E1, for example) peer.

The timing scheme is next:
   BOX1[E1(master)->TDMoE(slave)]->network->BOX2[TDMoE(master)]
TDMoE(master) is perform as timing source for BOX2, but because it's not so 
preciese as E1/T1 timing) packets being
transmitted from BOX2 to BOX1 will have some sort of very little jitter (about 
some microseconds). But because BOX1 have
externally synchronized timing source (E1 stream), there is possible for "late" 
or "early" conditions of TDMoE packets
received by BOX1, so constant delay jitter buffer is required. Be noted about 
BOX1 and BOX2 are still SYNCHRONIZED but
jitter introduced by networking and processing delays at BOX2 should be 
eliminated.

> Eg with x packets received from TDMoE over y time (for large
> enough values of y, and accounting for any dropped packets), it should
> be possible to compute the correct number of ztdummy ticks. If there is
> a variation compared to the actually number of ztdummy ticks, then add a
> fudge factor. Or maybe ztdummy drift isn't constant...

Zaptel could have only ONE,. SINGLE timing source. For BOX2 in scheme shown 
above timing source is TDMoE stream coming
from externally synchronyzed BOX1, so dummy timing source isn't required until 
something is being to fail (especially
network connection between BOX1 and BOX2).

ztdummy is required for BOX2 as "last resort" timing source to handle missing 
timing from TDMoE and make system works
without external timing (TDMoE link brought into RED ALARM condition). ztdummy 
is more-or-less accurate withing its own
time domain, so it's not a big problem to switch to different timing source 
while main source is out of work.

Be noted ztdummy isn't requires for BOX1 just because E1/T1 card have internal 
timing circuit which will generate timing
even without E1/T1 connections, but accuracy of this timing will be much more 
bad than when T1/E1 connections from
synchronized source are presented.


TDM clocking rules is very easy:
1) timing source within a system should be single;
2) two boxes on the same TDM connection should be synchronized from the same 
timing source;
3) when main timing source is get failed system should switch to any sort of 
internal timing or to elect another
external timing source.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Libpri and caller name

[Paul Cadach]

Hi,

Alistair Cunningham wrote:
> Paul,
>
> Thank you for following up. We currently have "switchtype = national".
> Looking at the code, I see in transmit_display():
>
>  if(pri->switchtype != PRI_SWITCH_EUROISDN_E1) {
>  ie->data[0] = 0xb1;
>  ++i;
>  }
>
> Is this the escape character? Is it safe to comment out these lines?

Yep, of course. If it would behave as required by your peer exchange, please,
open a bug on bugs.digium.com and specify type of your peer switch.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Call back functionality in libpri using QSig

[Paul Cadach]

Hello,

Dinesh Nair wrote:
> On 02/10/06 22:16 Alexander Lopez said the following:
> > Does the Callback happen after a specifed time period or immediately. We
>
> it should happen after a specified time period and retry for a specific
> number of times. i am not yet sure if infinite retries are required/supported.

As I understand CCBS isn't callback in usual manner. It just sends a 
notification back to caller about called subscriber
is being free. No real callback is envolved. As pointed in Q.953.3, "The CCBS 
supplementary service enables a calling
user A, encountering a busy destination B, to be notified when the busy 
destination B becomes not-busy and to have the
service provider reinitiate the call to the specified destination B, if user A 
desires."


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Libpri and caller name

[Paul Cadach]

Hello,

Alistair Cunningham wrote:
[skipped]
>The solution is to ensure your equipment is set to the proper
> switch type, namely NI-1 or NI-2 (as opposed to a Nortel switch type
> like DMS-100).

Current libpri code isn't sends DISPLAY IE for NI-1 or Q.931 switchs, and isn't 
uses character set prefix for EuroISDN
E1 switches.

[skipped]

> I've had a look through the libpri code, and don't see the escape
> character or Nortel specific code. Can anyone please point me to the
> correct place, or to a patch?

Look q931.c for transmit_display() function (found at line 1058 in current 
SVN-TRUNK source tree).


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] TDMoE timing

[Paul Cadach]

Hi,

Tony Mountifield wrote:
[skipped]
> When I start up zaptel, with wcfxo, ztd-eth, ztdynamic and zaptel
> loaded, my monitoring machine initially sees one TDMoE packet per
> millisecond, as expected. After between 75 and 90 packets, there is
> suddenly a pause for anything from 80ms to 800ms, after which the next
> packet in sequence is sent, followed in rapid succession by the next 18
> packets spaced about 20us apart. Then another big pause followed by
> another burst of 18 or 19 packets. At the second pause, there is a
> discontinuity in the TDMoE sequence number, indicating some packets have
> been lost.

[skipped]

Hm-m-m, I'm using TDMoE to pass timing between two Asterisk boxes (one is not
connected to TDM network) and don't found any problems. Note: The zaptel is very
old, dated arout January, 25th 2005.

Looks like the problem lives somewhere around your network card.


I found that TDMoE requires some sort of 'jitter buffer' just because packets
goes not exactly 1000ns but could be delayed for a little due to network
activity and zt_transmit() is called without data received from remote side.


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] chan_h323.so

[Paul Cadach]

Hi,

Is location of libh323 included in content of /etc/ld.so.conf file to make 
loader to be able to find shared object
files?


WBR,
Paul.

- Original Message -
From: "Hoai-Anh Ngo-Vi" <[EMAIL PROTECTED]>
To: 
Sent: Friday, January 27, 2006 7:28 PM
Subject: [asterisk-dev] chan_h323.so


> Hi
> I use * 1.2.0-rc2 and when I try to load chan_h323.so I get that WARNING:
> [chan_h323.so]Jan 27 14:21:36 WARNING[15535]: loader.c:325 __load_resource: 
> libh323_linux_x86_r.so.1.17.1: cannot open
shared object file: No such file or directory
> PATHs are set correctly according to the README file in 
> /usr/src/asterisk/channels/h323
>
> Any idea? Does chan_h323.so not work with * 1.2 ?
>
> Thank you
>
> ___
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] TE410 problem

[Paul Cadach]

Hello,
 
Looks like your link to Avaya is down. 
Probably there is interface down at Avaya side or link is physically 
disconnected.
 
 
WBR,
Paul.

  - Original Message - 
  From: 
  Chee 
  Foong 
  To: asterisk-dev@lists.digium.com 
  
  Sent: Wednesday, October 05, 2005 4:53 
  PM
  Subject: [Asterisk-Dev] TE410 
  problem
  
  
  Hello,I have a * server with a TE410 card 
  installed. It has 3 active E1 link connected to an avaya pbx. * is set to be 
  the master while avay is slave. * is the latest CVS headIt's been running 
  fine for 2 weeks. However, yesterday all 3 of the E1 link was down.  
  Looking at the log, I found an error at 11:18:15 log time which 
  showOct  3 11:18:15 VERBOSE[11393] logger.c: Write to 141 failed: 
  Unknown error 500Oct  3 11:18:15 VERBOSE[11393] logger.c: Short 
  write: 0/15 (Unknown error 500)After seeing this error, I was 
  suspecting that the signalling between * and avaya was not synchronized 
  correctly, therefore I stop * and restarted zaptel and wct4xxp. but that 
  doesn't work. I finally have to reboot the * server and all are working fine 
  for 3 hours and the problem happened again. Log file showing the same error 
  message. I rebooted the server and has not seen it happend for about a day and 
  still monitoring.Any one know what could have cause this?I 
  have attached a portion of the logs. look at time 11:18:15, that's where 
  zaptel starts to fail.
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] How complete is Q.SIG support?

[Paul Cadach]

Hello,

Q.SIG is based on Q.931, so basic Q.SIG support is already available. Support
for advanced Q.SIG features (including other Q.931-based signallings) like
supplementary services could be developed on per-request basis, just because no
real Q.SIG hardware is available for testing.

Anyway be ready to have some sort of inadequate reactions of PBX or Asterisk
with Q.SIG signalling, report the bugs, provide any requested traces/information
and such misoperations will be fixed ASAP.


WBR,
Paul.

- Original Message - 
From: "Tony Mountifield" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, September 28, 2005 3:10 PM
Subject: [Asterisk-Dev] How complete is Q.SIG support?


> I have been asked by a prospective customer whether we support Q.SIG for
> a unit that will connect behind a PBX using an E1 trunk.
>
> Looking through the change logs in libpri I can see that at least some
> support for Q.SIG has been added in HEAD since the release of v1.0, but
> not being familiar with Q.SIG, I can't tell whether this support is
> complete or partial.
>
> So, can anyone tell me how complete Q.SIG support is in Asterisk CVS Head?
>
> In case it's relevant, it will be connected to an Ericsson BP250 which
> has a Q.SIG module installed.
>
> Thanks
> Tony
> -- 
> Tony Mountifield
> Work: [EMAIL PROTECTED] - http://www.softins.co.uk
> Play: [EMAIL PROTECTED] - http://tony.mountifield.org
> ___
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Redirection reason

[Paul Cadach]

Hello,

Redirection reason is not PRI-specific. For example, all terminal channels (FXS,
Skinny) and some trunking channels (like H.323) is possible to generate real
reason of redirecton. Also, SS7 is redirection-reason capable too.

IMHO at least trunking interfaces (IAX, H.323, PRI, SS7, etc.) should be capable
to bypass redirection reason and other telco-related information.

WBR,
Paul.

- Original Message - 
From: "Kevin P. Fleming" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 28, 2005 4:42 AM
Subject: Re: [Asterisk-Dev] Redirection reason


> Kristian Nielsen wrote:
>
> > It wasn't clear to me from you message: Would you accept a patch that
> > added redirect reason to struct ast_callerid, or would you prefer to
> > stick to the PRIREDIRECTREASON variable, with the limitation that
> > entails?
>
> I think it makes sense to leave it the way that it is for now, since
> it's very PRI specific. You can opt to copy it into an inherited
> variable early in your dialplan so that it gets copied into all new
> channels that are created, though.
>
> > [We have the need to pass redirect reason between two different channel
> > drivers we are writing, and I thought adding to struct ast_callerid was
> > the cleanest way.]
>
> It could be, but it would also increase the size of that structure for
> all non-PRI uses as well, which might not be too helpful.
> ___
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Raw E1 capture

[Paul Cadach]

Hello,

Michael Beukman wrote:
> I have configured zaptel.conf with this:
>
> span=1,0,0,ccs,hdb3
> clear=1-31
>
> Does this mean I've merged the timeslots into one stream?

You're correct.

> and how then do I go about capturing the "master" channel?

ztcfg -vv shows master channel like this:
Zaptel Configuration
==

Dynamic span 1: driver eth, addr eth0/00:50:56:C0:00:01, channels 31, 
timing 0

Channel map:

Channel 01: Clear channel (Default) (Slaves: 01 02 03 04 05 06 07 08 09 10 
11 12 13 14 15 16 17 18 19 20 21 22 23 24
25 26 27 28 29 30 31)

31 channels configured.


Then you can just do
cat /dev/zap/1 >spandata.raw
or
dd if=/dev/zap/1 of=spandata.raw
to capture this stream. Also, you can open /dev/zap/ in your 
application to process receiving data "on
the fly".


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Fwd: zaptel divert?

[Paul Cadach]

Hello,

divertingLegInformation2 support is included with current CVS-HEAD version of 
libpri.


WBR,
Paul.

- Original Message - 
From: "Roy Sigurd Karlsbakk" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" 
Sent: Wednesday, June 01, 2005 5:25 PM
Subject: [Asterisk-Dev] Fwd: zaptel divert?


> hi
> 
> has there been done anything to make zaptel diverts work yet? this is  
> needed if the telco doesn't allow RDNIS to be set on normal calls.
> 
> roy
> 
> 
> 
> ___
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: Solved - Re: [Asterisk-Dev] Re: SigSeg in channel.c / chan_mISDNproblem ?

[Paul Cadach]

Hello,

Jeremy McNamara wrote:
> Andreas Czerniak wrote:
> > this problem was solved by an patch by Jose Carlos Garcia Sogo:
> >
> > http://www.beronet.com/bugs/bug_view_page.php?bug_id=046
> >
> > And it only occurs in asterisk stable versions not in the head revision.
> 
> *Gasps*  "Stable" code crashing

As studied before most of problems of this crash is chan_mISDN related.


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Re: New h.323 channel driver

[Paul Cadach]

Hello,

Read channels/h323/README and follow instructions. You should upgrade your 
PWLib/OpenH323 libraries.


WBR,
Paul.

- Original Message - 
From: "Ganbold Tsagaankhuu" <[EMAIL PROTECTED]>
To: "Jeremy McNamara" <[EMAIL PROTECTED]>
Cc: 
Sent: Friday, May 13, 2005 12:42 PM
Subject: Re: [Asterisk-Dev] Re: New h.323 channel driver


> Hi,
> 
> I did cvsup asterisk and I compiled asterisk.
> However I'm having trouble compiling chan_h323.
> 
> asterisk# gmake opt
> g++ -DNDEBUG   -I../../include -Wmissing-prototypes -fPIC 
> -DP_FREEBSD=504100 -I/usr/local/include -I/usr/local/include
> -D_REENTRANT -Wall -DP_FREEBSD=504100 -DP_USE_PRAGMA -DPHAS_TEMPLATES
> -I/usr/ports/devel/pwlib/work/pwlib/include/ptlib/unix
> -I/usr/ports/devel/pwlib/work/pwlib/include -DPTRACING
> -I/usr/ports/net/openh323/work/openh323//include -DHAS_OSS -DNDEBUG
> -pipe -c ast_h323.cxx -o ast_h323.o
> cc1plus: warning: command line option "-Wmissing-prototypes" is valid
> for C/ObjC but not for C++
> In file included from
> /usr/ports/devel/pwlib/work/pwlib/include/ptlib/unix/ptlib/../../contain.h:776,
>  from
> /usr/ports/devel/pwlib/work/pwlib/include/ptlib/unix/ptlib/contain.h:120,
>  from /usr/ports/devel/pwlib/work/pwlib/include/ptlib.h:139,
>  from ast_h323.cxx:34:
> /usr/ports/devel/pwlib/work/pwlib/include/ptlib/contain.inl: In
> constructor `PAbstractList::PAbstractList()':
> /usr/ports/devel/pwlib/work/pwlib/include/ptlib/contain.inl:419:
> warning: right-hand operand of comma has no effect
> In file included from ast_h323.cxx:49:
> ast_h323.h: At global scope:
> ast_h323.h:159: error: `RTP_QOS' has not been declared
> ast_h323.h:159: error: ISO C++ forbids declaration of `parameter' with no type
> ast_h323.cxx:955: error: `RTP_QOS' has not been declared
> ast_h323.cxx:956: error: ISO C++ forbids declaration of `parameter' with no 
> type
> /usr/ports/devel/pwlib/work/pwlib/include/ptlib/unix/ptlib/../../pdirect.h:458:
> warning: inline function `static BOOL PDirectory::Remove(const
> PString&)' used but never defined
> gmake: *** [ast_h323.o] Error 1
> asterisk#
> 
> How to solve this problem?
> 
> thanks,
> 
> Ganbold
> 
> 
> On 5/12/05, Jeremy McNamara <[EMAIL PROTECTED]> wrote:
> > Ganbold Tsagaankhuu wrote:
> > 
> > >I really appreciate if somebody can point me to the right direction.
> > >
> > >
> > 
> > Run CVS -HEAD.
> > 
> > 
> > Jeremy McNamara
> >
> ___
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Re: New h.323 channel driver

[Paul Cadach]

Hello,

Michael Manousos wrote:
> > The problems mostly relies on OpenH323 - there is deadlock condition, check 
> > #3967. Also, under high load single
cleaner
>
> I have also notice them, but only with the Pandora or above versions.
> That's the main reason that asterisk-oh323 has stuck with the Janus
> version of OpenH323/Pwlib.

I do about the same with chan_h323 about 1,5 years ago, and have the same 
troubles with pre-Pandora releases of
OpenH323...


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Dev call 1.2 release discussion

[Paul Cadach]

Hello,

Adam Goryachev wrote:
> On Fri, 2005-05-06 at 15:41 +0600, Paul Cadach wrote:
> > User-space only software which isn't depends on any sort of additional 
> > support from kernel level.
>
> Why?, it is still ALL software...
>
> Given that some closed source commercial 'box' may be a soft switch, but
> then you don't know where the line is between kernel and application...

It is portable and isn't depends on any sort of hardware/drivers, especially 
when no such hardware/drivers is available
or its broken.

> > Just because software timing was done myself for Asterisk-0.5.0 about 1,5 
> > years ago, it isn't so complex and could
be
> > ported to CVS-HEAD within one week or faster. Current mechanism to switch 
> > timing between zaptel-based timer and
> > receiving stream could make such port more easy. Probably, this thing is 
> > not for 1.2 but should be implemented
anyway
> > within 1.x tree.
>
> So why didn't you contrib that back when you did it? In fact, why don't
> you contrib that now?

The changes was rejected. I don't remember reasons for the reject.

> I would think that 1.2 is in fact exactly the same as CVS HEAD. ie, CVS
> HEAD stops accepting experimental patches/new features over the next 6
> weeks, at which point we say CVS HEAD == 1.2.0, and then we fork and
> start a new CVS HEAD, and continue 1.2.0 which is then CVS STABLE.

Before fork we should commit all TESTED BUT NOT COMMITED changes to make them a 
chance to live, otherwise those changes
will go away for some time then appear again...

> > Is someone have development plans for next minor and major releases? Is it 
> > publicly available?
>
> Generally, it depends on what people are willing to work on, rather than
> any specific set of features... What are you willing to work on?
> Mind you, I think the dev-conf probably keeps up with these things, at
> least looking 1 week into the future at a time :)

Mostly there should be wishlist or something like that where really GLOBAL 
projects/ideas should be placed (for example,
SS7 support, redesign of channel drivers and event subsystem, video, 
conferencing and video-conferencing, etc.).


WBR,
Paul.


___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Dev call 1.2 release discussion

[Paul Cadach]

Hello,

Jerris, Michael MI wrote:
> Major Bugs:
> 4164 g.729 codec one way audio in chan_h323 with Cisco CCM 

Patch is available, waiting for commit.


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Dev call 1.2 release discussion

[Paul Cadach]

Hello,

Adam Goryachev wrote:
> On Fri, 2005-05-06 at 14:41 +0600, Paul Cadach wrote:
> > Removing dependencies on zaptel should raise Asterisk as real SOFT switch,
>
> That is just a definition problem how do you define "real soft
> switch"??

User-space only software which isn't depends on any sort of additional support 
from kernel level.

> Either way, I really don't see that this would be a small enough change
> to say that we should complete this before releasing 1.2. IMHO, the ONLY
> things that should be completed before a 1.2 release are the ones that
> are already mostly done, ie, why wait another 3 months just because xyz
> isn't done yet? plus of course bug fixes.

Just because software timing was done myself for Asterisk-0.5.0 about 1,5 years 
ago, it isn't so complex and could be
ported to CVS-HEAD within one week or faster. Current mechanism to switch 
timing between zaptel-based timer and
receiving stream could make such port more easy. Probably, this thing is not 
for 1.2 but should be implemented anyway
within 1.x tree.

> I hope we would see a 1.2 release within the next 2 - 3 months (random
> time) because it has been a long time since the last release. At this
> stage, we should be releasing frequantly... once the dev cycle slows,
> and we are mostly just bug fixing with the occassional new feature, then
> a release once per year or even 18mths would be more expected

At least I would see in 1.2 all things already done for CVS-HEAD (and, 
probably, not commited due to different reasons),
mostly changes related to expanding functionality, compatibility and stability 
of channel drivers and existing
applications.


Is someone have development plans for next minor and major releases? Is it 
publicly available?


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Dev call 1.2 release discussion

[Paul Cadach]

Hello,

Adam Goryachev wrote:
> Either way, I don't see that this should be required for 1.2.0 release.
> I would like to see more work done on exposing the call quality
> (jitter/etc) values for a 1.2.0 release though.

Removing dependencies on zaptel should raise Asterisk as real SOFT switch, 
easily portable to mostly any *nix-based
platform. Current timing algorithms isn't allow Asterisk to work the same 
manner with and without zaptel drivers.


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Early media in H.323 driver

[Paul Cadach]

Hello,

Chih-Wei Huang wrote:
> Hello all,
> I encountered another problem about H.323 channel driver.
> The scenario is, A calls Asterisk PBX, and then dials B.
> B then sends ringback tone by early media (via faststart or so).
> However, PBX said
>
> chan_h323.c:703 oh323_write: Asked to transmit frame type 4, while
> native formats is 1 (read/write = 1/1)
>
> and hangup the call.

This is because:
1) H.323 allows different codec negotiated for opposite voice path while 
Asterisk have single codec for channel;
2) There is missed codec negotiation (???, not verified) between OpenH323 stack 
and Asterisk, so translation couldn't be
set up correctly.
3) Asterisk currently isn't have codec preferences, so it could interfere with 
1) and 2).

Usage of translation within oh323_write is complicated because state of the 
locks is unknown (sometime it calls with
locks held, sometime without ones).

WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Re: Asterisk H.323 driver

[Paul Cadach]

Hello,

Why FastStart handshake for incoming call couldn't be acknowledged on CALL 
PROCEEDING message?


WBR,
Paul.

- Original Message - 
From: "Paul Cadach" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" 
Sent: Friday, March 25, 2005 5:57 PM
Subject: Re: [Asterisk-Dev] Re: Asterisk H.323 driver


> Hello,
> 
> Chih-Wei Huang wrote:
> > Craig Southeren wrote:
> [skipped]
> > Paul's patch seems defer calling H323Conneection::Open until
> > receive OLCAck so the problem can be solved.
> > (though he said it is for 1.12.2, it seems still applies to Openh323 CVS
> > -- I didn't really test)
> 
> I'm totally not sure about correctness of call to H323Connection::Open() until
> OLCAck is received, i.e. when remote end isn't acknoweleges parameters...


___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] app_dial Caller ID behavior

[Paul Cadach]

Hello,

Matthew wrote:
> Their original logic was that a user didn't know who they were transferring
> from extension to extension or when a call came back from parking. Changing
> the CallerID to the destination fixed that problem. It makes certain sense,
> but boy did it screw up a lot of things on our systems.

One more vote to add full support for redirection information passing together 
with a call and provide full information
about each leg to be persistent for duration of a call... Usage of this 
information could help all issues pointed by
you.


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] strcasestr: referenced symbol not found in chan_sip.c

[Paul Cadach]

Hello,

Solaris usually have standard libraries with cutted functionality (I had such 
type of problems with Solaris some time
ago, missed function asprintf()). Looks like Asterisk needs to have own 
"compatibility" library... :(


WBR,
Paul.

- Original Message -
From: "Brian McCrary" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, March 23, 2005 8:42 PM
Subject: [Asterisk-Dev] strcasestr: referenced symbol not found in chan_sip.c


> Hello,

[skipped]

> I'm running on Solaris 10/SPARC.  Has anyone else had this problem?


___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Manager XML

[Paul Cadach]

Hello,

Olle E. Johansson wrote:
[skip]
> Adding "Accept: application/ms-excel" will not give you output
> in Microsoft Excel format, sorry twisted ;-)

MS Excel (at least 2K and higher) have possibility to convert 
specially-formatted HTML data into workbook. I've uses
this feature to make huge Excel's workbook "on the fly" filled with data coming 
from SQL server after "strong" analysis
(grouping on different "views", evaluating complex expressions, etc.).

So, it's possible to have application/ms-excel content type for MS Excel 
representation without knowelege of its
internal format.


Also, about iso-8859-1 and UTF8. There is possible to have national language to 
represent caller IDs, etc., so support
for multilingual extensions should be planned IMHO.


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Silence suppression in asterisk/chan_sip?

[Paul Cadach]

Kevin P. Fleming wrote:
> I've thought about this too, but I think the overhead of every RTP
> stream using the timer separately would just be too much. I think the
> best solution is for rtp.c to create a thread when it loads, use the
> zaptel timer to clock that thread, and have all outbound RTP sent by
> that thread based on a reliable clock source.

This thread should handle self-generated packets (comes from Zaptel, generators,
etc., i.e. non-VoIP sourced). At least it could help a little with timestamp
generation/calculation.

> This would also help with RTP bridging, since there would only be one
> bridging thread, not one for each call.

Bridged calls should use its own timing, while mixed calls (conferences, etc.)
and generators (and MOH, of course) could use internal Asterisk's timer (based
on zaptel, RTC or system clock source). I had done someting like that for 0.5.0,
just for generators (including MOH) - all worked fine until I moved to newer
version.

Also, IMHO there should have different SSRC for each voice stream (Asterisk's
internal streams is one SSRC because uses its own timing and any other
enpoint(s) have different SSRC(s)).. RTP's 'M'ark flag could notify remote party
about clock source is changed.


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] dev conf topic: better CDRs

[Paul Cadach]

Hello,

Matthew Boehm wrote:

[skip]
> If a call comes into our switch as 8005551212, that is the "destination".
> Most of the time, an 800 number gets translated. This becomes the "ringto".
> Both are necessary for billing purposes. Sometimes we have triple
> translation, where an 800 number gets translated to local which has
> call-forwarding on busy to another local number. We still have the 800 as
> dest, but the final number gets saved as 'ringto'.

Usually such fields named as 'connected number' (CN), not 'ringto'.

Also, for redirections next parameters available/exists usually:
1) redirection count (RC);
2) original called number (OCN);
3) redirecting number (RN).

For first redirection (RC=1) OCN equal exactlt to RN, so OCN could be ommited, 
but for second and other redirection
(RC>1) OCN is a number where FIRST redirection was occured while RN is a number 
where LAST redirection was done.

Together with CN, redirection information should be included into CDRs to allow 
better analysis of calls flow. Also,
making CN available everywere within Asterisk could make possible to notify 
PSTN about real connected number when PSTN
"lies" to calling party with PRI's general/main number, not DDI.

As for encoding of CDR records there is X.825 specification describes 
extensible form for CDRs, and already have most of
important fields such as bearer capability, supplementary service information 
used for a call,
calling/called/redirected/connected/dialed numbers, etc. But X.825 have 
non-readable form (ASN.1 BER encoded), so
XER/XML could be used for make CDRs readable by peolpe without usage of 
additional format converters).


WBR,
Paul.

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] CDRs with ms and not just seconds

[Paul Cadach]

Hello,

Kai Militzer wrote:
[skip]
> In my opionion it would make great differences in billing. A glitch of a
> few mili-seconds at hangup of a call, may result in a difference of one
> full second between my * CDRs and those of my telco.

Difference in call duration registered at directly connected exchanges usually 
within 1 sec, exceptionally within 2-3
sec. You can't have equal duration on full call path due to signalling 
transmission/processing times (for example, PRI's
DISCONNECT packet usually about 10 bytes long and uses about 1 ms to transmit, 
plus delays on transmission systems like
SDH, etc., packet processing time and so).


WBR,
Paul.


___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Application "ManualBridge"

[Paul Cadach]

Hi,

Probably you need to manual unlock channels when ones isn't needs anymore by 
ast_mutex_unlock(&c1->lock) or
ast_mutex_unlock(&c2->lock), at least after call to ast_bridge_call(). This 
should help a little.

Also, check that ast_moh_stop(), ast_deactivate_generator()4, 
ast_channel_make_compatible(), ast_bridge_call() isn't
expect unlocked channels.


WBR,
Paul.

- Original Message -
From: "Robert Spielmann" <[EMAIL PROTECTED]>
To: 
Sent: Monday, January 31, 2005 4:08 PM
Subject: [Asterisk-Dev] Application "ManualBridge"


> Hi,
>
> I wrote my own app to manually bridge two channels, however I get some error
> messages saying "avoided initial deadlock for channel xyz" and the channels
> keep existing after both partners hang up. Can someone help me? :-)
>
> Code: http://www.pastebin.com/235671
>
> TIA
> Robert Spielmann
> -
> TAL.DE Klaus Internet Service GmbH [EMAIL PROTECTED]
> Robertstr. 6 * D-42107 Wuppertal, Germany
> Tel +49 (0) 202 495-364 * Fax +49 (0) 202 / 495-399
>
> ___
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>

___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] possible bug in chan_sip

[Paul Cadach]

Hello,

- Original Message -
From: "Maurizio Marini" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, January 13, 2005 8:52 PM
Subject: [Asterisk-Dev] possible bug in chan_sip


> in chan_sip.c line 1137:

[skip]

> should be (conceptualy):
>while(tmp) {
> if (strcasecmp(tmp->name, "type")){
> tmp = tmp->next;
> continue;
> }
>
> if (!strcasecmp(tmp->value, "user")) {
> ast_destroy_realtime(var);
> return NULL;
> }
>
> tmp = tmp->next;
> }

To eliminate such type of problems better is to use for() instead of while(). 
In current example usage of for()
expression will be (from line 1136):
  for(tmp = var; tmp; tmp = tmp->next) {
if(strcasecmp(tmp->name, "type"))
  continue;
if(!strcasecmp(tmp->value, "user")) {
  ast_destroy_realtime(var);
  return NULL;
}
  }

More compact and readable IMHO.


WBR,
Paul.


___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] libpri ISDN features

[Paul Cadach]

Hello,

Andrew Kohlsmith wrote:
> I found the ITU's documents completely and totally worthless.  There was *no*
> actual protocol layout, just highlevel hand-waving in all the documents I
> downloaded.
>
> I found MUCH better info (along with bit-level descriptons) on the CAPI
> website.

Andrew, you are wrong a bit. ITU's specifications just describes how things 
MUST work but without relation to any sort
of implementation like CAPI is (CAPI is API, i.e. it describes way to 
implement/support ITU's/ETSI's/etc.
specifications).

I dislike ITU's specs because they are very cross-linked (for example, support 
for some sort of supplementary services
described on Q.95x and relies on Q.932, X.219, X.208, etc. and this list is 
very, VERY long)...


WBR,
Paul.


___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] New card - TE110P?

[Paul Cadach]

Hi,

> Matt Riddell wrote:
>
> > In that case I'd recommend the quad span E1/T1 card which is available
> > now.  (also seeing as you stated you needed 3-4, this will be a lot
> > cheaper)
>
> ...and introduce a single point of failure, as well.

And generates much less interrupts per second, because each zaptel device have its own 
clocking interface...  Zaptel
device generates an interrupt every 1 ms (1000 interrupts per second), so 2 or 3 cards 
will generate about 2000 or 3000
interrupts every second, and not all host CPUs will handle them successfully. In this 
situation to minimize IRQ flow
better is to:
a) have "as-much-as-possible" ports on signle card;
b) distrubute cards between different hosts.


WBR,
Paul.


___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Module unloading

[Paul Cadach]

Hi,

Michael Sandee wrote:
> When writing a module which does some magic on unload_module() I ran
> into some trouble...
>
> In contrary to what include/asterisk/module.h says, unload_module() does
> not get called during exit, only when unload is called from the CLI.

Module unloading at exit is easy fixable at Asterisk's "kernel". No additional work is 
required at modules level. As I
remeber cleanup of unloading process is planned for 1.2 version.


WBR,
Paul.


___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] channel driver sample - Coding/Transcoding/Conferences

[Paul Cadach]

Hi,

Steve Underwood wrote:
> The *appearance* of DSPs being expensive is an artifact of the way the
> industry runs. DSP cards are priced at an extreme multiple of their
> actual cost, leading to a vicious circle - DSP cards are expensive so
> they have a small market. Why are they expensive? because they have a
> small market. E1 cards were like that too, until recently. Apply the
> Digium pricing strategy to a DSP card and it would not look too bad. Add
> an H.100 port to Digium's E1/T1 cards and the DSP card and maybe you are
> starting to build something nice. Sure, it starts to look a little like
> a Dialogic card. That isn't all bad, though, if its a reasonably priced
> open platform, instead of a Dialogic high priced straight-jacket.

I think combined solution (i.e. DSP boards which are possible to process digitized 
signals from H.100 bus and from host
bus) is better, because those boards will have much wider market place, not only 
digital/PC telephony (examples of
different usage - spectrum analyzis of high-speed signals, high-end digital 
oscilloscopes, etc.).


WBR,
Paul.

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] PRI U2U display messages

[Paul Cadach]

Hello,

- Original Message - 
From: "Klaus-Peter Junghanns" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 29, 2004 3:18 PM
Subject: Re: [Asterisk-Dev] PRI U2U display messages


> Hi,
> 
> you cannot send INFORMATION messages with DISPLAY IEs to the network. 
> However you can do that when you are the network (NT mode) and send them
> to an ISDN pbx or ISDN phone.
> 
> The "please" hold on your gsm phone was triggered by the ISDN pbx
> putting you on hold, so a NOTIFY message was passed through the network.
> This also happens when you deflect or forward a call.

NOTIFY support on PRI links is being developed. See bug #1840.


WBR,
Paul.


___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] About OpenSS7 integration to Asterisk

[Paul Cadach]

Hi,

- Original Message -
From: "Storer, Darren" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED] Digium. Com" <[EMAIL PROTECTED]>
Sent: Friday, May 07, 2004 4:21 PM
Subject: Re: [Asterisk-Dev] About OpenSS7 integration to Asterisk


[skipped]

> BFGB> "Asterisk soft-HDLC code could not handle SS7 (FISUs and
> BFGB> LSSUs), was putting too many flags between frames, was
> BFGB> discarding frames, wrapping on the receive buffers, ...
> BFGB> It would not be possible to meet 10E-6 BER because the
> BFGB> Asterisk soft-HDLC was introducing more errors than that
> BFGB> leaving nothing for the transmission facility.  Skips and
> BFGB> drops and pops might be ok for voice and even line-side
> BFGB> ISDN signalling, but is unacceptable for trunk-side
> BFGB> transmission and signalling."
>
> It would be wonderful to see cost effective SS7 (especially INAP) solutions
> but the requirements for timing usually mean that more expensive
> "intelligent" line cards must be used, not to mention the cost of SS7
> validation, conformance and performance testing. Without the higher level
> SS7 protocol certification it will be very difficult to find a Telco that
> will let you connect directly to their switches...

As for TE410P/TE405P based on Infineon's PEF22554 QuadFALC chip, there is a partial 
support for off-load FISU/LSSU
processing/generation from CPU to framer chip. Look, for example, chapters 4.1.14.2 
(SS7 receiving) and 4.4.7.2 (SS7
transmitting) for E1 mode at QuadFALC's datasheet.

Also, TE410P/TE405P have Xilinx chip which is used for implementation of a bridge 
between PCI bus and QuadFALC chip. It
could be possible to move some SS7-related processing from CPU to this chip (may be 
replacement of Xilinx chip would
required, but it is not so big problem).


WBR,
Paul.

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Re: Instability with H323

[Paul Cadach]

Hi,

> > Also, I don't think passing additional 10 kbps for 100 Mbit/s network is so
> > significant.
>
> Ahem.. Thats nice for you to only have to think about using Asterisk on
> Ethernet, however unfortunately some of us are out in the "real
> world" (substitute "third world" if you prefer) and don't have the luxury.
>
> Unfortunately, in my part of the world, "standard" cable internet costs approx
> $55/month for 128kbps/33kbps. This means for me (or my customers) to use VoIP
> at all from home the upload _must_ use less than 33kbps

I've told about local "clean" ethernet, not long-distance connections. Kazakhstan's 
Internet costs much higher than
your... :-)'

> For carrying calls on these types of links, I am sorry to say that my 6 year
> old "Clarent Media Gateway" is still an order of magnitude more efficient
> than Asterisk, as is any standard Cisco VoIP gateway.
> I have very high hopes for Asterisk however assuming Ethernet connections to
> VoIP gateways completely ignores probably 90% of VoIP users in the world.

One of most poppular usages of Asterisk is to provide local office soft-PBX to handle 
and distribute calls, provide
enhanced call support features like IVR, voicemail, etc. Usage of Asterisk as real 
VoIP switch IMHO is at "beta" stage
because requires many checks, additions and re-works to support, for example, jitter, 
etc. at ALL POSSIBLE VoIP
protocols (not only own IAX/IAX2).

For example, Asterisk isn't have support for configuring frames/packet on 
per-connection/per-protocol basis. Now it uses
_best_ common parameters (i.e. 20 or 30 ms per packet)...

> To repeat, 10kbps is ALOT of data to me, as it is exactly 30% of the entire
> upstream bandwidth from the greater percentage of my customers!

Any VoIP likes:
1) bandwidth (at least STABLE bandwidth, i.e. requires some sort of QoS);
2) low delays (usually not more than 150-200 ms);
3) predictable jitter (to provide stable buffering scheme).

Satellite links can't provide you with both of those parameters, so if you want to 
have high/commercial-quality VoIP
connection you need to thinking about changing your provider to someone who have 
"land" network (usually it's
phone/telecommunications companies provides "plain" telephony services).


WBR,
Paul.

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Re: Inestability with H323

[Paul Cadach]

Hi,


>  I used firefly, in iax mode.
>
>  I used ethereal to capture the data.
>
>  33 bytes for 20 ms of audio frame.
>
>  4 bytes of iax header.

Plus 8 bytes - UDP header, 20 bytes - IP header, 14 bytes - EthernetII header. Totally 
- 79 bytes. When the same packet
goes through PPP it don't have EthernetII header and usually uses Van-Jacobson IP 
header compression (which compresses
IP header up to 4-8 bytes as I remember), plus PPP header/trailer (about 8 bytes, I 
don't remember).

>  Examine that frame with ethereal.
>79 bytes on wire. This includes link layer usage

Yep, see before.

>   50 packets per second, ==> 31.600 bits/second.

Yep, it's "line" speed on Ethernet.

>  Now, go to 65 bytes for the calculation, which is what you will have with
>  ppp (such as on a dialup)  ==> 26,000 bits/sec

Ok, you saves 14 bytes per packet.

> Now, go to ::http://www.openh323.org/docs/bandwidth.html
> 3 gsm audio frames/packet.  ==>13.200 bits/sec.
>   (This figure does not include link layer usage)
>
> So I think we have 13.2 to compare with 26

Continue your calculation. 33 bytes per frame * 8 bits per frame * 50 frames per 
second (one frame consists 160 samples,
or 20 ms of audio) = 13200 bits/sec. So, pointed link just says about CODEC bandwidth, 
not NETWORK bandwidth. Add all
header sizes (20 for IP, 14 for MAC, 8 for UDP and 12 for RTP) to your 33 bytes and 
you gets 87 bytes per packet for
Ethernet (or about 73 bytes for PPP link). So, consumed bandwidth for single frame GSM 
is 34800 bits/sec for ethernet
and about 29200 for PPP, not 13200 bps!!! To compare, the values for single-frame GSM 
over IAX/IAX2 is 31600 bps for
ethernet and 26000 bps for PPP (i.e. IAX/IAX2 saves about 3,2 kbps for you by using 
small headers).

Look before - I've got the same values as you get with Ethereal.

> > Also, I don't think passing additional 10 kbps for 100 Mbit/s network is so 
> > significant.
>
> True.  However, try doing voip on a dialup connection, where neither end
> is doing silence detection.
> I would far rather have both ends doing silence detection at a lower bit rate.
> My dialup connection is 40kbits/sec.
>   iax will not work on my dialup. But, gsm with h323 does work just fine.

I had used GSM over IAX2 for long time, and it works fine on regular V.34+ connection 
(31.2-33.6 speeds). As calculated
before, both IAX2 and RTP will fit to this bandwidth (if you don't run something else 
together with VoIP traffic).

FYI, now I'm runs G.723.1 6,4K over RTP - it consumes about 17067 bps over PPP link 
(G.723.1 frame duration is 30 ms
packed into 24 bytes).

> ==
>
> I suspect, on reading your bug description, the threading bug just fixed
> was the one that caused your problem with callgenh323
>
> =

I'll try to check it with latest CVS of OpenH323...

> > If you want to preserve bandwidth, use cRTP or IAX/IAX2 protocols with
> > _small_ frames/packet ratio to bypass audio streams over network rather
> > than RTP with many frames per single packet.
> Not so.
>  see above calculations.

See my calculations above... ;-)'

> Yes, you need jitter buffer etc, but I have noted requests on this list
> for jitter buffers in asterisk.

Currently Asterisk doesn't have any jitter buffer at its RTP stack, which is not so 
important for endpoint-to-endpoint
connection (endpoint must eliminate all possible jitter rather than Asterisk).

> My view is that latency is important, but even more important is that your
> audio device is truly full duplex.

Most of new audio cards (including AC-97 compliant) are full-duplex, so it's not 
problem. Latency is not a big problem
too if end-to-end latency fits to 200-250 ms range (good sound quality). So, 
increasing frames/packet value
automatically increases latency, and if you goes out this range your sound quality 
will be noted as poor (but for
technical talks it's not so important).



WBR,
Paul.

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Re: Inestability with H323

[Paul Cadach]

Hi again,

- Original Message -
>  I do appreciate your comments on the reorganisation required in
> chan_h323.c   Is it possible for you to detail what must be done?
> Or, point me to a doc which states what order things have to happen in?

I had used callgen323 on single-CPU machine to make about 20 simultaneous calls to 2 
asterisk's servers through GNU
gatekeeper (I don't remember about proxy mode used). Average statistic is next:
- without call setup handling Asterisk hangs after about 100-200 incoming calls (5-10 
minutes before segfaults);
- after call setup re-design Asterisk hangs after about 1-2 incoming calls 
(once per 2-3 hours);
- GNU gatekeeper hangs after about 10-20 calls goes through it (GK works on 
SMP machine combined with one of
Asterisk server used for tests).

Call setup re-design is very simple - just callback asterisk not immediately after 
SETUP messages is received but after
PROGRESS message sent out by OpenH323 stack. I don't remember all details how I done 
it (it was done about half year
ago).


> > OpenH323 _requires_ to be "right-used" for getting stable results. One example is 
> > SMP/HyperThreading support... At
least
> > I found callgen323 works fine in single-CPU environment but crashes while SMP 
> > and/or HyperThreading enabled. I don't
> > think this is Asterisk issue because callgen323 is fully independed from Asterisk 
> > and uses OpenH323 library only.
> thanks for this.
>
> I am intrigued by your comment on "right-used".
>  Openh323 has had a number of people looking over the source. There was a
> fix recently which fixed a race condition in the code. Indeed, the time
> to the last one was ages - my view is that there are very few races left
> in openh323. I mean, people are getting 70 concurrent calls through
> openh323 gatekeepers (running in full proxy mode).

This is one more example on how it depends on "right-used" OpenH323. Also, full proxy 
mode on GK doesn't say that RTP
packets will be parsed by GK, just _forwarded_ between two endpoints. I.e. OpenH323 
RTP stack isn't used yet.


> Certainly, when playing with a multithreaded program like openh323, you do
> need to code correctly - and there is your "right-used" comment.
>
> I don't remember any comments about callgenh323 failing. OK. I will look
> into that.

All works fine on single-CPU hardware. When you uses SMP and/or HyperThreading (i.e. 
have more than one physical or
logical CPU) callgen323 just crashes randomly (for me - after 300-2000 outbound 
calls). So, it looks like improper
locking handling within OpenH323, because software on SMP/HT system works REALLY 
parallel, and is more dependent on
locking mechanism. It's my own IMHO.


> =
> The H323 protocol specifies RTP for sending the encoded audio frames.
> Thus, the rtp audio packets on the ethernet wire have a predefined format.

Just format of headers, not data is predefined...

> Thus, if the encoded audio frames are sent by asterisk, or by openh323,
>   there is no different to the packet size.
>
> What you will find is that openh323 will put 3 gsm audio frames into one
> ethernet packet. This gives a bandwidth of 20kbit/sec
>
> Asterisk will put 1 gsm audio frame into one ethernet packet. This will
> lead to a bandwith of over 30kbit/sec.

Using large frames-per-packet values is not so much pretty as could seen due to 
increased packetization delays (total of
algorithmic and packetization delays for 1 frame/packet is about 20 ms but for 3 
frames/packet is about 60 ms). Also,
long frames requires to have longer (it time dimension) jitter buffers and loosing of 
long packets is much more
sensitive for earth than loosing short packets.

Also, I don't think passing additional 10 kbps for 100 Mbit/s network is so 
significant.


> Reason:: there are about 30 bytes of header that the OS appends to each
> packet generated by iax before putting it on the wire.

Don't mix IAX and RTP. IAX/IAX2 uses fully different "transport" encoding (looks like 
compressed RTP) and consumes much
less bandwidth than regular uncompressed RTP (independedly on stack used for producing 
RTP packets - OpenH323 or
Asterisk's builtin).


> Thus, it is much more bandwidth efficient to put more than one audio frame
> into each ethernet packet.

See before. If you want to preserve bandwidth, use cRTP or IAX/IAX2 protocols with 
_small_ frames/packet ratio to bypass
audio streams over network rather than RTP with many frames per single packet.


> Now, my point.
>  a)It does not matter if asterisk or openh323 sends the h323 audio packet.
>the format is unchanged.
>Sure, asterisk needs to send iax packets.
>
>  b)the iax protocol is bandwith inefficient, because it just puts one
>encoded frame in an ethernet packet.
>
> I apologise, I forget the exact numbers. I did the work at one stage,
> and showed that iax has a bandwidth over 30kbits/sec for each audio
> stream.
> There are web pages detailing op

Re: [Asterisk-Dev] Re: Inestability with H323

[Paul Cadach]

Hi,

- Original Message -
> a)the lack of response from others on this list who have been involved
>   with chan_h323.c   There is knowledge there that I want to tap into.
>   To be honest, I am not keen to "reinvent the wheel". I want to learn
>   from others, and learn what trials/tribulations they had.
>
> b)I have an architecture reorganisation in my mind that will mean
>   chan_h323.c receives/sends encoded audio frames from/to the h323 stack
>   Currently, there appears to be the asterisk does all rtp handling. This
>is not necessary, and is unwise in my view. I just need some clues as
>to how to "connect" the encoded audio frames to asterisk.

"Successfullity" of any VoIP product could be pointed as count of simultaneous calls 
to be handled without degradation
of audio path. For H.323 (and many other protocols) audio streams goes through RTP 
stack, so keeping it simple as much
as possible increases "bandwidth" of the call server. RTP stack in OpenH323 is complex 
(usage of C++ gives additional
computational "overhead"), so usage of OpenH323's RTP is not best effort. Asterisk's 
RTP is much more simple, sometimes
ugly, but not had this "overhead" and used for other protocols like SIP, Skinny, so 
having cool (in the future) internal
RTP stack allows many features which is not possible when using other stacks (like 
timestamp calculations) and makes "
to share this stack between many protocols, not to be related to H.323 only.

OH323 module have OpenH323 AudioCodec stub implementation, so you could look there for 
starting point if you still want
to use OpebH323's RTP stack.


Also, chan_h323 needs some reorganization on call setup sequences to handle all 
signals at their "places", for example,
do not start ast_pbx() subroutine until PROCEEDING message is sent (otherwise it 
produces "interference" between
OpenH323 and Asterisk and, as result, causes crashes).

OpenH323 _requires_ to be "right-used" for getting stable results. One example is 
SMP/HyperThreading support... At least
I found callgen323 works fine in single-CPU environment but crashes while SMP and/or 
HyperThreading enabled. I don't
think this is Asterisk issue because callgen323 is fully independed from Asterisk and 
uses OpenH323 library only.


WBR,
Paul.


___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] TE405P *hardware* question

[Paul Cadach]

Hi,

Check at the end of right column at page 2 of pointed manual:
"... Two forms of over-voltage protection are provided, one that permits 5V 
compliance, and one that does not. For 5V
compliance, a zener-like structure connected to ground turns on when the output rises 
to approximately 6.5V. When 5V
compliance is not required, a conventional clamp diode may be connected to the output 
supply voltage, Vcco. The type of
over-voltage protection can be selected independently for each pad".

As you pointed (and the same page 2 says too), both 3.3V and 5V PCI uses the same Vcco 
voltage, 3.3V, but as you can see
at pages 31-35, Xilinx have different symbols for input/output buffers for each pad:
- IBUF_PCI33_3 or IBUF_PCI33_5 or IBUF_PCI66_3;
- IBUFG_PCI33_3 or IBUFG_PCI33_5 or IBUFG_PCI66_3;
- OBUF_PCI33_3 or OBUF_PCI33_5 or OBUF_PCI66_3;
- OBUFT_PCI33_3 or OBUFT_PCI33_5 or OBUFT_PCI66_3;
- IOBUF_PCI33_3 or IOBUF_PCI33_5 or IOBUF_PCI66_3;

Page 43 specifies that for PCI33_3 and PCI66_3 maximum input voltage at pad is 
Vcco+0.5V, i.e. 3.8V (uses clamp diode to
Vcco), but for PCI33_5 there is 5.5V (uses zener diode to ground).

As for TTL specification, "0" voltage must be between 0 and 0.8V, and "1" voltage must 
be between 2.4 and 5V, so LVTTL
(3.3V)with their levels must comply with TTL spec. So, I don't see any is no problem 
if you connect zener-protected pins
(5V tolerant) to 3.3V system.


There was for Xilinx. But what about PEF? As I see for one used for TE410P (to 
remember - I don't have TE405P to check
which chips used for it), there was 3.3V-only chips, so IMHO TE405P must have any sort 
of 3.3V source (from onboard
regulator or  from PCI connector).


Any way, I don't see any problems to connect TE405P to 3.3V bus (after making second, 
3.3V, key hole). But I'm not
Digium's hardware engineer... ;-)' I think there would be dual-voltage TE405P+ cards 
(TE405P with two key holes)
available when all TE410P "already-made" will be sold out. ;-)'


WBR,
Paul.

- Original Message -
From: "Andrew Kohlsmith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 14, 2004 2:05 AM
Subject: Re: [Asterisk-Dev] TE405P *hardware* question


> Thanks for the reply.
>
> > As I checked out Xilinx's datasheets CPLD used for TE410P's PCI bridge is
> > Spartan II-E family which is maximum 3.3V capable, while regular Spartan-II
> > family (which is, I think, used for TE405P) is supports both 3.3 and 5V for
> > I/O pins, but requires different termination for each voltage. I don't have
> > TE405P, but as I remember there was a sort of problems with some chipsets.
> > May be TE410P have ones too but they are not reproducible because "ugly"
> > chipset (or motherboard vendors) isn't support 3.3V for this chipset.
>
> http://direct.xilinx.com/bvdocs/publications/ds001_2.pdf
>
> Page 30 says that it can indeed use 3.3V or 5V for PCI, and that the clamps
> need to be different for 5V tolerant systems (which the TE405P is), so that
> much should work...
>
> The next page goes on to say that the standard doesn't require use of Vref of
> board term voltage, only 3.3V on Vcco.  Now it goes on to say that I/O
> configured for PCI 33MHz 5V standard are also 5V tolerant...  we know all
> that since the card is a 5V card.  :-)
>
> Page 43 gives the PCI 3V and 5V buffer Voltage specifications -- it looks like
> there should be no issues whatsoever, I believe that the Vih/il and Voh/ol
> specs are acceptable for both 3V and 5V systems.  Vcco does not change for 5V
> or 3V operation.
>
> The pinout tables are a little confusing for me, but with the information
> gathered so far there shouldn't be any obvious problem with sawing the key
> out for 3V operation.  I would still like to hear from Digium as to whether
> the IOREF is connected to the correct place on the PCI connector, and what
> the unstuffed voltage regulator was to be used for and its part number.
>
> Regards,
> Andrew
> >
> >
> > So, I think, the problem is different termination of I/O blocks at the
> > Xilinx for 3.3 and 5 V for Spartan-II family.
> >
> >
> > WBR,
> > Paul.
> >
> >
> > - Original Message -
> > From: "Andrew Kohlsmith" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, April 13, 2004 11:24 PM
> > Subject: [Asterisk-Dev] TE405P *hardware* question
> >
> > > Is there a specific design issue with making the TE405P a universal
> > > 3.3V/5V product?  I've done a cursory review of the Xilinx part and it
> > > seems that it should be just fine to plug in to a 3V or 5V PCI slot, if I
> > > take a hacksaw and create the appropriate key.
> > >
> > > I haven't yet traced out the VIO pins to make sure that the Spartan will
> > > honour the PCI bus voltage.
> > >
> > > Yes I am almost willing to sacrifice a $1500 card at this point in time.
> > > :-)
> > >
> > > Can anyone who is familliar with the hardware design of this product
> > > explain why there are separate 3V and 5V cards?  Hell even the X101P and
> > > TDM400P ar