Asterisk app_rpt runs standard endpoints nodes in full duplex by default. The default config file specifies duplex=2. For bridging nodes, the setup is a little different, as you don't want app_rpt acting like a repeater controller with all the ID's courtesy tones, etc. As long as you say: duplex=0 ; kills courtesy tones, but is half-duplex linktolink=yes ; restores full duplex sematics hangtime=0 ; Sets hangtime to 0 idtime=0 ; kills the ID'er You should see audio going in both directions simultaneously with no mutual exclusivity. Steve WA6ZFT Skip WB6YMH wrote:
At 01:17 AM 8/3/2008, you wrote:
Tony,
I connected to it from node 2010 and it has excellent sounding audio! It was very busy when I connected so I didn't stay connected very long. Thanks. I have seen the issue that Bill saw, namely the long dropouts. I'm wondering if that's due to the linking protocol used by chan_rtpdir not coping with the long link between the Asterisk and Echolink systems (on opposite sides of the world!). I might see if I can find a way to shorten that hop (e.g. by using a "dummy" conference).
If someone is talking on the Echolink side does our audio mix with theirs or are we locked out? I'm not sure of thelinkbox is a mixing or one-at-a-time echolink reflector. In app_rpt everything is mixing, but typically echolink is one-at-a-time. Echolink is one at a time. Interestingly, tbd reports the connection as full duplex, so Skip, could a tlb based node run full duplex with Asterisk via my conference?
Yes if the conference is tbd 1.03 or later and tlb is 0.36 or later. Of course standard Echolink clients that are connected to the conference will only hear the station that "has the floor". tlb clients will hear a mix of everyone that's talking.
I haven't tested full duplex with Asterisk, but I'll bet you will to call my bluff!
73's Skip WB6YMH
_______________________________________________ App_rpt mailing list App_rpt@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt