asterisk/ 40775 765 765 0 7513704453 10451 5ustar rsbrsbasterisk/final_anim.gif100664 765 765 174740 7513704271 13405 0ustar rsbrsbGIF89a]d= $!2*+2B99,F*8M!9c8BS)Bi2Dd)Jt4TzIIIRJJRRJJRZUUURYiWevdeghkvsksks{xxx4V9c9kBZPlkwGsJ{tWrRlsމƎѪӔ祽ܲ! NETSCAPE2.0! ?,]dpH,Ȥrl:Шt*Yجvzv*hsj^R|.wx6.6`igBr )"͒sg̓>u``t`UshNBdc@W0Ȱ!Ri-zgM|M`A?lѧ<#t! h@D #0@pQ1IieM95(1b .r%@@¾C4'6*qrfxJH[Zs+DD7f.) 01zcp[OA}i@WɃwTC` {@\P/- 7s!A`t@Ay6>fx[dȘ}XD5(:΀hX>Շ܀)9 w\W,p"D#P@ƶt F' ꌒ0 9:6a>!(@>k@ns aVg?!31 ޒϙ.֙< 8 "x@WF@0'@,dPD3& Ϩl8‰`pPEBwɀ^1?,F * ]O @᲌g~|~(  @bBGhKƧ Ih\8$ o^$Rq:*djlbUMTy@`L~VG`uP!e bJ@.V,B#CkxV)@5" u"p @\->$e#$VEđ[$)B73`Ll4@0pQ5bJ1 QH0&hȧo$B)-Bc@g>0G1эd35NrRT :LJPQa>K)F|CyrԠR a \'C771g+CVKBTOT7lcrL0)NvkMnGqY"[!D5Xd#!<ݼJbZŜ&$=$VD@&0S gd}ܘ^V 5myYB!hե0STN#YMN v9#܀9~OE %Tze,XV!09> 'p`0G # 0=q.Vr: OΑvƟ $4Has #1@@iĕ#\:.9@v. <ʏqBeFj] mf7+ Xo?PR`t%Wٝ\сe6M/e@7#SE4Z pyK'˸'A;QL/*l8tt2+Z5$K`v@ <(Ckz0j<\0?uE^ (a, -P_&x@3v3"(VȕV8L.ڄK\9 x +x&z5.fJPrh:ӭptbPr1C[cg>AK#}C'+ 504K20#Ε{T |Y h~΀DK42$O$7ʸPw!g9*C:fAd9C|KBf[Uv01Qr!k}7 FB4".=rjU)f+C*/cIt>M3u%f@ed G-RM!>H/hwIb1$uq(PyF  c!KD%8GKpbJ1`]pdfu#@m!;SWHM2* iB0QZjQFHR:#*BC|O}K`Qcjv`C d,W&֌xH_.f2*E16̈ٶ]SoZ& 񍻧r,ܸ;(q;#L$vЅVՑ̰'Qp;2!1ďAL3 0/>sZA 003GgS IP>p!0k<ِ.IQ+sfQQ`Q-i[(HA# M [CB@21`Tu 4E@q ~=ەI[|bVSS ћ  ǀ08@\a/Sr-+5МE[ωqg t  %ə@18i)ft$ٖٝb`7p I:  0 /7x'0#tgB22!B:DZFzHV9 f,;ՍR*SZV: {e\ڟq湥]ڥ[ʠRrr R /ӦrsjcA! ?,Y`ox cr<:S_tcqaQ':ͅR_+:{91lpmo'uGpp,.)YWp[[G6.dU{qUF_RZCe?z96=G~?l_C{B2C H(Qo#io@  D L{H"Lа)ң< qw$HTĈ=\[(y{!*0L=a‚: &aF` XСȃkӣŹ\R 8Xp/n`R4r 4PHHe?xdtGCH (0@uqTF V'<`SQt\A@,0AH 0tG4T-M{d^UN@^,=  AqARW\d1wfPlY Ux3xjR ۵DB;:AZqn0X 8hK adxdM Y\!e0Al4RKt@1q ESi[*Qn`@FPV`<F?jKyA`Vd FT` 9*DLI0BNTu5Qp9. ǥ8_d% (Q%`*~1Ar}!G6 @gRwx-Q|C^|ph-7)H_R@5Y@0#PP?(R/]h) 'Lb"\סUd_pN…HA`t 5jg)Ut+Q{@9REٯ=TqmiR$hXd|6G*SK"8hp4:VR0!f:]G@·|l Cу @(:M(A;qL nCm` 2@B?N"!#LF1"<5@c5d#H)kɡE=D.SGioGX%06\Lq,Bth`"ד @@qab'@2(mF@ |)LGpL Tpv,x'  5D':Yh+ Đxz:0J& 0`$LbDj=cb5I@]sQ!A@vHb3J~`BeHG @H7= u]#2 `)zմx5OI@ q$|Kaȅ4:d#f%$}aM#VPGC>la(OX愅ttcw"H͸Y @ &hd€UT\k"x\e 8F>`#j@{à <pk%NXݺUV0NPEaijQ*@L%j^ nu@8u` mR}`wQO)Rd]6p@rݽ!  Z|n:=7)u~9A>BǒRH )Ɖ#R#PAJXN7GPEO#U5)9cS= =Q*Eyw?% WEM<6*wtx}'(L&6/ B (Q׀vp~qMpsMMUwAB>7D% 0 ?|ʔ E fƯ5~s #(| H~Dl/EPQw08@2l."~@(CDp X{oqD6Ѻ(b>t;xЏvW)gtDLBP@A|@YF`t]6;"v!@J aW āC14 L1%\G@5EE- L7 cP&::( AO?D JrD d5YhS[Oc|f*,:@T¦6eX)oHe)E% @O4~pu*9@tTQ[,!PPAnYxP I d ˜%$Y@WQEޞL{0ZwԔ ?|(C?PP'AhC&a҇dA'0ؚ+AcB(@КjZԤs3*Tр*QP© |@*w-If@Om8 4 ^t¿ ® :L`P#P dnQ6^m@G vQ?<Wa|"|鼥 P *9%"9 A5uTRY}a@uA!t5sz,76ţH\V_.A6mL$ItW @> !Bz¿*:Ԝhanۼ%Z@$(2@hE&4dY<<`h\\* HBLQ'k©Pf>`HaG !G@m8$LYP@P@9 p%l . 6p 9 Tpյ[ť8`=2XB* {؞.lP%Y`ĭu `pBд4 R 0: !ST2TaU37l0! PEPB4Ä20Jڎe娢T#pkB%,aC'~lrdr0@Ȋ^Ih. ?h3g0a{\'(  :x@M#eǁLt@jadP`G`0A CcZIДfG PPUd@PDY@ hp-a#iIDќI\(D<4^eC 0@OFT0mpUKTu@110@PL%6>&YET.rsZ6"@g0Rظ 4<(Pp`tp   QzQI"NHx 0pjd:3uCd%AzKLM`g  x.\< '1~̮I5Ѩ `! 4 8OFwJ@t4Bt`;4`E?"ԁ:G <.0 !706 V. G(c⎆dB9`Ml=6\b@ OI%xh;/2,#7ހJ`Xr]`@KTԜ * |P 0%9'WC4H:P a' D5*&Ƽ ДC!1lYBTdT \yIPIK$O“XM !Z @ fAu$e(Vƿ<$taMČI'i"I:b>tOjWfG`KmlG&>N&ܡLy_DhF[Z&3%#}86  ^Q^쨺L5JVShΘN @te(HVvkm L+G$P UlFs|`MBTdChDDl5%@_GL@CS"?%(X2@fr d1 "„*# /%?Th/"SP?zH2mQdh*@l6@exbHYtxA&| /Hs:n| C8 V T<71?G@3PTIN1C7M4<6K˲(a9!CK``6P])#8V{0KFG8I|,R㌠ܻN³! *&u $pF/P@ @Җu#aPA `K[z$9bPk*Y`m˥H1 0&eE"ț_/1-. ^(l ; i< l oC4)͑Q}ى8FԽ ]43Y@сETc݇-8GaFLK#XgIE-]&bOi80wn蔏/JrCnK`@#X ;xbj6>1 E|IϼNn O>- |SͷD_T:@$tgw IL"PB(D&L{ r_6|wN|Ee]P~M`0=`COU.Qef" $h}駀 H}F@zz*f 맂jp8<~H@=p~<x~G`C EPEW?! ?,YapH,ȣKlɨtJ.Pn`$4Lb]P貭xS.WO~R9czξ#*d }L-[D?i8pɫ`@@v^/@Kdyʻ<#Q xX9'"ʏW-`A '"h6CE}Ք|Ձ$Ss]V@eK~+ vOjP,.yh,{ Mm#F0AfGȠMGn<ؑr C]TAlzA <)9NpV 鈝!E#J1 EacBP4aQ?Pb!ztCH 8GkgT-'"a3G rJi R3|h$ [92-#2,QD>2|q O27KHp=02%|1Zȥ[a B&f@C,UvmP2p|c#Su,L_# ЀJ2QxLg`iE=*(BlT3p2 (hJɊF"b <&) fb'h-i2E `"/nݔ"aQ#7IG\ݱ'89`5 ƅLPB2 p\Q.q""APlA԰dKQ*7CvM9_FV+1v {@$HP1X|gvqq#XS6_~K  <x(]'Ō\) $K<:v@"MpIH'('G lV$ E.%(1@^`m 2E Y1 q1rxGDyXPTg5B:μ /1!֮8Ҁ&A8At& zFH;@5 B "rod8e p7umń k;oz)~͘nv.j)?(x$-?T6, I'u.1Jth d.="_GiȩS!tlޖ;w bY` pxfgT\<@x&b; *d` B@@WT0#NǽLS56;HTvw? Ct!p PKF?=C˵lBzeF!5B@m:vhv:!W~ak[F00 W}5e8Nq< ^{B@U[G @0C~ݵ< 4eG vA 1h11<>G! ?,YbȤrl:ŧtJZج6iK0;:!fK}x<aQֈ_?j$N$X!1 5<c56ʀ-h+`'UҚYI Lj#2u@PO;Y,{t"6?IWH);xx0DP&$ưB{ )N0/fDwF@C$0HNJ|B{$4Q cDhF $©1Hiz Af 'D@v@c62P8H\I` U"Vy"D%&99DiT IH Z`-8h2 "H=!iЙe~0VT `AcGY#'0!,QD )Da7sH!? LbD&TiPR8C)*hU20FYn$iE`@f"U?b|g&;,Iq^`st}N?j`6;Fؤc{ LxT2H$,lVUu-NoD` JdS\B"l-{P sJ1ΌX]=A \JtB3$1L`{=|;@Bӯ;oA.LcA,j!_U0*a9 ak_Br~` ]bdv0KJ/֕w!Qwd`&`( xsUOv$hAo|yY`͗|N|h|§3})=P=(>`;(cqbi>h`ΊvtŅ! !.J @#+kk΃ "xTEQJAR#E'e ~| сB .nңe&Ehspm&-,{A Br}I1V@(R{ >@b lXOj!  DxAe'j'  pW=MmB@ pxR dc)=0 q R  DiqD0PaMJLx@ (!2` =/#MO'P%fPAFppA)(0}"8rL×SQLHQ lu,A ,t%܄n(R]BZ?, !@hl?@ R:_Omep2p Aiv汓۠j$1Q$k$KOJnQd-FO0dHR0dp 4p8)ULF#BJQHÃЙO < 4F|m9$+!fiYpxu_&fQ@GH7P)<61dSa v!$\ķHi N, b +Hp Iـ7VPFp 8WIN l Oj" T1aυAQzY.ۧmDNX `5 (Xj8"@槁ww@6ڀ/GF`-Azۓ.  Lj!Czß(*V1$,&@5@><`<`)^H`aQpBP2MHb3r$P5Ёa8d ^\L@n02( !{M(Ѐ)&7i`FPW&*LܲбfN#8 ; `U.B@bc³}AxRb@9atɘ"T0hhKN=$BXCB#- G!"M"c o\PF3Y2QxjQ@8EDU!G0R4I(!L92zI4Po 7c TA!^BmO F#@ 3BSB @ *[:XoF@HK?0P#!r:R0@Orh$|!E7 ` -MT tȤMdږJ QekZ2`8 H "<='d )D>1dB*<QZ!!ݳKVP!4wnK cF DوaԏCh}@݊#3۞HHZGG:0DtI )g2NC?<$@]KNէ 29 9,(# px%@Nph! R*`{̩T29^B0`3UЙ5v,@U8֤P'55_pH'P)9Hb#.sz$^`{ph!tK"Dbl u"dS` zU:.sYcMPqۺ 4~F@H0gܜF#\d/'~HW*|{1U(۳ +@B\9G[*ڟUeQQLtloD=`[Ib듑xNsr'-"r4"&@@ׅ4AK#D(:fa-;lGw>C]0,G??E}`}LWXF\ A U mDe%U"ǗO@%* LZ - `W'i?l]~Q8xQQT0'B% T@ɤN`Np. f? a !X nQ ]H]" PpH_ х_F! ?,Ya%,ãRYl:MPJIجV{*vc^z=7p!¦켞[uZ.u.Tm6{luX]]_IKCPBifVFVM699??< zaE=1l= 9:@q`M9{@I\3n RlC,udhc q_Nx ]IOEV$Z)D599BO^ G6qwxM`cNKbMmnHIQ daZ ?d%EsK*ayrp*'`D pi @hTZ&۪AB\FM \F Z ?fvJ ;cPW "dJ ,iAqB^Pj dJ3t&Q@~fr x`Z( :I:^ Йbаy<Mnzc LiUy L0TN#A@\iu2>l~v:@W;jX"^ce>@MmaAx-! ΔjN2#p 4j.uh9`}@iKº|GhIpB K'8AΔjqB DHT+ن4uKl'i ^- ܇E ~ō,mI/~3*=Dx"00䨫+ 9 AW"©t dJX\?8P#˗ xvF)-G9"P) (n l=XG9dIB5@;2H iD$YM&kLƯ"W٦SW|BSNЁ|$fPxO =.":p3<>r F %ak`^TCآ\Bkh^ )P Nc@qRR-  0ON`jѾP g";GJ&P^-su&0TvNV˕8Qn6ET 604'/^ >$>` T>Lx}55#Fnׂ0Jr-R =RrS~R,x ǘ1#^I#dW Hҵf^;Z2;˝. QJ$s Z` J@ׂ_91 W >=N!рJ(~zIN l u~ u/@x-ki?o XB I_4Jz` }QHz|j@`PzW -= < =@%53X4Pl0X1[AH!!Â&jv0J !"Fh B'6*TC"pqpw":l)cDjC84iXd(:H0`d6~Qm"Y4CM'Jf8 VX#`XXCV`A4)$B%Ehel`Zj "KZm;ȖM4dX?6p 5aĔ~h  Oa1W5@OHrE`Ma L?p@l><plZ`ldy zte"`%`@KnP@{Yxߌ`Ԍ!j@\6`ZkABAؖH*& -]?c ZcP@V0$GiQB L6n:FiD0FjP x 4#! $|`؅ FQdDzkIL4­ JP 8’n*c'DAXpa *Dfk0#&$ppB o~ HLt E(RY,4"lL~ Kz{؀8 @AkhZup tfF@ T8x-uP%N'(E pB @M)@E$8Q8T'IQ\ zlIvY% $'QՏqRp2`$|!"`lŌ?(U~?%H[F(U 8P78VD6(-\40'=pPf$*0%JX [ p .DFja 8 H `Q0U\ D|*t.@*:Ps@79Jƌ4ʁ͝7@|@"?0.`*ٞ B!I(`1pMf@PcB O[l@2uB<WpC T  $ӫ )(%[Jm2j `cDDprGr:hJt  je &4Z@!CQQ64IL [)  R0 52\@]]k0`ƀg:6Lju  F:OPx I5"ƴZEװSJv&4lhWc` 7 BP"ZpX@BuirNI7HnZ @F8lk^)bP 'OQiBKD ohb]#@3PPrAJ72D#Y04S訵`~!anFP#iN@i80fN*.PMuIFCj 41`ȅVV]LO'N`̶0YjR E,2D~x@BwzJG+1#@[=1}'b0<£ <>9@0{ ,&M I:;ܸ6j$LTfdaL "6 {0_7: /a,Q:ph"[p1(F%@tZ>]E YatnS3 Mz &WV/8 HtnU% Vt{4B)<71WА{'\h `˱zo1BWW7dƢaӐc~rC-y=& wy5u@<`uِ,pQ~DxV ҁpɱ_xt0Q0z |/N@Q'\%=#L QZ;:Wyd?2j $> @)Xz]$RgXAn{i\܏ j(!U8cMH\PD~_q0Auժ%ᄍs>% 3cyxg=٢ 9 bN4TiŒ`l0$UIuxЮhNrVFe1NQ2tL#n@$; KXuavw- y8wq[7FȄZ氏Si;Ay] J~T2{*8`WKM zOܭSip޵g7RPҡ䂁tL^f XFp(ʂV #$נRg3?4_4 `)06p`KUBr'^%XhnsJ&Pzh:YF-{ i`Ś 05ր& lt9 [ &3(`M.x>\X|R]I:Oh'2:IBrt`J[6) f9.cNѠM){¥SZ:A`' s1; EDv\(R-:@}V6rz8dǴnOAphf"t *pTC b Z4}`JPʨHvvH9 luI_|YΫ AxR'U @|OP*36Xo9<ۛ|" A,tH#إ: }aUSj'} Cp,/B Bq6}xWt8 9 *ϔ؀ ,-P 6xFHF`#.bVMwc@-b3NtlgY hЁ VDT0p4)@!BfgXa'?Rf0BD}Z `\ <` @fÊd޼GZ2S8uy? >@8A7 #H8HxUAxUbO3 At%HP>䳪7Atg76B έuM_a^EPIpPSx 5B  Np4@4`0g͂Da4s8]=J @uΩ<0g|ȖD`mAJ`Y{?,#TЀ`PQF~@ ,`@"#C( hJE$@A0z(` x1,A9gz4YY v W8A0q0r"A<!pP e )"n D !iW!`zyD @. GdM P*ŀ/eAlp ^9y,0@YXh;ŢtAn(AR ?Ș8HmpDBz 70K}m 8`@ \ @": O9A{]( Q?4*`g!8V @C d{Gpk( Ӛ4p*% 89>aCAo`fe0cP=P$j >\RL Bu*d%L (/x \ƴa@PUfˁN*F.| XEa!F8ȽFlRA #F)g j7B";%"a~·B@5瘶0Mֳ pfF>CVz%rD(Y=`BeAm'J "Lp mNDY%VX$05i] ͊N%RQ4 %9yyG;h@&!"-nIBz`N']i'B"P-R`'4 2X+*PP*j2\{78}l Hhi\7|pY Qd@'0x n ^e@@ !O@0: O=(pM;rg 3 o7"t@ :WCTQ=ۓ s +ӢBᒹ GKwdy# \R'C 3``@5Q>SYZ—ͭ~N+FAuP_ya$mGxVPy  9HB_f<8^D@T# ! ,ܚȷ `(`cE1 qh ZI$`oN Ȃ DS510AA;u`o\fo$d@Pg~jV@QP, ̡$BDm l2?@tNzB*0H T5>B?y6 JeJLTpfa"_2%4!kM3t rGpPSoZ ߾  , 0c%1o p/c<YXP ѧL/BeƠ,HNϐ@җ|x`ЉS\H%FiF\p-y4k'ql"RBb `1XϠ,ъ@װB2 A@~ EzadCD ' Pc(6)sE㎉4L!DP{ 1?HGD000 PTDC dh+aP@X@Q2 !h(]id62F!f)$Ȁ>h/?@5.N`A)0L rtlU:# Lx.X3@l8cP C1 !\'Z< 0Ja5\C g@PFL$*A2p~1y:Ƴt L:"i1@x(0>:x'xIbna mRd $-!!4ZtY/ۂ) 618:DKЄ8tب5[P| ;VZ "Nw(nT *2FnO<@hW@_aS-%.V t,@@ :TL# hP^rK(MݒBIr Q`Jid4Ki*4( =VV>nFʄ*K'Ym` Y #$>J͛/ 7`]t&9`"J м(QRT@a=+@)aJa@YmJ SRElF5ߤ .jhelK2I$s͓0I`Q,FyR1,j/oxˑ@dOcp 6ɱ+sd11Q@N#NFF4baZ ,&P0Ex(4:VǽנKv)NY^({j "m!KMsb SxQ?j8B>:`I-x!Ģ(Nn dD!h"rVƕn:ΜI hPoUr%蝘E`ŪgoXw*B> Jy=L L q9Q #@މ1CRnVADž:)ުGGH+OAsfR'O s>|ua)чcI(9&fK$TP2zdW G!A%"9^!bE&#TV"lPz.xA#Z-{B 9^8NOB8 3x7!$j.x|AgzQ| |Ǡ|ڀCP H!S`$$8A! ?,Ya/%,$l:Шt 1v҉.>'1N>\WdW`И@Da%ƫB&8PpVL$| a!0`F6I$ 1bD &wb:$Snk<逡PKH3 0`Æ F59 ?IQu*h KxL-r1 A~e6! Lhafee@:3<\CU"xe& "߂ kA3&63Qޒ`-B[)4h0 A&w#dPW!E6TA6% \'DTeDG,0BM3  y _Ё\ܷDX UXLULfL|`t80, EX^HC$F7?=I>6Q?`p@h!efN: Jm Q}[x9D~xL61 @G wP`ۉN$ B@X@zzQ!,pNnT I ihǚFN[:ǶCsE YdMtDrM`y&D 8ABBPKf XH'!8D'=psu?EާM#H6wR5  Y83ZQ.' Tk`EiA1M\WR\DdlQ@PN6 Qz Qu.xa8Xwd3hx-ح@12n݊Od&PԯKF r`]7*t $ "Z] E +H=Ll~>Qû@1PA އ8)]|a寅 @Z`zxt NЃqS ɱQπnTN! ? ~YPw@Ԁ=4>PFQx!PYP՗C(T87f foPv-(, uKe@S UXC+&ID: W󡀉ЁQ`2"`lIZI6S`~u>bs~f /BP5x xQ! ?,YbȤrl:E8ӧ6zaXyJO} m.1})!g.,.km?6rnuHlIX|gJ,iBBpIrZyBgMFot dA$0DTvD =XDD^Ѳ,LW b~,`@"eNxdE0 sEh1}أA dm D= 0ՇJÖ,ABLMЀ4@'80@p@v&ɡF%"p=a>DK)OJ`[tB~HC.S 0Yo&- @Jަc @iD? _Ζ1!"pH0N@e$&s3|04 '<0:F2N/600᷁n}pdzRQ};l2  zV$)P1Z" Da` Bw zOh`A AP־q~P}}02 {AmI$'[ A RzV Q>b p4K D DA*Sp # |0Hs4~HTq_w6.WBܰpF8#+SARM?8đhHeЀya?C##?Z=!%+RTՁ)Dt%+ &C5@Bpu !`)m#m`  AxjjиD+cm~(f=q;B4uw*P#@)6D!&p@BP HK D /msIra+A qBM Xj`)9\!8ʨU'H !BIıKF ৤64I}66A5@I:t^A$EDL7+@?b` tP J[h?|'[Rw`#Z R-@VZ;2 0 BrMl`$l a$rAR% T?TuVz,v0_`6,84w"LiUhi>@Je>Sbk [rAzB72~2 8HV%2a*Y:ր*mc#@xFE/L@.yn@DŮ^@ZI:!:(~Des!j#{U8 ]Z~$!&e3 )8Yj?o-VAJks'C6XH).K"MӞA#D `M*p34Y x,+& /zx"H7'9j#0,^╡ 3zޘ$qj_x8hc ºs zrHZ{P'TXpTil@ _ƒHBۊUr3!asp @;plDi*~a #`ǯ8 `0?#Z"I%ERCܬRXs3~^0p&< VwZ#8U3KԺx 6$& Т$ THy( yI81@|uc 28 )OH2b-e >M7ݷRV3 l;Fvd ց ] jV$ց(;WYX'31)FE(+2ϕ@!q:a@0sf^-hDX.!MN4y֛xӋ#BS~'ۅ v>@8 KFQ3 _:<|lKVHQJsVvo4#B>PB[ypx(Ae$t;}\Snk YqKSX&x')Ȁ,-yOP:0zR;5 7*7EP= 3'r4G!}T8!|,_ `f[Pz[%ƅ;";ExDb_2 }0t+Y Bp- ppEjLM`(xxx@ "a +xSLj>#aW:53G"LXH"$tE8p:Gv@ahƸYhhk(=Ҩk( ('P[QpCوШH! ?,YbȤrl:E$ꈪsv?vl Og55E~\Mv6dTF'Xd,`.otC_w?L{\?hR?)WWJ.b6.JiBYVmGqva).w~e?y6{9}[9<ƏGQK=DBIKB9MCSB$0ďSQ5 >d`B *,`.WM X@S (|A]iv!*hp"ą$Ĭ%!a@D!t̠]ֺ6t@z `\ݴp@@Ճ_ΥZ[FTO#'P A ?0a0)@ !-°;TtBY$tpTl.!cRТMB} 7 2p XA$Bs}3+&]΄$y$Ap* 8`A 0&O C4YM`[~@`jЏdʙ$T \TpR/>LB o ` Xx~zh}"$pq"HB&T |<)`a@D@x a-q n8b`Q. M( ^3!4l`pIp2bs1I`xѓ| U+E!P^(pM(+0 bnJG48 XQPm#a*hpQL$w][ ò+8%zTD#BK)?0p*!r B r{ @솂P>6O Zh?p -]Z \cAM.g L@ @;AـoNGS .(i wไttEQUl(v{dD'}s``)`?%rؓzT@&@–#3('a+KJMbKJlJLX)N-Mȍ0iA ɁVF(4^zj64)V[;'<~#(ECnFDzx13B <; P4 =`! - l5BB7h=E&AZ;H0nVOA/=F~G(`+v@׶9R$^Hx~&%t$ed !u&t!XhPHH0vgmS?KL)9(?08 73su AsC  qM@ ^^V )Ġd 4VMqSgh%B{s|4M} {]` M^~V>)鎰e-K  &MO qE3ZDg=.Z؄Ҿ 0IAbL~)`A#.Um\ <r<%pee.XvTwL9!L䂃T( 'B-?d'@ vpFK< cU9)K`Y5]J$-ъp ."^RRaNG* J:{ׇ0S&(Al<&@X@4!]!H@ o`J0Z51d% ~B: R7 #Q7Z^ 7 vv'mM y0ܐcL/j00g `h C̞ƣ:Ѡ4uEl$F 0 $(:iDqC<HPc+@r;` ~4Q(dlj0pfH@7!MYF- aVH ,Ā ͬ[ 0`A@Q@|Y4Nd@0e=ZA *W=QDKBja'@*  PEB) BV QE@B>=f *5XةԙO#`S1l| #h `MdUF#F%d@4 hY2OAECk % %D0YFR$Ai2D4QB"PnDf@BWSרK m JlL KB B8+O0@T]+AYܚU ~E6GBjљ5"9tNm4JU1U_EQXZqGћm щ}S M L. o=: ټx89A8 D@LO2sBɶ Ps XS *A*\+gA _p}z0TBxD>D{?D0< ܷ9L͗^!T0BA9lBTB M ÓoD#[0±[07#)0@|( B0:z M'xьNAoQA%#!AjFO"P=K_(p  +z`m&EQkS$;t0LNQhȠ$0D @~@!`, `хNH07p ½oB[ `B@ZJ4'QAb 1J G5:Vc?Ж6  & V=@u2XI$,dC\6<@6ȁ*ѩJ$F; A%ldլDL!wDpGS@(t9\ A.7R qB5\CMʑ  H  LDH@#`[ʢ҂h#_`ܸB`L\Sj!Qx3}f4^Lap}+%p [( @8C9X"9: n%BHW1 :G%BR, zB=BhLxD/$9 Ϭd6_PR}~?AdbgDf?!h>ᏛdކBL ,A+% jv" h40OA~q$&$j.)r1p o'k14+WfᴘvwSY;( r{*j vbA1摦iL彩9ĸsȣSIZi+oB &v `\NFeWK :ɛwA) A bD`s^V E! 0UZ0R@Z " F GD9i{ Z9"oxՀ^fhy/IǨ3VPJJ$oehz F*@}29C ii]1Y>Z pTQ{%~S&L2@܌7׬ | ųi^(-hW$ I 4) 'A|@2ԥ!`QNp$x)h -ew/B !|A?$ [.PPo vX#Vo-pB~(0Wc<+g{pBRgpwAY(5"(_(YtpD@(i39x`x`[Vs?Z17#5sTʭ0BpBn4sRϲ OlhoDmjuB[Ntyc|y` #6,@˂p*K~;ѫFw@ dǞ^ye*Bx R `A j*!lVXN( bI`֦+~X1t7r-/D'#!itI= 0h Bx(Xdt¸c(fISCK?AWE<ꄹQL! VcZ$tƎ@ͼP,Cl$D%#)_H5.&MNG|4RQ)IcLȋ~`+ 0ߞXѦ 4"0)P ,An@Y$`PQ3C ]V0hqMMh2tqMa$5@fJ>A% ͘IMR _~IRae(0 *0"MLM 8bXړKr tzj:< CIv`DŽRomGf'knl-a }J`#ؗyp{}0 +Y+pw$^/RA@ 8A1.]1XލS`Kij3?]RppQgE>^S@{o~jw8{ D m1 vÄ-<˘SB8q<c17ξ@ ":R)!H/.c#! ?,Y`9 BO9l S?(rVWϥچnW9zVҸ#19fgON\Z'LVbSXm~a} !]e@֎#1,ǟ8< 04TLCF0:N 8P ܐd%@" #P T Tlt܅t@aAq:  P*\+8OL7B>\O|$lk!ĵoP`TT2wXW!@ :wdE;3rDd*4)|STBLp` `v}N` Xmc^{I{i,E4P@T=^4H'4FCpa88^BC $k UgU?LAB9TAU $hK \pORB(RAnRpHj:Z.4X% EԺll$eS(:`-<Yav,FV P1ICxB\6 6$LG(G"Kw2 ;V$5@Iޥ'!L(T_Tj@m 2ƞ"nn@:btnrE WCXW2] j h8 ݚ>G!XsX;N |@~d575Ѐ141Q6V9gۊKDZwS<9Mn?D.B1|E676}?9EzwyzuBbN]FN\NB? :RB ёBr"'  ? $$, eK W A 61BQ␴*P`AD8,LY#"| AbC*M:A$>!EVViաZ$.4H? eOB\#Qƒ 2@oL\Яk zJGn:GBʼn Ppj[.k}+NfK.e%c@iH  am~,p-@ ̧l[$N?.@,<rV0C}OOV34qy`DP9 Ѐ3: 1Aw01 $ PZ A!y7XT<"}@`LMQ#B,,`%(88B~ 1L@N^iM8bM`'AA uc%bPASBQbu MdJIQT@ @\"`ArqP<TD d0 8P2:,(`GPXk< $jh4㢤֋Q0'P>hYB.yKE;# 0@'6NcLa *+91[h@B̄#**`A08f_'WW !MR"r|^ t=ӈdhHX` :Ոp@Ȣ4e8[7U:MDE7x*!uTM,Y>65K$O INJV8 (3 pJ:tDIHc:b L` xHI d-a ܞLpGoH| LTw$ WK BP]?.G *wRx B6emw^+o1=Y+ 2mk ,@}b& ' vOnm4nM7Pa( T~c\(,N-ueč&lY- +G B1O\*82c)k/ ;@Vܬ% ^DDy~ +kh:!j< ' B[\rh8z psT pRpo80Th[McPNБ =";ʽRp;]$S ,\iqW8l3_2@Kx U 7k ,(0)TQY#{ 7H\9 Nߋ?: U[  wpi[Av# lr#Uzd v.lU U u'l$@15 ҄ r0v/tiozE۷^8h?Vt qj Xb4#4Zi&d3=  eWݡ asJ豗(@L4x?A ps4 PoH $O_j@H!1H /S?~.zN1$, Hi2<$B~|ERpq4F0P~Qx7pVP)zpDM -B` ~7WЁIyu3>(@a_TF] p]eQ Q5vlV=aI!:UzbqfGA! ?,Ya$,ã*:P'K8Ѭvp d8`"I@6AB)E$4PH|H&k0B6|() J Ō: %P@G".t bY]YC@ v@ޞHF0D ~h@v pqnB"d?"B(Ͻ$H?f9Q (X7 U:`X5o7NQTlp :L:7z@)s=!AE 0BDU?U! ^7S00~[pvBtP_aNtd`Ňt@dT@Ecg6T@AxvL 0AaW춌cfm4@AY^JJ $bЀvP#T@%!\I^u|q.P)_~@ j;?8d8&`8wYy*Fr <Z4p@E`p7lQe ȳ"sy >QO8^Kx|eg.*@pdyW G opLv 4+' \$ Xe[8Pì[Av[aN ,NC@!PYcY|LRP/T204NAe2)t4[DRCB,ӉO(h8ApubP4[`0@`Ps?!&ؠbBqoPu_ 4 3}<7bZV0P"@NVPUHHAg%JPY*'8E >ՆEapO~0 ep Z=@hJp#Nь,#PT&H`A xO|a#@@ZAc;? G@h cY jB(@Dd+0`Rt"B@> lmmdd$#x4aS]#]"G3Y@ (0F즕Onb ʹ]#m],6A*@NJ0-<;*F&$G]j"y'KӬZ(jBj"{J ^Kˇri 8 S)xsUx M$)p&tҶ4gA EO7/8t%HH:`fS$ '7葸}$Se<@I HATU9۶r !\8 fjks +CYJ΍J->+>h)Phsm%|xWJ+"vR'Ё 2JP$c,1b5 uH_[#5ߑ :!J"\ GK]ۥ1&]B@b/j^аf) ظ\d󝴔IF߇ g}bx@gy1G p@{6B50vF G`~~ $Xh$ P ɰ b +:*B *)A$ zt _G6Q@@}[pM4_qME(!!ߠY(g c#`}0 JP*#%tUpM$P0%6g*7="TB+gQ a|E$yϰ=3$P

NPQ0AeT\xG4I"50:W  ÂӀɤ500$Skv3K [,\MIg@ȂF ``|O'>҈?ʉ.NgA A*&W +s}PY~J93YЀ{ %e}Q| 6 l}FpI G., opq{&}5TED5D43@Uy φ =/B9@4Al( JKRtVsSD dhgaYof gHshx(kA! ?,YbȤrl:ŧtzt ؟vSYK8ޮ-J'[3bNsa[vmhF.kyP9?}CCHc.`ZJ9QB:BxTR<9=? yC\JLF{2UA :`@vf`%^_̀ai@ P $HGT&\sLά :gIM0!P$v0!`$H4|UR5e@$9:ٰ "_ EyNJe@BBQ#Q YJ'd92߭n<`3D$|HA.PɒMZk;A0Jt=U>fU@TڙØP G<8"#݁h (wW!&*`@U|" [ipVA'![_8]U":| r `"Ħ !e N e#^`h^l`0>S=$E G*"0@)}20/!0@x AHP=t -_bpD@(0@>0p)X@bq4 A^2P&_`~#$-~a, i,`% ]`$[(0'ts0(ns6pK2 *P9 h7P6مKAE0T$|G$l,D2&0|4/ȫ: B( dJֿ 1,Xʇ~R0 3z?T,c=8 0~(N',";C(@ "\N$CRq(Cf" '(P.I9AT+]^Sc'7t`hzp1Fba@UX"&XL HƂXw1@if$ `"H%1vpRr gN!EV-, %R )pͨz+ b5@L~ZU~p&Pkm<01d0uCs׌)=)VBc  v2tف^Bz@/pr8L;#KG{^&@xY*N1e oR20%u  ;)X3E` cA҃G瘇KC9Eh@Hh$`/$#EKOh F \XԅplnۗSiЈ 4@>xv_!܁9|@DŽF RA`$`p?X]B4P"O *@f5s  ȁ};!~JHv8Z`% j`q!ƐGkd8/ F`nX`%P`4RXãUd,Q#YtOPs C E\~B^H[mGG[B@Ip` x@k!]5{A4tG9s X'h|* %o=kc)pX#TJu%HHJi@TNOAB`;B0 Fu, zk&`N\ f΀D`+z4hgs>#j0\BD'%eXł5b #$h*vA0"‰ I\h1AI"X v BQatyJ A`@&tz \ԀvDDq;UTd@ wtuЁ#!HqQqD0J q?hք@5 l =z0L |dH D@GtN8@tA#@0<Ѓd`! #ܢ% ;]@% w C Az@B%Hv T` lBOLYLsxb%U )(% < \)0ekʴ-q0gB%7؀Q1 ]:FaIN"57eƚ@uRO@JM P]+@N]Mw &NV4: @8u-nH93KB ŐN1 @@PǙ -F @|c⠑"BX JTlq)e.?0.) A @sZY5<2$E "t`egBPE`!44ɔJ K %IXIv%^00 V,(IL0Hg 1>2iU%(A2'yS_ @i[**'3lh|?< RP+SuBD@$aF8ڬQH5;%#%dzR!k 0T~`)F(q6+MتGR 6sE5]0Qp(U`R]²8 !6t5AiV@ I? TEx p[ =mP]d@@Za)IB_(a"PM)S_p0lh? VЩz"p6 !`PJ!!!E48 rF@?BM8$Ij_L, `4?Xj~x@CҀ rN쉄܆>eB(I Ъ`X$R?Xe0 Kv[{ ZeS\ xD$ؠ  ; ,ptɇ7Îz L*`A'e]ZpR`.D HNIz "#dGj$%C5Y !oj(2YBcAG||/a{U(AӐ}t !dM^z]4cVa:,{٬?欉50;EM:tߨ;RpM`[ 3 u6 jh.& q_`xȓqA$y+ipU0 +8< /9NAXNE?%.,!Eo4r^J }Un+MU/y=@{.kt1Iiw{!This animated GIF file was constructed using Ulead GIF Animator Trial Version, visit us at http://www.ulead.com to find out more.USSPCMT;asterisk/asterisk_arch.html100664 765 765 401 7513704334 14227 0ustar rsbrsb Asterisk - the Open Source Linux PBX defcon1100664 765 765 3071 7503674075 10171 0ustar rsbrsbPresentation Summary Rich Bodo Managing Director, Open Source Telecom Corporation The telephony industry was late to adopt open-source software and commodity protocols. The open-source development community is rapidly correcting that problem. Everyone from enthusiasts to Fortune 500 companies are now deploying open-source telephony software, from PBX's to voice messaging systems to VoIP gateways. This lecture will focus on the practical. We'll provide demos of the major open-source telephony systems, a brief tutorial on rapid application development, and a discussion of the effect these systems will have on the future the industry. Special attention will be paid to Bayonne and other GNU projects, and their relationship to the more ambitious GNUComm and GNU Enterprise meta-projects. Attendees should leave with an understanding of the general capabilities of the major existing open-source telephony projects and a working knowledge of basic application development with the GNU telephony subsytem. Rich is a regular contributor to the Bayonne project, and the coordinator of the GNUComm and Voxilla projects. He worked as a software engineer at several silicon valley telephony companies, and one Linux company, before founding Open Source Telecom Corporation (OST). OST has been deploying open-source telephony systems since 1999. He has most recently spoken at the O'reilly Open Source Convention and the Intel Communications Tech Summit. He organizes the bi-annual Free Telephony Summit as well as the Telephony BOFs and GNUComm booths at LinuxWorld conventions. gnomophone/ 40775 765 765 0 7513704166 10776 5ustar rsbrsbgnucomm/ 40775 765 765 0 7513706040 10263 5ustar rsbrsbgnucomm/OVERVIEW.TXT100664 765 765 136170 7513704517 12306 0ustar rsbrsbGNUComm Overview: ----------------- History 08/23/01 v0.6 - bug squishing, function spec example - rsb 07/25/01 v0.5 - more terminology - rsb 07/04/01 v0.4 - added design goals:ease of use, general rewrite - rsb 06/05/01 v0.3 - TOC, typos, minor changes. - rsb 06/04/01 v0.2 - added design goals:documentation - rsb 03/13/01 v0.1 - created - Rich Bodo - rsb@ostel.com Contents 1.0 Intro 2.0 Functional Goals 3.0 Deployment 4.0 Design Overview 4.1 Functions 4.1.1 A walk through application space 4.1.2 Function Spec Example 4.1.3 Function List 4.2 Components 4.2.1 Component Standards 4.2.2 Core Components 4.2.3 Application Components 4.2.4 Miscellaneous Components 4.3 Design Goals 4.3.1 Power 4.3.2 Reliability 4.3.3 Security 4.3.4 Ease of Use 4.3.5 Documentation 5.0 How you can help 1.0 Intro --------- Telephony equipment is currently reliant on proprietary hardware and software to power everything from PBX's, voicemail systems, softphones, and gateways to large call-centers and carrier infrastructures. GNUComm will offer a replacement for this proprietary software and integrate the functionality of these common applications into a more flexible and broadly functional free system running on commodity hardware. Along the way, GNUComm will provide a number of applications and software components useful to other free software projects. The next section describes the functional goals of GNUComm based on the problems we would like to solve. We don't want developers to feel the need to satisfy someone else's requirements. Rather, we would like GNUComm to be the type of system that people will want to use to satisfy their own requirements. The current developers eat their own dog food and use the early prototypes of GNUComm every day. We hope that GNUComm becomes as useful and fun to work on to others as it is to us. Throughout this document, we will sometimes refer to the GNUComm subsystem of the GNU project as "GNUComm", or sometimes just "the system". GNUComm is part of a larger project, called the GNU project, which you can learn more about at www.gnu.org. If after reading this document you are still wondering what GNUComm is or how it will be designed, see the web site and the mailing lists. Whenever we refer to "the GNUComm web site" or "the web site", we are referring to: http://www.gnu.org/software/gnucomm/gnucomm.html. You can join the mailing lists on the web site. 2.0 Functional Goals -------------------- A functional spec will be completed for each individual milestone. However, a minimal initial set of overall goals based on the anticipated needs of the user-base can be described right here. Many users would like to handle messaging (voice, fax, text) and that's about it. Next on the list for multi-user installations are PBX-type applications, and more advanced call distribution and switching capabilities. Larger organizations will require sales and support automation, business software integration, softphones and requisite gateway software. On our way to implementing these basic needs, a number of more esoteric and interesting areas will get some attention, such as remote automation and control of networked computer systems. Users of the GNU system will be able to fill these needs with GNUComm applications that will interoperate with each other and the rest of the GNU system. We can further describe those functional goals with the following parameters: GNUComm is to be a working subsystem of the GNU project providing interoperable components that enable human communications. GNUComm will rely on a number of new servers, clients, supporting component libraries, and an extensive library of applications. GNUComm will be fully integrated with GNU Enterprise. GNUComm applications will eventually be composed at a high enough level to allow users with little or no special knowledge of system internals or theory to design their own telecommunications systems. GNUComm will support a wide variety of telephony resources and communications mechanisms including VoIP and PSTN communications. It will provide mechanisms for communicating with useful proprietary systems whenever possible. As a free software project, whatever is deemed useful gets supported; we are not beholden to any company or standards organization in this regard. GNUComm aims to be scalable and configurable. Several GNUComm components are designed to increase the reliability of existing three-tiered application architectures. GNUComm's component architecture will allow the system to be broken down for embedding into very tight systems. In all cases the unique flexibility of free software will be leveraged (i.e. configuration available on many levels for many users, interoperability with other free software components). In no case should the average programmer with access to a low-end PC and not much else be left with no solution. 3.0 Deployment -------------- The deployment strategy taken will be similar to other GNU meta-projects (GNOME, GNUE, etc.). In this section we will put first things first, describe our strategy for solving the right amount of the problem, and cover standard development practices. At the time of this writing, we have defined the following milestones: M1 - SAG, Interoperability Deliverable is a GNUComm System Administrator's Guide (GSAG), and a User's Guide for each application we have checked in. This will provide a working base for users and developers to get started with. (Actually, I wouldn't exclude manuals for applications that are *not* yet checked in. I tend to write the manual first, then design the application.) Many of the functions performed by proprietary telecommunications systems can be carried out with free software already. Some of this software is already part of GNUComm. Documenting this software is our first task, making M1 largely a documentation project. If new software needs to be developed to meet the minimum Functional Goals of GNUComm, then specific documentation of that fact is a requirement of M1. Although M1 will not be a complete system, it will be a working system consisting of GNUComm Components that interoperate with some other applications. In M1, although work can begin on apps and system design documents, the focus will be on Interoperability. Design documents are not required deliverables of M1; the SAG and Users guides are. The average free software user should be able to follow the M1 documentation to create a working system. GNUComm documentation should have separate sections geared for programmers and end-users. There are several reasons to do this first: 1) The documentation will help people to create useful systems while long-term solutions are being developed. 2) In the long-term, GNUComm should interoperate with as many of these applications as possible. Experience with these applications will help us to do that. 3) Experience with these applications will help us to design our own components. 4) We may find applications that we can integrate with. We should define a few terms here: GNUComm Component - Any software entity natively hosted as an official part of GNUComm. GNUComm components can be built from code checked out from the GNU project cvs repository. For a Component to achieve release status (non-beta) within GNUComm, it must both meet the Component Standards and associate with (help implement) a Function. They support all applicable GNUComm protocols, reporting facilities, and other requisite standards for their given Function(s). GNUComm Component Standards - Coding, documentation and testing standards that are applied to all GNUComm components. What it takes to create a stable component. GNUComm Function - An interface specification contract fulfilled by GNUComm Components. Functions define how the entire GNUComm system cooperates. Outside Component - We will sometimes use this term for any software entity which is not a GNUComm Component. Maybe we should come up with a better name for these. Interoperate - When a GNUComm Component and an Outside Component interoperate, they share their underlying resources and data as necessary to carry out normal operations without interfering with one another. Integrate - When an outside application is fully integrated with the GNUComm subsystem, it is made to support all the features of a GNUComm Component. Some comments on Outside Components: Interoperability is a good thing. We are interested in free software only, so if an Outside Component does not meet the free software definition or depends on other software that does not, it will never be integrated with GNUComm. We can, of course, Interoperate via any communications protocol used by an Outside Component, whether free, proprietary, or other. For many useful functions, interoperability will have to do at first until a better solution can be found. Testing and Documentation of Outside Components may be necessary. This is not to say that we should create User's Guides for individual applications that will not be integrated with GNUComm in the long run; those should already exist and should be checked in as part of their own projects. We only need create enough documentation for these applications to give users a coherent manual for their use within our system. The more apps we can interoperate with, the better. An example of this? How about an integrated messaging system. No attempt need be made to reinvent the wheel. We will only need to write a document that describes how a large number of servers (web, mail, sms, ivr, etc., etc.) can be configured to cooperate to carry out the desired functionality. No new functionality needs to be developed. M2 - SDD, Integration Deliverable is the GNUComm System Design Document (GSDD), an overview of which is described here and in the System Overview diagram on the GNUComm web site. This overview is very general. The GSDD will quantitatively describe GNUComm Functions, Components, and Component Standards. We are designing a system that is practical, open, flexible, scalable, and interoperable. Interoperability sums up the challenge for this version; making the interfaces clean enough so that alternate versions of any given server can be hot-swapped into the system is important. Design documents detailing required and optional infrastructure components, interfaces, and protocols will be hashed out. A functional spec for M3 will be hammered out. Anything that needs to be built from scratch or re-written will be. M2 will lead to GNUComm 1.0., and will be held to the same standards of documentation that M1 was. Comments on Integration: Integration is a good thing. If there are multiple Integration options for a given function, we should, at this stage, value stability and interoperability, i.e. a 0.1 version or a version that has only a gui interface are not likely to recommend a project for integration, but support for commodity protocols will. We want to get a working system up as soon as possible. That's the extent of the milestones in the initial plan, but here are a few thoughts on where we go from there: From here, we set higher functional goals and iterate. Both a stable track and an unstable track will continually be pursued. When we refer to milestones, such as M1, we are describing deliverables. When we describe versions of the system, such as GNUComm 0.1 and GNUComm 0.2, we are describing modules, or versions of the entire system whose components are to be developed, tested, and used together. The odd modules (0.1, 0.3, 2.1) are the unstable track modules. The even modules (0.2, 1.0, 1.4) are the stable track modules. Components that achieve release-status will be packaged into GNUComm Releases. We may talk about reaching milestone x before releasing version y.z, which gives the project direction, but milestones are not tied to either dates or modules (too much pressure! ;-) ). With goals and deployment issues behind us, we know what we need and begin the design process. The rest of this document is a design overview, and refers to figures on the web site. 4.0 Design Overview ------------------- Even for those who have the background to know what generally works when designing telephony systems, a number of design challenges arise every time a new project is taken on. In our case these challenges are exacerbated by the both the large scope of the functional goals and the wide breadth of the platform support. This version of the GNUComm Design Overview will be an informal introduction to these challenges and our proposed solutions. How do we design in modularity? When both the application space and platform range are as large as ours, modularity is a dominant design challenge. The rest of this section will attempt to answer the modularity question while briefly describing the GNUComm Functions, Components and Component Standards. Having the ability to combine functionality into one process can be a practical necessity (this is often the case with application and media servers). However, having the ability to strip a server down into simpler stand-alone components can also be extremely useful. A simpler piece of code generally simplifies configuration, maintenance, debugging, security, performance optimization, re-use and integration. Add to this the requirement for GNUComm components to scale up and down to accommodate the broad range of machines and operating systems running GNU software, and we can justify several potential abstraction layers. A component model for GNUComm will be helpful for project management reasons alone. We definitely want to involve as many developers as possible in GNUComm at a high-level. In addition to this general predilection, GNUComm needs to interoperate with some object request architectures (i.e. GNUE:CORBA) *and* make it easy for average users (read:novices without specialized hardware) to combine components. (Yes, we will be working on this design for a while.) We will enumerate Components and Functions later, but let's solidify the relationship right now: GNUComm Component - Any software entity natively hosted as an official part of GNUComm. GNUComm components can be built from code checked out from the GNU project cvs repository. For a Component to achieve release status (non-beta) within GNUComm, it must both meet the Component Standards and associate with (help implement) a Function. They support all applicable GNUComm protocols, reporting facilities, and other requisite standards for their given Function(s). GNUComm Function - An interface specification contract fulfilled by GNUComm Components. Functions define how the entire GNUComm system cooperates. The set of all GNUComm Functions defines is the interface contract of the system. Note that components are considered beta until they fill a Function. Often this will mean that we need to write a new function and redesign GNUComm to accommodate a component. The design of the Function interface should be thorough enough to allow any vendor to rip out the GNUComm component filling that function and drop in their own. Multiple Components can fill one Function and one Component can fill multiple Functions. The set of all GNUComm Functions defines the interface contract of the system. The set of all Components that have reached release status forms the implementation of the system. We will perform a system test on released components prior to making a GNUComm stable release. So, we've probably beaten that to death. To give give you a feel for the design of the system we will contrast GNUComm telephony services with a system that you may already be familiar with. We know that telecom resources (protocol stacks, drivers, etc.) are typically state machines which should respond within some real-time constraints with signaling information and/or data payloads, and our applications need to be able to act in kind to use them. We can also assume that we have observed the working, scalable server designs used to power the internet and we see that there is much to reuse. Although HTTP is typically served in a soft real-time manner, the state machine for the protocol is not too different from a state machine used to control a telephony resource. So the interface description language is a little different, but with little modification the same three-tiered architecture can power a telephony application and a web application at the same time. The additional interface server is called Bayonne instead of Apache, the interface language is called BayonneXML instead of HTML, and we are using TGI instead of CGI, but application development is no harder to for a developer to learn. In fact, you could probably call Bayonne an Interface Server or a Voice Server instead of an Application Server. With server-side scripting the line gets a bit blurry. The development methodology is three tier, and parallels web development closely. The same comparison can be made with GNU Enterprise. In fact, the same back end logic could be used in all three systems. They all interface with humans. The same perl or python scripts used for CGI, TGI, or (EGI?). Apache, Bayonne, and GEAS are at the same level. When thinking a bit bigger, the same CORBA-based Object Web can be drawn upon to implement the business logic for all of these application servers. The objects drawn from the object web could be cgi scripts, tgi scripts, egi scripts, or perhaps Enterprise Java beans. The web comparison stops there. Gnucomm Components will interact with systems that we are already using. Not just our existing phone lines or phones but our web and business software, our network monitors, our PDA's, our office applications, and the rest of the GNU system. We will need to add a few components to our infrastructure to correct the typically lax web transaction environment and to interface to business logic systems like GNUe. These business and server components are described in the next section. The web environment comparison may also be misleading in terms of scope. One place GNUComm differs from a web application platform is in the variety and sheer number of communications resources we have to consider. Replace an HTTP protocol stack with drivers from a dozen hardware vendors and a dozen or so more protocol stacks for various VoIP and signaling functions. Then we have routing, directory services, applications, etc. To see where we might draw the lines in a modular system, let's consider for a moment how we might abstract the above mentioned telephony resources. It's easy to get out of hand with multiple layers of abstraction and protocol overhead when exposing these. A thin Resource API directly encapsulating several common driver interfaces may be the simplest and most widely useful abstraction we can create. The actual implementation would be a small library with a mid-sized API. In cases where processing power and execution size is at an absolute premium, the library could be gutted and only the necessary functions compiled into an application. The Resource Library is a useful concept and a GNUComm Function. If you wanted to encapsulate a high-level protocol such as H.323, you would have to encapsulate an H323 implementation API. Most hardware driver APIs do not employ the concepts of sessions, white-boards, or talking heads, so adding this to our Resource Library would be a radical complexity increase. Effectively, an H323 implementation API is a superset of the Resource Library API. Protocol stacks like H323 require several network resources that most driver libraries do not. If we are using H323, we can safely bet that the applications can reasonably access resources in real-time across the network. In these cases, a Resource Protocol might be a useful out of band interface to both the H323 implementation's API and the Resource Library API. By Resource Protocol I mean a protocol that is a feature-replacement for the API. So a Resource Protocol library that encapsulates both VoIP protocols such as H.323 and Driver Resource Libraries could be developed for use on such a system. This might simplify life for the developer who has access to the Resource Protocol Library, but it is no picnic to develop and maintain. We also now have a network and three of our own libraries in-between our app and the driver. We can keep going. Say we want to manage our resources. We can come up with a management daemon that registers apps as users of resources, handles some security issues, and implements it's own protocol for resource sessions. In most cases a resource manager is a very complex piece of software that is going to drive performance down unacceptably. I'm not entirely opposed to implementing a resource manager, but there is a point where programmers need to think for themselves. In the world of modularity trade-offs, the functions of overbearing modules either get omitted, in-lined more efficiently into other components, or otherwise integrated in a non-intrusive way. A similar issue is the CORBA controversy. Are we seriously considering forcing an ORB down the throat of a cell phone? No. We have added an optional CORBA gateway server, called EWOK, instead of a CORBA requirement. Anything that EWOK can speak to can hit an ORB. The general problem is that there are lots of places we are tempted to put intermediate or additional protocols. Although convenient in some cases, these break many other uses of the system. The general solution is to make the intermediate protocols optional. We are not obligated to decompose our gateways or add abstraction layers to our drivers, but we may allow for it for compatibility purposes. We have discussed the component definition and have seen that a GNUComm Component is free software known to work with the rest of the GNUComm system for it's intended function. Basically, it's any module we maintain. Implicitly, the Component fulfills a GNUComm Function, and the Function has applicable protocols, reporting facilities, and other requisite standards. The Component needs to meet the GNUComm Component Standards for coding, documentation, and testing before the component can reaching release, or 1.0, status. A control server, compression library, or application could be a GNUComm component. An application component might have a certain structure, such as a flat xml file. As a component, it might be stored in a database, passed from one server to another, modified, and interpreted in one or more environments. We are planning to use CORBA for this type of object brokering. Some nice features of CORBA such as polymorphic messaging and method invocation will come in handy later on. GNUComm application designers are currently (v0.0) utilizing lightweight, homegrown alternatives to a CORBA component infrastructure (read:hacks). Nothing is stopping people from continuing to do this, but if you are putting together a large system and want to avoid a lot of work, you will eventually adopt the CORBA-based GNUComm Component Infrastructure as it develops. However, we have also stated that we would not force an object request broker into a situation to which it is unsuited. To that end, we have introduced a Function called EWOK. An EWOK server is a specialized CORBA gateway. It translates lightweight communications into CORBA communications. This is handy for both tight application environments where an ORB is unreasonable or for any server that for whatever reason has not or cannot add CORBA support. 4.1 Functions: -------------- Since we have already covered the relationship between GNUComm Functions and Components, we will start this section by walking through the application space and uncovering each GNUComm core Function in turn. We will then provide an example of a Function definition and a list of the Functions we have in the design overview thus far. 4.1.1 A walk through application space... ----------------------------------------- What follows is a pseudo-tutorial introduction to the GNUComm Functions we are working on, with specific examples of existing and planned components: To make large-scale telephony applications work, we suspect we'll need quite a few daemons running on the server side. For some tasks we can get by with a powerful Application Server: Application Server - This server handles user interaction over the phone system. An early version of an application server, ACS, was contributed at the inception of the project. ACS has since evolved into Bayonne. Bayonne is the default app server today, but PreViking or any other server could plug in if it was compatible with the GNUCOMM interfaces. In order to do this we need to define all the interfaces to this server type. The Application Server is a very useful program stand-alone. The first few applications (which exist today) are fairly common examples of what an application server can do: Integrated Messaging - voice messaging system that integrates with other data messaging systems, such as web-based mail or maybe just an MTA through the Post Office Protocol. Support Automation - Automated voice response with ACD to allow callers to get to the information or people they need. Sales Automation - Integration of voice and web applications for automated order processing. Once we start talking about implementing entire call centers, we are looking at doing some switching between disparate media streams while sending callers to agents, app servers, or queue servers. Let's look at some of the necessary ingredients: Switch - The most common application of a telephony switch is called a Keyterm, or PBX. Among other things, a PBX "expands" a small number of "trunks" connected to the telephone network into a larger number of "station lines". An example of this might be a few linmodems providing PSTN access to a dozen or more softphone applications running on LAN-based workstations. Our first switch will be called "Ipswich". Ipswich can be used as a "dumb" programmable switch or a "smart" switch. In it's dumb mode Ipswich informs a controller of every change of state and takes no call control action without direct instruction. We will decide on a protocol for controlling the "dumb" Ipswich later. In various smarter modes Ipswich will act as a registrar for terminals, a proxy server, and even an MCU. In a manner similar to that of Bayonne, Ipswich will accomplish smart behavior through scripting. Applications such as a PBX will be largely developed in that way. The difference between the Bayonne scripting language and Ipswich's scripting language, is that Ipswich is dealing with protocols, programs, machines. Bayonne is dealing with people, particularly people with a keypad, mic, and speaker in front of them. So the scripting languages have some differences. Queue Server - The first queue server will be called Advanced Queue Server (AQS). As with the rest of the servers, there are advantages to having the option of embedding intelligence here. For instance, when an important task enters or drops from a queue, it can be treated differently based on it's importance. When a program pulls a task from a queue, it could be issued an appropriate task based on a comparison of the available tasks and the program's profile. An example of this kind of intelligent, non-queue-like behavior would be when a call of great importance comes in; it might and get shoved to the front of the queue, and an appropriate agent might get a request to drop what he is doing and take the call out of the queue. If we want to integrate with other large telecommunications systems, particularly legacy (read:proprietary) systems, we will likely need: Device Monitor - Communicating with existing proprietary systems is a fact of life for many. The Device Monitor, Babylon, will help us carry out this function. Babylon maps various call control protocols used by Proprietary switches into a protocol usable by the GNUComm system. As of this writing, Babylon speaks SMDI and a few control protocols of the more popular PBX's. The more interesting GNUComm side of Babylon has yet to be developed. Gatekeeper - In most cases the gatekeeper will be a scripted application of Ipswich. A separate gatekeeper could be developed, but we'll see what we can do with Ipswich first. Unlike Bayonne, which deals with user interaction, Ipswich's scripting language is optimized to deal with devices and call control. So we're talking to the systems we need to talk to, but who is in control? GNUComm generally imposes fairly minimal restrictions on it's components. Some systems specify that all control servers be controlled by a Media Gateway Controller, which is a separate entity from the control server or "Media Gateway". There is no generic Media Gateway Controller in GNUComm, although any server could implement a protocol to talk to a Media Gateway or Control Server (such as MGCP). Likewise, there is no Media Server requirement (or even a specific Transcoding Server), although such a media server could be integrated. There is no requirement that media resources (telephony cards, VoIP protocol stacks, etc.) be abstracted with yet another specific protocol. As explained earlier, there is more danger in adding some requirements than there is benefit. There is more than one way to do it with GNUComm. There is more to integration of telecom systems than dial-tone. Transaction-oriented information must be handled in a timely, secure, fault-tolerant manner. We should develop a formal method for accomplishing this: Transaction Server (TRiP) - The Transaction Redundancy Protocol Daemon (tripd) stores the state and transaction data of all transactions that are registered with it. The TRiP is a set of redundant servers that not only share the TRiP data bus, but handle any failures occurring on the servers that generate transaction data via TRiP scripting, including the TRiP itself. This is just too cool an idea to not work on. So tripd's scripting language reacts to failure events. For instance, it might respond to the untimely demise of bayonne_1 by launching various scripts on bayonne_2 based on the last known state of all bayonne_1's registered transactions. Real Time Database Server - RTDB is a MLSRTDBMS? We can't use a database that doesn't respond, and it would be nice to have an ACL manager. Examples: When a request to a database times out, RTDBS will respond with the time-out and inform the TRiP. If a foreign bayonne server wants an application component out of the database, maybe it should be disallowed. That's the kind of stuff we could use. Hopefully we can find some intrepid programmer to take charge of this. So Real Time Database server is a Multi-Level Secure Real Time Database Management System. It would be nice to find a new name for this and perhaps even nicer to avoid implementing this at all. Although I suppose the implementation could be a lot of fun. So we have a lot of functionality already, but if we stopped the design here, we would not be able to communicate with a large portion of the GNU project. Let's address these shortcomings: CORBA Interface Server - EWOK. Described earlier, this provides a gateway to CORBA services. That's the basic description of the core servers. Let's cover some of final the burning questions you might have: What do the supporting Libraries look like? All of the communications protocols and stacks can be made into libraries. In cases where a hardware interface is not required, it makes sense to have the option to encapsulate some libraries in a specialized server (like maybe a transcoding server). This gives us the ability to compile in with the core server for embedded or turnkey systems, or to create specialized servers communicating via commodity protocols. The obviously useful driver, codec, and client call control libraries are being pursued, as well as several specialized libraries and servers for interfacing to switches of various types, business logic servers, etc. In the interest of configurability and rapid application development, each server should be completely programmable, so we will likely split off libraries where distinct server-side scripting languages are created. With all this common code, why not a monolithic control server? After all, what's the difference between the control servers: Ipswich, Bayonne, and Troll? They will likely all use the same trunk class libraries for interfacing to drivers and protocol stacks. They are all scriptable and capable of some call control. It is possible to devise one server to do the work of all three. However, they are functionally and structurally quite separate. Bayonne speaks to people, Ipswich speaks to programs. The scripting language is totally different for Ipswich and Bayonne. In fact, the Troll Function is a script! The Troll Function is handled by a component that is just a scripted application of Ipswich. Therefore, the control servers should use each other as a set of cooperating processes. Bayonne and Troll will ask Ipswich to perform call control. Ipswich and Troll will ask Bayonne to present interfaces. Bayonne and Ipswich will ask Troll to gateway traffic across nets. To a large extent, the separation of control servers is driven by the desire to support large, highly optimized, distributed systems. 4.1.2 Function Example ---------------------- Functions will be defined in the SDD (M2). Here's a sample to show the format: GNUComm Function Entry ---------------------- Function: Application Server Version: 0.1 Description: The GNUComm Application Server interfaces phone users to software applications in real-time. Interfaces Supported: SIP: IETF RFC 2543 SNMPv3: IETF RFC 2572 ccscript: GNUComm Spec 1 BayonneXML: GNUComm Spec 2 Telephony Gateway Interface v2.0: GNUComm Spec 3 GNUComm Resource Library API: GNUComm Spec 4 TOSI v0.1: GNUComm Spec 5 Interfaces Required: ccscript Required Documentation: SAG: http://www.gnu.org/software/gnucomm/SAG/AppServer.html Test Spec: http://www.gnu.org/software/gnucomm/test/testas.html Optional Documentation: User's Guide: N/A Application Server Implementers Guide: N/A GNU Software Map Entry: GNUComm Application Server 4.1.3 Function List ------------------- With that much out of the way, we can check out the overview diagram (Fig 1.) and compare it with the Function List below. Keep in mind that although we list functions and components here, the System Design Document (in M2) is the place to find the canonical Function Definitions and Component Standards. GNUComm Functions: Core Functions Control Servers App Server Switch Device Monitor Business Servers Real Time Database Management Server Queue Server Matrix Servers Transaction Matrix Server CORBA Gateway Server Base Libraries Client Call Control Resource Driver Library Audio Tools Library Switch Control Protocol Library VoIP Protocol Abstraction Library Server-Side Telephony Scripting Language Library ASR Abstraction Library Application Functions Applications Voice Messaging Support Automation Sales Automation Integrated Messaging Customer Relationship Management Device Control Gatekeeper PBX Application Libraries Core TGI GNUe Integration Misc Configurator Development Tools 4.2 Gnucomm Components ---------------------- In this section we will introduce Component Standards and provide brief coverage of the components that either exist or we envision will aid in the implementation of the design. We're actually designing the system before we finish coding it ;). Again, Keep in mind that although we list functions and components here, the System Design Document (in M2) is the place to find the canonical Function Definitions and Component Standards. The following component lists correspond roughly to the Function list. 4.2.1 Component Standards ------------------------- Primarily in order to avoid "undocumented features", GNUComm will add a few standards to the very reasonable GNU coding standards. That means documented code, an administrator's guide, and a test spec before a Component can get out of beta. Not that we're control freaks or anything, but when you dial 911, it's got to work. 4.2.2 Gnucomm Core Components ----------------------------- *-> Control Servers: Bayonne - application server Ipswich - switch Babylon - device monitor *-> Business Servers: AQS - Advanced Queue Server RTDB - Real Time Database Server *-> Matrix Servers: TRiP - Transaction Redundancy Protocol Server EWOK - CORBA interface server *-> Base Libraries: +Driver Library - mostly interfaces, we may need to write some drivers. +Audio Tools Library - ccaudio +Client Call Control Protocol Library - TOSI +Switch Control Protocol Library - a babylon plugin +VoIP Protocol Abstraction Library - this really springs from a desire to port a SIP stack API interface to H.323. There are gateways that can make this coding unnecessary, but we'll see where it goes. +Server-Side Telephony Scripting Language Library - ccscript +ASR Abstraction Library - as with the VoIP Protocol Library above, we probably won't need to implement these engines because we expect that excellent free software for this purpose will exist by the time we get here. This is basically a wrapper for use primarily with the application server. We can only use a minimal set of ASR with this method, so this portion of the design is destined to be completely revamped. 4.2.3 Application Components ---------------------------- *-> Application Libraries: Core TGI GNUe Integration *-> Applications: Troll - Scripted gatekeeper on top of Ipswich. Integrated Messaging - Just a document. Voicemail - Multi-user voicemail, Bayonne application. PBX - Ipswich Application Support Automation - Sales Automation - CRM - Device Control *-> Configurator Menu-Driven application for enumeration, interrogation, and configuration of GNUCOMM components on a network. Text or GUI driven. *-> Development Tools: Web-based visual scripting environment - All servers will be will be scriptable in one or more languages. Bayonne is scriptable in ccscript. TRiP will be scriptable to handle system failures. AQS will be scriptable to act on important changes in the status of queue objects. You get the idea. The ideal environment would allow at least the boilerplate and simple scripting to be done in a drag and drop manner. A full debugging environment would be ideal. A set of test harnesses will be a requirement, although we should probably split that out into another topic. 4.2.4 Miscellaneous Components ------------------------------ These are somewhat speculative at this time. *-> Other Specialized servers and libraries: Transcoder - could encapsulate the Codec Library S.100 - Telephony resource daemon ... *-> Client Applications: A GNU softphone: * M1 - first get a simple SIP phone communicating with at least one server (most likely bayonne). Write the simplest command-line app possible, putting as much into libraries as possible. * M2 - Abstract SIP layer so that H.323 can plug in. TOSI-enable this application. * M3 - Orion - The Phone Parts Project - a gui phone with plugable skins and codecs ala xmms. 4.3 Design Goals ---------------- By way of design exercise, we will now discuss some issues that will influence the SDD. 4.5.1 Power: ------------ An application that does a lot of work with little effort and is very flexible can be said to be powerful. Placing server logic in a high-level scripting language is a means to develop a powerful server. Script passing between servers is a fairly powerful way to move intelligence around. The gateway to CORBA services enables another level of this. The concept of GNUComm Functions greatly increases the flexibility of the system as well. The ability to drop in an alternative server is key. Consider the standard, well-understood HTTP/CGI interface of web servers. 4.5.2 Reliability: ------------------ One means to achieving 5 minutes per year downtime is to have both hot failover and hot replace. This means that any component of your system, if it fails, should not dump calls. Instead, a backup system kicks in, takes over calls real-time, and notifies you that the primary system must be swapped out. In practice, this is rarely implemented. However, various forms of redundancy are implemented. There is Application redundancy, which requires two or more systems to execute in lockstep (possibly at the kernel level) so that, at best, application failures are recoverable. Application redundancy doesn't do anything for you when your kernel locks up. There is routing redundancy, which the phone company typically provides, such that if you have a hunt group spread across several systems and one system goes down, the calls active to that system are dropped and subsequent calls route to the next available port on another system. Routing redundancy is arguably the most important type, since it allows you to perform a graceful shutdown and system replacement by accepting no new calls on a given node. As a first step applications need to be designed with an awareness of this type of feature. Then there are the pair of redundancies that we are attempting to implement to give us the ability to provide hot swap and hot replace on any scale: Data Redundancy and Stream Redundancy. The foundation for these two we already have in the form of a data redundancy bus. The idea is this: First we implement a Transaction Redundancy Protocol Daemon (the TRiP), which is informed of important state changes and out-of-band data transmissions on every call. If a system goes down, the TRiP notices and requests that another system take appropriate action based on the last data it had for each active call. So if a credit card transaction needs to be rolled back or something else needs to be done, like hang up a phone or call someone back, or tell someone how much usage a caller made on his calling card, or something, then it gets done. Stream Redundancy requires that a network of cooperating systems place multicast data on a Media bus, typically a separate, high-bandwidth network between the cooperating nodes. Stream redundancy can potentially be very expensive, but it allows a system to go down at any time without the caller being dropped, and sometimes without the call being interrupted at all. There are certain situations that you just can't easily help, such as: Your T1 card or the cable running into it gets destroyed. Your service provider goes down. Nuclear Holocaust. Locusts! Etc. However, if you have very good connectivity, your reliability should be very good with such a redundant system. So that's the general idea. Hand in hand with redundancy goes the question of how nodes monitor one another. The function of the Matrix Servers require some voting logic to be carried out prior to a proclamation of process death. Voting logic does not need to be so simplistic as to 4.3.3 Security: --------------- The author refuses to pretend to be a security expert. We can't force anyone to run a program in a secure manner, but we can: 1) Try to design secure programs. 2) Have a mechanism in place for timely response to bugs, particularly security holes. A lot of projects rely on having a group of security minded people audit programs and respond to reports. To these people, discovering and fixing a race-condition attack is really neat. We definitely need some of these people. With 1) in mind, GNUComm programs should: 1) Minimize privileges. The designers should document any assumptions they make about the privileges of their software (and attempt to be more specific than "We assume here that the kernel is: linux-2.2.x"). The administrator should know what ID each app is running under. This information should be available to certain users as well. In reality, the good admin will just change all the privileges to suit his/her purposes. The bad admin will just leave things insecure. 2) Minimize trust. Designers should trust as few resources as possible and document what resources their programs will interact with. The administrator should know this information. A security audit of a GNUComm program should reveal any undocumented resource usage or misplaced trust. and, 3) Minimize bad data. Sometimes even trustworthy resources spew bad data. Assume all data is bad unless you actually figure out that it's good. At least do bounds checking. If you refuse to write code to verify data and do bounds checking, you had better document your reasons. To meet GNUComm Component Standards, documentation of these issues should be made available, possibly through a recurring security audit mechanism. Note to self: build a security audit team! 4.3.4. Ease of Use: ------------------- This has not received nearly enough mention. Individual applications require only user guides, but nothing guarantees ease of use of an application. There is a world of difference between an application with a consistent, simple user interface and the typical IVR or Dialog-based application. If we do one thing, we should rid the world of poorly designed speech applications. There has been ample research done to develop a GNUComm application user interface guide to help this happen. As far as the developers are concerned, tools are their forte. One usually doesn't have to try to hard to find developers willing to write development tools. The back-end logic is relatively benign, but there is a learning curve to the specialized scripting that makes GNUComm applications run. Tools to make these languages simpler to code are always helpful for beginners. 4.3.5 Documentation: -------------------- By this point, the focus on documentation should be apparent. Every section in this document embeds a documentation requirement of some kind. System Administrator's Guides are requirements for Components, as well as code documentation and test specs. There are a large number of optional docs that we would, of course, like to see written. We'll watch closely to see if the absence of something like the Application User Interface Guide becomes problematic. 5.0 How you can help: --------------------- Examples of things we need: Writers to help with documentation, and translations of documentation. A complete international prompt library. Lend us your voice. A library of voice applications to work with our components; we can never get enough of these. Itching to control your home, set up a meeting, or get a wake up call? GNUComm will take your breakfast order and scramble your eggs if you have the coding itch. Take a look at the web site to see who is working on what. There are probably several Functions unfilled by components and several components with no owner or too few owners. Examples of things you can do: Write one of the things we need. Document one of the things we have. Test or add features. Use GNUComm commercially. Join in the developers discussion. Copyright 2001 - The Free Software Foundation gnucomm/PSCT_spec100664 765 765 137671 7513704517 12154 0ustar rsbrsbProtocol for Simple Computer Telephony (PSCT) Contents -------- PART I 1.0 Overview 1.1 Design Goals 1.2 Intro to the PSCT Model 1.3 Definitions 1.4 PSCT Resources and Message Format 1.5 Transaction Identifiers 1.6 Types of Messages PART II 2.0 Session Related Transactions (Actions) and Events 2.1 Address Related Actions and Events 2.2 List of Standard Parameters 2.3 Terminal Related Actions and Events 2.4 Standard List of Terminal Related Parameters 2.5 Call Related Actions and Events 2.6 Line Related Actions and Events 2.8 Standard List of Line-Related Parameters 1.0 Overview ------------ PSCT is an HTML/ASCII based, SSL optional, Platform Neutral protocol for third party call control. This will allow any application to communicate with telephony servers to accomplish tasks such as: * Make a phone call. * Set or Get information about your Terminal. History 01-03-2001 v0.0.2 reformat and typo edits, etc.. -rsb 08-24-2000 v0.0.1 overhaul of old SCTP spec. -rsb@ostel.com NOTE: Version 0.0.1 of the PSCT spec was a rewrite of the SCTP spec which was written by: Principal Authors Paul Davidson, Nortel (pauldav@nortel.ca) Brian McConnell, Pacific Telephony Design (brianm@phonezone.com) Advisors En-Kuang Lung, Altigen Communications (lunge@altigen.com) Steve Gelbach, Nexpath Corp (steve@nexpath.com) Jack Pines, Voysys (pjp@voysys.com) The SCTP that we are referring to is not to be confused with the IETF draft of SCTP, which is an unrelated protocol. There have been a number of SCTP's over the years, all telephony related, all unique. In a fit of creativity, we have rotated to avoid this namespace, yielding PSCT. As noted in the history above, the first draft of PSCT, 0.0.1, is a rewrite of the SCTP protocol specification written by the above authors and advisors in 1997, so most of the credit for it should go to them. 1.1 Design Goals ---------------- * To provide a simple and flexible interface which requires no third-party development tools or middleware. A competent programmer should be able to build a working prototype of a client or server application within a few days. * To provide first and third party call control services typically offered by digital telephone handsets, and by client telephony APIs such as TAPI and TSAPI, and to facilitate multipoint conversations (i.e. conference calls). * To enable clients to handle multiple calls simultaneously. * To enable clients to connect to multiple servers simultaneously. * To perform common voice mail management tasks (i.e. check for messages, indicate waiting messages to a client). Media control will be addressed in a addendum to this protocol or a separate protocol designed to address mixed media messaging. * Capable of interacting with POTS, ISDN and proprietary digital phone line services, and of treating virtual telephone circuits as real circuits. * To enable users to modify their station settings (i.e. Do Not Disturb, Call Waiting, Call Forwarding, etc). * To enable agents to log into and out of ACD groups. * To be scalable from small key/intercom systems to large central offices and telephone networks. 1.2 Introduction To PSCT Model ------------------------------ PSCT abstracts physical resources in such a way that a client can talk to many different types of servers, from a small office intercom system to a metropolitan telephone network. Care has been taken to avoid making device or platform dependent assumptions, and to avoid forcing developers to implement applications in a specific way beyond defining a consistent addressing and messaging scheme. PSCT deals with five different types of objects. Transaction and event messages are used in reference to each of these objects. The key concepts referred to by these messages are: * Terminals - telephone handsets or client devices * Addresses - individual users (a single user may use several devices, * or many users may share a single device) * Calls - individual telephone conversations or multi-party conferences * Sessions - PSCT client/server socket connections. Each client * establishes one session to each server it wishes to interact with or * control. A client can set up multiple sessions (i.e. to multiple * telephony servers) if desired. * Lines - voice paths (circuit switched or packet switched) leading * from the server to another server or outside telephone network. * Groups - (for future use) this will refer to collections of * addresses, such as are found in ACD (automated call distribution) * applications. Not currently implemented in this revision of the * protocol. 1.3 Definitions --------------- Terminals The term terminal is used to refer to any telephone instrument, communication device (i.e. telephone card, modem, etc) or other appliance which is connected to the server. The terminal is a peripheral through which a user can conduct a conversation. It is not permanent associated with a particular user (although developers are perfectly free to permanently bind addresses and terminal Ids in a fixed addressing system, as is typical with most PBX systems). Addresses The term address is used to refer to an individual user. A corresponding analogy in the electronic messaging world would be an email address. Many users could share the same email address, or many email addresses could be mapped to a single workstation. In a typical telephone system, an address will correspond to an extension number or, in the case of public telephone network applications, a telephone number. Calls The term call is used to refer to an individual voice path or multi-party conversation (which is treated as a call which encapsulates several other call paths, more on this later). A single terminal can receive many calls simultaneously. A single address can receive many calls simultaneously. Sessions A session is used to refer to a data path between an PSCT client and an PSCT server. A single client can maintain open sessions to multiple servers, just as a server can talk to many clients simultaneously. Lines Lines refer to physical or virtual circuits leading from the server to another server, or to an external telephone network. We added this so as to provide key system features to PBX and PSTN users (the ability to observe and manipulate external line appearances, as well as to monitor external network activity). 1.4 PSCT Resources and Message Format ------------------------------------- This section describes the general form (semantics) of PSCT. Session A session is a link between a PSCT client application and a PSCT server over a serial communications transport. The purpose of the connection is to transfer recognized PSCT messages. * Messages are transferred via standard sockets using port 9006 when using BSD Sockets transport. * Client initiates a connection. * Connection remains open until closed by Client, Server or fault. Clients are encouraged to first attempt to make an SSL connection, and fallback to an insecure connection if this fails. Clients are also encouraged to close the connection when not in use for prolonged periods of time. Messages Form 1 PSCT messages are formatted using the same string formatting rules as those employed in HTTP. These formatting rules make messages easy to parse, and to transport through TCP interfaces from many vendors. This format also permits the addition of additional parameters to messages without creating backward compatibility problems for existing applications. All messages are composed of ASCII (lower 126) characters. All messages are terminated with a delimiter There is no pre-defined limit to message length Messages take the following form: parm1=value1&parm2=value2&... ex. action=transfer&cid=1234&destination=301 Note: standard HTTP escape sequences are used to denote characters such as &, esc, , etc within the body of a PSCT message. Form 2 PSCT messages are composed of a group of strings each terminated with a carriage return, line feed sequence. Three types of lines are defines: Protocol: PSCT xx.xx The protocol line appears once per message. It is used to identify the protocol and the version. The xx.xx denotes the major and minor version number Content: param:value Content lines contain a single parameter and value pair. An example of the differences is given below. Note that the are omitted in this example. Form 1: action=hello&address=4155551212&password=xyz&version=1.1&tid=123 Form 2: PSCT 01.10 action: hello address: 4155551212 password: xyz tid: 123 Terminator: The terminator is an empty line. It signifies the end of a message. Form 2 syntax differs only from Form 1 in that Form 2 uses the traditions 'header' format used by many other TCP application protocols. 1.5 Transaction Identifiers --------------------------- When issuing a transaction of any type, the sender will include a serialized transaction id number (tid) in the message. This number need only be unique for the sender, and not system-wide. The transmitted tid is included in subsequent responses from the recipient to facilitate sorting multiple replies, or replies received out of order. The protocol does not care how you select transaction ids, and if you don't include one, the server should still accept the request. However, if you plan on having your client doing more than one thing at a time, it is strongly recommended that you include serialized tids with your transaction messages. 1.6 Types Of Messages --------------------- There are three basic types of messages used in PSCT: session related messages (i.e. login/logout), transaction messages and responses, and asynchronous events. All messages observe the same formatting scheme, and so this distinction only applies to the context of the messages themselves. Session Messages Session messages include login/logout procedures, protocol version identification messages, heartbeat (stay-alive) messages, and other messages related to the maintenence of a connection from a client to a server. Ex. action=hello&address=4155551212&password=xyz&version=1.1&tid=123 action=hello&tid=123&result=ok&session=1121&text="Login Accepted" Transaction Messages (Actions) Transaction related messages may be sent by either the client or server, and are typically interpreted as a command or action. The recipient of one of these messages will typically be expected by the client to respond with a success, status or error message. Call control commands would be issued as transaction messages, as illustrated in the example below. Ex. action=hold&status=on&cid=15622&tid=124 action=hold&tid=124&result=ok&text="Call 15622 On Hold" Note in the example above, the client is requesting that the server place call #15622 on hold. The call ID is an arbitrary number assigned by the server to uniquely identify a particular call in the system. A transaction ID (tid) is used so that the client can identify replies to a particular transaction if responses to two or more requests are returned out of order. Upon receiving the initial request (first line), the server responds with the command issued and transaction ID, along with an indication of success or failure. Asynchronous Events Asynchronous events are used to notify either the client or server of a change of state (i.e. telephone handset going offhook, call ringing to an extension, etc). Either the client or server may issue an asynchronous event. Clients are expected to register with the server to receive various classes of events (more on this later). This provides server vendors with an opportunity to implement security policies (i.e. deny attempts to monitor someone else's telephone line), and is also intended to prevent transmission of redundant or unnecessary data across the network. Ex. event=call&cid=15622&action=drop In this example, the server is informing the client that Call ID 15622 has ended. Ex. event=terminal&address=301&state=ringing In this example, the server is informing a client that extension 301 is ringing Clients can also use asynchronous events to communicate information to the server which could then decide to relay this information to other clients. Ex. event=terminal&address=201&state=away In the example above, the client is telling the server that the owner of extension 201 has walked away from his desk. No response is expected from the server. Events Versus Actions The important difference between events and transactions is that no response is expected to an event message, whereas one or more responses will be expected to a transaction message. ------- PART II ------- 2.0 Session Related Transactions (Actions) and Events ----------------------------------------------------- Message: Hello ----- Description: Establishes an PSCT session with a server. A session should be established for each address associated with a particular terminal ----- Message Type: Action Parameters: address (req) password (req) tid (req) terminal (req) Expected Response: Server will return a message referencing the transaction ID (tid) given by the client, included will be a parameter named result which will have a value of "ok" or "error" In the case of an error condition, a standard error code and description. If accepted, the server will return a session ID which will be associated with this session. Message: Bye --- Description: Manually closes an PSCT session. Can be invoked by either a client or server. The server or client can also close the connection if more than N heartbeat messages go unacknowledged within a specified period of time. --- Message Type: Action Parameters: session_id (req) address (req) tid (req) Expected Response: Server responds with an acknowledgement (see example below). If there is no response, the requesting party can probably assume the connection has been lost. Message: Heartbeat --------- Description: Sends a heartbeat message to the client or server, which responds with a short acknowledgement. --------- Message Type: Action Parameters: none required Expected Response: Receiving end responds with a short acknowledgement message, see example below. Message: Time ---- Description: Telecommunications servers often receive highly accurate timebase information from external sources. This event allows this data to be relayed to client workstations for time synchronization purposes. Note - due to latency in data transmission, this service should be used for approximate (~1 sec) synchronization. ---- Message Type: Event Parameters: date - YYYYMMDD time - HHMMSS * * - Zulu time (Greenwich standard time) Expected Response: None Examples Hello (Action) The example below illustrates a successful login procedure. --> denotes a message sent from the client to a server, where <-- denotes a message sent from the server to the client. --> action=hello&address=201&terminal=41564799911.201&password=123&tid=1722 <-- action=hello&tid=1722&result=ok&session_id=128 The example below illustrates an unsuccessful login procedure. For a list of standard error codes, consult the table at the end of this document. --> action=hello&address=201&terminal=4156479911.201&password=123&tid=1722 <-- action=hello&tid=1722&result=error&error_code=504&error_text="Invalid PW" Bye (Action) The example below illustrates how the bye transaction is used to close an PSCT session. (Of course, instead of saying goodbye, you could use the less polite "New York" procedure of simply closing the connection ) --> action=bye&session_id=128&address=201&password=123&tid=1988 <-- action=bye&result=ok&tid=1988 Heartbeat (Action) The example below illustrates how the heartbeat transaction is used to poll the client or server on the far side of the socket connection. Client and server timeout thresholds should be adjustable by the user. --> action=heartbeat&session_id=128&tid=1788 <-- action=heartbeat&tid=1788&result=ok Time (Event) The following example illustrates how the time event is used to deliver time base information to the client or server (although this data will typically be relayed from the server to the client) --> evt_mask=session&event=time&date=970903&time=181615 These four basic procedures encapsulate all that is required to establish, maintain and destroy a connection to a PSCT server. 2.1 Address Related Actions and Events -------------------------------------- As discussed in the introduction, addresses are analgous to user accounts. Telephone systems differ significantly in how they map users onto telephone handsets. Some used a fixed addressing scheme where the user identity is synonymous with the handset address. Other systems, particularly newer PC based systems, allow dynamic user/handset mapping (the latter scheme being quite useful in situations where people move around a lot, a phenomenon which is becoming increasingly common in the workplace). Most actions and events related to individual user's call management settings, real-time status information, etc, are handled in this class of messages. Message: SetStatus --------- Description: This action is used to set a user specific parameter such as call forwarding, do not disturb, call waiting, etc. The list of supported parameters will vary by system. A list of standard parameters is provided below. --------- Message Type: Action Parameters: address (req) parameter (req) value (req) tid (req) Expected Response: Server replies with either a success or error condition. If an error occurs, it will reply with a standard error code and optional description of the error. Message: GetStatus --------- Description: This action is used to poll the server for the status of a particular address. This action can be invoked in one of two ways. It can be used to request a specific parameter, or it can request that the server provide all available parameters for a given address. --------- Message Type: Action Parameters: address (req) parameter (optional) tid (req) Expected Response: If a parameter is specified, the server replies with the current value of that parameter. If not specified, the server replies with a list of parameters and their current values. (See example below) Message: TestParm -------- Description: This action is used to query the server to see if it recognizes a particular parameter for a particular user. -------- Message Type: Action Parameters: address (req) parameter (req) tid (req) Expected Response: If the parameter is recognized by the server (or client, this can work in both directions), it replies with result=ok. If not, it replies with result=error, and can include explanatory information in addtion to an error code if desired. Message: MonitorAddress -------------- Description: This action is used to register with the server to monitor address related events for a particular address or address mask. It is up to the server whether to accept or deny these requests based on its own user policies. -------------- Message Type: Action Parameters: address (req) tid (req) Expected Response: If the request is accepted, the server replies with a result=ok message, otherwise it replies with an error code and message. Message: StateChange ----------- Description: This event is used to notify a listening client about a state change on a monitored address. This can be used, for example, to notify users that a particular person has gone on Do Not Disturb. ----------- Message Type: Event Parameters: address (req) parameter (req) value (req) Expected Response: None expected Examples SetStatus Following is an example of how the SetStatus action is used to update a particular user's station settings. --> action=setstatus&address=201&tid=123¶meter=callwaiting&value=on --> action=setstatus&address=201&tid=124¶meter=dnd&value=off --> action=setstatus&address=201&tid=125¶meter=fwd_rna&value=vm --> action=setstatus&address=201&tid=126¶meter=fwd_busy&value=vm --> action=setstatus&address=201&tid=127¶meter=ring_timeout&value=4 <-- action=setstatus&tid=124&result=ok <-- action=setstatus&tid=123&result=ok <-- action=setstatus&tid=125&result=ok <-- action=setstatus&tid=126&result=ok <-- action=setstatus&tid=127&result=ok GetStatus Following is an example of how the GetStatus action is used to retrieve the call waiting setting for a particular user. --> action=getstatus&address=201&tid=131¶meter=callwaiting <-- action=getstatus&tid=131&value=on Following is an example of how the GetStatus action is used to retrieve all public parameters for a particular user (it is up to the server to decide which information should be delivered to the client). --> action=getstatus&address=201&tid=132 <-- action=getstatus&tid=132&callwaiting=on&dnd=off&fwd_rna=vm&... MonitorAddress Following is are examples of how a client uses the MonitorAddress action to ask the server to relay events pertaining to a specific address, and to an address mask. Ex. 1 - Monitor a specific address --> action=monitoraddress&address=201&tid=133 <-- action=monitoraddress&tid=133&result=ok Ex. 2 - Monitor all addresses --> action=monitoraddress&address=*&tid=134 <-- action=monitoraddress&tid=134&result=error&error_code=505&error_text="Denied" Ex. 3 - Monitor an address mask --> action=monitoraddress&address=4156476*&tid=135 <-- action=monitoraddress&tid=135&result=ok Ex. 4 - Stop monitoring an address --> action=monitoraddress&address=201&stop=true&tid=136 <-- action=monitoraddress&tid=136&result=ok Ex. 5 - Stop monitoring all addresses --> action=monitoraddress&address=*&stop=true&tid=137 <-- action=monitoraddress&tid=137&result=ok While it may seem like unnecessary extra work to register with the server for event notices, this is important as it eliminates the unnecessary transmission of unneeded data, and also prevents servers from saturating a network when monitoring large systems. Note: it is up to the server to decide which monitoring requests to accept and deny. For example, a small key system may wish to allow users to monitor all addresses on the system, while a central office switch would not want to permit a single user to monitor every address served by the CO. It is up to the server to decide what policies to enforce with respect to event notification requests. TestParm Following is an example of how the TestParm action is used to ask the server if it recognizes a particular parameter. (This can be used by client applications to ask the server which features it recognizes for user settings) --> action=testparm&address=201¶meter=autohold&tid=145 <-- action=testparm&tid=145&result=ok StateChange Following is an example of how the StateChange event is used to notify a listening client that a user has set their station to Do Not Disturb. Note: it is up to the server to decide which statechange events to present to clients. --> evt_type=address&event=statechange&address=201¶meter=dnd&value=on <-- evt_type=address&event=statechange&address=201¶meter=dnd_msg&value="Out for lunch" Implementation Notes The GetStatus and SetStatus actions are intentionally open ended with their parm=x, value=y syntax. This is due to the fact that while most telephony servers offer a consistent set of basic features, many vendors offer additional services that may be exposed through this type of interface. If a client attempts to update a parameter which is not recognized by the server, it will simply respond with a "parameter not recognized" error. Likewise parameters which are not understood by the client will simply be ignored. The list of standard parameters below covers most of the basic user settings encountered on private and public telephone networks. 2.2 List Of Standard Parameters ------------------------------- Parameter: autoanswer Description: Automatically answer incoming calls to user Syntax Notes: on, off Parameter: autoanswerspk Description: Automatically answer incoming calls in speakerphone mode to user Syntax Notes: on, off Parameter: autohold Description: Automatically place calls on hold when user is in conversation Syntax Notes: on, off Parameter: autoholdcalls Description: Maximum number of calls which can be placed on autohold (if exceeded, this is a busy condition. Syntax Notes: integer value Parameter: autoholdmsg Description: Filename or URL of message to be played when autoholding a caller Syntax Notes: filename or URL Parameter: callsholding Description: Number of calls holding and/or camped for a given user Syntax Notes: integer (0 or greater) Parameter: callsparked Description: Number of calls parked for a given user Syntax Notes: integer (0 or greater) Parameter: callwaiting Description: Call waiting enabled for user Syntax Notes: on, off Parameter: callwaitingcalls Description: Maximum number of calls which can be holding for a user (default value if not specified is 2) Syntax Notes: integer value Parameter: dnd Description: Toggle do not disturb feature Syntax Notes: on, off Parameter: dnd_msg Description: Short text message displayed when dnd is activated Syntax Notes: up to 80 char text message (lower ASCII chars only, no CR or LF) Parameter: fm_newmsgs Description: Number of new fax messages waiting for user (read-only) Syntax Notes: integer (0 or greater) Parameter: fm_oldmsgs Description: Number of saved fax messages waiting for user (read-only) Syntax Notes: integer (0 or greater) Parameter: fwd_all Description: Call forwarding (all calls) Syntax Notes: off, any valid dialed number string or address recognized by server Parameter: fwd_busy Description: Call forwarding (busy calls) Syntax Notes: off, any valid dialed number string or address recognized by server Parameter: fwd_rna Description: Call forwarding (ring no answer) Syntax Notes: off, any valid dialed number string or address recognized by server Parameter: intercom Description: Enable intercom (speaker) calls to user Syntax Notes: on, off Parameter: status Description: Current status of terminal user is mapped to * Syntax Notes: ringing, dialing, idle, talking, busy, dnd Parameter: vm_newmsgs Description: Number of new voice messages waiting for user (read-only) Syntax Notes: integer (0 or greater) Parameter: vm_oldmsgs Description: Number of saved voice messages waiting for user (read-only) Syntax Notes: integer (0 or greater) * the status parameter is used to indicate the current handset status of a particular user. There is an important item that server side implementers need to be aware of. The server is responsible for keeping track of which users are mapped to which terminals. For example, if a terminal to which a user is assigned is on dnd, all users mapped to that terminal should indicate dnd. In another instance, a user is mapped to several terminals, one of which is marked dnd, the server may or may not wish to display the user as dnd. The rules applied to address-terminal mapping will vary depending on the type of system and upon policies implemented by the server software. This is a moot point on systems where the address and terminal identifiers are identical, but on systems which employ dynamic mapping schemes, you'll need to bear this in mind when writing the server side interface as there is no universal rule which will work for every situation. This set of actions and events enables user to manage their call management settings, and enables applications throughout a network to monitor the status of individual users (i.e. busy, calling someone, on do not disturb, etc). This provides all of the necessary functionality to implement personal call management settings, and to implement status monitor applications such as a PC based busy lamp field. Note that this set of actions does not address individual calls or conferences. This is done with the call related actions and events. 2.3 Terminal Related Actions and Events --------------------------------------- As discussed in the introduction, terminals are analgous to telephone handsets or devices. It is important to understand that addresses and terminals may or may not be the same, depending on the type of server. Client software developers should never assume that these will be the same since on some systems many users can share the same terminal and vice versa. Message: MapAddress ---------- Description: This action is used to map an address to a specific terminal on dynamically mapped systems. ---------- Message Type: Action Parameters: Terminal (req) address (req) tid (req) password (opt) name (opt) text (opt) Expected Response: Server will respond with a result=ok or a result=error message. Additional information about error conditions may be provided (i.e. address not authorized to use terminal, etc) Message: UnmapAddress ------------ Description: This action is used to unmap a specific address from a terminal on a dynamically mapped system. ------------ Message Type: Action terminal (req) address (req) tid (req) password (opt) Expected Response: Server will respond with a result=ok or result=error message. Message: MonitorTerminal --------------- Description: This action is used to register to receive events pertaining to a given terminal (i.e. to monitor the hookswitch state of a given station) --------------- Message Type: Action Parameters: terminal (req) stop (opt) tid (req) Expected Response: Server will respond with a result=ok or result=error message. Message: TermState --------- Description: This event is used to notify listening clients of a change of state in a monitored terminal --------- Message Type: Event Parameters: parameter (req) value (req) Expected Response: None expected Message: SetTermParm ----------- Description: This action is used to set a terminal specific parameter (i.e. gain settings). ----------- Message Type: Action Parameters: parameter (req) value (req) tid (req) Expected Response: Server replies with a result=ok or result=error message Message: GetTermParm ----------- Description: This action is used to query the server for terminal specific parameters ----------- Message Type: Action Parameters: parameter (opt) tid (req) Expected Response: If parameter is specified, server replies with contents of specific parameter, otherwise it replies with a list of all public parameters for that station. Message: GetTermList ----------- Description: This action is used to query the server for a list of active terminals. Server may decide whether to make this information available or not. ----------- Message Type: Action Parameters: Address (req) tid (req) Expected Response: returns result=ok if accepted, followed by a list=x,y,z... string. Otherwise it returns a result=error message with an optional error code. Examples MapAddress Following is an example of how the MapAddress action is used to associate a specific user with a terminal. --> action=mapaddress&terminal=142&address=301&name=Brian McConnell&tid=145 <-- action=mapaddress&tid=145&result=ok UnmapAddress Following is an example of how the UnmapAddress action is used to unmap a terminal/address assignment. --> action=unmapaddress&terminal=142&address=301&password=xyz&tid=146 <-- action=unmapaddress&tid=146&result=ok SetTermParm Following is an example of how the SetTermParm action is used to update a terminal specific parameter setting. --> action=settermparm&terminal=142¶meter=rxgain&value=3&tid=147 <-- action=settermparm&tid=147&result=ok GetTermParm Following is an example of how the GetTermParm action is used to query the server for the contents of a parameter setting. --> action=gettermparm&terminal=142¶meter=rxgain&tid=148 <-- action=gettermparm&tid=148¶meter=rxgain&value=3 GetTermList Following is an example of how the GetTermList action is used to query the server for a list of active terminals. --> action=gettermlist&address=201&tid=149 <-- action=gettermlist&tid=149&result=ok&list=141,142,143,144,145,146,147,148,.. TermState Following is an example of the TermState event message, and how it is used to relay information about change of state in a specific terminal. --> evt_type=terminal&event=termstate¶meter=status&value=ringing TermUpdate Following is an example of how the TermUpdate event is used to inform a client that a new terminal has been added to the server. (This can be used to drive real-time status displays of terminals/extensions on a large telephone system). --> evt_type=terminal&event=termupdate&active=yes&terminal=142&termtype=isdnbri 2.4 Standard List Of Terminal Related Parameters ------------------------------------------------ Parameter: Address Description: Address(es) with which the terminal is associated. If more than one address is associated with a terminal, a comma delimited list is returned. Values: One or more numeric strings. If more than one, comma delimiting is used. Parameter: Name Description: Name(s) with which the terminal is associated. Values: One or more alphanumeric strings. If more than one, comma delimiting is used. Parameter: Status Description: Status of a specific terminal Values: idle, vacant, ringing, dialing, talking, holding, dnd, error Parameter: TermType Description: Short descriptor of terminal type (normally read-only). This is used to indicate what kind of terminal is in use. Values: Short alphanumeric string describing the terminal type. There is no pre-defined list of terminal types other than the following generic classes, vendors may add their own descriptors for specific telephone handset types etc. * pots * pots-centrex * isdnbri * h323 * [add your own types here] Parameter: Text Description: Shore (< 128 char) text message associated with a specific terminal (i.e. "Equipment Room") Values: Alphanumeric string up to 127 chars in length 2.5 Call Related Actions And Events ----------------------------------- As discussed in the introduction, calls refer to individual calls (point to point or conference type). Calls are treated independently of users and addresses. This facilitates first and third party call control operations, and also permits the creation of network based real-time monitoring and reporting applications. However, the primary purpose of this set of actions and events is call control. Real-time station status information (i.e. for driving busy lamp fields) is best accessed through the address related actions and events. Call Control Fundamentals The basic unit of information which is used in querying and manipulating conversations is the cid (call ID) parameter. Each call should be assigned a unique ID by the server, this ID should be unique throughout the system, not just for a specific user, since calls will often be transferred from address to address. The server should automatically destroy the cid upon completion of a call (either via the PSCT hangup action, or via a telephone handset hangup). Care should be taken to insure that resource ids are properly disposed of once they are no longer needed. Note: (req) denotes required parameter while (opt) denotes an optional parameter. Message: Accept ------ Description: Instructs server to accept call, create voice path ------ Message Type: Action Parameters: cid (req) tid (req) Expected Response: Server replies with result=ok or result=error Message: BlindTransfer ------------- Description: Instructs server to blind transfer call to another destination (local or remote) ------------- Message Type: Action Parameters: cid (req) destination (req) ringback (opt) tid (req) Expected Response: Server replies with result=ok or result=error. If ringback time is specified, call returns to sender if not picked up within N seconds. Message: Call ---- Description: Instructs server to place call to a destination address. destination (req) ---- Message Type: Action Parameters: supervise (req) audio_cpa (opt) network_cpa (opt) timeout (opt) Expected Response: Server replies with result=ok (completed call), result=error (incomplete call), or result=? (call setup in progress). Detailed call completion or failure data is provided in the response Message: CampOn ------ Description: Instructs server to camp call to a destination. ------ Message Type: Action Parameters: cid (req) destination (req) ringback (opt) tid (req) Expected Response: Server replies with result=ok or result=error. If ringback time is specified, call returns to sender if not picked up within N seconds. Message: ConfCreate ---------- Description: Instructs server to create a conference resource to which calls can be joined ---------- Message Type: Action Parameters: maxsize (req) owner (opt) privlevel (opt) Expected Response: Server replies with result=ok or result=error. If a conference is created, it will also return a cfid specifically for the conference (not to be confused with a call id). Owner and privlevel parameters can be used to assign moderation properties to conferences. Message: ConfDelete ---------- Description: Instructs server to destroy a conference resource ---------- Message Type: Action Parameters: cfid (req) tid (req) Expected Response: Server replies with result=ok or result=error. Message: ConfJoin -------- Description: Instructs server to add a call to a conference resource -------- Message Type: Action Parameters: cid (req) cfid (req) duplex (opt) owner (opt) tid (req) Expected Response: Server replies with result=ok or result=error. Duplex can be full or listen. Owner can be yes or no (to indicate whether caller has owner privileges) Message: ConfLeave --------- Description: Instructs server to remove a call from a conference --------- Message Type: Action Parameters: cid (req) cfid (req) tid (req) Expected Response: Server replies with success or error message Message: ConfList -------- Description: Instructs server to return list of current conference members (can request list by call id, address or terminal) -------- Message Type: Action Parameters: cfid (req) listtype (req) tid (req) Expected Response: Server replies with comma delimited list, or with error message. Listtype can be cid, address or terminal to indicate how to return list. Message: Fwd_RNA ------- Description: Instructs server to treat call as ring no answer Parameters: ------- Message Type: Action cid (req) tid (req) Expected Response: Server replies with result=ok or result=error Message: Fwd_Busy -------- Description: Instructs server to treat call as busy -------- Message Type: Action Parameters: cid (req) tid (req) Expected Response: Server replies with result=ok or result=error Message: FwdCall ------- Description: Instructs server to forward call to specified target without answering ------- Message Type: Action Parameters: cid (req) destination (req) tid (req) Expected Response: Server replies with result=ok or result=error Message: Hangup ------ Description: Instructs server to hang up/terminate call ------ Message Type: Action Parameters: cid (req) tid (req) Expected Response: Server replies with result=ok or result=error Message: Hungup ------ Description: Server uses this event to inform the far side of call termination ------ Message Type: Event Parameters: cid (req) Expected Response: None expected, although the client may respond with an acknowledgement Message: Hold ---- Description: Instructs server to place a call on hold ---- Message Type: Action Parameters: audio (opt) cid (req) ringback (opt) ringback_target (opt) tid (req) Expected Response: Server replies with result=ok or result=error. Audio can be used to specify music port, filename or URL to play to caller. Ringback can be used to specify ringback time which, if exceeded, causes call to ring back to the address of the user who put the call on hold, or an optional ringback target Message: NewCall ------- Description: Server uses this event to notify an address of a new call, or a call which is ringing back from a hold condition ------- Message Type: Event Parameters: cid (req) clid (opt) dnis (opt) line (opt) name (opt) sender1..n(opt) Expected Response: Note re: sender1..n parm. This is an optional array which can be used to transmit a call forwarding history for a specific call (i.e. so the user can see who has already handled this call) Message: Park ---- Description: Instructs server to park a call on hold for retrieval by a user. Either server or client can specify parking address (behavior will vary by system) ---- Message Type: Action Parameters: cid (req) parkaddress (opt) ringback (opt) tid (req) Expected Response: Server replies with result=ok or result=error. If parkaddress is specified, client attempts to specify park address, otherwise server assigns it. Message: CallState --------- Description: Server uses this event to notify listening clients of a change in state in a particular call. --------- Message Type: Event Parameters: cid (req) status (req) Expected Response: None expected Message: TransferStart ------------- Description: Instructs server to place call to destination, place current call on hold. This is used to set up a supervised transfer. ------------- Message Type: Action Parameters: cid (req) destination (req) tid (req) Expected Response: Server replies with result=ok or result=error. The TransferDrop action is used to abandon the transfer attempt. Message: TransferDrop ------------ Description: Instructs server to abandon transfer attempt, return to original call. ------------ Message Type: Action Parameters: cid (req) tid (req) Expected Response: Server replies with result=ok or result=error. Message: TransferComplete ---------------- Description: Instructs server to complete supervised transfer ---------------- Message Type: Action Parameters: cid (req) tid (req) Expected Response: Server replies with result=ok or result=error Message: Unhold ------ Description: Retrieves a call from hold. ------ Message Type: Action Parameters: cid (req) tid (req) Expected Response: Server replies with result=ok or result=error. Examples Accept --> action=accept&cid=1655&tid=178 <-- action=accept&tid=178&result=ok BlindTransfer --> action=blindtransfer&cid=1656&destination=302&text="Bob on the line"&tid=179 <-- action=blindtransfer&result=ok Call --> action=call&destination=14156479911&supervise=yes&audio_cpa=yes&tid=127 <-- action=call&tid=127&result=ok&cid=1511 --> action=call&destination=14156479911&supervise=yes&network_cpa=yes&tid=128 <-- action=call&tid=128&result=?&text="Dialing" <-- action=call&tid=128&result=?&text="Waiting for Answer" <-- action=call&tid=128&result=error&error_code=551&error_text="Busy" CampOn --> action=campon&cid=1657&destination=302&ringback=60&text="Bob Smith"&tid=180 <-- action=campon&tid=180&result=ok ConfCreate --> action=confcreate&maxsize=4&owner=301&tid=190 <-- action=confcreate&tid=190&result=ok&cfid=192 ConfDelete --> action=confdelete&cfid=192&tid=191 <-- action=confdelete&tid=191&result=ok ConfJoin --> action=confjoin&cfid=192&cid=1655&duplex=full&owner=no&tid=199 <-- action=confjoin&tid=199&result=ok ConfLeave --> action=confleave&cfid=192&cid=1655&tid=200 <-- action=confleave&tid=200&result=ok ConfList --> action=conflist&cfid=192&tid=201&listtype=cid <-- action=conflist&tid=201&result=ok&list=1655,1712,1811,1813 FwdRNA --> action=fwdrna&cid=1656&tid=202 <-- action=fwdrna&tid=202&result=ok FwdBusy --> action=fwdbusy&cid=1656&tid=203 <-- action=fwdbusy&tid=203&result=ok FwdCall --> action=fwdcall&cid=1656&destination=305&tid=204 <-- action=fwdcall&tid=204&result=ok Hangup --> action=hangup&cid=1656&tid=205 <-- action=hangup&tid=205&result=ok Hungup --> evt_type=call&event=hungup&cid=1656&tid=206 Hold --> action=hold&cid=1656&ringback=90&music=1&text=Bob Smith&tid=177 <-- action=hold&tid=177&result=ok Newcall --> evt_type=call&event=newcall&cid=1657&clid=4156479911&dnis=4158212356&tid=189 Park --> action=park&cid=1657&destination=304&parkaddress=901&tid=209 <-- action=park&tid=209&result=ok CallState --> evt_type=call&event=callstate&cid=1657&status=holding TransferStart --> action=transferstart&cid=123&destination=123&tid=190 <-- action=transferstart&tid=190&result=ok TransferDrop --> action=transferdrop&cid=123&tid=190 <-- action=transferdrop&tid=190&result=ok TransferComplete --> action=transfercomplete&cid=123&tid=190 <-- action=transfercomplete&tid=190&result=ok Unhold --> action=unhold&cid=123&tid=190 <-- action=unhold&tid=190&result=ok 2.6 Line Related Actions And Events ----------------------------------- As discussed in the introduction, lines refer to physical or virtual circuits leading to another telephony server or to an external telephone network. On larger telephone networks, the status of individual lines is generally considered to be irrevelant. However, on small systems, particularily key systems and intercoms, it is very useful to be able to monitor and manipulate individual lines. This set of actions and events permits client applications to emulate the behavior of a key system or intercom (even if the system is really a PBX or group of Centrex telephone lines). For the most part, this section of the protocol is used to monitor the status of physical and virtual telephone circuits leading to other servers or to the outside world. There are, however, a couple of actions which can be used to directly retrieve a call associated with an outside line and map it directly to an address. This is the equivalent of picking a call off a trunk on a key telephone system. Message: GetLineParm ----------- Description: This action is used to request a parameter associated with a specific line. ----------- Message Type: Action Parameters: line (req) tid (req) parameter (opt) Expected Response: If a parameter is specified, the server replies with its contents, or an error code (i.e. parameter not recognized). If no parameter is specified, it responds with a list of parameters and their respective values. Message: SetLineParm ----------- Description: This action is used to set a parameter associated with a specific line ----------- Message Type: Action Parameters: line (req) tid (req) parameter (req) value (req) Expected Response: Server replies with result=ok or result=error. Message: LineState --------- Description: This event is used to notify a client of a change of state in a monitored line. --------- Message Type: Event Parameters: line (req) state (req) Expected Response: None expected Message: MonitorLine ----------- Description: This action is used to register with the server to receive line related events ----------- Message Type: Action Parameters: line (req) stop (opt) tid (req) Expected Response: Server replies with result=ok or result=error Examples GetLineParm Following is an example of how the GetLineParm action is used to query the server for information about a specific line. --> action=getlineparm&line=12¶meter=linetype&tid=187 <-- action=getlineparm&tid=187¶meter=linetype&value=E1R2MFC SetLineParm Following is an example of how the SetLineParm action is used to set a parameter associated with a specific line. --> action=setlineparm&line=12¶meter=status&value=block&tid=188 <-- action=setlineparm&line=12&tid=188&result=error&error_code=504&error_text=Denied LineState Following is an example of how the LineState event is used to deliver real-time state change information to a listening client. --> evt_type=line&event=linestate&line=12&status=ringing MonitorLine Following is an example of how the MonitorLine action is used to register to receive line related events. --> action=monitorline&line=12&tid=189 <-- action=monitorline&tid=189&result=ok --> action=monitorline&line=12&stop=yes&tid=190 <-- action=monitorline&tid=190&result=ok 2.8 Standard List Of Line-Related Parameters -------------------------------------------- Following is a list of standard parameters to be used in conjunction with lines. Parameter: linetype Description: Type of telephone line, used to provide descriptive information for monitoring application. Expected Values: Short (<20 char) alphanumeric string. Parameter: Status Description: Current status of line Expected Values: idle, block, ringing, dialing, talking, holding (not all states will be supported by all systems) EOF gnucomm/TGI_spec100664 765 765 14761 7513704517 12000 0ustar rsbrsb Telephony Gateway Interface Draft Specification 1.0 The ACS shell command is now compliant with the draft 1.0 specification for "Telephony Gateway Interface". TGI specifies how a telephony server such as ACS can securely invoke external programs and scripts written in other languages. TGI uses environment space to pass command line arguments to TGI applications so that these arguments cannot be observed through a "ps" command. TGI also uses a control fifo as the TGI programs "stdout" to enable external programs to directly issue commands and set variables back inside the telephony server. While TGI has been developed specifically for ACS, the specification should allow TGI to be implimented for any telephony server with a need to securely invoke external images. All TGI applications and external scripting languages are invoked from an executable found in "libexec/tgi" (examples: /usr/libexec/tgi, /opt/ACS/libexec/tgi). This default directory assures that no arbitrary images are invoked outside of the telephony server from the search path. All TGI applications are assumed to return an "exit" code when they terminate. This exit code can then be passed into the telephony server. All TGI applications receives a number of system configuration variables in environment space. These symbols include: SERVER_VERSION (1.0) Version of TGI protocol this server impliments. SERVER_PLATFORM (pika) Base hardware platform this server has been built for. SERVER_SOFTWARE (ACS) Telephony server software being used. SERVER_RUNTIME (/var/ACS) Working directory for telephony server runtime databases. SERVER_PROMPTS (/usr/share/aaprompts) Directory where primary telephony server audio prompts are stored. SERVER_LIBEXEC (/usr/libexec/tgi) Path where all TGI applications are presumed to be stored. In addition, since a TGI program is invoked to provide external processing for a specific telephone line, a number of "transient" or session specific variables are also passed through environment space. Many of these variables are optional. The only required environment variable that must be specified is "PORT_NUMBER". PORT_NUMBER (1-x) The telephony port this script or image is being invoked for. Most servers will number telephony ports starting from "1". This port is required when using stdout to send commands back into the server. PORT_QUERY (-a&-c) This symbol holds any command line arguments that would normally have been passed to the external program. Using environment space assures that any key data (for example, a credit card number) can not be viewed through a simple "ps" by any arbitrary user on the machine. The "&" is used to seperate command line arguments, as in CGI "QUERY_STRING". PORT_DIGITS If there are DTMF digits pending in the telephony servers buffer for the specified port, those digits are passed here as a string. PORT_DNID This would hold a DNIS or DID number when such information exists for the specified port. PORT_ANI This would hold the calling parties telephone number if the server has such information. ANI also represents the "telephone number" portion of caller id systems, or calling party from SMDI. PORT_CID This represents the "raw" caller ID string if one was retrieved from a CO for the current line. Caller ID strings may hold ascii data and other information beyond simple telephone numbers, and so is considered seperate from PORT_ANI. Finally, as noted, TGI applications should be able to send values back into the telephony server using stdout. The exact implimentation of stdout may vary from one server to another, but the critical subset of commands that should be issued with an ACS server may include: SET port sym value Sets a symbol for the specified "port". The "port" value used should be the same as the "PORT_NUMBER" passed in the environment space. In ACS "sym" can be var0 .. var9, temp0 .. temp3, or "digits". If "digits" is used, then the current content of the DTMF input buffer is replaced with the value passed. Any value that represents an unknown symbol will be given a symbol in the ACS process environment space that can be retrieved by the referencing port through it's "^sym" name. PUT sym value This may be used to set a global symbol in the ACS envornment space which may be retreived by it's "@sym" name. IDLE port Forces specified port to disconnect the caller. The "port" value used should be the same as the "PORT_NUMBER" passed in the environment space. While any command found under umdctrl(8) can be issued by a TGI application, the above represents the most appropriate subset to use. ACS Plugins With release 0.5, ACS introduces the concept of "plugins". Plug-ins are simply loadable shared modules that can be used to extend the functionality of ACS in a modular fashion at runtime. This keeps the size of the primary ACS image small as plug-ins should involve optional or alternate features. ACS plug-ins come in a variety of specialized forms. Some plugins support only one active instance, while others may allow multiple modules to be loaded. ACS plug-ins are C++ classes derived from "modules.h". Currently, the following plug-in types are defined: "mod" This covers all "generic" modules. Such modules may add one "keyword" to the script interpreter. "dba" A dba plugin implements the insert/delete/search/update script keywords through a database system. The most common "dba" would likely be one that uses gdbm. A dba module is defined in "database.h" and only one instance may be loaded. "mbox" A mbox plugin implements the commit/mailbox/extension/deliver keywords and provides the underlying support for both mailbox database management and transactional objects (class Mailbox). Only one instance of a mbox may be loaded at any given time. notification A notification module is derived from MWIModule. It may be loaded as a generic module, and more than one instance may be loaded. The module may export a keyword into the script interpreter like other generic modules. Notification modules are used to implement message waiting indication and paging. Generally, a module is created by defining a dso with at least one global module initializer derived from one of the module classes, as in: #include class MyModule : public Module { ... }; MyModule myInstance(..); The module constructor is created as the class is loaded, and the destructor is called as the dso is removed from memory. If the module makes use of service threads, those should be started and stopped with the start/stop methods. gnucomm/TOSI_spec100664 765 765 16624 7513704517 12133 0ustar rsbrsbTelephony Open Source Interface (TOSI) -------------------------------------- Overview -------- TOSI is an interface to a library of C callable functions that provides a simple way for applications to control telephony hardware and software. TOSI is designed to be platform and telephony hardware independent. Some examples of telephony devices suitable for control by TOSI are: * Voice Modems * Analogue and digital Computer telephony (CT) cards * Smart speakerphones with built in CT connectivity * Daemons that speak the Protocol for Simple Computer Telephony This will allow any application to communicate with telephony hardware to accomplish tasks such as: * Using a GUI on your PC to make a phone call from an on-line phone book. * Have a GUI pop up on your PC for incoming calls, telling you who is calling. * Handling multiple calls at once and setting up conference calls. * Providing a nice GUI interface for all those #$@ DTMF codes you need to remember to control your voice mail, call forwarding etc. * Using a web interface to tell a call centre when and where to ring you, rather than waiting in a queue. At the appointed time your number is automatically dialed and connected to the call center. * Providing access to any phone system that supports an open protocol (we are starting with PSCT). History ------- 01-03-2001 v0.0.4 Converted some notes into content where missing - rsb 09-03-2000 v0.0.3 Modded according to discussion with tosi group - rsb 08-31-2000 v0.0.2 Fixed some typos, made a few mods - rsb@ostel.com 08-30-2000 v0.0.1 Initial draft - David Rowe voicet@bigpond.com.au TOSI is being driven to 0.1.0 status by the TOSI development group, it's current maintainers. See tosi.sourceforge.net. Design Goals ------------ * To provide a simple, flexible, unencumbered, platform independent interface which requires no third-party development tools or middleware. A competent programmer should be able to build a working prototype application within a few hours. * To cover as many of the common terminal settings and third party call control functions as possible, while leaving room for extension to those we have missed. * Not to get feature-bloated by trying to encapsulate switch control protocols, or the features of every device imagineable. TOSI should remain a small, easy to use interface for use on clients. Introduction to the TOSI Model ------------------------------ TOSI abstracts physical resources in such a way that an application can talk to many different types of telephony devices, from an analogue voice modem to a multi-line digital Computer Telephony (CT) card. TOSI deals with one object - the "channel". A channel corresponds to a single line telephony device. In the physical world, this channel may be: * A voice modem. * A single port of a multi-port CT card. * A smart speaker phone with CT connectivity. Using TOSI function calls, you can control the channel, for example: * int tosi_open(chan_type, chan_id), attempts to find an available channel of the type and, optionally, with the given id (id can be an ip address). Supported channels in v0.1.0: PSCT channel Vmodem channel The TOSI library is extensible enough to allow you to write a pluggable channel of your own. You just list a few functions and definitions in chan_types.h and your_chan_type.h. Most of the tosi_ functions will then call your functions. * int tosi_pick_up(chan_id), takes the TOSI channel off hook. * int tosi_hang_up(chan_id), hangs up the TOSI channel. * int tosi_dial(chan_id, destination), sends appropriate info down the TOSI channel, may be used for control of switch (e.g. transferring calls), or control of speakfreely, or control of a modem, or whatever the channel is. * int tosi_xfer(chan_id, destination), transfers the caller on the given open channel to the given destination. * int tosi_get_event(), reads events from the channel, such as ring, DTMF detection, and Caller ID detection. * int tosi_send_msg(chan_id), sends a text message if the channel supports it. * int tosi_rcv_msg(chan_id), gets a text message if the channel supports it. Once again, the list above is limited only by the channel capabilities and your ability to extend it. For instance, when using tosi_send_msg() and tosi_rcv_msg() and tosi_get_event() to communicate on a PSCT channel, you have all of the control that PSCT gives you over the device on the other end, which can be considerable. Note that there are no media-handling functions in TOSI, you cannot use TOSI to play or record speech samples to the channel. TOSI channels are signalling channels. RSB> Maybe an ascii art picture here showing signal path and seperate voice path, different kinds of devices present, etc. will drive this home. RSB> Also, an example of using get_event(). Since most protocols require registration for events, should we offer register_4_event() as well? Design Notes ------------ 1. My main priority is simplicity, for example a small set of function, abstracting away as many details as possible to the lower layers. Note that this is a complete 180 degree shift in my previous thinking (ie to model TOSI on PSCT)! :-) Rich - I used some of you ideas in a previous email for the open & dial functions instead. I arrived at this current model by looking at what was required to implement the simple applicatons we have discussed. RSB> DR, I think we really need to put together a list of the applications of this API we are going to solve. Let's compile this and then work from there down through this API. Here is a more detailed version of an example mentioned in the overview highlighting the usage of the TOSI interface library and PSCT protocol: WidgetWare's GroupWare Application, WGroup, recieves alarms from other applications telling it that an important server is down. Joe is paged by Wgroup, and arrives at his terminal. He finds that the situation is grave, and all support technicians in the local area must be paged to arrive on site. In addition, all of the managers must be paged, and those who are available should be conferenced in with Joe within 30 minutes. Joe tells WGroup that these operations are to occur. WGroup opens a TOSI PSCT channel to a telephony server... 2. Event Handling: I have used an event Q rather than call back function to handle events, as this avoids the need for threads, or the need for the event handler to execute quickly. RSB> I personally like callbacks better. It actually is just as easy to implement(given a good example) and doesn't waste cpu cycles spent polling. I have followed along with the no callbacks method in my mods above. The get event function is non-blocking, so that a flag in the polling loop can be used to exit the program. Are these valid reasons for using this sort of event handling mechanism? 3. No threads are required with the current model. No big deal, but will make life easier for some. 4. The API is as compact and simple as possible to make people want to use it, and build apps quickly. It also looks suspiciously like the VPB-API! I need you guys to help get my mind out of the VPB box on this one! 5. Is "channel" a good term? What about port, line, phone, extension? RSB> I think endpoints and channels are good. If you define a set such as is defined in the PSTC spec, we should be covered on definitions. I would leave port and socket alone, since most programmers use those in other ways. gnucomm/acsbay100664 765 765 2676 7513704517 11567 0ustar rsbrsb[o8)O\$h:ZFH۾W$Є#0M2}47RKwYPms|Q& zz&8p8A:TGmok&<P,4}gHQUX2$Wˇ3譂UK-W,oV' {P# }9j nI& _/:}=DxPxXiͳ"ꮝς\IwŇsB?$oD0<  w/z| G8It8oHJʌSQH7(,*Kv\ȁO`eublw4# ,D]GHcP^?9(/`Şf`QiҜN%3mΓh õA8E¥/.t(|+)J[DAR[R$#Z)+&V,G@=(;v{¾U1Ҩ[jv*]ypxjնP1u9MzC, <+WqrWdQ($;#gv~,b'u6}""ն簨m9曷jy.=5igLZ)7&_2lRbib;wY~GLJ%0hg@ 8iwn̲):<@Cb@$ιlµ\~v\'z?q}kIgnucomm/acsbay.png100664 765 765 11606 7513704517 12363 0ustar rsbrsbPNG  IHDR1a sBITO>IDATx]b6atu{{zC~GB'x+{``tc 1 hYidCw^:0rQ 4h breMO%X}{p"WLĥy*۲.FTP' d >%-jp%*bij|42j`0H`l/n du+q[ZEǛ8Cd{wuvkV=kn ҙ[C!z.`o1YZJZ>7zCxOػ;ʊ?l͍HyI+8yfs6lɜO4G?A%X VZ81 h h!&-$bBLZI@ 1 h!&-$bBLZI@ 1 h!&-$|y}}=;.///gg8Bzzz?;>\ RM>>>'qZI@ 1 h!&-$bBLZ=<<9gj1Ne19G2&' 4i!JMԩɩ\]sCdEDLLjI)I_Lj4kdzzk,8PgoLƁ@ubBLZI@ 1 h!&-$bBLZI@ 1 h!&-$ X=== _^^^ú'ظ hbBLZI@ 1 h!&-_k]{A >@O xgL&bp͖oL<*;"åK!]05U\soJX]wn7X(;[/`vȟ2TY9)k/m{4py1iX-; ^/q51q@lLS*n%gDly2pk3C9&(M$Ξx4p aowe7lnxyݩVۮCtK{e}ZI@ 1 h!&-$bwe?p0&EpZuCLW'Vc29šn=S{tLj3{=S\a$ɠ&b\1H?CqU7WB=halbBLZI@ 1 hi^I^:^2{˶]kv J2H9i|:Iv8v}HA:1YvEC4-wbBLZI@ 1 h!&-u1ֹzxH9! T+no\O@C`x4)&wY$Ove=monpF0BLZI@ 1 h!&-$bBLZI@ 1 h!&-$eszv\^^^ɏsׯooog}릞(BS=~v^~WIlGbBLZI@ 1 h!&-$uNs=M)tc߿|\p<)x<߳s9\X~۷s9ZI@ 1 h!&-$bBLZI@ 1 hxW_ׯjzD|=]vTm[P߾}ٹ.'?uTbk#&]\`GZI@ 1 h!&-0 8ggDLZI@ 1 ha@B|yD\Cg1Vk{<H_`?=0Y:/?7> >}>rKoooӄ1,#(m ̭<-NBʜS}ӓxjy*$#8Iư?c=) })AiNN1鲼jsudMEx ܟĨ0}*hN'#QO&L8(A_5ud4N9%#&@ 1 h!&4~+4t>/]\tO|/J[stV2|am׸Ptpy]so;g>ԟƷԒWtEgW>*x7GpvJ|adN\l\,uiWs56802\xӫ+|a=Ťi2.ًi{/ oxh/:R?zk8|o6f#NX.]#&t-q^LG-i>% -S~uۮq F<w眚\1}v)yNnw(fbO0y\j97v-vҭwEss"WEhq6mLy=[LyH]+V$Ukϒ  O!L6N)LGڮ9srϕRv <\5|c/Yj(:d%!]#Ξ u}ڿ4ٹ]qN3_-v)ăBqr'nTbr~w<右It熭Ͷۮ^1ط+Ip ՓAp ?/GJ.&=rin0qK:f2\ ZM.\4nquڒk'"-_4We̙l\-Of~ceb<}ӯМ\=is[ ϗb.[f}Hn5vĿTGm`ӵW_\i}}uNO5't8f  Mq۞k<f$UlI>lls )enP!17?P<(4 ݑDZpYTдws I@ mW@ 1,1|flUwMzi{ݵvźXO2w]* yr.m1_Iӟsvp]]vN1p:!q/&I+ÞܮsgkwuYt&j7M]bϤ+oukw5k LAi1&]geۘ쯞•!N~c+WOBzY9o֜#olow.m(yp@1=lc[rn _ay%0Όs~ek51cW3]]vF]?9ˀ[=}~d)<>ž+.h¾A[IENDB`gnucomm/alltextpages.html100664 765 765 1452 7513704517 13754 0ustar rsbrsb

Bayonne and GNUComm - Rich Bodo





Bayonne and GNUComm


Rich Bodo



GNUComm Developer

gnucomm/apps1100664 765 765 2454 7513704517 11343 0ustar rsbrsbZMo6WUD}Y8Y$Ah,c@˴͖&U=w(;?+Rd@C|o3˂[4SL>Fnmo4adB}Muq%+Eg9RpNo{hbuƹ zY&s1GDrYτOdE 6kL޼£&bB[qsr@-@*(}M)w30kTQ`h>YUo&m^wg=/GEҔhXL*R0OI1t?$ 'sp\K ,T&)06e2\ k:(j75S%O9s&]&ygqMT˄Mù pfM."/L|J٥1e1u55/UQlGp4\WD1OMպ˵\NUZW!g.)Q"q9&Q©zB$ZWqh&sCn y̠8@n,xUr\\LǻhPе54K+ ={ȴc?9ʺXJXvZKj *w ߳x }Yr5eEؚe)VOq#[ziSK˩3$ʚ@yV+-9v!ZR9,a@u߫V FNmoAm?~4gnucomm/apps1.png100664 765 765 12240 7513704517 12140 0ustar rsbrsbPNG  IHDR9jsBITOXIDATxˎDq{4A-Hp  p&`$v$HlA!N:~o5>Ttݮ~杭]]PbIkW@)D>s㋫r{LWؚ>}l1 CFix̃/og9OWytFwZ<5r#7v[jNHm^vG>l ތ Su={ŝs!(w7CXc,}`=abҩ`0OO?SX\’6zJ<Ԥvj.\`yJdmve;ʕ׊?ng|Ul S38ss6%GA|8J§v)=9OX}S:np;yW֞ݍwK/ϛ #j䶅Ն~-8VV:U@ @V*Yt dЁ:U@ @V*Yt dЁ:U@ @V*Yt dЁ:U@ @V*Yt dЁjb:| (3{TD׳hnfKM*voJ \0 SYv;?S}Ɖ: ֞ٞmigVe41}o_srU"γmtVnW9:wb2[^Q=aq}fxO=?VYk[ĆNo;jW6]%OvyӭbVٓϬ+Դ]`"Wn_k BH8}uTX>*Kk`Or\ZšhᇷeSQ4&*?*Yt dЁ:U@ ~-x[;@q6£tipc+V]u/^lMJ_{%1BPjط˓kVvjT{m@SdF+|5ksy~;!xW6j}_洴؍Tn4|Ɛj;UrXZv?0mi]n/hpMU)3 {RA+c_QAhWU>3v1*=HGC/j2.GV^z|UF~={΋̵>n 'OԦ/^k<>9IGG\x>lT{/$P>Nׯ_/Y^y_3zWv8g+s7dUܹ/Y"Euqo OkFd;7:U@*#E>vU't g @9 VAXxV)o'}Cr.؊ږ0Rt<#,}^*yQF.8U`keW,~o[}F:P)SSX6\Ce\RnumeWʹN\+1JULod"lv,J R7/}JlQZ`rw]PIg@?*:Ѯ%\}teqx:3:v.0HԯU:w\YmwsB7s呭zIZ^6foEy@Ё:U@ @V[:UxP*Bt]܏%=Ro<~T1,P]h{rglSdđ3}Ie2HYA ZXrBMRgxKѮFw Sir|ӷV!o\nk镌r#7gs@VN)|]:h+i2*9OywnySK7i ״kWhA`|"jp"M}`@ _]]ݺukɪ~z]Yϗ#|U-6x* 1@ @V*Yt dЁ:U@ @V*Yt dЁ:U@ @V*Yt dЁ:U@ @V*Yt dЁUn9~ VC5[6-{;koxscUzHG:ϼԌ3;? ceujuY@᜖f49}5`̛s_ZRFpBpv5mK:h4'n2y"/8}=g'gypI,ܘݏC(#oDn>+4:hPX-L6+^xaϟ]@A܊ڵx?@Adu#hW{ڵpxo!k#uUz_]O>}1֧#$;EV!04i>`0)yo vlx-3b#]bյ6k$YVp_ôfDcgY 3^ȎA̔>NJGdu'6݀FP;V;+ΞgghReGk3cm vj5B:]Uo:EcM .N.>0U^]%飍%7Q}LYŚ;+I}`Ql*יT@Ё:U@WWTDVU3q>wޏ ؟QYg98RTng\{K08c)383A ]E^ `BVѶS=@9c^JCzh61~U6!{C}3>0ĕjo]o櫯Zָ@V*Yt dЁ:U@%ʃ[jщ3Ϊ;%{m} ğ :DN_4ѱ6[睵OcL&Mg1v>#c>OL\48uwߕ`QYK|}bG'~ Ԥ]ܥBuzL©h/UI?磏>2fi6c=|I }Q %6 |t[8:W£aa%gԴ4p*:_qE+8㕒،ܞg7h']ܞ˯8:u+S]0U2wZMS8;xӧ6Gnk^__g,;OPR}yW܁հSze\R:;vnoi8]>oqyjpW'9?W>](=oyW䭎T/O \4M_|o.8k[mu?:i͝^9I[[Px1{ [^obuZ2.Qqtj':U@ @V*Yt d!YˋU<.3~iz%gt:|EUb(x K'OZ{Kkq<{l%[Y~] *ںwZ߾}{U@V*Yt dЁ:U@ @V*Yt dЁ:U@ @V*Yt dЁn?=|/1wy TVͱwI$}<ĚgSm C^62B}k9_ +cog_q gr![-Ɖ ڧLXpJ<K)*2)Wx[)\3XW< @V* CIENDB`gnucomm/apps2100664 765 765 2310 7513704517 11333 0ustar rsbrsbZKo6WUD~,6A[hlҢ@ѱ}ޡďQȀA$f>Q~,HeD221rp\I FBmkķQB"V(O9m{sss>RI!DNIΦO#>0v>U:_lK6;M֒k6SMmel鱕,Q6l O ,.[ ;Se>JCNTp׻m{Vt%)̈FJ̿-$`!![@'}L dih:8<Q?2CP`+-좠f.B&Öy;~y&!d=l!%m 4N$}iDm|Z1x]'~D%lͦ.WFky))1;+1'ȁ^^ö|C+|93|y,cAimǒP`+'䶮ETf~pPە1 Ǯv~8xc=ΌtN<ԥg8㼸 #n_8A$ɶ#;ci]FMY"nIiҺe:g?[)6כ{Qi]Myi1(}v|/|8wBv$wUұF)9ZA%;mj4;Ԩ= G8t z,@=mA3jIL$Mx01-72*a˻P:] o]~E G8Wh+L/O]HѲ".:R&Nnpq 5/ۂ?8ݰ Lm{4!N3#K T.EPW+N;"Wg?!^-Ecz0gnucomm/apps2.png100664 765 765 14665 7513704517 12156 0ustar rsbrsbPNG  IHDRDdsBITOmIDATxv6q;M:Z-I:H'Ђlgl42ea}#EF Ekg:ىA@Sg8Sp85#a[rU$ƚ$-s/yiTwV@#GV7ey\LcЁxF`N.*-T|hdn}K};[Ͳ3 +RE>|duAiز<"͖rBZiil6-dZ@&t%f@ P` %f@ IzU}[' % -O3fnT/I/l=>ySc PE'GܺO%|ɡ3$`6.XW_B07mҫw}o4>m|x/seu3% ^d}vsn0zŋsoΙ#PVnˌ">|'Owz!"_|rwwIaVd: [$ONJ0s9:1n̘6'~ ӸnK WB0o<+E0oЇ/fd%3Oz[[zsCF"(&&;-s+A7P` %f@ P` %f@ P` %f@ P` %f@ P` %f@ P` %f@v_sss}}=gn쀲 櫫I|~~~yyT- *wzz˗,] (A0J̀3 (A0+}u|3 (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀3 (A0JJ-#%;뢾79}O <5|]QCUGdtyfr~Oj~xe5sFBR{q^:O[WA픰/ߘz8;;J5\1c9nǟ mvumH0b!쯜Göj.۟󍩄[TbUYclgĀq\j>L(OP[=6/[;a;ߵCTd*x;;wJXXi3Z N8Ծ=k! ZR{TY>==oQyu䯩 i: v/ \_Kev+̸mrs؂+K}*rO:a´}noo&ޖ^5<4"ze_(++sʢ (A0J̀3 (A0J̀3DC#/G[@Y믿K͛gϞ-;`>8???993O>v9s j7_zŋ9s|۷o(0@ P` 7wn (h6`߿_*'O,{ >}TgggR 2}_\\̙ׯ_?|0gifw34 J̀3X~Ή`F䟶4~tѢGn-3!>}zm3$N0Cꍫ8z55t}œ='G ܡJvqtѮm0NY=3-3^M-3ZtXo{{Ku46~uo ֲv*`0 (A0J̀i]1a>j^+FF]+-31:>e/IysFcs f8K@ \4)#a>s\huq&71$o[rꟴ9-ZA0"I0g89gn|.t9svsfHͲo='^C|uutels6]-"& >MD0c5NNN޽{t) (A0J̀&lqM!%f@ P` %f@ P`n]kNf5ů.cU{Ydw嚈HnYdq`#͂cR g2: vdύ"6 ːKeb/56hKn۹ vwch}=mՌ|{$KiutUs3~}o /- Ĕٹ~48???993O>v9s j7/_Ι߾};g@A J̀3 (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀3DExx}zwݜeWWWKXÇK~|bA~_ t鲠$ %f@ P` %f@ P` %f@ P` %f@ P` %f@ Y93 (A0J̀3 (A0J̀r?WmH@ Z}Y*2/KK厂h[n߿ϥ\_3ǟ~鯿3GT ' (A0J̀3 (A0J̀3ցȃp ypC5^o"XүqmTv>6^y ǷR2WWyx_vЮc nX0J>+aifmf:㋍w\uI'#")9+/>U]Ñ<;wBdق"9C1 WW⽞`>w1]ƞ4vEėY`a@4~1+[q[NM.#B 2*Y"b.7dzOvV}ɑlLvjGAY*]X RMm~ JJ0hczerrz9 2Ϝ}g.[~8"e8/^CSiW&e%1 -練4|co\^^`o,a~)~J$U?1bd{qiX If;H^9BBLm#@׆]*a .]=Ɯ9EʹA8 v1ޓg\GvVI3 r(yO\__^'g!~3Ga\0?G9#O(2fJz6Hj]eNj3G c3 (A0J̀3 (A0J̀3 (A0J̀3 (ق?<ׯsfVxb"`=~xwbq (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀3 (A0J̀,?s"l|Cs2ҺiQv[6K-TfkAn tkfIsqo0v!?7RK%.F<2d:u|Y׮hhӄø2֔*y[ȳ.C\W.s篍=zlWZ1r;+e>Hn MhYW,)Rmg /BmF0'r˽R=nDT٫e[YЅmRop><49}ot-@٦.=*NM:FR}/l$  C\O^=Pysa[rXYmZw0CX(֎nvD2ZX:}3A(A7Pb0+hP=sŜkj;$mYKlgz|HYhcJ&36:\&,Rb{f@@7;mjLw~fHxxp'KmR:"ُ^٣>b_SۚZɥ {ycYڙH'8]"7OHQR8&;ɘ<+aRMv!_<܅nv|dk Ss1J>\;tSE<`A?2iz*xf9/{HΛn1n-D adRU"Hؤ^ʹYJlٕv_F.H6ogB4^Ki$u#w.sE$0VGMXjc7ƈNppRÚ rO]X*Fpi'o;q"׬].tl_mU8y>Sk/1f(@C#D2Pbu9Μ/0(@ %xw[GhAYb}_˪~R.[, (Qe4;K 㙛IKEkohZSHx'rٝIrk,?:"5ٍv*򜌩scj.4+UN9XB~^.}VM:#Sv<!fr=Gp.̙znLK#c,b6^yy=U~E眳e2=Eέb,XɹYF%fWKԛkԩ0){חL(odMfjSm)zȡc0΁G| eu# 9>K^|]U7XiKcoi\2lb-n76w9v2ـ7*}ôRƺ̀3o)C (_ru>-4 }Δg|O gpkfoi)CTBe}{<|գ]ok􅳳 Ð95-;*p&Rx6wk2jioq=sEt*w͟:B9Ϟ[9: fw@]+8+ 5q3n46͜ߛo=̀t%f@ P` isoB <4򯥾7(]I)WSߘ4a|2(n6nysCH{0}'Wv S|driEYYkh mߜglenԉl|3xKOǔ*q|JS̭kJʜ-~5ܺ6ϹzI9nG[qg--Qto%eţE  <$Ϲ%5^1/Ʀ d0J s4dcV|Ocs!DͶ5 %+P`_D)e'ۜ }pR$'ӕFxlN9g,5=dͻϴnB-sV,6Ysx](dl>FvjP-X">'1.Ljn{_A%sθc)cl- .fcd>ѢБcg0$,֚k[۰EtJ 2J/Cn4!uiER\|pR5N4Y:O u՞Uo<RS/&}qLcgS%Tlw !-:?:KcQ6:fCr@@.5 TjI{C*Qql9%3$5d귪8a^`2_}b=c~4r tf)N.C<[jYq.S-{+}>yc}RcAunLyxv~ t 3 ~ɺ?ΜK%T쁮Anf=) al2gP)Kz\jR%OQ7I:2@t Qd4gS#>{2%P7?cwϤ8N,=6ba$L|M7e}A nHW*]t_+՝U(D;O"Yk&c]M t~ U C'#-ڰ,ý*xk&}M:7^ciRέeЋ/f͸}-~h~a`2V\-'g@|3{6ik~uUT(UmD4QjfuVrp &Ηehg #L[kov"hkw9kelM;_LaB~fJ!f+ņlQ,c0qhgS,D2%f: 4L?wwwk~|P+/⣏>;fk9>ŋS(_=e_~9e ￿[)SR`f /7o,e ,AYSy7je [n5`N@fVo+Wj>hf|GGGro=M^?+ft_,t]&68?CR2ͷЌ.'b9e?;ћ͔!XdҮ|f6XGyK:f,^7@x~sR384qcǵ#]SvBiigt5B<;bޯ49q}6K؏sUЌRm A4vϔwtk -)- I|5vd`YY%s9A;uhc_ 'CMuF,NJEM!r dgq[ffPfa{ u-i SļV!A p)ЁftqfsB7+vg@@3?ݞhAk3@&~c,[?@9H"B&؞, 71990Ȁ\^n΀/ ۬\{ҜM4@3:r~~>nl< L>|h&k*;Rʓ n22fsDNw޽{j[Qi>E,]'c0̖""_Tr'f0 9gll#v k`̌`D?l{&8AN<l# cz[`szL3ƀf KFl ggg===W_|h[vAwBVqepqqӂ֨z~găj͋yؐCic|zP;ɓ;w2Ew}W+g^њ`sD~ȏ~pppʕ2~w)wdڙ~Ν;;;;7n(hS/g Ȍ@۷srrrxx0*cbVE3: 4@jM\Lټ2PI5CX5)bjWݵ-&Ռ?nEҖo2Μsrr'jR^!1cw+KDJw=WؾG$^Qvܶ) ~Quwu.ՙiSٰ0M4%q9}{;~D}zlF YY6Ģ;[Ǘo2]*)ay_\oGm(Y0aVezEdy7m՟1TA.Ýl䂷N'w}:Vx?*fy?dޣQ v+ݑik S(/:DY6sxx|N$o-zM` q(SȈۨovU0%m&oV| "yK@3: dD B3:2nN XWqבE/ΔW懶sdq?#7%}DNJ~)q3 77TI-Δ($&ڙٓ^Yf/R)9*43{Ǒެ˜ g77AY"Lfӻ%/!6q&̞NH`,nͲ zZY^8!6mXvL޼tAIf`jf-n}󳳳Z^~VVkr>ZC6[ ׮]ۛ2ϟxb 4sqqa6gϞLo &˧~O#f==-e , 4@3: 4@3: 4@3: 4@3j &h3~]·-)ԢQPF5c٨>N9|INYި1%_/$|^kU,3f? Ojp S̙ܿ.dBʽ{όEL,0h& qD¦%bĬr2}6dahӀ L&iB'6C xG#36=`1*=#+48Lq xf##) ͷ5mkƠvf}94-B7'qĔ,͜߉d4Ȁ44ꛍF'fÙxm @LŸm0h@,;{螞nƦtaYfd;T%삭`I_s~_']N(ba-ۜ0N8vAK S21jxQԜS”5b7sZ 3c|/M7oc-NΫ3x]5P )gqށi{T-f0"#u`\wOm1R3Zʺm;0* FeUfYap*"GIENDB`gnucomm/bayonne100664 765 765 4351 7513704517 11750 0ustar rsbrsb]]s6}`3}HBBI:>ttۙeMl<o^ )iptA\J⇇e|uCWYpt=|.bx|uXd9J ZG$ pxx5pga(vSDN.m8:ϳM:g9,r[\ݩḺ||+xpPUp:8\suX ŸrA2qGaR$As;_bҸC']ݗ߷@;`=W0(`wvX-uۘ9$zrL%Lx r1P|VT!x;^TósV1|4r>NMմV(_ei__ulАuQ<_x =]`Ip)هGyyn5^5W:3.e٠яCDDyP$ē8V@D˛i“ W5Cpvztw"FlQ& >fٖMDu!"g=p+ tҴ<]>aY/6*g rm{0vZDH)T,c՘N@LeIXEYm6j6s گE^+aT CrxA?yX]6ʲ,SHt EW)yPN3 n"~e,E3+ͣ䰺&O`]sq\aO9#!cnZ= l+Ϯ.=άO4X2֜"yt:MRHtuB >aF 11ʩ D9 oү7z^{* r4J05moĸDV|l iƓF$װ8loaF7H' *lG cxHjh擦Idvj;<<➁S:[,T6J1tCj`yR;KlpgƃR{%N:NUd@eQ::i7Q:S7~?KVw`t]fmcu;7݄yotǨ&M׍Ԇ=z @*z'yUm9AEVN$s^;v7C;Qp.g`~%W 5o@:TWskipB$`Bb NsI}j@"PkB{o&t'rZiёl9Wod;_UؖV+:s 89KˊbAuv+7)SlHĄL_TRrB*yZU*yHZxYr?/ù}D fg (dTnFJrKؾm+՟c:#𹢚V_f=\SVNKvXqvL &9z 쪽['0;aUdgEOrrtpsW#-KPi"B>҄% y8$(O~UBLJF$nq>f2x%_KN/CB2@Q  (v\lȁM-Fu/؄6;ƹ)XX/<{g .^B̅B2@P )ZJ{ 7e/!},fbR$6bd&"f,h S%mOY cgTRg܇R>èN3: ?@ hV a}ylYfns;h@gn6)9:G)3 XDkFN1h@X0(ܗo~&[bt ~I$quIԸց~ׯLzZ"ĄeΈi) Tˁ 5Zrmr!X΍[)RLOƭ=sPW /ͫuVؗ]](;Bg,).~XR\o4 !Mvka@k$eŶ;GT':WƸe@}V|*roMG-Mv^Q `NFnS[cݰcނ ubϪH$UU@C1+W;Z^S|{Iqզ=whP*aɽ/):aK|3 c9aՈͧg;0*a_˔v-%X l1h|\T-b@(T* 2JFiVMn]#ji]9ñ ch2 zXL G/kJCNxһ]uze5,]T]/JmUGFǓt`X~r S=j[v9-]6|T_6m8w]͟*Q4Nλw#cakиOT&h":"XV}?uvJHrg1+.m$vL@%cհU X)oR;_˔|q8:3R:2 T}?tKyOp*F8Lk"DM*oB</ lғv4ZtyW *1Rd6%/_ȳɔ"1Okk>{%'ʸS9W71k5O$V c2uU=vQ5)ǶFĞR5Sm)Bjᙧ лF;`n#-7fk̆lXl_C\V1k&INZ8UWB >aja,S5T؊ba*AE[7 leS$6Xl* j1KgU-!:hLTQ-e eg=8]Yͫ6&bXMNIA E-P"4fmq {J*T5lث^L4g ŅUeb*icUUe66"vٷ__???M֦uNX&*ܙ]51I8tc>zMl"'H|Eq 8O o޻A]3U:G !:iUwj4.SdLOk켪>rGIךF~f}cϾ߷^6#<(]uc:Բ 3<g:}d{?#I^/ypt۔2ndfZx^.)g6=^̝351{m]J:<:X.ĝtujjey]gev2;eMLL "e8v;/AΌ қ93 cYf̭vo {- u0u|uL~*k"c=^-; iu#ؽ |#dB4yAˊɬeVa0,un:NȢ ΒZ':V?8ى<eo'0p_0gQdSw1"ODr[7]tvFlB\u¬\G @ IN"1̈{v&@YٓU"Sw ^sE:UNU+Ut:V%B+RcH+@᪒CX :6$L{q<#&#LHoA|?͚_|?MݍcPҐye%S>8b}fEe|㩙)^?4+'\6j_fMs 1ie=3 rǪJNf%AlkL"#w^E|` TvkiVsW{?nn0 _! Z:P=CIfRR[k]P믇ug6շ՛ &ņlkY$0fuJ*Klڲׯ] &qԔ i@F<'vn*D9;bB@YttkF&}fݫ\ۯ]j=s@p 6[jfW.:طK;f ?4.,f3;|}eڄ)q@tQSSF#x+煢哰r_GL`>6uǼ#ʔƢY-^1qo-cE\=LQP뭅+SbDӫN_UrԃڸZcX U'C (ѸdLoJhkYJ'H1x6͍azR#"fg{[֥8ZP0<(D7ͿXJ|.=.92l9JyY]r]t6[8(;hљgܷȱ:}icW$RNdK]4ׁݛu1Zdac^a'G{̣dfgDGlDp݃Nѹ&Ye3ʢǨR MUwus[7Go ³m+-[lϮ\O)&,o_18(OWΙAذr3x^1 9.üIv'].1Hۧoݸ[շ:Ҿm+:0LnlWbY L*ɊK PF}dvG'djDG[ ȌHBT&6010#3SZ|;ps0Iab;k[x 5΂x:8j8[w#Amyt)*cf> >/Kׯ0q1f\SXdFuu,==PPȂdz+ӨYmZFM s653l,r-u|PeC6cuyvu$@=Z˜k)(ФgN.o/tOq%L)eꪦ`Hy.YKkYEYrAr5gkwmvH*:߸-09ǭV ˘0?Yr;k?W/bu lͨU}zK5KyOCw7ǐ]q -f /]b"$lolL|9իOq|Mb^_6QK|VOUКۡ*U6 Zr_<:txuk$3ce]5@Jcb2p!dd1AńcIc녤"x۹1ucB ʨ"Rx6-`pl7kߋ0gkFe'88۟?N3?NpzY[bv,R8YXv𽵶[e[6mQ> Aoґui<=ZR\昭JRMc`A`1౴ndu?rB݊TuNr|syσj30%RqΫJ5ο^Z8L;y{$ҞGJ~⻚q8;sڱ}*uJ|͕dgsn8ڏȶ.ۋRKAYuqѺ3^D' @fe1LVS4XRfLN3w.oQ4#z,d^#_5&9nPrF̓mu,dN_[޵$cC0BQ$3811-{ ݜovm3 5᾵o$ cZ,n?-a9zf45;G4hl>K.caa%YJ9)7~s}?" "R_,M*^'D#l)]1W4lo ӅxU--<̈́UU zFçahW>+J"E(#RV"25E NCcIP-H@^x57FwR5pM`dUSVJ>b>; }++NCʷiZX).R3e׶-5Sr}66U{Ml1Y ꉷ]- ]cDr&fsO'^ bMam"CtS qc1oj|lB2VpX$VA`dGN u LWV@ݦ7epukuQ{lc@֫5oZ6OQ^cq^; RWbW] KT((&89krNZLj3FLVSB `u rBWȹVWtzO˟NdkQ`YyA1\:j9d鮚Os|5M[[q``Z 1=nMQJٵ2 ~<6`駱:zü\?73zew,SGw`hXnZE^:-}o=\v{s(Lu 5c˔Lkmu9 z$:t)S= JVK9Ƒߔjcge~[<.)66aL%n}+=쫣'Rzkڟ͔{gNJ#C8L 3ن@U2)Yd#Xp?߇}Jje3>pq-X *x,04Tܕ9Q:]:DIĞ q,BZj`j ~^8'6:dY3:Lu_|`l#XݥUU3=>G'v'Ftj8vϷrMQi±4e^wt)si21홈&0{Hzfbhg[QV&dMIL0zeidwevepZ&<˞~[]QL 1e0&ν,(8:UR*ڇ:DŽ*)6xJ)#[hd-CoR͋ZZo,=J7]+=G=Q7U}ߒf&ᣋf5F)zU`)&ÀtODi13m<\*}XplxKzgѝ&;MQW01[~_%NfXx{&M |&L) ^>p&(BCVxV%:zѤ>k'H],-e_:!Jj1=q'y%ReP>#%bZk,"}ypѕtLىJ)kefksZ\~<\m%H@V$Vi5!X@QO(ӏ٦Mۿlݻ;*ZvgPct"UBf{fKrzuعLfl k 9̔{eb*^L"Xĭs1b!= 6.:o=Ky|efSc(c2R_9KhCRdC+|VaDƳ`~~6nůͭ|︰O/^B1ukZvo^}.ݻa\06-[aluk=$fS$E:M'pKj\5e-F1'7|>nݰw.[ژڰu6l:Ӓ3)"g٦Mۿ  v~HJ1D𪻏P0ټ]_Cַxg#`~~6njo{a1tqHs~;SE[TƺG)n\';TuVVkDfHgqD:'9뫗?ͭr97oc8ů.lUwʢf=r'ZuZ%k0yeFp2w7䷓hucT}u5kkRއr2 SVq Ű'I1?V\"D&ZZ+VEzP)(JV,#A;?!nX=KX~DBmRv`}kXaS)mJdĭhأ5eVE v=l `tx*QP[ \0#L9؁OWآ6LOuIJ]9ug۪7*2xl؅zkklX,_iTzdfے@uX/`i4ۏir6_p;x/IA@h"+֮w2.^ J=PIffpc% T`45 @>{el0@nӆCTeh`CeG$_ڋ\:C'ކ(|@/r SÙޛՓ_f%\xVE7D6j䑶 ~v;"A\ꌞQC_~sK@I>7[wAG *%TD@!1 6"MkUc+\ jn=O jr_%]|7 ێ($]NxE* C4?è?f#~ΦNw !hY)}0HGSE%#x{o v l]lx ]a z!#bøFQJ8C A~.]H`1cb-{ k,{(S_2SQB2%od^!EA7х]&OKFb·ȘXfjcq| @w0\d@.h<;X!Ўџnm-^wư~BrFf5G}(ʠ!W !Ў۳&=mE8N@ϒqo%51O#.`toK1` 2 :ZcG$5B4@$61]zg Z^2t`0 -UkV KC׆p۸s&8K5zA?:آK!@_]|p"򺉤53?/oAHtO2AfqZ\ ;@怑`4G`cG4Fa/RhfLj|fUư\6Yf\3G\ΟSadž kTOdWVƊQB W@H&GFf3+ _CUl9DWWL9,<1~(HFj6R7̣Bَͯi< a8 g=(-Ae%R5Ue;GG;ƍX-tSxc XZZɰ.{,TUiWLpa*$j1M,"oC4mOAfW= 8%w k\@IB3>fZ)+ W::qU335IW="l/C c(ֱ7!(&'2cRPmŜ"w|8l%`굥uBxF:@Y <*o<@0 *B~K4| R%q ie뛳0:[%%(bFP{FVc@VJ`0`&G:N]P.+ƃ\k}<5S }C`gNaAEcwye!hmx 5PuWAdz7t~%> >ZT JA/\\3}a p׀[CA{B7t7F|nGWs nw=xERk%5 N)` SF$-.k?zʴnK^yw!s ҇N#sewrѥnZ138wDz"*v 2dPdߴkjQ"T >JX1E$R gԆ~qehnaq,kZ{C|rx4$zjdO[jX?KXPve#R>I+'u138Bh=o*~>/Mt7L,5#Fu4v._LB?^EUY(B{/@[̈,;#tM}C+rڡtB8}-TAu٢iqmVmU1,9L9;TJ@ Ƨ ܒI' ֆtO?!_?!_ @$I @ $ @ I@ IA H@  A$ @$IH  IH $ $H I$A @ ?o֤YDm:)p4aƴ'l6TAGa\CɈL$(fi΄JE.!:/-v5whx`"m҃t+(MF,լj%w2&0HEف eĂ>%[Pg4h_l h8)hIV[t24k +|U|Qh~dO=\8{tM8gE* b0Կ(-`|@ @˛;Gs{M7'!N6IAI~5NTz-  L-AvJW>*?A!fh3+YNBEq*+Ɛ Ŵk_bg쑑!P,k"<s4k\E@PKpl|8bW[`St c 'lb/\m+*e R*$EW.U #O|>E+ᵼ.zl`L wbА @#R(ڢQ+pS7le)gES92L8~&`hEiJBC= {tIGl\Hk# |f,_sNkwtա+ĻY@VF ɴH ?rsk^ wGCl$k9'š TR p͟m5 $\4lRӻ7P-P׏˜x JS*4*nJyzn^d5c1-66}VjWz dPi9+"Q6U3(CXQd!C#O qa3"StMap$4 kpXZiI4;f{@;6ΨD&[(`IKGeùkO!8[@3U c/eB Ƚi-ը,/(e𤢙[̈́{Qt6tdk@P#9bcULl, V}/d=M2(RFa;wˏAؕJnV;_{S!Ÿ0WÝa(8{i8׳!bP$I%Yp8ٷK}P10H!޾_Pl+zD ep{<!qTnêb,d$c0]5=˵Tmʞ-a|F֫|nY^]ҷWV֖ݹQmMLgQRA~_ |NQcma5\eIڝ6"m:Lk9%?G]MvXh+oMci7qdZcT0ݙr SSiKg2$kMoQNNɘ6ʕ-M ;$@]ۄU`}0I˞bQUa*t}\S :'kWyM;N^w[:ʴw>ٽTm$9 ]UH2d "@D$I.\*[j}Af?{}9V7n}AZ֭[s/zS@8M??KULmڴiȐ!ޔ. 0"̰nM(~Wte?7MNFce$MZGT8}ym̏ ]qh)_KM7?6w"'aiL\DN2@}'t_ǫ~ ,#^C_ӱeMޠe[b|ǵN D"AݛB5ʥKk6}Fh}$K=;ҥK ~.Ц{**ݿnk`:7)k͚5#FP>b2q:P d]IDq ɋro|>#>D&wD)3S*ft3rR+Id@5e5{9qA@hEՏEC`AtD$I,.~2INDwp# ίPzs-Z)_'S;۷o:tÝl޼y͖69r믿PI FuסN2}. 'sebihUU UͲWI5%jW P'Y!uySGž^~hDEewmUc\ֽv?!Np1IjTK+5ڧDeZ8dqe.duN۩'΃_HI6hgo<_vjMĤUc]#Ι友jcDwG^:9^كy@ɔ_<7(Zxm=i׎}*9\A q`* Th4jzUWn 6l@_g̘1r+ɒP\e`I<&z7)kҥޔ #^"0>oEV:gP@_;wܹs/E۳@'f[T^wTJNNdy/ZwwNidg[ޝl߿mذ<^^ N`d'ҔnngK̶GߤP0io7WF_M8yF% ȌHo D'jd8iK1HH\;fcW aad:谱ӝgˋۗf?%8Y Ήsu>%W0io8I#Yc)ɶs@H2d "@D 5}rF-۶m۶mߵ8In޼|qM_gڵxI $@H2d "@D$@sձ!I޺u֭[Od,ТE yD/ "@D$I $@H2d "@D$I $@H2d "@D$I $@H2d "@D$I $@H2d "@D$I $@n%9g\@T֒D)@b1G &nsX.+כTc!DgN\nYm){Z!)KFHz\[R_+|+mUTqJk?*Q>tɇ"Ty֢<#ڥ/ @XKbvNʥu-9JUPMMMuu5ڐoNGo)>v/k}liKKK_|EJ̞={ԩ!\̓Hn?rD1$=#_t˭!U$G*.e)gdoorC?v9s渱gSRnɺx, owkPfg$N+ʹ^FψA]}&B{7t^Kdܳj^ dxwcNW$#~3q$q2ۜ2hI+[$cFu2'PR[b({dFѤ_J^4\2 <=k/,S~gTƘKd0A?{'PUl_zqX.tu ,52a?4ll=$Lոč3݆ߓ5[Q1/tRՇT^ǃm2ƺwѨvM`Y5ҽbT WBK;m왾ruǫM Hzgm2Hx. hn]I $@H2d "@D$I $Y\+(3u'8$B;+ ɜRHX&s7]^joKjjj*++mDMM Idjoj̀cd޽V"I1Z[K mLIظe˖B۴icz\Xz!ɢz4^WWjժ 8qҡCǏ3ET\$6|MYYYii7|CѣǤI EE+$9lwoGtĉ Zr]wM<'HHa9>cz#R"mhڂ?x`IIɖ-[#H߾}^Inqq޽{ !\s͐!Co|w- .nZʕ+[n-))O !iii#G8qbN|#p6Y4/^뮻ӱc5k̟?ㄐK-[tjHMM@}QBH޽Z--[V__v/eB)..vizB;vlyy9!d'^J{V,=!|DѪ*+Ϙ1O>6lڵkĉ}i'O\RR}$~ѣG]ؽ{w4MII"$_Nr|߾{7666444444kʀ/dl2]`?oߞҴi8W8;@H2d "@Dkpd`6ߘkױ1dpEL3ՁRڥJ ]ya$P&OL' OQZ"݉S]dvUbOrV|OY$ d)ͩG< QѩuwRiIǷ\9C8N7\AhtlueڪMw+#҃F{'K e)?܆$/z4ϥKΞ=ۥK͛X%nLbYj\KP*8,;v$%%%''G+W\{NR$Y~w}'۫W+W[% Fđ_Rرc^^ށ|xIʺuyBHn뮪%Ko_ddD"+V?/((_zС &iyyy;v6l|E$Y4͚5۱c !?.\xԩM6=~ux=z9s7H6m:11qРAΗ_~9cƌΝ;=z ++k;wlllG^zĉ{/~cǎK./c ؇$ǝ&M=wݻg~,CW۶m'M磏>>|x_Wƍ?w$w߽zӧO/[;tRiimvw,]~W!Go߾Ǐoժէ~۱cg}?oWA$ZϞ=-ZTYYq|aڵwM7T\\|Y+:dЗ4xw}ѣӦMԩӑ#GL{n(H2ڵkaaW_}k׮lBץKiӦ?~ !H20jҤI߾}?VTTѣGee+r 7Zr-[{{e˖ݻw'"z_hp}7믏=:i瞻;jkkkjjزeKW |ƍW\Ղ]  |_~ʔ)Np̙Wh.\PooCy6wÇsrrDoJ5u\+;３Lͽzͣ3I$<Çݨ* vڥ sBBB{=UAy#5jȑҮ!zիWIa9rdeee,;|aaa--Mj{dɒZ^_ ɁRcXUUռyt"UVSLXx I:ž͛7g?ܬY!C۷o)$9˓!yyyR?SE۷o͚5"}woٲo)O<АK(++{/]Dƍ&##{Y NNHHرE7xcѢEG!1bݺus8555~.HMM4~w ~Z~/^jYW\ٹs>(]ѤIHw /_Da„A]s5.m$==]KUUUhrX]zo[~~~nĈG;wn֬YڵСٳϟ?MRg 5k֌;ZB /0w\ƕӧO#G,^x͚57|~aÆWSg@=55566޽{iiiaaKKK?ѣGO:uԨQҍ׹W Ɂ0|RJ/***((y˖-'OsmݺW_ݷoߜ9s͛OO0W^ F0|4mt|#k'`6 KIHHx'<3M4y뭷;sÆ }~J!r4*hG_voqӧ_{:t__TTtEkn"'NJmRmA}/ɓ'/_~-TVVt977/vaIVj}mAWrrrNNΡC{K|}ݻw/^RO8V(<#{=z={<#={\r%̪_䇟 #R{='Yul=&GK.;gΜ_999YYY3g<{&8_%嗲r EgiM>d]8Zn]PPp Ͽ]wݻuW;'7>U]jSzTW)(QYfCݿt~XccCVZ5LЮjU"h]T눜d?uʽ)l s=oɓ'{M_4Ɩ|sm9VCX|-;g嶷p.33ܿR)\@Z~UE[*W$CF]l\$9djkk%]TSSSYYI_e /ZQJ!JbYbĉsYYYYY}SΞ=ۍmA#LFAӎdܸqU]qr"另FOPJ Ae*MױT eՈ"P&ØPYp%+ӦMD$I3,%Y{bDoјd`*xέ:RU+(4]Gqil AtπS.1-%bM_T;oZATzر@$GۇGLK0. qtn1!slwصn_qɶ\.aeuWcTnKoտRJLwMo~[J_㶺;V;\|j-7z_UK2G+Ҝס~$ kҥ|xŋ[j֬Y3gtRnzzzff=8odyRuuuMM8W{<@7f̘J5kK/Wq%pcX1mr 2$q $ki97k͚5k֬bN3XucnM@̶b]fWETwe>#>|!W_uinM5ђ:R\+/UkoV wu m `m2G+$&4(]*qM"(mZ_1d3}qL]{%IvrejN.fxD IDATK5@|BD$ wH`3 Aq IWVVҼϟ?>}Bܟ $~ ---==yDNF?'-͝;O>{l/KI_]C\kM*Byo ^A6V-j]yD˗}D-RRR)+~2xȂ+VXBCtUژ1c)+~L4TX $/KRSSŒ_ oQUUF,1~l5ڮ/a999999,kΛ7dh?Dž.]kċ=oڣbb<DnW/_k]"')#ջ $@H2dn|mRk-F AtE ʚGܾSen7h2$N=z7ܴiSΝ?# Sv $Yp˖-[lߵ07sW^yAsΟ}Y׮]^ Wkvܮda1^5%qcnMvW^cLy~mBH۶mvڭ[ ;v4ڏV^͛4i cl݀$ kѣGf_ȥ5YL>=++_<^n_Z8dSK xN!/,q1d;~q/ݥ=WWWzN:DtԩSʕ忣Ѩ¡Խ8(3,S/\^3k9"_/ob~d(%Ӭ֍eI {s6̛uM^M! #eHtn/ H: X~\$AO`D@`F贈SQ^Kɧ6$;l=ħS%N2@h=C zs@j僔mh}a>RZ^b+B?yZڳn i$z.KujZ+w@ Auokr3@∭v:9??0"c\ nYM$re$diXFcFs|IE 2謁Dƕd˕m_)M?o6/ƃdEd˕Tz&{2ȾLeE *o~ nlwWS+&c4L4@{sXKg!e{cfF؅5lRR V?.a:NVԵ& S^U :m{2zB(Iva]${"ADd;N& T!>3ʥ5ڋvLuVw qDTd/@Iq5' ҽQy]́>L?Q7SJ!"@@H2d "@D$I $@H2d "@D$I $@H2dV$@IENDB`gnucomm/businessinfra100664 765 765 2254 7513704517 13170 0ustar rsbrsb[s6)4xNv:n#V%*8gvX{$B.stfJYo&󔑵$[\Ե:ﺻJEN GQ;2B!׺ rJ41ixBlQh8kkA(xj%RdB;][Wr_IN6A.g'7򡄂|}sSx5w:)D?ԕdu#}'Zv%DKK2-RKB^kkYjI2*+zH*:w4%K_ ;ͷ3vCXQ)q-?,Y3NKzeO(l"k ;.Vӹ{43RR}zQg pXMi­&<%2Ez'OY_SkJ@Aq@oc'|TNi.jK:8;^h{NE'mnҦ{9ܣSQu9Ob*~+Iiԅʞ+55x}yMpSF֫Пvx,L0h IQ-U%#-2U/3NjxvDw'`xV|Eki;= HgHlWbb t~`c@+Wx[<<*DH XRzG3#mܮWl?T a;f #]AGv$yp_Ǽ!I~hӰ>@ _¢^c]&+M2?*[5jD#]0`m$ة,Z#f vSZrM(ecn0#]a8FUL Vsa c7Ο^ qg6!=~/2)#F@ `Mmd*$utÎcaD"pgn"yC@Lf_3z,cDL\mΐ9 01+G dVgI!uXP"Ζޘ 9Ф,`[ܭ.Lo LۨP2gnucomm/businessinfra.png100664 765 765 12261 7513704517 13772 0ustar rsbrsbPNG  IHDRzBsBITOiIDATxݖ]gbն(LBE^ I1sA! >hwiv#2epNjٛ%ng .K0In=(_Y|_ (Y5pyA<ԭ_~mTՇ~>"ֻY{J$+iHƴћ|{G.|afZL\,QCF3iK2uIr@uXW^y1ŊY ?xFgpZ ~/5!xk驃Yw/U] f:X?~lf-upYP\%/ZX^:K`5B-Ǐ]" !dU!BEY/BȪBV*_U" !dU!BEY/BȪBV*_U" !dU!3 d*_?x?,cm437zތ:,BȜ+'I5ZusZZɔbTɩX𧪫lV-zrVUq]yuֳ'*jzԑPF[`[w40гa?bFκRv]%-u G/ejݎz1k-SG}q )8b^.G^ocܳlhxPhlnƼ-֢뚮ή8oe~ :5⻿ՙcqj·^j^)~RaZ%R k ԁ}[dY[ج~Mp};5;,,T:~xZb{X_.LqWvz&)K`%pˬ`.V9?/k]VBH1[3;֊<}W9uBUUP^,Dc4{&z3Z =ʅz$V T)hN`ꥷncS2J>zF-w7Яcʟ} @Y?Iyy]Wc%I&fKz]2Vjrjx(KP]PGt#zY%)O7R޷SȝA> UgGrQZ4L,Q9-F.Q ~m;G֣c匪m#%u8{ԗ(*{k}QXu8¢3)+WvUb(kN=z O?uMĦs~iۗ\1'۰JH}y?p!dU?BV* /!B2M]+*=b*.r$]|]`%a~=d+KJ{B"ũ[FڄgeFYƏU" !dU_5ofFdw*[B|EE^OyVgumM23rw 96Sj)ݳ~/Z&Y=;U46RYEp=]HrUns<5<~ʼؒo(-FN-mdD?f4YbBZ\\+Kؿz(lO6Vr˗Shsgt,0U0 FZh[̓nk8J3#[AkmP\@y"Jg^IɷY:% nV3_H}vc-uE:Ggƫ&tT} eɊ_5k v)z(M±ގm$>>{`UМc^1$L#Zgg ]B"l[GB~BV*_U濸xl9"0|6^вk#Hq}f-5_䖈&[s!1ױO+q !?sV!%nݽ.-jyӭR, kZotJm&g%}.h̞xh%][a,Oy@`l,~ɵ?U1cs<ݒ0bS*{)NsvS; 㔜YeUUyO/6ڏB l՜6WQu.Q}9[5XF_޲>vZS"C{jUU1WiqҗCY^wdrْ̞R+O]c-k̰bImzۭ L)]Zp,2Mǒ7a¼-[y1=~Ɨ~-".ʋamdЋBV#!dU!BEYWzBB@pvB*ÁǷs7* gBVg#!LH]f(O!߻Vh'el/$Q !mSjPzrm ߭Xo:,M?m$Ueox`X$͢r3yF_Egޘ{~?VL8$ = >6_pas~ ѼGʂ?'B.֯D^C{7;ɶ tV;cb |XIl44i~5=1~ZAgi@ 2Yy_ft psZE BV#!dU!BEY/BȪBV?snӪ`mV ual<|Lu"h"Bo@vTWuR XNAE'm\ɪ,w[:*Bq\\FR/uZjK?lpTZQ5J`gwYp#_+h폕N&V[o^l>Ұd\^E)?6_1w~܅krPX%TߩE6HyYdLc+^ Ilsv-O=v2C:G1iVx׭sS`8,IѪq~^#XX\؜Ǐ`R]Y@0R]hHDю@ ukp43FCRljCܤG5׫{#ֹՂ%p)+v>8?eܱ^C5۰Et|C+y" фӊG,SE|mb}NY:1$pwϡ(Y)LLf3YN᳤IDɸDGG@ S1q?cԁNXKyvU{Eldw-Ga1[DT/ =Up ^z>V%6P(|rz⒞NrRHT &\ĩ>g@tu~OOd'L~P~9-Vk7L$=KtpTi~j9K9q397N6\U+]]W[Pud@![9k_ D #/0kvA֊: ䷄\y6pNNJiOuXʪ[YznC$X+?UƁW^[Ch[UVD׃/4_G|,=gȚߕՀO?O$⣰V<|2T!Ffs8݈i1ϡn=䗪m/9 w&" UTC@`6ܱ Z!c@R7(mAӟ)@ݎ?X]A~!2 | *[FQ@ܻٮ4}[bSO¡|mP^|Q<<9{p;. 3Q߶pǡ:>/q~˥H/1 hPi "m+RUj!SCOU !v`LM$O;$&TZD_ yV݄8VZ Og'45>9 lAii7Jg'<=dZ R#g'ο>yf^,N**4|:k,@JްܪNW<{O*TūE 5wt2ȿ 9Zcr@FB r @PJ=:pcgkqj^R\v`乎s6Ő:pcgkqzoQHB-Yc0I6aĠ֚oFŰMb).di#=^y)oF91_\~{s/!Agnucomm/common.png100664 765 765 26165 7513704520 12411 0ustar rsbrsbPNG  IHDR msBITO IDATxyXwoB gS.AE kZOZZmV㺿ZjvV[^+b7(rnB8 "`1?fc$|^=wfA %&`0.Ntг(6،50uA UTebmu{]c|lfK9'kVr{ҎrSmߓ5cYsV{cNvj)&п=Q2}TCS.}hx{(Rck~4*]MID9Fªw鲵1_ ںRuO!A/l̴ұft1!ָ=P/tNsbm'v+dJaD~ItL}63ʻMnXA}`5ս#kܭ׽ئlLUtk"'X9>9r< x 'AN9r< x 'AN9r< x?'xѳgϺtvvz{{ٳ AEE%vd2 0 """999!!bYfϹ3Vww;wVo'44p5555*W_MNN~bcc!34ٳgYYY;w<{4x puuP.WUUK.UTT(z{{7JoٲСCɌL|.224@pK.]pѣGƌG:8>@gMMMS`СP(̙Do޽rA@Nt/)ZbEKKkxMȴ꫅/dfdܸq#b2_~L&$9;|0-[]DŋG)3f"{9zB}7tעA^^B(55ٳgtc|FZZѣGgϞo>k,??ܸq---W_}epD"Qssssss[[D"J9iWx 'T ✝޽Ow9Z%$$D"-ښPجI&YF>}CBB"###""^yڵ !駟ZsHBr`UWWדW-l444rꞸ{zzzzzx<6W#O^TVVښ';vѣ}.k`F=ҿaE3Xo:u5@p&PXYY>|{ܹNMM裏RRRLu֒ 'ZDGG[d}mjjB1 㠠@@Z***_sNrzСxczO#Xk"ΝKw!uuu׮]s5__zupp0B`,^9jĈcǎ]Jׯg!??j+U]]]bX,wvv;v477;;;]]w+**/\`zPNۋ&MoYe.sz_vݻ*Ml6y<׫W#FxzzR;y)S޽Bw9'O^|wQ`^2d/upgW\Z0*'{ٺu{ozꕔ4f̘q[PqcFFF] $77wƍGF̟?ҤIIII`R_SSSIIɠA.Lɓ' , b&O%J FݻB0ls͟?b-[l<Bde96l؀JHHعs;;Bbb1BH| eۓUVXN>r᚛B{ ɪUXtDaFo;ץ5p).]]];;;B̆1vPPNw9Tlo{RSSk!!mW~vJnԚCtR\[oYyH-{xx0ǏK$k1rVPόunnn| ݵ^N\\\/ϝ;Gw-&4o ^e^s!}"⥹}hcs ;׬y8p`ٳrteuQϞ=#Om߾Z #*lFV͛7+ǑTZZJwQzh"l跣*вS4eil$***?v#F(===wa?zOP#bї.]:sLll,A,*$*l} X,րGErAsϘ1cʔ)^m!o:u̙3c:tw<ܼyltmLB,! {W[[KwE=KCCüyobXׯ/--=+j rQ7o줻%##ÃLԩS޽KwQ&f9!|rBRRRoڪcyyy˖-olR?@xbHDwQ&c'^qF!1`ؗ^z)**wnnn\..;;;33S 6,]֑mVڱcL& ;zjzmmm;wLNN6!Ϙ-ZAQQQ`` Bitcw$[zzzzzT*----((sΣG?~ɓ.???oo~_|EAAߐgݻhѢ۷ϙ3_}5lGwP̙3-<ر|wk1i&w5wܓ'O:88]֦[|4aGg5kf|Bw9 lK,+++AN@^&tbkjj@?$%%!N>Mw!I("lvuB0((H"nݺnݺ!C[ÙDHw9|5Yd B(>>v{x⬬'ORR]]տ`imm%&j(?>$_z#G~7nܐH$)ʕ+ѣG[l9yAyy+B(11r !Bڵk_|+!>mڴ͛7u֑f3 2 ' شiSww7G.8!t9233.\c0cƌkמ={  ?sQL&sŊ6%!AN4DX,(<{wAyzzR,UUU;v9s_8qP(2\Lv׏3(v]fĉ˗/'_o94#˖-ggΜQDZEEEnnn^^۷ :;;UZ`X~~~}JD*WVV|Ld„ C5 rB o۶\/"x<ިQFe eff>|!y游8z%TUU] III;v1ccЭD'?K_xA/Ŋ7n۷{s1mze2YmmmCCCCCC}}}KK f'$$$888,,L<触… /^pbUp8 _ooo}9!D"P(,...---+++**z䉢OO)SL6mرM '[ZZZZZZQQAޜOחf;::(>>}T$Dmer8{ZZZRRʵE`rSjhh*B.x<8pA,HCbNf6Vr9r< x '}gKKQ i۶mz(\c _LwX;8r< x 'AN9rd2@ |)X}P#BBHQZf2}dYX:o˫`%7p<ȉ2}Ztuk]a >~icdLu^|@6{Z3ݚuVd9!.V  Yh\Rֲm{]3vFeݯҎ4&GcHiH=5lO:B9!GOy ǎrJ¡qwVhR5R^}s[40[ 0jlY>ٕLXշcꡞ Jn5~}G< x 'AN9r< )T9@MeZOY"@3@||9r< x 'AN9nll\b1Ltt%K 6;;{ǎGwtx .-Y$::ڰn׬YM[6ml`޽{&L0Gc_|ae/ZƲO:e:t(777\ɞWfSM%%%7n4?Ç7o]VVVVV=5kVJJIQ۷oW~ӦMŊ!!!GwK,0D[rꑻ|`L):}Irfkjjtω7$&&l CIrj ˍ+XK웎SX1k`H] %*BG)mj\MIOhj/^P,SoE&+kN(65dBȴ(ZFJ 篢Tx1{ڦŔQ)mSP{q2F*(IpmM'NަlvT$C}S 'NPBNGFO;֖Aw]y02rw3{8Em*{8zoRiXVBV(ƹt)E $3Ev)mVl^~2ʇFkJmG>* >TiŦ>7?6>bxiݪwnwzKZ]zG~nGrߊbi&LحMvLyݟ= r|ѾwR yck`(3M 3=z91ddd@l=䄡ƒC7:##ä32~iD(~Ow->ѥ[őxsֱ$_w{CNOUQ/gߥp?RY?9mAưji åh=vj7 qŤQYGTa9E zz=.+JcqʎMOXa@0` <vWض[90؞9r< x&~" -Z'''•ߓݙ%5kxyyW:z}0YNvaY҃7U& KGHKd2 0fX)RWWoooSfbr9?9Aw rާek_Fy}omL'/ * ,",։/=щ(lꦦzod;lU*j9ь\ˍրTCQg㫵W­T}IQJSbi=Qe UZb %r?K't ј+PyS9jR}muED" cP@Sh ANh\nt?7x} e?h|`{}m{bZ6@Ntb-xXw9r< x 'AN9r.\Uzn@A*R=bzfK=袺zڴiLHH8z(@}5kVcc#Eȉ9::2]|9sB炙91\.Baaatc7o ,YBw-rbUV!x DBw-FJIIAmٲZ뭵/66ƍO*2W^tcgZ?AHB ,DEEEtb 'zF]ɐW{Z[[.zANd2׬YAw-&Ҳi&Fw- r7#|~\\@ TVVƶd L?x~- dk֬hll|w.AN t-e˖EEE޽utt CCC LwQrb_~޽{+WJOOӧϊ+.]$.MLv̙˗{xx|MMMW.))4[@t Ю]H;v$''g=<|x !IDATHcV#a,kܹs˩S9r!믿>x~ :Ԭ2֭[=*,,,++;{D"!+?~|jjoiDommmAAA/].ZhѢE2~+,,>q™H__ߠ~xyyݛ=;Š% {FwZ=njjP2qÇ4hҤItvv۷ӧO =Douuu|>5uԩSsrrݻw+Wh;a*J2 LII  0a7ܿۍ7Fr#"" Occ@ hlllnnnmm}1gϞِd,  '''www׻wog_1bD"ya }gd,~[;]M_o6&c6p^@+Wtqq3fDw9z9spB˱v߿O޽{̙sU[o9rdCy,ȉS__ݻ7))sʕt ݻѣ|'Bp֭\.loluF |_|ONUwyg޽EEEW,I&ڵ+--Ã,,$$dݺumuF,87'N>|!&9tИaÆ7^cKJJSSNMLL}<==}||\\\\]]{f9A]]]bX"(N744477D">_[[Рx $HHH9sfBBBlllRRu,]]]+ ἰ6X/Qd2ɏr<;;Ç<+))1ꞛ[PPРAƌ?|p9|CCn9 'z#nO?7n:vd2_y hhh mmmbٳg%`'''f{L>;w;v !=2d}4QWWB8 iӦǏ]~8|pHHȶmRSS,X@wErb s…͛7?~xڴi_rֶzj7sLDm۶Ǐ;87p O?mmmݾ};斜aÆ2{Aqq_}UrJOO} Bwqe"1ӯ\}_~!Yf 2$>>>66X۷o斖8p|WIOOnb4gۗ}'O޽`>?444**T "$ KJJJJJJJJ=zDB$%%?~ԨQ/ 'z+//wssc2#F1bٲeR4???77n:t3Yy|xږ&H{x3AN `0.]Z\\NqD=ѣGⴝvqq߿?L=|s BAݿ͛UUUW:#stttttTagggwwD"immmoolllT 8p믿DGӛL3ꭳ388յHۯ=zH BӧOE"Qwwwww7WWW>>>!!!:p@wwr@~b]A k1 fX;ݵX5ȉmd27oLד!ɾ;xQ˱vݸq_~e׮]tW-[<8l(b#:u:7/2ĉs!n*J6q d~!33ʕ+A8::5j_˫|85D":AAA _sg<9r< x 'AN9r< x 'AN9ryCIENDB`gnucomm/examples/ 40775 765 765 0 7513704520 12102 5ustar rsbrsbgnucomm/examples/join.scr100644 765 765 320 7513704520 13620 0ustar rsbrsb# answer dial 5 set %source %id play agent start 1 join::client %source slog "WAITING for join" wait 60 exit ::client slog "JOIN request from %source on %id" dial 16503039451 join %source exit gnucomm/examples/vm.scr100644 765 765 1214 7513704520 13326 0ustar rsbrsb# # multi-user voicemail main script # answer slog "starting voicemail" set %extension ".ul" trace on clear %digits # clear digit buffer play y_vmwelcome # please leave a message at the tone sleep 2 set %msgname unset set %bname msg # base name of messages set %bdir /home/voicemail/ # base directory of messages libexec 10 nextrecord.pl %bdir %bname play vm_tone slog %msgname was set. record %msgname 120 "*#" # record the prompt file selected slog %msgname is still set ^1 goto voicemaillogin # they can hit 1 to login ^# ^* play vm_thanks_bye hangup ^! play vm_invalid goto voicemail # any other key is error gnucomm/examples/nextrecord.pl100755 765 765 6136 7513704520 14720 0ustar rsbrsb#!/usr/bin/perl # # Nextrecord.pl returns the next consecutively named file with base # bname in directory bdir (i.e. if vmail1.ul exists, return /msgs/vmail2) # Designed to work with the simple answering machine, YMMV. # Pass bdir ending in a / # # Copyright 2000 OST Corporation # # V1.0 3/31/00 - created - rsb # V1.1 10/1/00 - begin mods for bayonne - rsb use strict; use lib $ENV{'SERVER_LIBEXEC'}; use TGI; my($version) = "1.1"; my($debug_level) = 1; my(@file_list); my($directory); my($file_base); my($next); #$directory = "/home/ivrapp/msgs/"; #$file_base = "vmsg"; $directory = $TGI::QUERY{bdir}; $file_base = $TGI::QUERY{bname}; if ($debug_level != 0) { TGI::set("val2", $directory); TGI::set("val3", $file_base); } @file_list = voice_files($directory); $next = $directory . next_file($file_base, @file_list); TGI::set("msgname", $next); ############################################################################### # voice_files - return names of potential voice files in a directory ############################################################################### sub voice_files { # save the full name and print the immediate directory name my($full_dir) = $_[0]; my($stripped_dir) = ($_[0] =~ /(\w+)$/); #print $full_dir; if (!opendir (DIR, "$_[0]") ) { no_such_dir($_[0]); return 0; } my(@allfiles) = readdir DIR; my($j) = 0; my($filename); my(@goodfiles); foreach $filename ( @allfiles ) { # skip files starting with a dot or ending in ~ next if ($filename =~ /^\./); next if ($filename =~ /~$/); # also skip special files stat($filename); next if -d $filename; #save the rest, stripping .ul, .au, .wav, .ra, or .mp3 ($goodfiles[$j]) = ($filename =~ /(.+)(\.ul$|\.au$|\.wav$|\.ra$|\.mp3$)/); $j++; } closedir DIR; #print @goodfiles; return @goodfiles; } ############################################################################### # next_file - return a name with basename of first arg, and an # appended numerical extension one higher than any name in second arg. ############################################################################### sub next_file { my($highest) = 0; my($next); my($base); my(@unsorted); ($base, @unsorted) = @_; #print "\n next_file base $base unsorted @unsorted\n"; foreach $next (@unsorted) { if ($next =~ /^$base/) { #print "\n$next has $base"; if (($next cmp $highest) >= 0) { # bugbug ...lock file... $highest = $next; #print "\n$highest is highest"; } } } ($next) = ($highest =~ /(\d+$)/); #print "\nthe number part of highest $next"; $highest = $next + 1; $next = $base.$highest; #print "\n next file is : $next\n"; return $next; } ############################################################################### # no_such_dir - if the directory read fails ############################################################################### sub no_such_dir { #print "\nSORRY, $_[0] NOT AVAILABLE"; } ######################################################################### #EOF gnucomm/examples/useraction.pl100755 765 765 6733 7513704520 14722 0ustar rsbrsb#!/usr/bin/perl # useraction.pl - Parses the values from userform.pl and adds to db # # Copyright 2000, 2001 OST Corporation - Released under the GPL V2.0 # See the file COPYING included with this file for license info # If you did not receive a file named COPYING with this program, # you can find a copy of the GPL V2.0 by e-mailing rsb@ostel.com, # or visiting http://www.fsf.org/copyleft/gpl.html#SEC1 use CGI ':standard'; use File::LockDir; use SDBM_File; use DB_File; # yeah, we need this print header; print start_html('User Info'); if (param()) { print "Thank you for your interest in Dialogic and Linux!", p, "A Dialogic representative will be contacting you as soon as possible.", p, "The agent will be provided with the following information:", p, "Your name is: ",em(param('name')), p, "Your Daytime Phone Number is: ",em(param('dayphone')), p, "Your e-mail address: ",em(param('email')), p, "The SDK's you have used: ",em(join(", ",param('sdksused'))), p, "Your question is: ",em(param('question')), hr; # Add the ticket to the database my($return); my($name)=param('name'); my($dayphone)=param('dayphone'); my($email)=param('email'); my($sdksused)=param('sdksused'); my($question)=param('question'); # not even bothering with session ids for the demo, very kludgy my($sid) = customerid(); # using the customer id counter for ticket numbers, like I said, very kludgy $return = tie(%hash, 'SDBM_File', '/home/customer/dbases/tickets', O_RDWR, 0666); #print "tickets tie return $return.\n"; undef($return); $hash{$sid} = join(":", $name, $dayphone, $email, $sdksused, $question); untie %hash; print p; # Assign an agent to the ticket my ($agentname, $activeticket); $agentname = "Demonstrator"; $activeticket = $sid; $return = tie(%hash, 'SDBM_File', '/home/customer/dbases/agents', O_RDWR, 0666); #print "agents tie return $return.\n"; undef($return); $hash{$agentname} = $activeticket; untie %hash; print p; # Run the bayonne fifo command #$return=`bayctrl start 2 join`; # Provide a link to more information print "Click here for information about the demo."; print p; } print end_html; ############################################################## # customerid # # one way to generate unique customer ids for ivr apps. # randomization may be faster, but the count is semi-useful info and # gauranteed unique unless your countfile gets blown away. # sub customerid{ return count_file_increment('cid',1); } ############################################################## # count_file_increment # # crank up the count of ivrapp countfile $_[0] by $_[1] # sub count_file_increment { my($count); my($increment) = $_[1]; my($countfile) = '/home/customer/counters/' . $_[0]; my($countlock) = $countfile . 'lck'; unless (nflock($countlock, 2)) { print "couldn't lock $countlock in 2 seconds.\n"; } unless (open(CFILE, "<$countfile")) { print "couldn't open <$countfile and I had the lock!.\n"; } $count = ; if (!$count) { print "couldn't read from $countfile.\n"; } $count++; unless (open(CFILE, ">$countfile")) { print "couldn't open >$countfile and I had the lock!.\n"; } unless (print CFILE $count) { print "couldn't write to $countfile"; } nunflock($countlock); close(CFILE); return $count; } gnucomm/examples/userform.pl100755 765 765 2136 7513704520 14401 0ustar rsbrsb#!/usr/bin/perl # userform.pl - Just returns an html form for the user to fill out # Copyright 2000, 2001 OST Coporation - Released under the GPL V2.0 # See the file COPYING included with this file for license info # If you did not receive a file named COPYING with this program, # you can find a copy of the GPL V2.0 by e-mailing rsb@ostel.com, # or visiting http://www.fsf.org/copyleft/gpl.html#SEC1 use CGI ':standard'; print start_form( "POST", "../../cgi-bin/useraction.pl" ), "Your Name: ",textfield('name'), p, "Your Daytime Telephone Number: ",textfield('dayphone'), p, "Your e-mail address: ",textfield('email'), p, "Which Dialogic SDK's have you used? ", p, checkbox_group(-name=>'sdksused', -values=>['GNU/Linux ','OtherUNIX ','Other '], -defaults=>['GNU/Linux ']), p, "What is your Linux question? ", textfield('question'), p, submit, end_form, hr; if (param()) { print "Your name is: ",em(param('name')), p, "The keywords are: ",em(join(", ",param('words'))), p, "Your favorite color is: ",em(param('color')), hr; } gnucomm/examples/template.pl100755 765 765 2663 7513704520 14357 0ustar rsbrsb#!/usr/bin/perl -w use TGI; use DBI; use strict; use vars qw($err $dbh); use DBD::Pg; use sigtrap qw(die normal-signals); # grep for atexit in perlfaq8(1) for why if (defined $ENV{'SERVER_LIBEXEC'}) { use lib $ENV{'SERVER_LIBEXEC'}; } END { if(defined $dbh) { $dbh->disconnect(); } } sub error { my $error = shift; TGI::set(return => '-1'); if(defined $error) { TGI::set(tgierror => $error); } else { TGI::set(tgierror => '0'); } exit 0; } # This is how to get variables from the caller. # my $foo = $TGI::QUERY{'foo'}; my $dbh = DBI->connect('dbi:Pg:dbname=cci', "postgres", ""); if(! $dbh) { error "Cannot connect: $DBI::errstr"; } # This could arguably be prepare() because this script is only # supposed to be called once. However, I'll wager that I'll find this # as boilerplate in dozens of other TGIs in the near future which may # need to be reentrant, so... my $sth = $dbh->prepare_cached('SELECT * FROM transactions'); if(! defined $sth) { error "Cannot prepare SQL statement: " . $dbh->errstr; } $err = $sth->execute(); if(! defined $err) { # returns undef if error error "Cannot execute statement: ". $dbh->errstr; } my $dataref = $sth->fetchall_arrayref(); # Do stuff here... $dbh->disconnect; # This how to return stuff. You must return a value or bayonne will segfault. # Note that set is a function and QUERY is a hash. # TGI::set(return => '0'); # TGI::set(return, "$var"); exit 0; gnucomm/examples/tgisetdbval.pl100755 765 765 2220 7513704520 15041 0ustar rsbrsb#!/usr/bin/perl # # Adds the give key-value pair to the given database. # This is useful for a simple key-value pair data store for a tgi app. # Returns 0 on success, -1 on error. # # V1.1 4/24/00 - created - rsb # #use strict; use lib $ENV{'SERVER_LIBEXEC'}; use TGI; use POSIX; use SDBM_File; my($version) = "1.1"; my($debug_level) = 0; my($value); my($return); $database = $TGI::QUERY{dbase}; $key = $TGI::QUERY{key}; $value = $TGI::query{value}; $return = setval($key, $value, $dbase); TGI::set("return", $return); ############################################################################### # setval - sets key $_[0] and value $_[1] in the database $_[2], # and returns 0 if o.k., 1 if the value already exists, and -1 on other error. ############################################################################### sub setval { my($database) = $_[2]; my($value) = $_[1]; my($key) = $_[0]; my(%hash); my($retval); tie(%hash, SDBM_File, $database, O_RDWR, 0666); if (exists($hash{$key})) { $value = $hash{$key}; $retval = 0; } else { $retval = -1; } untie %hash; return $retval; } #EOF gnucomm/examples/bayonne-mrtg.pl100755 765 765 1111 7513704520 15131 0ustar rsbrsb#!/usr/bin/perl -w use strict; use vars qw($line $used); sub usage { die "Usage: bayonne-mrtg.pl\n"; } #if(! defined $ARGV[0]) { # usage; #} my @in = `bayonne_status`; foreach(@in) { if($_ =~ /127.0.0.1/) { $line = $_; last; } } my @cols = split / +/, $line; chomp $cols[3]; #print $cols[3] . "\n"; my @chnls = split //, $cols[3]; $used = 0; foreach(@chnls) { if($_ !~ /-/) { $used++; } } print "$used\n"; print "0\n"; print `hostname`; print `uptime`; # I see the following states when I watch a call go through: # r ring? # p ? # i idle? # - clear? gnucomm/examples/playrec.scr100644 765 765 5112 7513704520 14344 0ustar rsbrsb# Copyright (C) 2000-2001 Open Source Telecom Corporation. # # This file is free software; as a special exception the author gives # unlimited permission to copy and/or distribute it, with or without # modifications, as long as this notice is preserved. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # # Play and record main menu answer clear %session.digits # clear digit buffer play *::47 # "press 1 to play or 2 to record..." sleep 60 # wait up to 60 seconds ^1 goto ::play # if pressed 1, goto play ^2 goto ::record # if pressed 2, goto record ^star goto admin::main # if * go back to the main admin menu ^dtmf # any other dtmf digit... play *::23 # "Invalid entry, please try again." goto playrec # repeat menu ::play # Play a selected prompt message clear %session.digits play *::48 # "Enter the 2 digit ... followed by the pound key." sleep 60 # wait up to 60 seconds for first keystroke goto playrec # if none, go back to main menu # timeout or non-digit entry is invalid ^A ^B ^C ^D ^pound ^star goto playrec ^timeout play *::23 # "Invalid entry, please try again." goto playrec # restart menu ^dtmf collect 3 5 "#" "*ABCD" # collect all 3 digits, ignore non-digit set %var1 /usr/local/share/SEX/aaprompts/ %session.digits .au # build name of audio prompt file goto ::reallyplay ::reallyplay play %var1 # play the prompt file selected slog "annotation %audio.annotation" # show annotation slog "played %audio.played samples" # show play result goto playrec # go back to main menu ^dtmf goto playrec ^error # in case the prompt is not found play *::55 # "That prompt number was not found." goto ::play ::record # Record a selected prompt message clear %session.digits play *::49 # "Enter the 2 digit ... followed by the pound key." sleep 60 # wait up to 60 seconds for first keystroke goto playrec # if none, go back to main menu # timeout or non-digit entry is invalid ^A ^B ^C ^D ^pound ^star goto playrec ^timeout play *::23 # "Invalid entry, please try again." goto playrec # restart menu ^dtmf collect 3 5 "#" "*ABCD" # collect all 3 digits, ignore non-digit set %var1 /usr/local/share/SEX/aaprompts/ %session.digits .au # build name of audio prompt file set %audio.annotation "playrec generated prompt" sleep 2 tone beep record %var1 120 "*#" # record the prompt file selected slog "recorded %audio.recorded samples" # bytes recorded goto playrec # go back to main menu gnucomm/gnu-head.png100664 765 765 14345 7513704520 12606 0ustar rsbrsbPNG  IHDR$ugAMA1_ PLTE""" ,IDATx]v8 ?K4J,:%9+Q#ePH?@U_ à_s o ue"> {c ` $t@xt9(؃bտBaͥVo%-W"׶,[oܽlřEܑe Pw=QBL(0@hP>ЂHb-AG@%`UJ- fP4EܒX~ՠ=DO)"" IfwEQ[{R;e}?ث6\m썝 [m$* "2Lv"./u/!EK+򵹬eϺş_ګs_&AQ;Nj!/+R$e,~*ڲBIm"+~@&G.(7l2O/ai^BQqLA b¾i-*#`@/`^ˁl#G*%ʛh7gXIàģ lB`pP忂IYy9*l p\t" kZzR,hIn1q0P!N [bukP _6;RY úKq%Pfbpœ[Y"rmz >ŴP KpQWTݡl)]~3Hw /Bk#hVVԻ'r_/R lyPUARV7SdfC=|n&ٴ̰ӂ |8(w1)VixE9"X/\(ZCZrBFW(@)"WCMAM2Q ,x4r=K֨L|7i%uqnFxSooZ{=U$o*kl׉7GQ \;ΛӣYiڿ >ZPv4ʰ+D VURPܣPccJu I*NӢ3mrz7xGڰ)M#Z۱AC&-bp"TF:EInusJE,P=}MTMb%a[ v耐:PY%hr3R˂/ԙ] b SkCBAY/X5 ͆q{*<,CRKɉWUNl_i>ETvN5Tɥ* :(K &xGw{Ջd30L0cr!fS޽ a|T먂PcěoA^>+no^G7 t[H{6cf*`݈a? \8:K_nYY} buH='<%:i/F>v O06@47On]gƅh٤g9iU&sHU"*2ᴤT&7a9Aѹjn6>['f NQRcCNN\h#B%PlO;@')WŲ"52/9P3 W||yd!9gm@0 䁰l0=z5L<V}%I22oz{eB(˄?* 'L !Vt6UOx#C[`]8 .PAɯ XJS(!m瀲ET~ 5{8x0ǁHB1PJJK3nxnCPԥB|p?&A9ڕu(ҿᎳ%^ < J`BU;Dz'61YW"vCL#{>RL]ZGd͋ޤOCa@-"W3LhɸO5>Twt(-;GQAĨd3@ɱOgWJʲdsZƃ7IJ)ښ硽 m)OOp] *K^(>@4BKeTpVFe.1C,oCky5(>6PԳ',PF&tg3-Ppw ?+ ςBbwdY:/F? 'Fa`/(>T&V5'nR*tK% E O@4/PA8#Af$=w |SC{c&d]]^ V1KN+Tģ:]tUSlh\N{u(x;`;`׶rBSh8;M2V,'>{C>yR 3޾k`-9U0A`kVb(+ QTp:HQ-yM)EZ "c/i陋:Tz'G[;So w ?ڼ2Yek=]ca}C̟JjZ`lܠcrL%51gpNPhެz|v-(aQwL !.LT@7AIMm3AI ߸{.2=.VPCc$>dε݂ }r~L3X_)> A>䰌T3dQcN郷#҇d@Sn7t65~AQeeNi\J1p4k6!yʵa}G\8ԁV4g01=YN> TsZ+HB*s_m$ >la9VLׁ@U˼T$s1b $ +~(ӄDGYAdk[i w29z|b?}IA5?+AJx}6X} j J.O8sF}+(Ε@Qi#]_d4բ%pQmr Cf"I;g)u~\1wؠtnP}l B# Ms@?K%Ko=٣Rx OGIr8 x"(Vg^hRG؀REGd޾wRe, 6JP'Tra`x/PRJ6IENDB`gnucomm/gnucomm.png100444 765 765 74417 7513704520 12565 0ustar rsbrsbPNG  IHDR`dsBITO IDATxw\G玎T QDc5j$5XXhbL4QT^}cW"Xc,ލ (J Aul/w|<ϳs{33l6#ǨG65F_VmNAʃ2@\ | z[8GXUx|-FRY?RSK1z*fC˳-Nפ3ks-dyJ+NfV!{ N#ŝ,*Ah =)e&;⼞yi3_ ʵ%,/ 9H1  %uV!}SFKa?V{!?z[}Έ'2z,q$Zk A*lr?\eҡ&71ޅX<%#SKôd7'dႬK2s2z1;2q5A51FfmjxT- ULNkVagG/8H:tCeNd<_>Pb>7>I"mOsؖgĿ'%b+:*)aW,jBdG!gWTnj` Qx~a@ޅ|8p|7 g4fyے+W؄~ 3S2^o*+Dh[A}GGGjժѣC[ ~(?NKK駟222؞uz9~A9:Np; `69tח Fc֭;t_UUUYYwĉ+WwWWX{(A#iii׮]C =z3w߭VÇ׬Yw]z!ԢEŋwMm$}qڵ/G~qӦMݵk~Mc4bO,+++++;Ueeee +//QƷ~;bB*++foqF///%jm퓚jV֭[#Fرc HۻwoZB]ty\F Hnnnnnn^,Aii'OTVz^z]t) `͚5(7짟~m. q*ziPP˗[n~#AwQZe˖}2J#bX֋&+DMzj@@#G<==e~~{ܹ/adWdrrrLL| \Y4a3˗/W;[˖-9rqzQ~}9UXօ,-222%%E{EM4Ik+8/njӵkWE}6lؼyshhhZZTC 8iӦ-X@QVB)[nݻwwRR RSS?3W^*hT[[ jO:Uk+4`ɩZ[ҥKBfVA݋/>a„ .8;;TQ`+ RXXsNGG>@5SNmѢŵk.\R) DۛRJ?xc)UE,:x-TlWTTK:8;;3LUp"1 D{7[)q=KҊ?zht]NVPomf;S+NYz5Bhȑ*ݻ۷ۧj)moGz)b[ް^i`9rSY`=z4BhŊ*p 9 NW^>bh 슓'O":u2QF M6]FAj ![MI5 ;Le39Zt`&u3AL[U6y8q!ƍ륥7n<SR00b mEi.ڹ2SEC$wj96VO."ؾtJ[F֎%ʀz?x!UUU9997 Fh4 ''m۪@R$~QROC!>xvB[CD6Ioɂ$BA;woRTTtȑ'N?~<77ݻEEE55kּy-[8W_h T3,JXyVT/|oб )~Tij庵177]V6ԫWq9'O;w.##ĉ999h4իWl6q޽۷o_zի7oNHHhҤɈ#޲eKyHӇA$C%"A4}$F?Ή ͔3x#c+NaPF!_&/7n ^z% m 3:_~e֭GwssԩӫبQM֨QQxee˗]vԜٳgϞ={Ĉ-]\gR<7Am烔ex 8n&qn[c rjEII Bh2NRs?Z+N;t蠂ѣGwҥ[n;w3f̊+, ' ȅ֗qnfɓ]\\6m:nܸի= `ǎoƪU|||ϟ/ZxVfMN ;HƜ ie pz)3fxz1`رƍ`޽{ݛ[2dXXXXX씗߿ɩN:dCI1mG83G# 9sfTTTppVX#'eeeeeeusssssS_RZZwww>ܹsl6׫Wё>,Kv-{KL8qѢE۷o0` dܹ={_^4Lϛ7oڴi[%*T{xxI/…+ 3RSV=L?w\Ν;w̙뵠*fWHOT$~|g;wܦMDlLNNQT#QQQ%5kVDD:"""̙.6[DGG6?}t){CF)%QNpuu6mɓ׭[;I`?}Dut(Wk]ĵ6뜳g^pݻ{A%υ162y(UAGFGGũ ō+'%ĬYرc]T!A+r\W)qG6t ,ޚSRR[o9sgŊĪT@4 )k$ŭWs***'O}|ZۂQk񝄃,.. .KѪLTKpBZZҥK_lUTWWW'''OTTT8;;lR$$$̞=[t9sH6yΜ9fݞ&җè5qbܹf>_ֶ >kLxzz{{{lRGio!1bFmcbb͛'mttttt "A.""".\(UJJʔ)SG榧;;;;OgAw24u5kVDD넄55ZOLL6..NIIIaaaR$F},YDi>헗+WLÇo#h}+irN"(FHA"3"=;ȤXqmE| ` ء>}M`55a<#©S8 6 !CDV#4Ǧ$]:!3gTS3xrrr.\PF7xCk[lt3f̐8"(Xj۷!Էo_An@&h$CVVO!%͚5^rYP6ĖGjЯ_,ƢdxVVVӦMKYΝ;zW6Ė}6BaÆZ@_Nի6mhm-[_\~]Q{d=K`2 s+9r!]vmd4Uj)tbȨTwϟG5o\P+ 4ãDimȶ$2%9]Ν; j$ 0&&T+erdl֭[ j$zHVVVyy9[CA~TI&R y>|\#QGezAPǎF BBB㄄`^~_.3䍐<<}ZY)XSP)Mee%߸qD4/ӑS;"N:%LP^^d|iGz[G^md|NZjUvvvm%F 3A* .I?,bHA&??=**Jܛj8H{{f/++{& (I%nL%h֊./4RdLK/TZ7oԪUKF\PPЧOÇ$$$ު!zg۽;ho!qGkނȢ#DGGϟ?_( ,X0uTڭ )"2Q:ڵ;|ӧ#B)@l6ҥKEij8H%@%5j2${ٳgk\(III҅Ɗh\fMqJ%Gr v,J:>|ɓ SQQ1jԨt77͛7ׯ__(5dRR;$ ;wܹsE4*22Rqsssss(D=JE^v-NBXXؼyD;m4E0mڴ QBBϞ=SSS#""e%U0L۶mx񢛛޽{v*EMĠJ}o!`|_g͚5wpmE9s"1cf^@F233?۲IƥeLOHHŋO<٩S''fܾ}_F 4hȐ!۷/((XhB͛7_n]۶m%RAD#n`̙f\D#K`BQbA@yȑ)))K.l6-[lٲe_|qɟ~t]HЬY3ݻw ֭'|`wwwqB^UDL-> >y#XF\\\/_>h PÆ KJJ֭[F __߱c8HŽ;Np°-Y ЪUΝ;?~|ӦM#G!e#bZsD>™1y̙MYnR;_~wF1++3TsO>A%&&VUU)Hw)KҹsQFL&ԁ|˗-Z$]K)Ej9==VZ;wp}ɒ%7nmnYsK a47L 6\fhS(;A`Mdee1ˆ-y뭷Fv?|׮]B3 @W9(~J>{)))cƌ9y򤓓D;) eYp]v޽`P 4GʕNs-[?>))I4 p,1x{oڴiO>#333 @a e %ƥ|ٳg-[Q8H_UkTw;nܸR|-[ :HO>Ic#]!I/etAAA~ŋǎ{QFQE::1cƬ\1>>>88ŋ:&Mzw>|xa3 Fl4b*R}dl* ֭[رc۷og#pzdĈ鎎{m۶WZu˗/]vo4h*..dpww'ҚJLl Đq  tiӦnذa/S֭ӧO;vsȾ$BO?>rȡC @ԪUk޼y3g0`K/Pv#F?9sLNYĭ`<<<&Ld "aKl4jȥ=B X'&N`;w?^^WHHHHHH @YJKK>@3驅9:O?]parr5k  ,tWh[hm`ShѢ͛75̂QGkΚ5k֬YGDD(WQ㵶B%=>yDv{:uꐏY啟QZB,ϑ2*tHre"1Tʎo```FF޽{(QdRRRRRV#:h^o!:v>}6Ǻ៎}+fQ;D"]n-EB[le)jvETTTTT3g΄g& ֭=(N}uѿYf۷O(:3f̘1CDh|f&lA9GFS> lٲ[nnnQQQ$8:D6ȶk#>Y]*ppphժlpDQ RQQQRRB9XTT2͘...ժUS8P')_~ԩS.]޽9 GXTTTpȑA IDATVR.eAg"-whdF~BrA`k8;;{xxtZ^W~2BtHiiD9 5 ?\jѣGi7n|ƍM@|m۶]dɠAdQf͚ׯ7o|ذaQ'ʋ]y 9sOO@\\l.}=ˏx٪k BBB^z?sÆ ryY'~{7.^'رw7n\JJ @U4A6 BR6Eo].y9*,Alllll,Ž A_~%^;F)Sƍ5h -D^ l۶o ,Zo߾TLÇuiȑ2AfZi4DFFw.<"%aD޴VΟ??+++&&fܹZB=srr'~3 'Nٳ/_[oϛ7m۶B$$$ر{2ds 65'!4s̙3g@'C}!9@vl &TTT0ΰ\[n;t蠵Eh֭UUUAAAlӢmڴ9}~;gΜ={o~ 4">>>::h4YFzU2a V刈RNd.:|SͧduBK Sx\`-_ly>sMSΝ;OeGG˗'%%q> :4**l6'%%GFˑ˴7َ`~ؖ;Rd%EH1v&#!ç|`)? ...5iԨQ!d0gjΝ۪U" -9t^zu>5kLIIz!C>}:s^x7Xzk(WK"""Zj陖6m4yXD-٬,ѝ@oBEH@iD{0bҖ^~M6*# c|a5oԨQ&NNN{yO>ݯ_]viIEEń B'O^:VM4Ynݔ)S-ZiӦ߿!d4uӒw۷oNl%;2;H'^(aN;/[ BPW޽{{qȑݻo޼YOB p႟_hhж;w֭[sΌ܃Z*ԪU:t믿\s_`/K  kE:AhOJQdm_6vx/c:w|֭[~Ǫi?~jjEl}G}BСC 4prrb&4Ŋyga8n :uxeHT K6QjD,}.OYbrJIzΟ??lذO>d%%%*MHH>}h\zuǎeԥK6m4nXd~۲c)J:[`K.$H|$M|J}q>l}|L*8U!c[=^a ^zZZZHHȄ 6lذy!CL6M\t ?m۶%K热 9߃_A[Gư!~Tv:|H88&}>ސ{<= =@IOOOOO U5jTnݢ>#88xȑ#F+kkee%Kbbb߿_FիW"YCj;Xo4G9B߷dpÇ9n2B͛7OHH4hRA"@͟/h3f̘qݭ[n޼yϟ?%KBFaÆ 6lРh$LTVVfeeݾ}ƍYq 0f\#.$GW޸qƍɓ3gddd8q"##ƍM4֭[nW~}lVpk׮]vJ|yf^^۷ -W9887hРI&ڬdNNNvv\`4kLmE!B۬IrժU1112YͲ`SjmC!&Mdff⧲k Gq$hm XBG%z 銮 _.>9'sH̄*>v $u`q l 0'e JdMrzA0&\洊^_ހ$g75-$#T!6k2: GqvV1IF$b8ZtHY## j: GY(>(Y^4YDOz48H|}}wͳrfffV7Z-x90VPZ/OdžYO Fm˥ CYVVr`H\ê*mj,P+5ΤCUG @vrrrT8#Iͭf͚rvm*qAT$ꪵ I2,,,,,L.S 7o^rr)EYYY͚5!I&HNVu8GlS\QQq%ArlڴiS,+$X7 v[innn6mO=ux> m UTUyV~:,.F09k% hCUUp\YYa?r۶m^z tV }EFWBwR乗$])zJ>J<$'NTHxYYYDDB@$[U;!8$oLцIEUV(9 5axĝ9dXemH6"HkB'a-v `3CeD?ee"!APZZgǏkb >Ut+Z ym,ffґ1ӡ7Tp`5_{ @3ۗKDW+=88ѣD+w݌E?@y}_^^޿`t`xn{˲*++yV 8Hzf^]W0m1q(/%9l-0۷)H'k%`, YYY ӵk-ZHNIi/ ےNRxFl v ůMZϵW g0bG;vV$j2?` ^)VqѨ8*~qЅm$.uXd/z$++kȑSo܂ 0F"((&ώU'!.їP-ZjmQy鵜Ab^#~uSJf!5J̍?)eNߖ~b{oAWLo'(x~ d2:ujB<)+Mz.=Hud_%,Ez)y{򜡚^=c4vp+Mk?A A$`{5RYY9i$Ƣ*GW} p68::>}TMcVf 28ȲHXRF#+'O|עsozPJdrrrrrt9@3~\#`WHrnnn5k֔Jquu~ǿ S_~;wF?~Æ ޓ'OŪŋߺuq}ZDӧOo^v{l{… "^pM6`HGPԒNhν2fķUUMXāJc ׭[ס^:tpE!bKŘtrqF;mV\ `?k9e^@A24E!!!*2ruPvvֆ_(7f-`h42!="*>*84d{xn#ChkU(UsY2\gɼ (=ȹ;Be+}.*@6`xna g@h+{eo m!QXXH/uqqуWHyɡCJJJBǎϧuMY`?`m"lqFzvWҙ2eʔ)Sx%ڰ\F{YXXػwoL/xESNy3P^ܓNy=|ǎ7xFn޼M ""Bk S|vNTGPյ{<+cNT#%%UVZ[GrrrƏ:8Hooݻw_5h@Q{l:u\???%@UvT7 :={VDógϾ+qed2% u8HAA' L0aTAbY~}vxVn׮ݹs@$;2F|,xǏ"-, )W$;;ĵA,q qf͸խ+X'/!//}|x wsi6l֭[eMЃHG#?\V9:1FsS*5d 6Ö*Zz씗ljb^B? x UpbUa۷o⋊c؉` dԴ"7mB6)"!"#ylR)Pz@f6|jҸX22a„w9s }̓gR'%%zAb^j$zāy޽{*C2tIePc!|2x;v 8¨QR:uꄅ)$\Q 9_jq}m;ֲ,G(A)_0lI)sRR- 1Tm<1czp... vR;VCt?¿kbwh{c$ѣGl$ <3 |||~%"""""B\[PfM<==ũvvv&üX5"y݊',MT$ mB$pfmٳgϞ=[k+p3nFd4Űvt8Hf֯_x F Eܬ9atW2X]GAUK2S9< IDATQ0|j+9WURr9Y3@ׅmp`eXע*pb$b[0 V +VA$W/wdLEwlr0mϗ(zF֭;qrs玚Au@d@L$%z[dFQٲ51v Αdvzm21ŝDR V&lDxG|EBWo+Wi{ԭ[WE 􂗗V !ֲlS^^z18JJJɓ'Z#A$X#]wȉw+$\rm9ŊLF݈L^z5>Va #`3}=$GTj H9drזl gME8cWrZI ^>@ )z-d;#<|[ _)nI,^%DZ¿8V' y'n^zurHA$(ll7>3ZōV0=Iq0ʊ8$[HA$(DIIIFd6g)e>(Q2C)Ξ.U>@ Verצ,䏈*dXFͤ*((斏-)ے[YΑ|xR|Ob [7L& EaDGGL4Rs||<xUVfM~wwwqqq`vƍc,;"HnrL[)ys`H~sqq![& ©IA!PJ+e۲ՑF,EԲVt'B߸J^Ī&) [SԩD)JJJ߷o_AAxGf2%{GD6Tz IXdtilȥx1N?Bqi|22J|)lHu2&&fʔ)7nLj2~GIP q7M̝~蛵I;6;E5IlMsK|6_I"!|E(`OB\}KR)p}>|8 p+hr "^9#NW{Z<^xu7F{n:UUUYYYW\C?~q-[ttv$)1'U`~0gY_^Vvӧϴi |ٳ:tӧoݺE.7o޼y5j/ӧe˖ZkϲF/2cwY/}`gB˗oxhlҤwUUdݶmBE'N=ztjմ; +F] ve vٌ g$^c|QR{8kPôe˖{}}H=zteeM#G,X %%e .Q'a݈GK:gӋ.A߂m8-5䢴4<<~UUUk׮}7|3x`ޑ!C>|ԩѣG;;;X?--M AۙD232k1R( ٳgOw=|pWWW;tbŊ7n?#F:thaatBoYEU5_ F6q+ŋ'//}ǎuww]Kz۷dɒ^x!=== òk_Sj !glQ93Tb;#JMZbD6"z)E/FşoEP$[!w||eٲeǏ7 N TTرcϟ?߽{w޿42dzߊRٚ U1#r@VDK|NSze:+9ix~J}>Om6vXɴ`puƍ![)eV,NKT 6LW^}qIIIff&B(33s޽޾deSw}WkCYfrl6ggg;wٳgϞyիW%ƍ ޽{۶m#Bc\'E}oR@ 9S~ř֊>xDyhӧO˗/_x˷n***Ylٲe,۴iӦMW_}k׮nnnZ͋VZ:_%8{,Bz&ŋ.\8uٳgO:UVVFذa&4j֬_lqFFFFFFϝ;wV^}̘1&LEH !^Ǭ5ӫW>tЙ3gok׮umРAF<<<<<<<==*++>}ZTTTPPw?!d4;vһw.]h}fsΐ}imHMM2elqd"+ڵ{WZjռysWBU;#F30d˧-[Za߁_+UUU111NNNwyg޽߂B^^^WYY: m۶E?~\+7|!ԠA;w9HdDWKWܺu/^ر%K^yu=ztԨQ999ږ-[kÃ:PYuQQQ|Ν;߿Uh![9i5@ɯW.]ҥ˵k322T]fee͝;ѣ׮]SM5Afffyyyƍ;ra??Ǐ2JlBoP)+3mf;wŻw1c1&Fq̙۷oq޽XQQs/6m(6]bŊl)R K@%|>eȡ |aA Rl2?3F&oui ***=ڱcGe$$$_ׯ|S;sgdffVVV+O&M|ŋGFFoHI@TEgO?]h+0Ao+H8\,!*E -[&]TUUձcf͚Ew~uo۶kֿ Ǐ#j׮]PPs+|>vϰYK>)*aR|/Cĝ/`HG苮^sQFNNN҉yb24hРA'N`%K<~8ꫯyFV\\\d2Ni׮ݹs-[6qD>t\~A"& $!I|+h(2{Fn4"5}֭HxGh6l… ֭+dڶm>LiҤɀ УG@.Ǝ;a„۷km~3plS[!J%jY1"zubŊ999jժEDD 0UV jt !t9 AH ɧ O%=%Ib<#$ODZ8'O`N.\0z#L';JӲeKWWלwwwM1j?#}Z^<0?۴ZĽsCiK/lx&QCȥN~3gj4.\@lSUUxMeggWUɩM6fH 7閘޹s~Q#*z_Mk'{3lNJ,|lVIթSh4Yӧ*GUUUZZ`^:fvvv=fΜYQQ_;wnذaiϴk!A"AHGLKC(ǒ9#rRWUR3SVxR9H 1L7ooBCC!bbb({Y0kO}Q613ًaGOl1C{ȗW2~GP ,P??3f;vLkCжm[nv޽zW^ׯ_׏w_w7p \f^z/ 4_}jժi'||&^|{wJ_/_y啘;a˖-~~~ѯzvv?ҥK8sNb^a;;!&e|L6 Z-p,ŧ0`|Fr} } U~'NHHH?tBWd6mֺuwytɒ%ï\-++C}x?&lbr.6ǦR V2KTP})X/0hο@C }^Vs71 7nݻI(gΜINNUoݺ5ḵ֬crvڵkvڽ2ڣUM)!c91`y<0~klJgD X9Vʿicϡ|󝜜fϞݶmz}Giii.]UUUΝ[xg}VZ:̘1QFnݚ3g1ɖ-[BǏ^5H"#7oD6- Q?vj+k,_)e3rp=Hb ( "~H-E08EF,*xzҥիW:thժU+V vԩnݺ 4hԨGj<==M&SeeӧO ݻwׯgeeUUU!ہlْ%w6 Piy/=6e#dơ&"N3աF)hHU%h?< ۷(55m۶ ߊ\,cJ՜壔g[)z$byPF/'C&gﵞYkuk3G\[#H#e#PNQUi⒍ N'>@^^k[4֭[zzӧnzСHmWG ~$ʼn-̰(ʰaF?Ϟ={֭Q\r4̬!N6lؐաC ulrO DObb%K'? /׆CU^Ej9r^A\^YnxFamf$_˛4袸GzF0?UV۷->b@ [fٳgjՊk׮UUUq1dȐ%K>|bܹxGrnh+[{,7!\>  ("~EH>4d!QXz=Y UL/.HZ k_r_hBhڴi>dmvcJlEC}dbbٳgB.ҙ뭮.((Xpa !,DX Iy4^Ake!(ucTe`G"cCEJ"ɪُ 0gΜ={ƍQFEsHSTTo744L6mŊL3sä<*caehK.S.\OUq$IOc#$.W^ϟ4hPyy9k>XCBB֭[jժf͚eggϘ16W17Lk*P* zʳr5HBߊke˖HII)//߿ѣ/_]vM2ѣ?ɟNm#v~'+WA5Xr-6T('}? Qj!}.4*W9)5Pb%+P)iP^U}a?ѭF#]@SUdXDFF>|xŊQQQKbbɓ'OH744l۶^;v MfrwE(5:t߾}QQQyyyYYY K/.'Ad$d"jF1-4Vi(\^OEEzEBWfhJ^ ב)bs:%Kn͚5_? 6mڴi&˕֮]֭[nݺ… 'N?'s۷oݾ 0`_rǏ"?Fso3̳Jd.sG&y0JɔR)ҦM~ѢEyyyyyyGϗܹsVV֘1cڶm[]]m~Drref͚ԹsgiD4eYMl+v[yV(qϦb:Wq`H%K#b 'O޺u֭[;v֭[nݺvrcbbXkwfΜyС &nEZ`U;Vٞ9pґ)VuUnF114B(ǑC:t[YYp8rrrN:U\\ggg pP,vpDEEmٲ!r6 wԀA6?HNNNKKZz5k[0 ~^6o7oBh 8H0`߯ZܼyӧOT?X&9Hc8H4!taֶ81º&]Zֆ۷GݻwO(C^SS2 ACBBBҥK 'BUUUEߠxfFТEcdž6cƌ4I~.]NK$J_tty*v`ϐ Cd=zEǏcX1Կ$wGFFܹ̙3 iDIIɮ]knwbbb}}}QQI*'N zmLv!o`ϖ";a\cdz Bp:gN̫摘=!9bО={Sa O޽{fffAAߟٳAAAIIIi 9$]ң"K֣Wv`%Ǐ߽{kX_oeȑ-[<}<-F1o޼ .^:55}K,P>~„ F_-?B.fkٳ!!!khh`m Ӥ+W!vZSMddd۶mr1sLsƍDz:""^R ]0[W5TOJH0SBo_'Ane,]!4f̘zfx}j:=}50n8֭[%%%SLi֬_~73N6 !ԱcNJ lUR:B^%ǒ4X*U"wW@AS3UIP9K.u8۷߱cŪ7oܺuk˵zj+v\0#H %0سgڦ^xDEEE8p"KPhhݻNO~Ba dll_XXgQF_ӹm6BHppѣ{t"&LqFcۗog̘Q[[kJOj֬on;*0uuu999=zM`k?믿^/7*ZAsAZJEEEVVVBAAA'N޽S۷׮]k\.P˖-?;wbϟϻj4]tA}G4O>pB> ON}u֝;wNYzޒիWz]VV$Xb'Ovܹ~m8_ԩS||| Gy}F9x`K[qԩǏ# 2{#FLy!CΟ?ߧOhBqJ`iii#G5jk 9 q%%%׮]rJii Is XGUUUNNW_}UVVr:)))):_׻3g.XԔ=i۶eҚo@WC`_9is\ lc~@4fLnUכ?JPLLL^=zhٲNE=*,,߻w˗B.뭷Ύӛ A"IjeSwͺ)l31 |M2<J?~\XXw|g[j /_lժUXXXhhhXX>0ӧO˯_;v~7}5RzE,)~ّP  ?I)|WUB |2'9 &[y̷il i!pʕsΝ@ !!!wޝ;wa\.WJJӓn Ҁ$*.j eU)K6>Q9.R;H$Pl qY9s޽{? k/ ..nر~TߤChmi&)H"IMSPT(B[.iʓ:}Y7mC(4~YpȈnݺ5k n4&f*A <(Zi@DQ /=%#Xuږ&ZcgOLomJ2B#3XU0f&Ҹr(rV9![iB;-kҊ12&= hX p8N=M È/"Vpj*Ujؑ\%K泗פ9!蹋m W1Jrc8Hh;)R(+jyV qi$ [)"8B ֗4aҸC+ yp%X :3;?>Cu3ץ Pƕ*Eh$V )PQEqEhC+Dړ0DA уᶑU[מLﺠ 0ߨyUkGm=oZRό1`0 .(Lz5M&4/e\ R\SUmfX3ҹh3r{Sv_GCQ"" j+g6La*h"&V.3RW҂J  5ZKIhr-b5GԌZIY<45br F LZdW"`-Z`m07岂0 XGHH͛7Y[` Ab5 + 4Ж"i\nEj̞ku`U`D%I^Aڐ*LEsq. *B4d4S ۢ'Eظdx29ʠNbq LǬp`jcQ9.t5=0_C x`RShk鬙Ӗ"4MzQ>`sf,K)p4bzFJXȻbՓWXM4r!S3RDmzQC&Z/ʭ**BćEXF%o^ZQU)͝WO^~6 pX|Jg?Erń0IC]31%'b蟂Ґ(#i^\ߴyM#/vSŸWdirS8HccDvĉ2i5H R&P[K3sHf@804 J aMP$޵!7×夳rcnc;FX|X 3;Pd۬3p`GڃFrmһfH{Lg#\Fa!䕜a2TK0M_MT 8(0@ 4Ż4 `0 8H0 8H0 ^9AIENDB`gnucomm/gnue100664 765 765 3257 7513704520 11251 0ustar rsbrsb\Ms8WP++H|L%S[sݭ=d`p<0}[؉p0eHuZIf}eM#:I٨d 6{hBL;|>G٢b(QPŝ,˘;9+z>8a6Ä(Lp+g~QYYQZYv{XzpxS6&dZT)lvأ;Y5*&6nYHE:8hvi0-JQTl",_brƻcWC02wG|L(^eU UèLbpK"X2~:и=+Mnz5@[?-"ώPy]҄9lB`,Gp)cpQ6vð(s5nmX:h,BvC!,YD)J)kۧ0OfqtTz5)@Dڏtr'% tZ XŁL+3XUYnlEQFbEz1(0?I3|j~gM(OpAU-vŝM[lLu&禩N]`jbV@G{o`^@:ݞ{:[a:'|y>1{3cV̒WGT]A rP{NжGGR+hwsv%69,>2"Ptxʒdn|S(:PHjC*Jlܾ*vl!Ow!}R"OqDYGvGkv:Mà Y(t)=7:W*+*ΒUqNn8u"#rCٗE l_g[˅koE*`m&T)VJ#5 WWY+hOX) -7tja&V}a,Ȳև9Cg_>陚^\PFNJ$ yD.ӈP5v4bL_Ck`2(SPGbf9e9E΍oIo`tE\߃d; qDp$y_F-0,JTuW2P,!Rj"e/,;28A}&A.) iK</xf # Oy(YMil$u#RE{i{(r1[y31jZcЦ| (Y-1M̰)zm9mMzFҲ0T`.,/TCmJй ѣp]**m"dY3bfC9gbkMd32>]j  yn-4D~1sZKc3IbvZcj1ȄWxnUs.@>KɻSxڇ"6n*gܨ/C-7Ѻc>jV'M%tiR)CZr6z1 ̲{!9[rFB^om0((,۱,gbE6Yb㓆ZPؙds @xR :zY%;W7,Gu|ؙAc}v6vCOcrۥK[SY֊CTz]ʲJ42FVJ899*Sm6o޼_~$ҡ0G`Yi=~mmm=L͔+ I6RPomSQT,Jޏ=)ÕJeYY--y-:&vޢ`;9 TRT@Gntd1 ?nd:|s6oܹsg\O?^vMRD+..޲e9a\ι1 ֭CӰAZB6С揯¼h''''((駟fggQ({֋L6MPpR\.:u*6!!F~~rb p(NtHK2! !m̏?ةS'P޽8V"+oK.g}j3B;v0)mAAAdd$B߿BKxB!ެ Պzb3glm8}P(7}vm`֊׿Bnnn999f$oll:t(B(::Z&Yb OGa4Pz;?K@ i5)2TU={Z裏> cbb233 ;YSYY'Ԩ(3r8q,Xw^,6v`~bfjׇm\,[ !4|pzwn޼ǎ3π+V On^rsY "!7m0LeW_}f͚z7LLL4utQVoڴ !{Q6UV3"Hn]_bdLuuu׮]sw~饗 v%3Qս{߻w̙3MJ9pzl(p JUYYr\*rK: PBӧO$PeѢE[l1_~E.477777766zyy#-1#!!СCYYY??߼T*_/cǎeh:4đ#GBǏ<+1&?t6 xooo vZyy9Wݺu!s 3o Mp=PxxP ޮ}(::ڪE744,]4%%EV#bccӥKGMMLLLDDDAAŋlPbsss]] ҋSj@Lh4]vXo! 8lذTڣGPiӦ˗755 „_~^Rcرnݲ8@V#?gΜ Pdd… ͛;M]]ݟg"^VZZjB%-KٳIIIMMMRt͚5sε,O8޽{jAzl^x /6lؐl^ZС~ǹs*3fر/M ƍ+**ׯߑ#G/Dth_?o]_K/)BzQQoܸ"DC@kk뫯T*_/+vرo߾Ν;ݻבd JkmHXV6v1[Gjժc'_~aáWئ&Fnj+R=hO!O9C:t!EEE7n={%g`r٘m!!TIn B.uf.]4|'r*21ǔWX,F555q'VvZ -?ǔ愄jԇ8lݺZ%}^I 8!U)lջ6\;g}֭!Nll,BիDJ3f@ HKKYZe= Ր 3PVV;,Y:$˖-ECC]F 9hwmwByiD0$²2MMMSO=U\\ܿmp^@ގW=zHoƛ8 )޿C ͆&###00{ĈÆ ӧOΝ}J?}@};f: T* LiiH$rvvJ?\RCeWQuR&D"ܹs<7=x ^hcQڴT*HgGV*G%m:WNf#?=x~hh() wwwRCM2<`6϶ѣ lUM [[[# 8̓YT.eAQFY敏MIWWW@ ɔJ%)s;y4FR B[`СifR6ܹc?{ȒLrrrjuXX#9DCDj:77ۜ_uQ:u`jkkW^;$$df޽{B#F:th2x 4n{ BVzes9/ݻ!퍷 Ǐ~7Mʤn pnC:4wobG^^ޘ1cfϞ]^^7fHHٳ9_1>T/Z!~5k>*6uuucǎd&MUZZ~~bbb>3DgϞ^z]V999P9ϡ 7ns΄ }/hղei&msX',""<333o3({޹sg{{N7x!lh4j:$$!tU*ԩS}t^;s }b]ii BbɓZezymFRD͘1vB*rQ5BH*nڴ:P(tj//ӧOsbFu릳KR=z411% cbb,X曃+T.^ȕ=f:@ीSLdV\\Wf(Z[[nڻwos}K,߷R{!D" E{ŋcbb?+**,1r@Wb񄄄OUU:uUV=zt̙lo߾x\$M:uϞ=f,:{,BׯgDP\r?֭[w }NSǏ߶m[II B詧ڴiرc/ r[lsOKáT*׭[퍯H$߿ŋmۖ~ST׮][l/NdRoRN~鸸ѣGO6-..k׮q$9v"c^}h-)C?^{K.]vpwwǏ+VĹB&ݺu+333333##@5Pꫯ=a6>pv?Iy05cryFFFzzzzzk״%G0hРŋ`W@\^UU%e2L&kjjJ@ɓ'MMMXj:::gϞx!A> y@@!ty@@!ty@@!t|K'+xr ^sS= FuOq[5\4{ֳ񮤎Uǧ7rFMMDoSS Qrm znzﾡn!25gIkKGoZ-ƲtCf,U:_C c9orO{Yk4[*6X2ߣ?P(H[aVt\R***H$Jdu->oxIVt\밬,(( DGG߹s bFKikk0֚NT[xi+@{{{ee%^vl-ԩSǏ<ӧsb57o?@ &xÀ&ʊ!mÏ溺:V:q>|`۶m i+1/҉Y  tBoT.$d3CtX?#~:C^!6?Ge :Ȯ0?ІjTq/# 4t/ضm.FtZG¨~ys>zŌ1?]:'D8: /7o]K^TpzvQZZ7ѣF #ϟ :u*Qm;!6M\qi|-!ˌK  gϞz?l 瘏"KW[eAcQC!z Ƥ-Q@a v) V:d}]1_tV s|@mi(\'C|< vN3uT3}ֳShKm|MLuW/2ef34H[eay7 x0S+AXtv\]]>"m/-yfTvGkkkMM ]]]9Wzҡ{Ύ6;yttWǎ2e Ǐ N4@!ty@@!t1 ̓m|peOرcBQv/Co OPY{WrL<}dkp/tFqfK`}-izep3~1Ao anܸ'Nqym\{{}嗎*BД)S򗿜^rETS/裏 Muqq5ku&Ix# rCΝ;gϞg"Alll\\\|||XXؠAb >8.]tͬ,Frww?'MdK{:20KO^\\fIff& ]v5ÌjL/ƽ{q4@0|H_~ٖ9rʔ)_|&zrI^اRT׮]T*1tb&z&"駟 ~l˗/>|„ ?T.咠w}wS999 6lذaTFXUUU^^.kjj EKKKuu57Q `AD"ݻc;wH$=z~wbFrJ@O[ K;vto5ۧ@ B Q*3g_Bq`܂cbرcׯ_?rȊ pɃbccΘ1-{NmxǏ=*((R޽{ttt^Fm򲲲1c 2$%%Ŕt%7n8pi+** >|XPPPRRR]]]XX ~~~AAA!!!QQQflw_|1))@K޽k]~F_BBNxeeeCCCEEEmmL&Z[[ E{{;S,N:I$www\yLJMEdžK BO!C.qssDw܉?uT׮]-S*JR(,,3fLEEZK999%%%+++,,lΝonn{]^^nY CyW\>wnݺmܸQ {/O{왝=j(F9Cѣ~A ,^X"k0iآRN:5g77K߿'-dGǃ>FPٳgȑj{zz.\pΝdF.Kx^ ?~޿pXH4k֬Yfׯ[ɓ[lټy9s 4`>j:---///===;;;33!4f̘1c$''d:||PSSsܹ߾};@ 8p`pppDDDhhhHHHPPP@@%QPPPPPPZZzMFm:t_QF9#璘|LR?JԩSYYYnNA׮]4]ti:u ; \.ɚ4555ڥ;;;8o߾aaacǎe9QXX>eʔT`C.qqqikkۻw9swvv4iҤI2j>MUUUIIIyyyYYYff&$<==uѳgOj>MHHÛ۷oW]t1/9@t%K,0#xGd2YKKK[[4bͭK.֐իW?3@y!8;;bRϜ9======$%KxyyUUU4C >>>f͚0a|~sε A||YMdc:&0%˗/}3g)g^~_~zj[[wvv۷ohhhpppPP[nimmb4yyyԴD3`#F`PYY9cƌ2*@cv6!'N8qDZw^VVVNNɓ2L';5M"4t44Ӧ[nAAA/bdddttttttPP =JKK2e Q>䒟~iҤI˖-[f%4 嵵rܨ_ <ۛ],g\@?P Z=~x@~zҶXZZd i[ !444`gmӟd2isğ2eB mC:䞖s"677R-Z$ ;Ｃ&С{.3tww޽K"s8u+ҩS'PRRRqq1iСQ՛7obDGGx-QT/^|wR`P8u .ˑR[cǎ۷?z!啘8jԨGGG򈡍J8s?N"##͛7gΜ@:8Co߾+W\x;S }:thlllXXXdddݭmF1}f~W$/^kmK ƍiii/__߿O쟆 yzM[[L&i>|XZZZTTD <"QQQ#Gį> !/Pՙ:`z;99Qi@j'm'7:ԹȰ:/x> >3XH"a???T 'C Y:96<<2&rf*Y"UR҈'}%v6mûfƇG*J653e] $(E/HgjcjT*e2MJ)iԛ/zxS1IBx0R0%R2苬v^o4bq`vcB (}PIܑMW-SܹmtV9Ƕ0BGIk@PJ*ΤBfǖ]wo2=Ur뺎m]>PQrޅxæTBHNe:۶3kɡL&MH/GƿƁ/6"5x*׻+/qَ-[EuX#_;ƦRJД0/mY}͜L` P&1Ʉan4VK@;)شwMJ4#ӭ2[ 8V*ᑑjV*]EArߴ=l:@J)(qlX*WkJT@ lXERkxCjVT m!gtǿ2KZsq VyJ)ϻf{mmf5~emtݱ?JP$ 0BW83(0T($@MB(@ M4Fl6GFF eYZJD+\\\.Eh@P)J)6l}X, l6;`} F] K`J $Bsmr\Xܧ<]67_oKik>nͧ*M{SԖ-[ƁnA*MV󆛵)M \.dlz\S!۞ 7,"#e2NӰׂt(B(2\ nAY`۶l.f' \r"Y*R ej/}=NN L'3``T @9:<4_k6CJ{'=vꤻHiORdGkձ)?־(!Bo]cZehdZ. sϕB^%a9/[~pشa$nfl}B>ZB$cM}_[I -$ƂR0$Fut%kRAV$6DSslTl.U^*!M6F}a!Tr\r0QW2 [aFNc8%ajv\<c liO'.b6A98䑅 &hI$h$Jb=rG 8ۣ*LR;U  HFJ@m $JvxLs$)l8V_93Z*$z *O (Q= LWǩŢ6+Kf^1+q!8wtm`~1ĂBh;;k?xєJ ^7xcMnh4FVm#4RBax7Т""皉DXDr":Bmc_Ԗ%l3,,QR)٘Az{1}g](LTDXxDwo6~<: dzPш&=gi8ؾk_GۓVagi?&0 cuwn:G ]nyL/O.$e4Ihvi)ˮ$,JH9膡z@ۑbDDrJٶ801 : JM9%!cX9MDSK_l?!L&8HECiӋO|?_-sc1O<  뙮r|>y/咙kN5$e9Khq]7޼L_2eaJ”$qttF{QJOƊQӬɥT:ϧySc*X*HYrםzm^",J1AA"( tlkP}c S^δ3!A 6uʫpH}(T!6m{-uy!s: ֵK|$4-d1M׻ut術!,hyu9qz= X(4#JR 8&ud1kĒ&Rp}ػiYֽ:"O7b 1\)e缑\'OǶ%BD+ 6!6 2a/'>jSʏ,FSRAcIv ֶ^dAPo -NJQɒ##vjy? Č(aƐit6b~"h̄\`캮l&H2II,Q92ТӅf"yi,h$JlmF㳿M-'M@K)`Rc 0@b4/ k@ )Tp$SB?2 8^&=T~RW)l}u֍d$g28p6;(H[-d,!F„ p|YiRv´6q h'b^x*h,X"U=Q.E$` z۲;dl|f݃viCh(BJI)WXH4Zʒ/@BF;nWaρRJ k0(i`m۶mo:!P@Ii5VFiRH!ҭlLXj!4IbPq}e9=ED4M K4.mZ OBV!3J}Z&Ă$RP%Rmy./\I$HSJ!]ވpY&%LJ HJ\.9WJXeW*)-kה=5ݬmHz>~sҊ%RfĆ@MNs*XI,X"9WJ=bs{w<10\KP 6Տ.FGB7[%Vy۞,ˏ~7w}7a?##/.NRЪoMBA6ӛmN4yi=Nvi`@lȔnt<4hFӤTJM(=NS̋gf _2{)cqzV ,W(#c0ƃpSJ [ÀJpmEm D "H"h"iWXvm= R*)g$ Q(߹ܻwsto}P/R?,BS !G&tBr>Gnb\+[nX"ӞH 1jfdddVGR(NLE-&=c |4]-ؙ)%R$q:}vY%c(XS EADf"9]À+8bt1Wrm:![Ē&DDRP =eP )DDЈ'͓@K|ta"=kB H&?B Ba 0p`\ʋ/x]YЁ}MJ^\,R䀄xy!8 KMO@)笅Ϥ'|_2I-2z/ nvšD+a[4$L1!J@Yk 3s-R*%Ч`76sh|/hĒ9TrgbX*٬8+)4U"u]oJ-5:{l $KS%L &%WKɪ+pm&Q@la'gz9c'p4(x^3JF9-21rs9SSf'%D J)szA(6.5\&@0ũ`15R[aLv6HiF:0mRJx7#,/)B.+JT}߲,ϱ& "k]G~OcqNJ(>;#SQL &yَW!͗ao꘤0B1Ƣ( 8ci'b+D dD-ۖz p5+qAcG%}mRdGr2Vh%-`˅P ()ʀ6x6p- -+!+ {)mwy) kJECi c,$ q uSalr%8i?;\q*9Uk(R7 )X헝\ʖL6sӁX44fiI,9J*tl[rkӁ1CK$Mu*% m}ebts_63 Â&Ɩe={^aw}g} : 8r|J /RɀPp$غL `{[f^$]2끋ln}ۧxa2l/W d ~/XXOlz8־agyU$ڒSl:0aMgf&JŢHF⧎/=ioҨ#$rƓ -"I$X*P@ ( TR:qD杕ZP,F{Y>_OA/@`=/+5*NK!!e6:k5\s-x㍹\%-Q@))xH||gET @,zF-g!gg=;hn$ð)HϟZ݇s* Cf].E‹I/jUWmcBf#Y|%%J^ׄ0 uU3 m7tv"=yB'+|| ghrZoD)ZMn|mW\_rt! *k)N./T+ɮQw?ܲ#(Hߞ ܓWpgkxC|MyS^QR'G5S!Rяٶ}TJ )*" Batn61Ӎ4k1^\M1J.ƾ1 &%8H.nTrjϵoc˩9]1]36bB=ЎųgbˀlZ}Chv= [@ֳhpnd=P˲;Vgo</3U ~cmZd,]}ܿw<=vytn\kwO|_SO6'+,|mW濾tԍhMs {}{r_0wԏV|csNjkcwc϶mT[vF~} =_|p] {7}'^;&OF<|t9sݟ/wמj<{]*??c>㍬>`3w:WOz?:ֳ~+ A*>3 {eGx=} T㕔pj[~*rlYJ\ yvʃTZ\[vd(TﾮtdBCg̹swAxۮ? |v.~sg=7Ekd;}i{p`MgZ<#7!etֵ\s]'˦TjϨ;!nXm99Kn/lîȜjo>(6h5g L¥gk&gLT9J~zo:Ip,wtו9"~ơomoL^5Q:*n:BF~F~}_5'"|;Apgw^_@ް5sq|t摣+ǽb"$qKp`>Qsmrp1^s sp/}]ݹurm;CeTtb~6|f8L, A3o_V, a|YVpkŹi[߾xp1;[vdNjXZn"|7)S}Ծhk&PK]~Uǁhd<[vd?QBJ<08^OGe5癹0sEy# qA{F]xww`\s/40(.9e?}&21(WްwL  }gsqc3V[vdWOWOx??>=<|x)ц̶}`M"ڕkcmБ]{TS^D|=" Y}%*6Y1R|%PsmZYD|l?t${Ocw'{{>qs[*tsѕN޾٨DTմr¿uuqːmE۳W^c*''VT~XO)wn,zl5rEܕ/YYJoܲ$<~{K-0|J%>ϝw!psUӳ5Sn϶Wnۙ(~`Y؉l5;o]Slc7n GS.+]Ix1,zC/vd$ƭ].n*mQ-=s&~#.pETumɱгg[W3-ʥzՅ=ߴͿj :QOޓFڎo8qWz7*TƱck="jܝ;͗eoݑmGr.swJZʘ%T_I\;߼s=J8͛o q`Iw/ȽB_XJ$aו?>ڳ +]?mӟel|מFj=}`>yL4Z}mq` δ_ Bayonne and GNUComm - Rich Bodo  Introduction
 History
 ACS and Bayonne
 Bayonne Architecture
 Interface Languages
 GNUComm Architecture
 GNUComm and GNUe
 Common Three Tier
 Applications
 Applications
 Applications
 Business Infrastructures
 Wheel of Reincarnation?
 GNUComm Overview
 TOSI Spec
 PSCT Spec
 TGI Spec
 Bayonne Manual
 Code
 gnucomm/icsx.tgz100664 765 765 13444 7513704521 12104 0ustar rsbrsb;\{wGϿOQΑ^~핃 .1mH8LKx4B%!@NɹK3]]]U]]nzkOg|6:ۛ mo-'[Vw~C_JĎG>7T6^Њ t66><=3[.|C/@˵T ȪӦUUBa9\2c$hkKfh1U(jU涗VǪ^bYYϬ?(R*NhӜ0`dnmv;ٵ*[0WZ+_/?7'Xk\+ MS?XEtzڞO4›%֊YlŊqѡjӡ&*=j+Jٲ+[{I\TVH?4LG#6DboӹpcE{Ȧc$J&0Ԍzi<lOܚgCy}(A8PH׋=6NhSNFAC0r[3`ӣ/ِhN܎ 㷬]t&wW 413+Ar$8sbu!q (M<l:[|bpuά; .m(U1buGj}<}qCp p$4t?2;Qq:\"띅iY#6^;px޼),EU'9ZXW1 f3fuiSj~چ+L+ǴÄ gl`M jwOAx΄{!D2b&"& 0@F1$s0݅NXF9 )Z" of&:PbIJ]CTPA"Wa0xضx;!DZALr[0a&Rq$=L8EZv?s#|uZ_ͅ꯯Rdb5ꯀh_*l L_df?U>ZƽJ?7Iʽp،6ώMYx٭CȂt 숳 y 1K̞9tD1!9g^Hlƺfԛ<2 bLw3Z}+KQ֩*2.ZǦ .֖a5pwߙΨ.Gb(l:?jZ~\ w4e؀2/Zѽ7$C\^v 7!tiChdM0UbB$pFZ22iep7ϙDI_w+&,#/& GUYc ƮFkeOABB'O_6bod畈rmFwyW{k\ZRرgv+#JUvh No@VHyR&^MXI]ׅou%PzkuD́g/y[ ?T`쥝mGs2 0E#A C<)K]fQ8i7CGsHbU& Rk\Z 巜P0K/$$ɬn(hf%oMrr%])M]{1cphuU bՄ(([{*Rݦ15 d?MgITWh՛\͂BvbKy0uLV %C$ۢ1UPFFEsnQ_e@&s.U@CsmXJI2իL;f=:ٗz+{fbUf=yʼnǜj`Qn4\* ќss Xe L+`o翛0F9C< K@7J8 DY{Bt AI"_;ĿұLjY )겍.PΦIF_U%t63x+fO.A 0Mmr'UsK.;`v1.4xPĻnFS?)0׍lQ5?J}c`)%J"04 ړKwƼćk+'O'"5k֚gH5Y7 !t"HYDlzĐNKu HBIsO04} ˘6+,Su3Q0|{>tV_cSX=oK5jS ~o:Nj׈%ΒIdi SK%dr ⏩n ;έ?ZY*Q|< J;R\Fe(> 06<-jv{}/[[: [k\W?ͭ䙮&/skvo"ZuF|?8Ap˩Ƶۏ5L|7'c&bdz!-BlGo>-MN"7*02N|z 'Kr(GOXV٥ZW CJ̎睒gPf ztx}֩,ʎN锣Đy6r$O}_E\V`Fax^ X7CDh^fRCw,}jp'3DC]KAw2qk?'WC4O*W-!2~]4:EC8W\6>{ddw!HLo C}Bv,,(&(1G5S{!gwrB"+0MC>@dU4 ;6D'OO.=:~#qXzq-pes R:9%E xsFȨZ,zYs~m$Z3);r_'ZZlXh`˨ę`(hK:-Dz\r0TAдHxKHs+D`BY[W#@ # ]cϹ]n~5D,W^:k_T~OwSלϷ_LdW<)yQrp_ք,2Zg엋-&,b<3&NfGVPߕokr0-1 0sΦQs$ek.0`j$g!2)UrA3 xKyiYP/= kGo_/N!T ktJ7o&H9~?Ig\#iJ]9&W/*@nEc0O|؀6#kWnrK@>nwO\+~C6l~-8ѯ@'oϣOMX`cpHp:j&e6BvLqɅ4 Ӈ(P"ovJCyISor|+L ی5zw)(7.#>f~6ˠ8yAVUto \KĬND\JtZtv^%+KIvjϑ IRԾ`F-rlJ͢ c=llwGƇ׋&(,N_d xgnucomm/outlinec.html100664 765 765 3774 7513705615 13112 0ustar rsbrsb It is now safe to compile your phone system - Rich Bodo  Introduction
 History
 Asterisk
 VOCAL
 Gnomophone
 OpenH323 and Osip
 ACS and Bayonne
 Bayonne Architecture
 Interface Languages
 GNUComm Architecture
 GNUComm and GNUe
 Common Three Tier
 Applications
 Applications
 Applications
 Business Infrastructures
 Wheel of Reincarnation?
 GNUComm Overview
 TOSI Spec
 PSCT Spec
 TGI Spec
 Bayonne Manual
 Code
gnucomm/language100664 765 765 2714 7513704521 12074 0ustar rsbrsb[O8QC9:qhYiVH2ZrShKi7"`M>?a9MG8.G6FN&QL眦\O=Q|2ͧ',K*rxJfIBM]T* r4<_dѨI΍G\N﫟^A W"/c,Ż[W%ܐͯNN'fx{~@[EEJ ! g?4]$c6{ږz'pX2/"lVr2NiB]! ia;:U`,rIbNi'VhD"JT%̘@kNP!!8dtʢEt/hNrsjqTJz"m2,al+>F,:P@|)tyOK "Ό* r|N'<9_{ ,)sx{gF?1n<RP3"t:3W9BZa;D?@ӾDvhB;|%gEJa 4T>$V 8RY@['װUx'XjFwD#QCBr;c&AQbMc׷EgAoI#_x7 Oh)8L^VrQXW;FѨvFU4FXHxRF#|gcQe.;Ĭ:&%Ngnucomm/language.png100664 765 765 14303 7513704521 12674 0ustar rsbrsbPNG  IHDRtzsBITO{IDATxzF|{;x'y'K8>.6*(a!)w8!v3nI=x]J=^٠sBW1`'JCq }O_c09&)|\.ppaJ#PܒN}k?/ +=e]rNsЇ˝LY`ݤ*zZ2>˭ZwRW7? ^vz^!xx%v咓Z1I:Q!4qƏ̭ؕF3Ꝇñ=;f3뺚vF{y%gy?#FQ%- WμBdTl^NiXy2+X'+{Ԓ)ٙY9_x1q#+a8ATU~`q = t`]؃AW+{= t`]؃www_/]u^ _e z|||Eڸ{}}mry||liكUNxXVw]^7J~;25Mw\[S#Sh]A3%L+:|:煣.o wE|JC@lF+ ߍZ2Ųrӕ6=ϵ9uڴhv{)u/g#yrY[ȒJXR>uO{j8 ^-kiARWK}67aeր@u !ւSZā+{=  +.py?e3b? >ӌWy:OhӟitN LqטB }».I'm%DV{_ѱ&˲j@WC_h!uJI_Wty_ѱ?/H*)L%t"b7b%J0χJRϚsxfd]%~j,AW!P or]mWnץCz|e%/Q.%;>g_%J ~[W%_VW,LtA8&67x5hFBCymg9VS >W';q = t`'0o҃?4WW///]\8 _tˏ^qf= t`]؃AW+{= t`]NZ=>==Pu/K/5蹮zE6պ-m_.ǖd{wU%[$9cg=Sur9Kp8rJ΋OqpXՍqU֕#SejpXM?am=+ѯQkR,*H6$7`R۬ݰ΢N?h6 H[j|roԹ$)312ܮcB7#}".u0o9';_FeksFzW^*:[& =3}PFTeGsX|98WTBʤ|O;n0/Ws6'$Fm@W۝Fm ]؃AW+{6x?dwO#00GU'NQfq@ˈ𵯱س$VCr%F5Jvu=}ԝ͈ .WS,gwhQIy`oΈZ"ppJ^JLa^Z $`RȠ1Z^-*Ȱzv{!x.ƝBuԒ ;ȸ:#W2٫ױ_௄_ԗ’W˳vW~[-PgJ]-k'-z7/9oᑇ^}%]؃AW+{̳@3ztt4|?~eoML{u}zze{u~:@ ?[>>>~"@j]ז/cK((u_98|^Q% ,!e6&]65vm쮨+{c[k'6Vur9qBp8rJ.47)߻/-oaCngٮ|~QWԧAȻ';u9SַK&<|7·}}#4/Y@ngِ|~.`RufeޒP^^iKzJ.I}jRjM݈CMs(?MsEd.4L+=+V52 -Pez8z8aWü8`$Ss+I'{I%kZƌ8^ɱ\ @j%sP~wgS~,Ro)MjjJ4xm˨?JFՒ{_]9gbv&]؃`2yB]SQWs3EE]MQTgk,8+I#*3>y9 "ȷ%V"HXBN=RҒTվS]k#?y: N:,H0+Y(6x:Rsf9}+!2IٵjIՕЭ/ߞjnSQ=(+Y05~|O=*ML7ew]+g?,Q,VUC.4Q]i)QصL ]؃AW||{{ki9fz}yy is/~4@%| 0o`]؃AW+{= t`]؃AW+{= t`?g]ק^sۯJyozgKiɧ^__[ZCK-OaݢTd.-@̥~:j D4F+&ӕ@PSHEHycWwm |S9|=9@Ok*@Q>̤@fJrLHler^0 z[4`_,-9sL>'%Nmr]9+x0{9o9'7ucK( fOd>WJone'b>]E|QR!=pb2fhww߿P/lvz^lKQsnvj]ז"@}J85.}0J7%o-ޝA΂&e/q|~oymoAoF? WbصG3vIKv wv! D Yp6S:, +íWYVv*N,8IS.cqׯi΁s,tָ^f ?SԳ {K,2xeYsIUX` |^uoga]( 'RpoU5qZlgAq -̻{obV4 0D4Ul'x pp}?%| zhYvrKX"=2,(o1ς9tOQ,UzRM?X_~R[)eWT0AOvw`.WͰ  q = t`]؃f)zO80~bkA/FUY5'žnpǍz-0z(3mbU0x&Ƭιߜ'q = t`ϗ[h_]]חO]=??ǏLTl+{= t`]؃AW+{= t`]؃AW+{>oML{u}zzeu/y{AoeWKmu]___[ھ\.$M_8M[}H nWLA7 ZP䠺ZBmلPr*NbH9(GmSS0zjWW2WWYr!BϱnrTm}'y*G8Cjazƒ%%ve ۩gf?ۮ2 Q\l9D,q̡{!!{vɷy>UAF)?''ol?XЁ :c*$Λt9T-6xNrͫ!gGU.P|+ܟz tk䝿\`?ym0v5ǁВ1a1WPmD%C`]؃+Txbj9Z hdP] (=[)5+t(jƓb%hV$-̓TWR\aAa8]X:Vp&5r{U$.9WqAƫ`XFM]׆./XB$}uNW3x,?kjX"C{ő~t:ޫ`^{"Cedk1ːÜ,NI> VB^"٫_89xuH5i9jJg?kXS}aD]}'Jkjn7XG',:u?ҿ>L;fܘ=$d*$XrZ V{Gds>7[\Sk,Vx'y/nO&o+M;xpKLWKaS.BFk]5z]Wv6*9@+g4wНt=^G`]؃2o{Ks?#,IENDB`gnucomm/title.html~100664 765 765 1751 7513704522 12574 0ustar rsbrsb
Bayonne and GNUComm - Rich Bodo





Bayonne and GNUComm


Rich Bodo


GNUComm Developer


Download tarball


Download zip

gnucomm/left.html100664 765 765 4134 7513704521 12204 0ustar rsbrsb Integrating Telephony and the Internet-OST  Introduction
  The way it works today
 The way it will work tomorrow

GNUCOMM:
 Overview
 Control Servers 1
  Control Servers 2
 Matrix Servers
 Business Servers
 Client Apps
 Libraries
 Other Components

Bayonne:
 Architecture

Apps:
 Messaging Overview
 E-Commerce Overview
 Support Overview
 CRM Overview
 Flowchart
 Promptlist
 Script

Summary:
 Resources
 gnucomm/manual.text100644 765 765 265375 7513704521 12625 0ustar rsbrsb next_inactive up previous Bayonne User Manual Anders Dahnielson 2001-04-13 Contents * [1]Contents * [2]General Information About Bayonne + [3]What Is Bayonne + [4]How you can help + [5]About This Manual + [6]History of Bayonne + [7]The Name * [8]Bayonne Licensing and Support + [9]Licensing Policy + [10]Commercial Support * [11]System Architecture + [12]Introduction * [13]Hardware Support + [14]Dialogic + [15]Pika + [16]VoiceTronix + [17]Quicknet + [18]Aculab * [19]Drivers + [20]Introduction + [21]Drivers + [22]PHONEDEV.IVR + [23]VPB.IVR + [24]PIKA.IVR + [25]DIALOGIC.IVR + [26]ACULAB.IVR * [27]Installing Bayonne (Basics) + [28]How to Get Bayonne + [29]Supported Operating Systems + [30]Installation Layouts + [31]Configuring + [32]Compiling * [33]Installing Bayonne (Advanced Topics) + [34]Compilers and Options + [35]Compiling For Multiple Architectures + [36]Optional Features + [37]Specifying the System Type + [38]Sharing Defaults + [39]Operation Controls * [40]Scripting Language + [41]Introduction + [42]Events + [43]Symbol Notation + [44]Basic Commands + [45]Bayonne Server Commands + [46]Optional Commands * [47]Phrasebook Rules + [48]Introduction + [49]English * [50]TGI Services + [51]Introduction * [52]Wrapper + [53]Introduction + [54]Using Bayonne with an existing site + [55]Running Bayonne seperate from your web server + [56]More on running web services on a Bayonne server + [57]Corba and other future services * [58]About this document ... General Information About Bayonne What Is Bayonne Bayonne, the telecommunications application server of the GNU project, will offer a free, scalable, media independent software environment for development and deployment of telephony solutions for use with current and next generation telephone networks. Bayonne already offers a fully distributed application server for use today with multi-line telephony cards from many vendors under free operating systems. To speed development and simplify deployment of custom applications, Bayonne offers it's own native script interpreter which may be directly extended thru modular DSO plugins and TGI based applications. TGI, "Telephony Gateway Interface", allows Bayonne to be easily integrated with other system resources, such as web servers, databases, and other application servers using standard and familiar tools that are well understood such as Perl, TCL, and Python. Bayonne can be used today most completely under GNU/Linux with an ever wider selection of telephony hardware. Bayonne has also been built under, and can be used with, FreeBSD and the new Voicetronix API. Bayonne is highly portable and will compile under most multi-threaded POSIX operating systems, including Solaris and Unixware. As Bayonne's telephony hardware and next generation media support broadens, support for functional deployment under operating systems beyond GNU/Linux will continue to increase. How you can help There are many ways you can contribute to Bayonne even if you do not code. We need people to help with languages and building of multi-lingual voice libraries, people to help with testing, with documentation, and even with the new web site. If you wish to help Bayonne, feel free to send email to dyfet@gnu.org About This Manual This manual was put together by Anders Dahnielson . However most of the text are taken from different Bayonne documents published separatly. This manual is an atempt to get a clear overview of the Bayonne Telephony Server. History of Bayonne While Bayonne remains in continual development, it is based on ACS which is usable today. I originally started the ACS project as a GPL licensed multi-line voice telephony server, with the goal to be the most flexible and advanced telephony voice messaging server available. The final milestone release of Bayonne will be referred to as Bayonne 0.6.0, and will depreciate the ACS code base. With Milestone #5, Bayonne now supports FreeBSD in addition to GNU/Linux (and possibly Solaris). 0.5.0 is the first release which demonstratebly works under FreeBSD and also happens to support the Voicetronix 4 port analog DSP card which will be used as the core of Bayonne VoIP development in coming weeks. In addition, support for Aculab and Dialogic hardware has been initiated, though it is not yet complete. The fourth Bayonne milestone featured many changes, starting with international support and the new french language vocabulary. There are many less visible changes that effect and expand the scope of DSO capabilities for the Bayonne server as well as greatly improve stability of the server. With 0.4.2, expanded support for initiating dialout sessions has been added along with preliminary support for locating streams and the dialogic sdk. The 3rd milestone release of Bayonne is being made available from ftp://www.voxilla.org/pub/bayonne immediately. This release represents both a more rigerously tested server, and a "usable" or "deployable" server. An audio library has been recorded for use with the new phrasebook system, and some documentation has been drafted. Many features have also been clarified and greatly expanded upon for better use in deployable servers. A lot of bugs were also found and fixed between 0.2.1 and 0.3. In particular a number of new issues were identified for both QuickNet and Pika hardware. In the case of QuickNet cards, it was found to be nessisary to do a full close/reopen of the /dev/phone devices to reset the card otherwise they stop responding between calls, and this was done in 0.2. When the server is started as root, the /dev/phone devices are initially opened under root, but then the server reduces its privilege to "mail" and can no longer re-open /dev/phone. In 0.3, the server now resets file ownership of /dev/phone devices. The Name Some have asked why the package name was changed. I felt there are several reasons for doing this. First, I have received numerous complaints over the use of the name ACS in that it is similar to Al's Circuit Simulator and several other common packages. Also, I had originally wanted a name that was more than a 3 letter acronym. Bayonne is taken from the name of the Bayonne "bridge", and represents the idea of this package as a bridge between the computer and telephony worlds. Finally, I wanted to bring across the idea that Bayonne is different than a "1.x" or "2.0" derived release of ACS. Bayonne Licensing and Support Licensing Policy GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software-to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) 19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items-whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. Commercial Support Commercial support and products based on both ACS and Bayonne are already available from several sources. Open Source Telecom OST offers commercial support for ACS and Bayonne software deployment, a complete line of turnkey IVR servers based on ACS, and discounts on telephony hardware for use with ACS. URL: [59]http://www.ostel.com TekLab TekLab has offered production support for deployment of ACS solutions since the first widely used releases of ACS. URL: [60]http://www.teklab.com MySite Sweden AB Swedish portal and consulting company that offers custombuilt solutions deploying Bayonne. URL: [61]http://www.mysite.se System Architecture Introduction Has yet to be written... Hardware Support Dialogic Bayonne supports the Dialogic 5.0 runtime release under GNU/Linux. It may also support Solaris Dialogic runtime, but this has not been tested. To date analog cards, such as the D/41x and EPCI cards work fine. Digital (T1) span card support is being worked on. Pika Pika Inline GT and Daytona cards operate with Bayonne under GNU/Linux using the latest MonteCarlo API. More information may be found here. VoiceTronix Voicetronix provides 4 port analog DSP cards with a GPL licensed API. The Voicetronix driver can be used with both GNU/Linux and FreeBSD. Quicknet Quicknet and generic /dev/phone based Linux (and possibly FreeBSD) devices are currently supported. Aculab In active development. Drivers Introduction Bayonne differs signficently from ACS in the way platform specific telephony API's are integrated. In ACS, a platform specific server must be compiled and installed. In Bayonne, a single (unified) server image is used, and all telephony API's appear as loadable modules. Furthermore, Bayonne differs in that the server can be ran under "user" privilege, at least for most telephony API's, while ACS actually required root permission to execute. These differences are substantial enough that the very concept of configuration and deployment of Bayonne differs signficently from ACS. This document is not meant to highlight those differences, but to identify issues and configuration options relevant to each driver and telephony vendor that is supported in Bayonne. Drivers A "supported" Bayonne telephony device is managed through a plugin "driver". This "driver" is defined as a shared object module with an extension of ".ivr". Drivers (and other Bayonne "plugin" resources) are found in /usr/lib/bayonne/version/, such as /usr/lib/bayonne/0.4.4/. In addition to telephony device "drivers", there are plugins for "integration" services. These typically are used for switch integration, such as the Bayonne "SMDI" module. Other modules offer extended call logging capabilities, network integration, VoIP stacks modified to operate as runtime loadable modules, and script language extensions. While all other forms of drivers and plugins are optional, Bayonne requires at minimum a telephony device and API "driver" (.ivr) to be selected for Bayonne to execute. Furthermore, at present only one such driver can be selected and made active in any running instance of the Bayonne server. The primary telephony driver API is selected in the [paths] section of the /etc/bayonne.conf file. The name of the driver to load is specified directly, in the form "driver=drivername", such as "driver=phonedev". A matching "phonedev.ivr" plugin is then loaded when the bayonne server is started. When Bayonne is "configured" (by running ./configure) it will detect what telephony API's have been installed on the host system. If it fails to find the files associated with a given telephony API, then that API will be excluded from Bayonne. If you later add a telephony API, you will need to remove config.cache and then re-run "./configure" before Bayonne will recognize and build drivers for it. The remaining sections of this document will cover the various driver and plugin modules currently supported by Bayonne, as well as vendor specific issues. PHONEDEV.IVR The phonedev.ivr driver is used to support operating systems such as GNU/Linux which make use of kernel mode "native" telephony drivers commonly found under "/dev/phone". This driver supports interaction with kernel telephony "phone" devices through the application of a known set of ioctl calls and the use of "event" notification through the exception bit of the select() call. The phonedev module does try to treat phone devices in a fully vendor neutral manner. "/dev/phone" device drivers from different vendors can be loaded and mixed in kernel memory under separate device nodes, and the phonedev.ivr module will accept such a mixed vendor environment as well as query /dev/phone devices for specific features and capabilities that will be supported on each instance in Bayonne. Furthermore, in that Bayonne executes in "user" mode, the bayonne server will only open and access "phone" devices that are actually made available to the current user id that bayonne is running under. This means that if one wants to use, for example, three QuickNet "linejack" cards with Bayonne for servicing incoming calls (say /dev/phone1-4), and yet preserve a QuickNet "phonejack" card for "private" use (say with gnomephone or speakfreely), then one can simply set the ownership of the linejack cards to match the user id Bayonne will run under, and preserve the phonejack (/dev/phone0) as owned under a different user id (say the userid of the workstation user who wishes to use speakfreely). Finally, the phonedev.ivr can be used in multiple instances of the Bayonne server. Hence, one can run different "application servers" by starting multiple instances of Bayonne under different user id's. Different sets of "/dev/phone" devices can be marked as owned by each of the expected server user id's, and each server will then operate only with the "/dev/phone" devices that user id has been granted access to. One should never start more than one instance of Bayonne under the same effective user id. Also, when using user permissions to partition "/dev/phone" devices between multiple instances of Bayonne, these device nodes must never be marked with shared group "write" permission, otherwise the device may be accessed under multiple images. When starting the server under the "root" user, one may find additional problems. Bayonne will change itself from root to a new effective user id once started. Due to a bug in the Quicknet cards, the /dev/phone device must be closed and re-opened between each telephone call. Hence while root, /dev/phone will initially open, but once the server is running /dev/phone devices may no longer work unless they are given r/w access permissions under the effective user id the server is now running under. By default this will be the effective user id of the "mail" account, although it can be changed in [server]. The "phonedev.ivr" uses service threads to service event queues for driving the call processor of each of the open "/dev/phone" devices. The total number of such devices that will be supported is indicated in the [phone] section of /etc/bayonne using the "devices =" keyword. The default value is currently "16". The maximum value that may be specified is "240". As each device represents an individual telephone line, it is possible some cards may support multiple "/dev/phone" nodes from a single card. This value thus represents the total "port" capacity that will be tested for rather than the total number of cards that may be supported in a single chassis. Normally only one or at most two service threads are needed, and these can be selected using the [thread] service = keyword option as described in the bayonne.conf man page. Generally the service threads should run either at or a higher priority than Bayonne itself. The phonedev.ivr can support a maximum of 240 device nodes (sufficient for 10 T-1 spans or 8 E-1 spans), hence, in a very high capacity "/dev/phone" based SMP server one might wish to select 4 or even 8 service threads. At the time of this writing, only the QuickNet cards are known to be using "/dev/phone" drivers under Linux. However, the Voicetronix multi-port analog telephony cards will likely soon also use "/dev/phone" based Linux kernel modules. It has been assumed a maximum of 16 QuickNet cards can be installed in a single cabinet. It is possible to also have up to 16 Voicetronix cards in a single cabinet, with each card servicing 4 analog telephone lines, for a total capacity of 64 ports. VPB.IVR The vpb.ivr driver supports Voicetronix's 4 port analog DSP card. These cards use a "user mode" library, libvpb2, which must be installed before Bayonne is configured. This driver will work for both GNU/Linux and FreeBSD systems. It will work for any target platform that the libvpb2 library supports in the future. The vpb.ivr module requires that Bayonne is started under "root". This is nessisary for Bayonne to access io ports under both the Linux kernel and FreeBSD. Once started, Bayonne will reduce itself to the effective user privilege specified in the [server] section of bayonne.conf. The [vpb] section of Bayonne must be configured properly before you attempt to start it. This includes the base address of the "first" card (in 0x3x0 range) and the total number of cards in the system. Bayonne assumes all Voicetronix cards will be in sequenctial addresses, and hence, if you define the first card as 0x340, and specify two cards, the second card must be set for 0x350. Multiple instances of Bayonne can be started so long as each instance uses a different set of cards. A seperate service thread is started in Bayonne for each Voicetronix card. This service thread performs all event dispatch and may be tuned for process priority scheduling and by scheduling policy for optimal performance. It is possible to have up to 16 Voicetronix cards in a single PC, for a total capacity of 64 analog telephony ports. PIKA.IVR The pika.ivr driver is used inconjunction with the Pika MonteCarlo SDK to support Pika analog telephone cards under GNU/Linux. This SDK has been made available for RedHat 6.x based systems as a RPM package which must be installed before Bayonne is "configured". The pika.ivr module can be ran from "user mode" and does not require the user to be "root". This is accomplished by making /usr/pika readable to a given user, and by setting permissions on /dev/pikadsp and /dev/pikacti device nodes to permit user level access. The ivr module supports all Pika trunk cards currently supported under GNU/Linux with the MonteCarlo SDK. These include the 4 port "InLine" series of hardware, as well as the 12 and 24 port analog DSP Daytona cards, as well as the non-DSP versions of these cards. No station side cards are currently supported, however. In addition to "DSP" cards, the pika.ivr implimentation on Bayonne supports fully "dynamic" resource assignment and can work with non-DSP cards that are mixed with DSP cards, or with systems designed with blocking factors due to less DSP resources of a given type being available than physical ports. The pika.ivr takes full advantage of MonteCarlo MVIP bus support to locate and connect DSP resources to ports on a as needed demand basis anywhere on a given host. The Pika implimentation also supports DSP based audio conferencing and mixing of multiple audio channels. This is done with the standard Pika conferencing API. Only one instance of Bayonne may be executed with the Pika DSP module running. The API uses a single global configuration and cannot dole out partial access to Pika cards to different processes. If more than one instance is started, it may lock up the whole system. DIALOGIC.IVR First, before you can use Dialogic support, you must install the Dialogic UNIX SDK for your platform. Bayonne is designed "generically" for the standard UNIX SDK, and will work with it under both Solaris and UnixWare, as well as under GNU/Linux. When using GNU/Linux, you must also install the LiS streams package. The dialogic.ivr module has been developed to autodetect Dialogic resources at startup. It should detect both analog and digital telephony devices, and will support both with the same ivr driver module, even if both types of devices are mixed on the same system. As of release 0.5.15 only analog support has been completed, but digital support should follow very quickly. The dialogic.ivr analyses and assigns ALL dialogic devices that it finds at startup. Hence, only one instance of Bayonne may be executed on any given server. The current implimentation does "static" assignment of DSP resources at startup, and requires that sufficient vox ports exist for all digital telephony interfaces found in the system. This means one cannot use plain DTI cards unless one has sufficient sc bus voice resource cards also available. This may change in future releases. ACULAB.IVR The aculab driver is in early development. It is based on the Aculab PRI and BRI span cards with Prosody support. You must install the Aculab call, voice, and switch modules and libraries before building Bayonne Aculab support. At the moment I assume that root permission is required to access the Aculab, though this may be incorrect. The aculab module does automatic card timeslot assignment and will detect and allocate aculab timeslot and card resources during startup. In that all devices are allocated at startup, only one instance of Bayonne can be executed on a single server. A single service thread is maintained for event dispatch, and a service thread is available for each telephone port. This may change later on. There is an active workgroup working on aculab support, and the mailing list for this can be found at bayonne-aculab@lists.sourceforge.net. Installing Bayonne (Basics) How to Get Bayonne You can download Bayonne either via our site http://www.bayonne.cx or directly from ftp://www.voxilla.org/pub/bayonne After download you can unpack it with: tar -zxvf bayonne-VERSION.tar.gz Substitute VERSION with the version of your package. This will unpack the Bayonne distribution in a new directory with the same name as the package. Supported Operating Systems With Milestone #5, Bayonne now supports FreeBSD in addition to GNU/Linux (and possibly Solaris). Installation Layouts System Directories System directories are installed by the distribution of the Bayonne package itself. While they can include application specific files that are placed there later, this is generally not recommended except as noted. /usr/share/aaprompts{/voice} Bayonne supplied default prompt library. These include phrasebook prompts and anything else found useful to distribute with Bayonne itself. User application voice libraries should never be installed here. /usr/share/altprompts{/voice} Maybe optionally created for single product turnkey servers. This directory is generally referenced by prompts, as in "play myprompt". /usr/share/aascripts Default system scripts supplied with Bayonne. These include test scripts and any simple applications supplied entirely with Bayonne. Turnkey applications may place script files here, though it is not generally recommended except for turnkey product servers. /usr/share/aawrappers This is a special directory to hold user supplied executables that will be executed thru the bayonne_wrapper program. These programs are generally initiated under the apache user id and converted to the bayonne user id by bayonne_wrapper. /usr/libexec/tgi This is the default directory for Bayonne supplied TGI applications. Bayonne distributions will in time add a number of useful tgi libexec files. User supplied TGI applications must also be installed here, as these run under the Bayonne server's user id. /usr/lib/bayonne/{version}/ This is the install directory for all loadable modules and plugins. There is only one directory, and DSO's are assumed to be compiled against a specific Bayonne version. User created DSO's should be installed here. VAR Directories /var/bayonne is used to host all modifyable files, both as distributed with Bayonne, and for user applications. Any reference to a partial path with at least two components will refer to here. /var/bayonne/tmp A place to record temporary files /var/bayonne/save A save filespace for serialized classes. /var/bayonne/prompts Used by the play and record script. /var/bayonne/maps Used for loadable map files. HOME Directories Bayonne itself has a home directory and user id, starting fairly recently. This is typically found as /home/bayonne. A simple "adduser -r bayonne" will create the Bayonne user. The Bayonne server itself runs under the bayonne group when started under root, and tgi executables (and wrappers) will execute with the unpriviledged bayonne user id. /home/bayonne/apps Starting with 0.5.20, this is now the prefered base prefix for installing new Bayonne applications. /home/bayonne/php A prefix for php include and drop files. /home/bayonne/admin A working directory for plugin php admin forms. /home/bayonne/html The primary document root for Bayonne integrated web applications. These are typically execute using an Apache server running under the "bayonne" user id rather than the nobody or http user. This is used for applications that include web services like unified messaging. Other kinds of Bayonne apps might integrate with an existing web application by using bayonne_wrappers instead. "Click-to-dial" typically uses wrappers rather than a seperate apache server. APPS Directories Starting with 0.5.20, /home/bayonne/apps has become a standard prefix for installing applications. A number of directories exist for this purpose, and a number of special requirements are needed to use this fully. /home/bayonne/apps/aascripts User supplied application scripts are installed here. /home/bayonne/apps/{APP}/{%voice} Each application gets it's own private voice library, which is also fully multi-lingual. For a script file to refer to it's APP prompt directory, it must use APP:: notation in play commands. For example, to play the voice mail intro prompt, one might use: "play VMS::intro". This will then play from "/home/bayonne/apps/VMS/UsEngM/intro.au". This allows one to refer to both default prompts supplied in bayonne and application specific prompts installed locally. User HOME Directories When starting Bayonne under an ordinary user id, Bayonne will use the local user's home directory rather than /home/bayonne and /var/run, for various things. These are stored under /.bayonne. This has not been changed in awhile, and is only useful if one either always runs bayonne unpriviledged, or if one is starting multiple instances for different users. /.bayonnerc Can be used to override some things found in /etc/bayonne.conf. /.bayonne{.ctrl,.nodes,.mixers} Local user priviledged versions of /var/run files. /.bayonne/schedule.conf User's private scheduler. /.bayonne/tgi User's private tgi directory when non-priviledged Bayonne is ran. /.bayonne/aascripts User's private scripts. /.bayonne/aaprompts/{%voice} User's private "" prompt path. Hence, a play myprompt" should go to here. /.bayonne/aaprompts/APPS/{%voice} When not running under a priviledged user id, the Bayonne application specific working directory will be located in the user's home rather than in /home/bayonne/apps. Hence, a "play myapp::intro" will go to " /.bayonne/aaprompts/myapp/UsEngM/intro.au" Configuring The 'configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a `Makefile' in each directory of the package. It may also create one or more `.h' files containing system-dependent definitions. Finally, it creates a shell script `config.status' that you can run in the future to recreate the current configuration, a file `config.cache' that saves the results of its tests to speed up reconfiguring, and a file `config.log' containing compiler output (useful mainly for debugging `configure'). Change to the directory where the sources was unpacked and type the following to run 'configure': ./configure Running `configure' takes awhile. While running, it prints some messages telling which features it is checking for. By default, Bayonnewill attempt to build and install all of the telephony servers supported in the distribution. Since most often only a specific set of servers to support specific vendor telephony hardware you have available are needed, there are ways to select and remove vendor specific server implementations through configure. The advantage of doing this is a shorter compile time and the elimination of distractions from errors in building uneeded API trees. The "-without-pike" option removes all Pika Monte Carlo related, modules, and libraries from the build tree. The "-without-phonedev" option removes all GNU/Linux /dev/phone support. If you're using `csh' on an old version of System V, you might need to type `sh ./configure' instead to prevent `csh' from trying to execute `configure' itself. If you need to do unusual things to compile the package, please try to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the `README' so they can be considered for the next release. If at some point `config.cache' contains results you don't want to keep, you may remove or edit it. Compiling After you hav configured the package you need to compile it. Type the following to to compile the package: make To make sure everything went ok. Type the following to run any self-tests that come with the package: make check To install the programs and any data files and documentation type: make install You can remove the program binaries and object files from the source code directory by typing: make clean To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'. There is also a 'make maintainer-clean' target, but that is intended mainly for the package's developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution. Installing Bayonne (Advanced Topics) Compilers and Options Some systems require unusual options for compilation or linking that the `configure' script does not know about. You can give `configure' initial values for variables by setting them in the environment. Using a Bourne-compatible shell, you can do that on the command line like this: CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure Or on systems that have the `env' program, you can do it like this: env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure Compiling For Multiple Architectures You can compile the package for more than one kind of computer at the same time, by placing the object files for each architecture in their own directory. To do this, you must use a version of `make' that supports the `VPATH' variable, such as GNU `make'. `cd' to the directory where you want the object files and executables to go and run the `configure' script. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'. If you have to use a `make' that does not supports the `VPATH' variable, you have to compile the package for one architecture at a time in the source code directory. After you have installed the package for one architecture, use `make distclean' before reconfiguring for another architecture. Optional Features Some packages pay attention to `-enable-FEATURE' options to `configure', where FEATURE indicates an optional part of the package. They may also pay attention to `-with-PACKAGE' options, where PACKAGE is something like `gnu-as' or `x' (for the X Window System). The `README' should mention any `-enable-' and `-with-' options that the package recognizes. For packages that use the X Window System, `configure' can usually find the X include and library files automatically, but if it doesn't, you can use the `configure' options `-x-includes=DIR' and `-x-libraries=DIR' to specify their locations. Specifying the System Type There may be some features `configure' can not figure out automatically, but needs to determine by the type of host the package will run on. Usually `configure' can figure that out, but if it prints a message saying it can not guess the host type, give it the `-host=TYPE' option. TYPE can either be a short name for the system type, such as `sun4', or a canonical name with three fields: CPU-COMPANY-SYSTEM See the file `config.sub' for the possible values of each field. If `config.sub' isn't included in this package, then this package doesn't need to know the host type. If you are building compiler tools for cross-compiling, you can also use the `-target=TYPE' option to select the type of system they will produce code for and the `-build=TYPE' option to select the type of system on which you are compiling the package. Sharing Defaults If you want to set default values for `configure' scripts to share, you can create a site shell script called `config.site' that gives default values for variables like `CC', `cache_file', and `prefix'. `configure' looks for `PREFIX/share/config.site' if it exists, then `PREFIX/etc/config.site' if it exists. Or, you can set the `CONFIG_SITE' environment variable to the location of the site script. A warning: not all `configure' scripts look for a site script. Operation Controls `configure' recognizes the following options to control how it operates. -cache-file=FILE Use and save the results of the tests in FILE instead of `./config.cache'. Set FILE to `/dev/null' to disable caching, for debugging `configure'. -help Print a summary of the options to `configure', and exit. -quiet -silent -q Do not print messages saying which checks are being made. To suppress all normal output, redirect it to `/dev/null' (any error messages will still be shown). -srcdir=DIR Look for the package's source code in directory DIR. Usually `configure' can determine that directory automatically. -version Print the version of Autoconf used to generate the `configure' script, and exit. `configure' also accepts some other, not widely useful, options. Scripting Language Introduction With the Bayonne package a brand new scripting system, ccscript, has been introduced. ccscript differs in a number of fundimental ways from other scripting systems in that it is designed for single-step timed execution from a callback event thread. ccscript is therefore a scripting interpreter that models and controls the behavior of near realtime sequenced state-event engines such as the Bayonne server. ccscript itself offers a programming model that is easy to embed in C++, that is fully thread safe, and that can be extended thru C++ class inheritence. It also offers extremely low call overhead, and has a two phase compile/memory resident runtime environment. Finally, ccscript allows direct runtime reloading of script images without displacing currently executing scripts. In the case of Bayonne, we extend ccscript to support telephony functions of the server. The main server offers extensions to the core ccscript language, and each driver can also bind it's own driver specific commands. In some cases plugins other than drivers will also bind extensions to the script interpreter. When the server is started, or when a new "compile" request is made, the server builds the core memory script image. While runtime replacement will happen in a live Bayonne server, it will only occur when a "compile" request is made thru the fifo interface. Each script is composed of three parts; an event flag as appropriate, a script command statement, and script command arguments. Events The event flag is used to notify where a branch point for a given event occurs while the current script is executing. Events can be receipt of DTMF digits in a menu, a call disconnecting, etc. The script will immediately branch to an event handler designated line when in the "top" part of the script, but will not repeably branch from one event handler to another; most event handlers will block while an event handler is active. The exception to this rule is hangup and error events. These cannot be blocked, and will always execute except from within the event handlers for hangup and/or error themselves. Event handlers can be thought of as being like "soft" signals. In addition to marking script locations, the script "event mask" for the current line can also be modified. When the event mask is modified, that script statement may be set to ignore or process an event that may occur. The following event identifiers are considered "standard" for Bayonne: identifier default description ^hangup or ^exit detach the calling party has disconnected ^error advance a script error is being reported ^dtmf - any unclaimed dtmf events ^timeout advance timed operation timed out ^0 to ^9, ^a to ^d - dtmf digits ^pound or ^star - dtmf "#" or "*" key hit ^dialtone - dialtone heard on line ^busytone - busytone heard on line ^signal detach notify while waiting for other trunk ^part or ^cancel detach conference/join disconnect Symbol Notation ccscript recognizes three kinds of symbols; constant "values", %variables, and @indirection. A %variable has content that is alterable. Some %variables are automatically initialized for each and every telephone call, while others may be freely created by scripts themselves. A fourth class of symbol exists only at compile time, $defined symbols are substituted when the script file is compiled, and usually reduce to a simple constant, though variables can be named for the compiler. All constants are defined in the [script] section of bayonne.conf. The following variables are commonly defined: %id id, timeslot, or trunk device number %error last error message %date current date %time current time %session.id global call identifier %session.digits currently collected dtmf digits in the digit buffer %session.count count of number of digits collected %session.starttime time of call starting %session.startdate date of call starting %session.duration current call duration %session.callerid identity of calling party %session.calledid identity of how they called us %session.home initial script invoked %session.schedule script that was scheduled %pstn.dnid did number if available %pstn.clid ani or caller id number if available %pstn.name caller name if passed in callerid %pstn.redirect if origin is a telco redirect %pstn.ringid if distinctive ringing is available %pstn.infodigits if telco infodigits were passed to us %pstn.rings number of rings so far %policy.name name of policy for this session %policy.member nth member of this policy %policy.* various policy variables. %application.language current language in effect (default = "english") %application.voice current voice library in effect (default = "UsEngM") %application.name name of application grouping %audio.volume volume level in 0-100 for play and record. %audio.extension default audio file extension (.au, .wav, etc) %audio.format default audio format (ulaw, alaw, g721, etc) %audio.annotation annotation of last played or for recorded file %audio.played samples played from played file %audio.recorded samples recorded to record file %audio.created date played file was created %audio.timeout timeout in a play wait %audio.trim minimal number of samples to trim at end of file %server.ports total ports on bayonne server %server.version version of bayonne server %server.software software identifier; "bayonne" %server.driver which driver we are running %server.node node id of our server In addition, DSO based functions will create variables for storing results under the name of the function call, and the DSO lookup module will create a %lookup object to contain lookup results. Also, server initiated scripts can pass and initialize variable arguments. Basic Commands There are a number of commands that are part of the core ccscript library itself, and these are documented here. set %var values... set var=value ... set[.min|.max] %var values... Set a variable to a known value. Can also set multiple variables. Can also set a variable to the minimum or maximum value of a set of values. clear %var ... Clear (empty) one or more variables. It does not de-allocate. init %var values... init var=value ... init[.min|.max] %var values... Initialize a new system variable with default values. If the variable already exists, it is skipped. Optionally multiple variables may be initialized at one. Can also init a variable to a minimum or maximum value of a set of values. const %var values... const var=value ... Set a constant which may not be altered later. Alternately multiple constants may be initialized. size space %var... Pre-allocate "space" bytes for the following variables. select value match label [..match-label pairs] [var=val...] Select is used to branch to a new script based on matching a value or variable to a list of possible values. For each match, a different script or event handler may be selected. Options include "select.prefix" to match string prefixes, "select.suffix" to match by tailing values only, "select.length" to match by length, and "select.value" to match by numeric value. If a branch is found, an optional list of variables can be conditionally set. today[.date|.time|.unix] Creates a numeric variable as a date, time, or unix time stamp and gives it an initial value based on the current date and time. inc[.day|.hour|.min|.sec] Increment a variable, perhaps with a specified offset, otherwise by "1". Inc is aware of "time" units and can adjust dates by number of days, or times by hours, minutes, or seconds. dec[.day|.hour|.min.sec] Decrement a variable, perhaps with a specified offset, otherwise by "1". Dec is aware of "time" unites and can adjust dates by number of days, or times by hours, minutes, or seconds. goto value [var=value ...] Goto a named script or event handler in a script. If the goto is successful, an optional list of variables can be conditionally set. try values... [var=value ...] Attempt to goto one or more labels. If the label is not found in an existing script, the next one in the list will be tried. If any branch attempt is successful, then optionally variables may also be set. gosub value [var=value ...] call value Call a named script or event handler as a subroutine. If the call is successful, an optional list of variables can be conditionally set. load[.get|.post] timeout url [variables] Invoke a URL thru the plugin XML parser. This internally creates a special script set. Either the get or post method may be used, and an optional set of variables may be specified for the method. return Return from a gosub. pop Pop a gosub off the stack. if value op value label [var=value ...] Used to test two values or variables against each other and branch when the expression is found true. There are both "string" equity and "value" equity operations, as well as substring tests, etc. Optionally a set of variables can be initialized based on the conditional branch. for %var values... Assign %var to a list of values within a loop. foreach[.offset] %var %packed Assign %var from items found in a packed list. An optional offset can be used to skip the first n items. tryeach[.offset] %packed [var=value ...] Attempt to branch to a script based on the values held in a packed list. Each item will be tried in term, starting from the offset if one is specified. If a branch point exists an optional list of variables may be conditionally initialized. do [value op value] Start of a loop. Can optionally have a conditional test (see if). loop [value op value] Continuation of a for or do loop. Can optionally have a conditional test (see if). continue [value op value] Continue a loop immediately. Can optionally have a conditional test (see if). break [value op value] Break out of a loop. Can optionally have a conditional test (see if). slog[.info|.err|.crit|.debug message... Port a message to the system log as a SYSLOG message. The logging level can be specified as part of the command. exit Terminate script interpreter. Bayonne Server Commands The Bayonne server adds a number of additional ccscript commands: hangup This is the same as exit, though it can be "trapped" with a hangup handler. function name [args] Used to invoke a function from a DSO loaded module. The result of the function will be stored in a variable named %name, based on the function name invoked. alog message... Post a message immediately into the audit log. cdr message... Declaire a CDR record which will be written to the audit log when the call terminates. import %var ...vars Import a variable value from "global" name space. Normally each Bayonne trunk has it's own private name space. export %var ..vars Export one or more variables into the "global" name space.' debug message.. Send a message to the debuging monitor. sleep timeout [rings] Sleep a specified number of seconds. Can also sleep until the specified number of rings have occurred. sync timeout [rings] Wait for a specific number of seconds from the time the call was initiated. This is a time synchronized form of "sleep". A specific number of rings can also be waited for. pack %var values... Form comma seperated content in a packed %var. unpack[.offset] %var targets Unpack a comman seperated variable object into seperate variables. Sometimes operations like "lookup" will return a list of values or data fields. packed char Allows one to specify an alternate delimiter for packing and unpacking data fields. once label Within a single script, once is gaurenteed to only goto a new script (like a goto) "once". on trap label Allows one to test for a previously blocked signal and see if it had occured. If the signal had occured, then the branch will be taken. answer [rings [ringtime]] Answer the line if it has not been answered yet. Optionally wait for a specified number of rings before answering, and allow a maximum inter-ring timeout before considering that ringing has "stopped". If the rings are stopped before the count has been reached, then the call is treated as a hangup (abandon). collect digits [timeout [term [ignore]]] Collect up to a specified number of DTMF digits from the user. A interdigit timeout is normally specified. In addition, certain digits can be listed as "terminating" digits (terminate input), and others can be "ignored". flash offtime ontime Flash the line a specified number of milliseconds (offtime) and then wait for ontime. If dialtone occurs, then may be used as a branch. play[.any|.all|.one|.tmp] audiofile(s) Play one or more audio files in sequence to the user. Bayonne supports raw samples, ".au" samples, and ".wav" files. Different telephony cards support different codec's, so it's best to use ulaw/alaw files if you expect to use them on any Bayonne server. Optionally one can play any of the messages found, or only the first message found, or a temp file which is then erased after play. record[.append] audiofile [timelimit [abort]] Record user audio to a file, up to a specified time limit, and support optional abort digits (DTMF). Optionally one can append to an existing file. dial number [..more digits] Dial the specified telephone number. A "F" may be used to flash the line, and a "W" to specify a wait for dialtone. dtmf digits [...more digits] Generate DTMF digits, like with dial, but do not perform call progress analysis. transfer number [..more digits] Dial the specified telephone number and then exit. This is in effect a "blind" transfer/call release, and should use appropriate digits to achieve this effect. hold Put a call on hold and release the trunk. Script can be restarted by a hold-recall from the pbx, for example... pause milliseconds A short script pause. map[.prefix|.suffix|.absolute] mapname keyvalue [prefix..] lookup a key value in a named map table. Optionally strip off a "prefix" from the keyvalue before searching if the prefix value is found. When the key is found in the map table, the specified script is executed with map variables set. Suffix mapping can be used to reduce a route by the reverse order digits. request expires group script [parms] post a request for processing by a named trunk group. This request will be processed by an idle port in the specified group, or when such a port becomes available. The expiration allows requests to become "stale" afer a certain timeperiod if never processed due to no available ports. start offset script [parms] start a script on another trunk port as offset from the current port %id. Hence "start 1 test" starts script test on the port next to the current one, for example. Normally, a large offset like "start 24 test" might be used to start a script on the next T span. Start differs from request in that it starts the script immediately, and if the script cannot be started, it returns an immediate rror. libexec[.once|.play] timeout program [query-parms] Execute an external application or system script file thru the Bayonne TGI service. This can be used to run perl scripts, shell scripts, etc. A timeout specifies how long to wait for the program to complete. A timeout of 0 can be used for starting "detached" commands. Optionaly one can set libexec to execute only one instance within a given script, or use .play to run an external tgi that will generate an audio file which will then be played and removed automatically when the tgi exits. speak[.any|.all] phrasebook-rules words... Used to impliment phrasebook rules based prompt generation. See PROMPTS.TXT. tone tone-name [duration-msec [repeat]] This can be used to emit tones defined from the bayonne.conf file. has keyword label Perform a branch operation if a specified keyword exists (as in a test for a bound module). missing keyword label Perform a branch operation if a specified keyword is missing. schedule name or * Select alternate scheduling "name" to be in effect or use "*" to clear. signal trunk [msg] Send a signal to a trunk in a wait state such as joinable. idle timeout Set idle timeout value. read %var... read.from script Read data lines embedded in a script into a set of variables. One can also specify the script to start reading from. data values... Embed data for a read statement in a script. gather %packed member Gather a packed list of the names of all scripts that contain a specific or named ::member script. This can be used to determine what scripts or apps are present and to generate a menu based on that at runtime. swap %var1 %var2 Swap two variables. alias %var %newvar Alias a variable so that every reference to %var will automatically goto %newvar. dirname %var Much like the shell dirname, to extract a directory name from a path. basename %var [extensions...] Reduce a variable to a simple base filename, and strip any of the optionally listed extensions from it. fullpath %var fullpath If %var is a partial pathname, then merge it with the passed path to form a complete pathname. insert[.offset|.end] %var values... This can be used to insert new digit values into a string either at the start, or a specific offset. delete[.offset|.end] %var patterns... This is used to strip patterns of digits either from the start or a specific offset in, a digit string. If a given pattern is found, it is removed. chop[.offset|.end] %var count... This is used to chop out a specific count of digits from within a string. trim[.offset|.end] %var count.. This is used to trim leading and trailing digits outside of the range of count and offset specified. It's the inverse of chop. Optional Commands Some commands are only implimented by specific drivers. The missing and has functions could be used to test if your driver supports a specific feature or function. The following may exist: join trunk duration Join a joinable trunk for a specified duration. wait duration Indicate we are joinable for a specified duration. rtp address portnbr [portbind] Connect a telephony port to a RTP session directly. duplex recordfile [playfiles...] Simultaneous play and record. enter id Join a TDM conference resource. leave Leave the currently joined conference. detect timeout Perform call progress detection for a specified timeout. Phrasebook Rules Introduction Bayonne is provided with a standard "prompt" library which supports prompts for letters and numbers as needed by the "phrasebook" rules based phrase parser. The phrasebook uses named rules based on the current language in effect, as held in "%language" in ccscript. Phrase rules can be placed in bayonne.conf proper under the appropriate language and in application specific conf files as found in /etc/bayonne.d. English "rules" are found under section [english] in the .conf files, for example. Phrasebook prompts are used to build prompts that are effected by content. Lets take the example of a phrase like "you have ... message(s) waiting". In english this phrase has several possibilities. Depending on the quantity involved, you may wish to use a singular or plural form of message. You may wish to substitute the word "no" for a zero quantity. In Bayonne phrasebook, we may define this as follows: in your script command: speak &msgswaiting %msgcount no msgwaiting msgswaiting We would then define under [english] something like: msgswaiting = youhave &number &zero &singular &plural This assumes you have the following prompt files defined for your application: youhave.au "you have" no.au "no" msgwaiting.au "message waiting" msgswaiting.au "messages waiting" The system will apply the remaining rules based on the content of %msgcount. In this sense, phrasebook defined rules act as a kind of "printf" ruleset. You can also apply rules inline, though they become less generic for multilingual systems. The assumption is that the base rules can be placed in the [...] language area, and that often the same voice prompts can be used for different effect under different target languages. The speaking of numbers itself is held in the default Bayonne distribution, though the default prompt list can also be replaced with your own. Rules can also appear "within" your statement, though this generally makes them non-flexible for different languages. Speaking of currency "values" have specific phrasebook rules. Currency values are also subject to the "&zero" rule, so for example: balance=youhave &cy &zero remaining and using: speak &balance %balance nomoney can use the alternate "no monay" .au prompt rather than saying "0 dollars". English The following default phasebook rules are or will be defined for english: &number speak a number unless zero &unit speak a number as units; zero spoken &order speak a "order", as in 1st, 2nd, 3rd, etc. &skip skip next word if spoken number was zero. &ingore always ignore the next word (needed to match multilingual). &use always use the next word (needed to match multilingual). &spell spell the word or speak individual digits of a number. &zero substitute a word if value is zero else skip. &single substitute word if last number spoken was 1. &plural substitute word if last number spoken was not 1. &date speak a date. &day speak only day of the week of a date. &time speak a time. &primary speak primary currency value (dollar(s) and cent(s)) &local speak local currency &duration speak hours, minutes, and seconds, for duration values. &cy speak default currency (either primary, local, or both) Number Prompts 0, 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 30, 40, 50, 60, 70, 80, 90, hundred, thousand, million, billion, point Order Prompts 1st, 2nd, 3rd, 4th, 5th, 6th, 7th, 8th, 9th, 10th, 11th, 12th, 13th, 14th, 15th, 16th, 17th, 18th, 19th, 20th, 30th, 40th, 50th, 60th, 70th, 80th, 90th Date/Time Prompts sunday, monday, tuesday, wednasday, thursday, friday, saturday january, february, march, april, may, june, july, august, septermber, october, november, december am, pm Currency Prompts dollar, dollars, cent, cents, and, or TGI Services Introduction Has yet to be written... Wrapper Introduction So, you want to integrate Bayonne with the Web? There are numerous reasons for wanting to do this. Perhaps you are building a unified messaging server with Bayonne, or are trying to build a "click to dial" front end for a Bayonne call agent server or as a compliment to online customer service. While on the surface these may sound similar, they actually are not at all in operation or implimentation. Using Bayonne with an existing site Starting with 0.5.15, a new Bayonne executable, the "wrapper", was introduced. This is typically used to bridge between a web server, typically running under user id "nobody" or "http", and a Bayonne server, typically running under user id "bayonne". The wrapper (bayonne_wrapper) acts as a simple "sudo" facility, where you specify which scripts the bayonne wrapper will be permitted to execute based on the original requestors "user id". This is done in the [wrappers] section of Bayonne.conf. Basically one enters the user id and a list of permitted scripts. This list of permitted scripts always execute from /usr(/local)/share/bayonne/aawrappers. Bayonne_wrapper itself runs as a setuid executable, and the scripts or shell commands found in aawrappers are given the user id of the Bayonne server. These scripts also receive useful information in their environment space that is similar to "TGI", but without port specific information. In particular, a wrapper initiated image receives the server software and version information (BAYONNE_SOFTWARE, BAYONNE_PROTOCOL, BAYONNE_PLATFORM), the token seperator to use for fifo control (BAYONNE_TOKEN), the Bayonne node id (BAYONNE_NODE), and the location of the Bayonne fifo and control files (BAYONNE_CONTROL). In addition, the defined trunk group policies are passed as "BAYONNE_POLICIES". No "PORT_xxx" symbols are passed since the wrapper script is not nessisarly executing on behalf of a specific and dedicated port resource. NOTE: These symbols were originally named "SERVER_" in bayonne_wrapper, but were changed to "BAYONNE_" starting with 0.5.17 to avoid conflicts with CGI initiated scripts. A web server or any other application can use wrapper to invoke executables in aawrappers that manipulate the Bayonne server in a controlled and secure fashion. A wrapper can be invoked thru a CGI and then receive both the web server's CGI state information, and the Bayonne symbol set. A CGI executed wrapper of course can send html back thru stdout to form a web page for the user. Starting with "0.5.17", Bayonne wrappers can also be used to execute scripts that require interpreters in a fairly direct fashion. For example, if we have a "webdial.cgi" script written in perl, you will be able to specify as the first line of your script file: #!/usr/bin/bayonne_wrapper -perl This will re-execute the script with the perl interpreter under the specified user id of Bayonne. Similarly, one can then use -bash for /bin/bash, and others for other common shells and interpreters. This provides a simple and direct means to integrate cgi operation with a Bayonne server. In fact, one could use the alias map of apache or other web servers to map the aawrappers directory under a "/bayonne" url as a convenient means to access commonly used wrappers in this way, and in the future some scripts will be provided in the default distribution of Bayonne for this purpose. Running Bayonne seperate from your web server When you have an existing site, you may not wish to run web servers on Bayonne themselves. You might have a e-commerce "site" you wish to add Bayonne to provide some service, but this need not mean that you install Bayonne on your web server farm, or that Bayonne need even run a publically accessible web server of it's own that has seperate or additional security issues. Bayonne_wrappers support the use of "ssh" to invoke a bayonne wrapper application on a Bayonne server from a remote machine. This is done by placing a truncated /etc/bayonne.conf file which indicates the node name of the Bayonne server it should contact, and the wrapper permissions to use. The "bayonne_wrapper" will assume to automatically use ssh if the /usr/share/aawrappers directory is not found on the local machine. On the remote (web server) machine, you will need to create a bayonne "user id". This user id should contain a .ssh/config "entry" with the same name as the Bayonne "node" id in the local /etc/bayonne.conf file, and should list the hostname to actually contact. You will also need a passwordless ssh key to use between the Bayonne server and the web server. This will allow the bayonne_wrapper to automatically hop between the machines. The bayonne_wrapper can be symlinked or placed in the web server's cgi directory under the name you will execute the program in "aawrapper" on the Bayonne server under. Hence, you would take bayonne_wrapper, call it for example "webdial.cgi", and place it on the cgi directory of your web server. Since there is no local aawrappers directory, it will initiate a ssh to the Bayonne box and then execute the "real" webdial.cgi from the aawrappers directory there. SSH does not automatically preserve environment state variables. While bayonne_wrapper has supported ssh for awhile, it is only with 0.5.17 and above does it now preserves key CGI environment variables when it hops between the local and remote machine. More on running web services on a Bayonne server While wrappers do allow one to execute Bayonne in conjunction with a web server, this is not nessisarly the most efficient manner to do this. A higher demand application might suffer from the performance hit of executing cgi. However, there is one other option currently available. Certainly one can execute and access Bayonne resources directly if one places a web server on a machine running Bayonne and then has it execute under the same user id that Bayonne does. This allows one to use one of the various highly efficient "mod_xxx" intepreters (like mod_php or mod_perl) to build a web integrated Bayonne service rather than requiring cgi wrappers everywhere. Incidently, Bayonne can of course alternately be executed under the same user id as the web server. Which one to change probably depends on your actual need. You can of course also run multiple web server deamons, and have one of them execute under Bayonne's user id. Corba and other future services In the future we are looking at using Corba. Corba would eliminate the use of ssh and the difference in operations between a local web cgi or server application invoking services on a locally resident copy of Bayonne vs a copy running on a remote server. The Corba interface for Bayonne will be in the form of a plugin which accesses Bayonne server resources as a "whole". Hence, one would have a client object that represents a Bayonne server which can be directly manipulated thru Corba IDL invoked methods rather than thru control files and fifo's. Of course, not all languages have commonly used Orb's, and I am not sure if there even is one for php, for example. Still, a Bayonne "orb" interface would provide a direct means of controlling the server as a whole. For the desktop user, and to telephony enable desktop applications, like pop-up screens when calls come in, or dialing names from an address book, TOSI will be used, and Bayonne will offer a TOSI server for desktop applications to access using the TOSI interface library definition. I do not know if TOSI will also ever be used for the purposes of Web integration, but it is not impossible. About this document ... Bayonne User Manual This document was generated using the [62]LaTeX2HTML translator Version 99.2beta8 (1.42) Copyright 1993, 1994, 1995, 1996, [63]Nikos Drakos, Computer Based Learning Unit, University of Leeds. Copyright 1997, 1998, 1999, [64]Ross Moore, Mathematics Department, Macquarie University, Sydney. The command line arguments were: latex2html -nosubdir -split 0 manual.tex The translation was initiated by David Sugar on 2001-04-21 _________________________________________________________________ next_inactive up previous David Sugar 2001-04-21 References 1. file://localhost/home/dyfet/src/bayonne/doc/manual.html 2. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00020000000000000000 3. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00021000000000000000 4. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00022000000000000000 5. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00023000000000000000 6. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00024000000000000000 7. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00025000000000000000 8. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00030000000000000000 9. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00031000000000000000 10. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00032000000000000000 11. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00040000000000000000 12. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00041000000000000000 13. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00050000000000000000 14. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00051000000000000000 15. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00052000000000000000 16. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00053000000000000000 17. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00054000000000000000 18. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00055000000000000000 19. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00060000000000000000 20. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00061000000000000000 21. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00062000000000000000 22. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00063000000000000000 23. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00064000000000000000 24. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00065000000000000000 25. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00066000000000000000 26. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00067000000000000000 27. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00070000000000000000 28. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00071000000000000000 29. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00072000000000000000 30. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00073000000000000000 31. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00074000000000000000 32. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00075000000000000000 33. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00080000000000000000 34. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00081000000000000000 35. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00082000000000000000 36. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00083000000000000000 37. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00084000000000000000 38. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00085000000000000000 39. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00086000000000000000 40. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00090000000000000000 41. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00091000000000000000 42. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00092000000000000000 43. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00093000000000000000 44. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00094000000000000000 45. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00095000000000000000 46. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION00096000000000000000 47. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000100000000000000000 48. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000101000000000000000 49. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000102000000000000000 50. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000110000000000000000 51. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000111000000000000000 52. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000120000000000000000 53. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000121000000000000000 54. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000122000000000000000 55. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000123000000000000000 56. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000124000000000000000 57. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000125000000000000000 58. file://localhost/home/dyfet/src/bayonne/doc/manual.html#SECTION000130000000000000000 59. http://www.ostel.com/ 60. http://www.teklab.com/ 61. http://www.mysite.se/ 62. http://www-dsed.llnl.gov/files/programs/unix/latex2html/manual/ 63. http://cbl.leeds.ac.uk/nikos/personal.html 64. http://www.maths.mq.edu.au/~ross/ gnucomm/title.html100664 765 765 2041 7513706040 12364 0ustar rsbrsb
It is now safe to compile your phone system - Rich Bodo





It is now safe to compile your phone system


Rich Bodo


GNUComm Developer


Download tarball


Download zip

gnucomm/progression100664 765 765 37361 7513704522 12712 0ustar rsbrsbPNG  IHDRK* &sBITO IDATxw|Ul )$!$ЛFDJ U @DE""bA$ !@n6;# ;sgf|vg{f9$*E{  ܝ)@ 0;.u㸠8_0^luOᔡfj.;L9ʈvyy-.U,)4@Mؚެ\.wJ:Ic? !B<+gku6Xewcly"&V+vX:kn"d[lBE#, Hp@fjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjg^рx777?Im y{{c4Q:tąF [Q///h__ߺ:́H5 +5`|8=(K%ϊR `A1>!+Fc@)(CfF$I<$$}ݯoSG*nV0+,BLJgJjf**//73N}TE?˙?yrB gãC'QWWǬ5U)3pن?8p@(CʱOxSE@>(C辊в ([nZKeg>@T[FaIBBƥ z-pyb2 wƍ7n6QR-]VclhݺuG}_~>hϞ=ab)eW/1j%%%999'OM_~m۶Uh9PSw [v<|ڽggg7440ov{5sY P8[_xS G|uuuΝ_\\Lrssܹ3ޣAң~sUN KZigee17x {>}gX¥%F8י![nݺuc"Z_E (=====!h:uD+νN%T7+Y;&&&&&ZPP@=333'''''gݺu}I&N2 ?ꬥ7kyFQIN;<-BFС;t`tQǭ.{ι:*-{X:gX(,,~yNG {߾}%a (!&}yLL̤_PP@"}{ԩ;…G,-͙ Įp<+jhgddHIVƣ5۷o߾}EEE܍7"Cw)_V/0Wa*-#<9=|8FyYYY_N""**v;wvsssDN%<ɾjG)bMhΌeXm[dY)Z&LwF~'.wŴϝ;WWWGݻ7-xz[p6"*3% /N8p444deeQO>>z*,,OMM-lW8-ZT=p@jЀgQl޼҂aA0GD;b|p^Q=TجK.x-$C W 2iiiﯮ:4((Qüg#2';F>LgR^lK.Tج_~, ((4*VVVF҅/y\Kʍw۷ R}||H5[hB@&Q$n54A0cHebfͥ'mڴTSO6B GS&tÇSa3zr'| u@wy y:⒦(,,T}z}СC2DgeeL&$^}gq*Q+b8MӧOSl:jУG*lֻwocrɓ'3SO5wҥKODDD^Dɐm)?Zh֦fiBlZֆOEEEjj/oݺeG2!;;)蒒2ʢFnٲE<Շ}8)!ӱt ə3ɡS u022 =5r^NJJںu+=}OkcǎQϭCJpSWWwA]PP@4h6k}?`hԨ/o߾_~E,yܹsرZJl@RpuJՇÆ }Ϟ=KEAAA̙3@SLϧ:N׬Yj޼y``E_5ŁVxiiMFH ; `ȑŸ-[n͙3 M0ڮPT#A .С[ouA^@)..~7F;v˗):33!d_Kv}TN>5`mS(++OW^]WWhFl8 6 ƍt'3w^A¡~j?Nmxw.n {,mj4K\A < dpW+++-ZOЇ~9,lٲ!ԳgO,++R}A9R}= B}7mP)d)k9OΔWAyuuҥK鱴(u:y5N>8mɚ=o0Bbo/_^VV0`@RRO<.qF4bEL!xrq` ݟ)j~=m}8tҲ9㥮? ,?p/e˖CE18^"im8^Hke~ufy/u-[ZMo߾/((h۶pۢ$)x[aj9U;-f!zƍ?#jў={&&&|r[]K90}`N![Jr-eS(gΤ*Uyң֭[S&uuǎ0_VV c'~d<|[bk 3;w5dF?!:ux#F=n޼Y><""-Jf&i֭v(۷OHH5jׇSNm&NLLv\hѸqeӧ/\C0: s@.I;vXxqNNBM6-0aRv^~=B襗^mҐ/=*q&i׮]ݻw-[5Ϗ \ܶ(eHHH8s BYf޴i[2˜۷WWW?۷mPCOuŽdm߿?!!ɓwygƌ MMئLea]^Cߟ'44>mWSSEH>t{ᶂNǏOHH8x B($$䭷ޚ3g/FgÆ $I3F7 Nosԩ}!͛k`憆-Z:uo߾Q$ٳgBoƛo.qHKK+))ܹ3n@J%33sŻv"I^7os g@uC<.\x_$I__9s[>MQQQV4ͭ[ww>\I&&&O&{֬Y , mSHNN6 #Gy;(\\z5))i˖-FkƌNxx8nI7nDPEw]u&MD |Wn޼(s!P˖-F#n[ prƍ%KP[yN>}…BeM4IsZDHaaҥKׯ_'LpBĦ*"">//^˖-[nN\hQdd$n$e˖-ZvРA o˅˗YFj41c$$$l*˹S^^NmY[[KĈ#/^,V"33{AAAEEEԶ#ɝ;wVX_WWWS[y.^k׮ 5Wt oQ//{.B(>>>11gϞŒNk֬ٝ;w233]M'å/\reee%B(66611fVPرΝ;zy(\:jjjVZgUTT .16сZխYf奥'x")) 62ڵkm۶***RX`{U:8-*֮]#{챤:8EC /pY̚{3nPӭZYfT)}pFA`0h!taܶ X"Al< B=zHLL>|}ݼy322'm7bth06mڴdɒk׮!tx{NzdxVtq0IIIBSN #FQB(++۵kĉqۢ6@b2mۖxPvF sO?-jPyÏ}ĩL_~%11ŋm.Z_Vrvv V8%c ^}Eܹ3!!!;;!ԦM KJSV:uŋaaas3P/$IZf0LXؽ{wBB_jٲ?ydnql'NSMG_ iӧܚ5kj*N.Nuu5s+WpۢNT$Yni(:p|"y睗_~Y[y jGEEEDᜈ ?r|pQPhhg͚x& n-<2%Ǐ/[Ak&.]BC>䪓S^ݻw {EΝ;^퀈PdsSQiM2{̂fu7HNsWP#"fky #w,%jWB8}> jbч+~,80cǎ>}DGGŅV8C\5U dFqiXv8UE2e nC\ "c2̘4<;S_ni? ]`5϶YqmǧҐv8oY05; =$3;eo;) Ӡcv6l@ /68ј ƆP8t[XX[o߾@\;cp cSSP)`^KfБ66oޜ$ɛ7o6Ç RYYt&]SټysCCó> ƂLбcܝ;w>3mqEpV};m? /((ЙJfgsB'Nߴ%#86z9 ꈈ+WDFF6EQsm3ؾ}{MMMAQRQ,ئpssR^߳gU򼖃֭^řՠ|w]]***BBB;|(m: Eͽe@̀@̀@(/-\KXS(IÅxK?AH#d>{/}$$$!TQQ9Y>#kNx&{x#AP]9 l+pW/+LvCG`z;yY;~IHCIt &s g &P…Hičll5=;bT\HIDATZ:en+\8yP5E}}ܹsP<6f*|bA"ۛ*@ W,Ço۶-??7oޤd^H%\xb6圳G١2_6F(O;3Cvf16~TJm۶[n ƹ8xK䃰ἊtE \ye1{S8 .Fqٲe{q6[nݦL}*%p111^5kVVVVPPʕ+]?$Cyp@L&h"V۲e4!thV@@@?3yǏ#NrJzh"ҕ1 $jժnݺ?~<"""--￧ 6NׯO2СCW fNt$0I}].]:Cرc oW(N3 pڴi{E5j + ZŜiH]5xJL){rroYUUzQFY+9)]Kͮe`9' !oߞ1cݻB=ܷ~C6 eƢZ4fk^\&i&;w޽{w``͛wvMdíBڸ#9)g)--5k֯[n]DD}YFvj, 7}qȟK y,iӦ!۝-GhҤ5Qi{ּ+{UH=yEEūeРA֯_߲eKssss{g<;;fذannnvPYYy1 P0]8c5 Yk-}\K8JϮ]B7oL&3L&/I=Nҥ&[5$g*++'NH)jyyy,|r6m藝/!!.2b'{쉎NII/<2&22rʔ)tSwPƍkhh@ݾ}͛bZzZ̕@\p3f̈+,,|Ο?ԭhݺu/ ={LΝ;E3%͑ ^n]F/_~Ѩ(F .իWvž|ƌvZ 4M6m~wQt=0 {={6${}EKMMMBSN%Id2ٝ۹sB:u"IRӉfK"k09vX׮]W^dɒ?cǎW^y%77s_}B G&"kԨXF&wqZ_Lnݺ]vɛ6mݾ};\t !DU .wN:ս{?>?YҥKsA^Z,M2}8( Et:;C ܹٳgq[dNmmmNB'N1v!De˔gv!`ye;vXSS#V:M8@CԠvڝQ\|W^A}T]C,04. '|y䑍7QhѣGԌ?^0. .]4iҤ3g1{O>Qy׳۵kf3.2 `X|BUVmRSSBNuS9s p\rC1}{ W\C]7444jԈ .(F/F5o<##EjԌc:˗/#Zn]hc ??ʔ)GAM8/hҤ n3wȵk:Z$ۮ]9r$,,lΝɊ׬Ym6 &:å`ڴiG3fժU?3}tʕ+wf~PӦM'؀NѣBhȑ.*?tvA(ܺu+..z-))mmPSy䑪*d4ceeS r)@΅7((mFI0-??bpgQRR2s~ !4|.<<Q?m4Ч~ڳgOgpgt}Ν;o7n'o^?f̘%B ˇݻ(..'S^^>{۷#bcc׭[עE Q9sM6ׯDNw3dݣGM|֮]kw!ٱcAO~!>,Y|8Ell,6 VVV7oF=S6lhݺIō7LB'|ҧOʅٜWPh-[}xZZZfB_}r]7Iz>7RXX DA>\AܻwoܹTK߸qc۶mqSZja)w0Xׯώ9ty޽{ʕ[n h9 PSS3o$ɾ}&''oQRPP0i$$.]JUԥ|n3Gڵ5k<==.]zqȻaرÇ7ow H[mm-o=%6y̟?!ԢEr,Pb)]ŀG'ŋz9t ݏ?ŀRP@@! íVXa4SRR:GZb _z%$,Yz+B).ípٞ={._ {̙3j`7n\yya~m\f@#y^?cСCd)xICBB±cǚ5kBt$U8$yR 8/7#33sҤIYYYnnn[d طoڴiSw"XXnCT)ZN%h^}Z+O" b4SYYn*QR-|n)MǙj*99Ҁ*ILL<|pxx͛16)*z[Jpz0$~dgϞ`|GnnnTE/fs*JR8bTP\\<~xɔ(J ٜbVYܒnh4?x>ns|SQCˇS0:G}t~ 9>ܩ(ÇSrewqGۈU3qD&($'Mt{lɒ%3wd.yU U+Vؽ{wpp֭[}#lhRt#mfIHY\YYDԩSA-Zmp.A\f߯}F6$vݗ+7ܹ3f̘s>9vBhpEii)PbD3Ac؅#Yl_yp0 &L8qDƍձ*ISLqF~-[8]KtMξ}?uE~ĉ]nݺ!4i$u_~Ν;n@.7L3fذa1b^D,X@ƍ@Fh4ӧO#Y nƌ_{g}9!ؘhРQ233ΝZn]۶mq9qy9?L>/]ȗK(ȑ#^^^| n[zԨQ:n̙Fm\-+uQgΜIGy嗯^ڭ[?-C}~ԯO>:t?>n[۲e߶m1aIuuرcyo,tÇt:CzCڻ.;\Eđ#Gp(YYY- | G@@Yj^!?}v#ZE>$Yft)S<qѣGkӧ79No˖-Κyݻw[:?^Z7***;;ۦes!9W u~BCCCZZZлwoxYjUv,X0~xooo/ n_xݻ/1U85lӝg%8۟n:Lm۶ VʊbG||ą*?ph4#GQSH6B W B\oK6,.x5{}=a~-~ P': mjGvtMH@@1#^P8P8P8P8P8P8ݻ700P-! )|ҤIM4Ɋ)Pxll,B/(BɸMp$~iجY={JopDŋcǎh4yyy[m w޽{NNBUV o@V";;;99j~#z0>Ν;)4o<4r0?qDxxu]"xOIII*++onu6gܹqqq o@}\xz>Z+JHHyrnK,ҥ˛oj6s=z 'N9p Ir̙z_y|m|ӧOtR&MpV@iiiܹuѣG6t;w;w p߿Ȑ!>>>.\hӦ ns@> (P ,Y?DGGϝ;-`PKΥKwn0?裏6l|3f> ׯ6mZXXXnn.te˖1c6lj|̛7Ν; o@ȁ흓6AeddЫ G׿$I .\pM>^0~$h:QF l) f~} wm2l-Ji2ڊf@f@f@f\E၁A g9O ~Sᕕ$I$$ + @f %oKg@\D Wf;3 tK@B7ΙidNE,iOyqP9F,+!DM8 ;¦zȘe9@_wܱT&y$\E¡u &ppM@f@f@f@f@f@f@f@fԯp2W Szzzƍ%(h4JP Uv&PV rڌ7IENDB`gnucomm/progression.png100664 765 765 36022 7513704522 13466 0ustar rsbrsbPNG  IHDRK* &sBITO IDATxg\W,EĮAWa7&O,hԨ{5FQWh*B,wY͸3;;3;gfL9uO?I--#59Щ S=8./jnXX_A%efGk7M2cq?0 q llGfG8RƎR[m_^.TSef>);n%sG>-}|+k%Vgfz;/z/Q.@u8%t٣Z 5z38TQ)sz/ǗlGlmX;>|Jx~W/e !ڦtl,_n^xp\c?CB4^#Vʬ5ʦ?ߍ%9ZL&k러OdS-qW(K8Z}ZZ* ٖ.sA"ǥfK/CN8 @̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@̀@͸Zĉ9tPII F/Njąoaa!F%%% n.]JEn]bpvM~wnnnV =~8nQ2~*ZV0,gB XirJTTTjj*A^xq@@mO 8'PKYs-XcӦM!!!)u点X:7r-Lga5::O<޽{~ 8!p9)2}֭[̙3?ώ;BBB+0@MíC/ܘ-eG F0aBzzz۶m_xѻw=z<{L6@M͡/FKo”"P5֬Y/lݺUxjpt_e̹tuKm9ZmѣG#F8rBk׮k֬\2u1dƬμњ,]lu8kUT9|plllҥ:ԠA;@p1pk׮}yyyÇСý{pptnRݻ===%O?%I w=nܸL__y3v8tN\(zڵ !Բe 6ԩSGTus0 ؿ&5ӧ^^^s̙4iX,a0>\١C* 8\L<966!S]c~~CǏVXѣGGC3gFGG9(/ᮮ]tqPtǏիWk׮%IQF6mjܸ#2+G/'O;á}Չ_zubbb͚5/_Jti&--mĉ%%%}&M.\[(ΈҥKիw)ShZܺ;/-Z믿MFŋΜ9[ 2psΝkذ۷۴i3v؂ܺq!޻x~r'NHҊGp\oEG @!>{/{رСCssslA;)\]5|#)ՂÁiذiǍ76h >>љZvu<5 i1#?w@p8JW-222>gggKgddXXH,ԫW/99yҥ>>>۷o q's8`GL81--M6ϟ?իWϞ=?^23`7p5k&&&^߾}!!!۶ms\vV״5Zyc+1r+Wt);;{qFFX /dcfO!zO+P/Vzȑ͛7.]:>>>$$dÆ &?F!ooAwI^BNej'l`РA׮]O ֱc >LrW۰7;h^[ϲggY>O{^Qbܹ300ĉ={""m۶eʔ1y~JQ [ ZV)tgϞ\}%ԑe˶mۖ 5jH: M9HStԉY>ߨݻwtoq,)>W":$\$IQ𔔔ׯ_S===)W7i:ՄLw&4h1Y\9K\tZSxCՉAFFe˖^^^"իRJygŒʕ+;΄r3u=}4Ug:^Z5ڵ ĨP3Zv_#Oz)W x@@@6m(cשSH@bpӨf6S)Y|{m}&f'XJHv3gΘ6$rwwoժf͚)9:d[Aʕo֬/@t O>J>+rt8zҬ'󓒒p}u7aT9:,m`0/\P\\Lkݺ5w}H@0 bJ7oޤ\}iS>pss%P2u8G=!DYҙ?~}o╦@7;iׯOuʚa0LiȽꑣy:u <U9sr+WLk׎2vʕP۵Z'|[#GTΝ+**|GCCCeیo.] jժ%Vׯ<<<+L9F}%֧Nɡ|[hiF1..n„ ޗ.]%x$+++11 k׮MM6K'PLN>=a„tN:eoPLL BիWwVK-xpeӬ@jVfUW# >ϤUVbB}^rŋJ)`$LBRֶm[zI˫}111.]*))L4%PS$8*S E${JN2܄rVe# ܰ6FʤI|8Bh޼ysh^XhiIǴfVee괤>͖mJJ>3ӧZ?~n7wq1[|-73b&Α)kʈYeb@Aٳ'22/--z. ///''' y [ژ#fŐa?MPmsdj)e'⩙jKjԚR={6zh? Fc~~>APJؿÇgggwyذado4`%; ͛7u3Z.jӦMCYFMKBP [PRR2hР?8w ntxNZs/^|ʕ+/_\ar[D\zu֬YAlذː2( A11B8bܹ.]QƢEpi X$55u޼y&66 p;:naĉ-[ĨF 7\~~=^%ÅXHIIYdk\\B 4h4N>Yf=zՍ7pႛ^1$I ^]oqĉ;_x% . }}} qkQ$PJ%77wȐ!$I~r7"`L8ѣG͛7ꫯpkp@?8p ..;66  PVVֈ#B ,Sn9SGBhԨQϟ?o۶رcqky :*p8v?oڴInA)] pgɓ'ƍC-YZj8ܩ!Irذa/_ڵ!Cpa.pSqÇ-[v-m;/ߟ}p˱wR~ӧOZ .;#nݚ>}:Bhڵʕ- p@NV4hPq˱8\ pc…ϟZ?[u`6p"==YfǏ-:EEEZbR E{ȐCVBo^_1c(:m7pqٳNíi4͜9sjժ#*Jpbҭ[7\$yA ㏘XɄ .pݻWyh4r,۠j p)  ҝ3fܼy3$$dΜ9 Yp1>z(Lӭ1Y$%%-_M҅1\LZ-dGW.p@ ?ܬOeu_TR7nÅWǏG-[J*bp᪂$ݻ8 x///Nq)ܲr]zB XdHqqkqq1n- bXj 8\|0oi4^z]\M8. v8A<ciC`ᢠ/:<-g-M̦O53x$)>];OUf}fr{p((nsLl-92/+fVUqn}ʡ@K(&Dxi&:"~BV RKEqCXcEA1\MkʒmV:5XjCRp4|lo+ . .sW&9ʖvizGo^dY>?ҽs[*HowP`FQPEgfp<{56%Iy±3}߆ CeEAt@@)]L8\%ȳQpQPv=\nǻch4ZIIɡCDLVFcAAA~~~e!)j*GKMt:SF݋pP6š[nz шYrqqڵ G=zp ,P1Sb]\efeea 8 8 8 8 R 2XQ3_Xp)Ve=f[ZҦucYϪc's#AP]ʖ-kʰgNI"F <}foGL~~a-哲z8`?%dψYQ"p@l]V'e3T̀R:X8&k!qfg M<}(Xg>kvu}vv6kam]7֒$5Bӻw{͛7=zD9֍S1,٣|VW6 PZvڕKj0]O !C_pɒ%ˋދ:;;a͚5{7BQFQQQa#Y&N͛7?3fQF)Sfɒ%.p'h4.]ojUVݰaCBO ŵ< :pg<>>!駟YB ER1\رAK޺u믿 vN /^5_~Aue*U/~MTu|ǒ==ztff%K b_:Z* p=v]v!"""6nXjUSsqq޽ݷ߿_tŎrrr9&|!s UF#Fq߾}kצ~Z˗/;)jr[XXp8p VZݹs7oV^9~sssCUTI\N+Gy{{'OQ.1k׎2M)o֬}z^\\zGT|I~~ût-Z_&L;[o:lԨ}̜9355LD蔀Õɓ'CCCׯ_p3gԩS(tʕ & V\ٱcdž ڗN>}֮]KF^E|&6PPP0f*H6kڵkCAAABIIDATQQQ$ILS?B!!!$It:T:%CrrrXXʕ+Ν{w}=z74hO?!2!<<<@j_eˌFcFbccp-[޽[q27n@Q@ 7ntRo… ǎZrXe z XDM6[9!!!lݺuB"鴀eJjjj B...lpFկ_@4u:<Yqe^5k5nݺΝí-[ \"bW\AթSG4hi|F4i[ 7o=z4BhTYC,J848\. 9s5kn޼e˖Ej### oUKP &pYpA]x 1ce &׭[wբ'1\dpWpBOOOPjq+Ž;B^^^iiiHtE [nh!Dİap+­[Bk׮uDA8PRR?R#*W|܊jc}uPnB;J z8޽/-[[u&O|ڵk]AY@%\t`Ԫ$f͚){Yz={#tс.>:t'B}YbEٲeqŝ;wZdK;b&8 7n,UB(00p޽؀Nkڴ)BW^΋ٳy;.]P>5uf͚ͨЌ pc1m[L۷c3CyxxHA}]뫊 G~Pn֭[WbEܢl޽{ԠEQg ?8hKw{iРK*y*z>22277>7n9@^1رcEEEU.]dee3fϞ=:lذJ*/V^}ƍ1!&Lv}}MYBٿ?A.\,C>}Zyp;Zasrr&LuVP6m6m;,N*ժUۼy}pmqFOO~!))I_dۮ]n|ɀb=L:u͚5$I*i>zhРA$IΛ7*K p1fV^>o޼]6 }֭ۗ_~)wC[ȼдo&MԴdtt4BJ*YYYX"?~%w ={os&5%%/^ J*nyptٳg/^$444..qƸEFFF_|Aܹsñh0fIzRSS6mpB O~E5ٛ~geeuyԩd@%q@ ^`P~X)xIٳ0Os8pO$IA.3n˗ h˹sRKǏ/XuǎTC.`Ή `Ֆ6Ɵ0OqZfΜU'GQ|yܹsqk!+U{.n!*D g5}7%hƍWXX_0 [FuС7v%DItۅpKt5*M6v=s9}tŊnJuc*׫WU$[u5+'ԏ,55\rv(TsuqqٱcUP Wu(Jr8bj> \%ٳg7}UPt98LrK/ؿgϞkn̙pats&&&m۶M>^E1+tĬ%sNӧ̙hm[?>|ãf͚e8iK>G;/^ׯ_IIɬYڵk[οܼyh4֮]mnRTh0`'OZn=k,r*~,Xpo߾PJ%q:n0INN={Fٺu+58TV(=+W3}5 3fСr!Iɓ'ݛ*[lFFFʕ-]FlFe((jIVKq,wbW-$I80##e˖}2*,,0'"""/`M?00ZF8Rpղp#G+WnΝT!Am,RNS\긒6-u^p:gΜIĖ-[Lp(>>>eiaJ)xB {:afpp>%mW?vX@@۴LndggSΝ;u]  *kx^9:|%($ ѣs#&fEI\>y9cǎU EZxq|||ٲe~KɁ˗ 5]^8)R<Ϙ1 *U#&~&.CK3>;$O?nݺvʍ>}O<[n ՀD`ԼD-\I-Th3L c옙,ylz^yp0  p$?>n9gq.S)]6:sYk?3=,,l׮]JXlفJ.k.777r\1h4>|ӦMw^=J/FGGyjժfذa5j0ZvǏ' FQ3(z(S2dȐ{5kl…Xh4>}Tx:Tj2k򰺢oB۷#˗#ܹKC~~>B;TXQBȮСܺu+,,L'%%lEEE?3???___HNKJJ={VbEtڄI5jTQQСCU`＼Ȣc*9*fs y)ޥ/j~ q[l9uTcbbpkÇ߹sI&?n-|X`d!skvgggO2!x2e#իWٳ*ޡVfO=}x{Nfen)e4gjv4*+++""˓'OF_VZN7}S&m.q˗S8<)))66sժU%??w:nȑ{-G.X'ersf,𢢢#G$_׮]1ۍ5Zt)n- >B7wxLL͛7ׯ?uTZnݺ;w޽۷/AtYtݺutf0?8Qs]~ܺuӓ $ZFM۾};n-oKNNBTRgjx`Y#rQPPj @viYԍt~t<>>lGFN&igfS]$i@ Yy=jŘ,ZBu~sčeʔ[ ؛`)3-w-[Alڴi۶m{QzdSNl׮;^:n8ЪUի[03gl޼WFKFFF~z -P*t^:O^Nr1vׯX@1117nܨW^tt4n-ٳg7n9C75oߞ7oAk֬Q7n3!b nzXWAUF't]-Z622_~C-/>>><] )ߤ]^֤˜.;)GpookV!I&թSgոcVҴ69$-LÏ;VTT+.]v||hk׺3ԩSNl_ֲž|]`JBbŊϞ=Õ{^^(IyyyFSRR%kPRJF`)Sƺ0h zw/Y]JC33/Yd):v(Ç ѓ֭FcP"Ng-$IJ2{JĒhvbSf`nG ۽e/J-YX(6j:pP3pP3p@j;$IȨ pF#p8 5^\2n8F1Gy)tsQQp,$1[kX4q\΀n:kc򰥡TLk׮񹌠򮱪Zvp!uZnݣGׯsN_jG?}%jX{)xnnnnnnf/ݻ7sC,Ԛ`AF=L\piTK`#ܿ΋/ PBF199999vԚ`:K-[Z5e5;|- !k[. kj  Ϭ+WuSNzzM0p/ &>)ۗ u|rCqqC"kKCf^eŊu֍߿Zw_(`/\H9_bpSYayhQ誣hܽ{wϞ=*+f77]Jꑯ9Y{Fի5mT̺4@̭Pujbkf:K Lk>x0fKG$.@yZٺ'G@1#^p8p8p8p8p8p8;vm @V -A%;v8_BVVVqq1B`uG@dvv6U  ā$-Z?>88iӦfdd 2dÆ g p\vo߾W\h4wyw$p  /6iD9m(,,6mZƍ\ZFծ]{FqĉKUBҗM|7*THNN޳g.  yfn"*UKܹsBSNjdr._^z5m4((&M<|pѢEeZnݺ#FTXƍݫQF=ɭZy& BxiB˖-+UAxjٲe^ *dpׯߎ;t"\~qLLhyyy¦Mϟ[dff|F1@) SΝ;[$qqt:ww%&vb۶mԩӑ#Gpk{2{ 77Ν;VrILLl߾ו+WT3r6E@@t9YjP9bZ?z~„ TիW^jݺu3-*+:vh4ݺu(X"^t\3tg^^TTQFnnnҥ!Kc8EΝh[2 [k'Y}vi6'td|c];#o|L@̀@8˔)CA!_ Y#^p3˗II`W@eAЏ({[: *@g`r@M8ˈ;韩W^8c 物rNlg@&TK&4ћL7Y_;i7YP*w8BjK/]ӛnl2(;"''RU|,A89Qá pfp,k pP3pP3pP3p: p8p8p8p8p8gYþdm FoQ@aa!ܝ .\L鷰¸U.,;apRIENDB`gnucomm/templogo.png100664 765 765 15423 7513704522 12744 0ustar rsbrsbPNG  IHDR$ugAMA a PLTE""" ,IDATx]( mUn$6x;Po(AJP "T6(~2n0K=P3g}`С+(͌Q.`nt~5en&Yqt÷ͽ$q&u x^ (rF(j)pB@);C(NB.b~E *T6(bs CA /P[hGƌe#5e4?r!pAà؀S *,\]$H/^::Nq܇`@Y)I.v Ad}?PŒrڅ-7@YK 7Xy[ԠȺ<Jqq[FR1,34YM=ef!} ƆT.s@QvLAqlRLh5"hn/s,F)k79#[I,NG .(h `@0! ru#8Tހde]bc2'МtF52($=W)UgPa O@dT}'R*DjHSP:Xl[DI[2-@a)1I!p)$$٬{bm#Mڴ/]Fid%nQx"GģarV|2PN> JA&Zvf _u f٘*ո=֟Պj3Y PaSՊ3_#" WWpJNx"远YKbj"^Xe= QE3{m: kXk`qX*P awX=}ka! (ž*M[$vk^#3،6r do]Z { fmPBW'qHS E}skPbo@M@09̱5M:B"viQ/}s$ \%sgp0 3L)biMyH>q6aa#$nvzjJ1{x'ᓦ]4*:TG>M+/DPJEE׻\kNDp@rw)LKV}Pl`R-ƳNf0i^ݍ'9k( pʬ8Eaf`]Ԍc 9v ..DZTٙˁ!%ɕf/38DHkqT1P*FW~ܢbi$94"f/V4dg]F򶁥G<{gv$:eR|>[rk84I3=Ĭ'sk}*Y`gy_p/nnSSa ,A)V i{SEvLG ݺ0܀4O6?eSlE-LlKd=*BK*( JRB\إL m60яIz wJ"h9TNxP< 퀂@d\wAXd Z[0fͫ7Q1'є~ H|slGLk4o=t(@ëVǜDY]P@Ћj  0KPfn%a"^.('j݆eը4dEsƩh9P1yd=_ư֠SʽPh r{h@;{h@4R,JDn┬džؕ:(\X—3YLon!b ِ4uS31SSq˟Uٹ]$h𳞺6g~z"#NA=)8n(ZTЈ8Ds+P8Z'V`l7T6rq_s9LyMP7Rz` Rhހ$95Y4`T\ ĹcITܶ!_i)b]4)1 _@ACH[ȽY,agZ,9 ,(l%|Kn8Jc'cKeSOnIhɷ ȲJ>Bz %rPE]7ٸR ]Nm$J8t2JoGtUעhcy4EURC&kr.L{)hiQLP/ NI6jbQq9@KuY}ELX ;-2Hb*d?}d49 [D4KQ$V> WA4%Am(L-i> E.lS&'EHC\RxKd<)AoJHDՙ&GCtc.^z 2t%Yny1T G,34A4JVp>gR_ ЄU$ݯT PPI\ yHS}{TNPrz8 q+,kkþ 0xsb=bN){-zkI 2qvڤ ;j <A3Pժ820y8%Gse)WÅZ:bAqɎ)<"1XF@r@kPtP=i]H4?!̹1(0 }5  7rP 螵(TO2!ƀ֪ٛkCcED^dT a*s% `{C±YkP=9R(2kڦ֘nEwv߄"}Umz/^ DsP{ yKnr3g]ʀQ ^ߠyDF]5MF@h%]+> 1;bV $sJfLG=0+!o$(՝4ΆUeIaTcAc`4Έz~!֫鈖X' GO.8/Q =O-#O\,'bqT: A!#T}x$^hX[1'{p{C`(3XLQq);ZMnE *PQ{-ݨ&Jp8*[̒SςX>G(Q¼{ٲD9f / t.֩ )t(( qJ@|nj>(CJT+Q'FNQP~oH(a9%N]<ºQy1uȳj앏%mt4l]RMT zQ+ L-iν&Ήp- '|2nѼ tm%mcTP6>7?%١pmR亼@NU P '%Iolm}nhg m6rH` x#pc3$P(ER]kkewMKM PӅ6atiOO"q :AIV(BO븯#}KgInKfhIμ J.n<СՃxu%7VZ >tm@)==P'w'' ԷRx8!΍%JtlV1ʪ'\^1YtT}+&';TSGpзˢFާ(Qc$^gB;m#ReRyc<Py[($_>}O$I$hP{#ouUs R`Vhl66PvQ=T=,;Pg6cOߤ/OvJfr^YĻʄ {]P ΂loNW> \jq8!۟qtq)/fO@O8Th%6]gcվ^Qu[:i cIPL.ӋN{8zSE?IPr@4T0[N-|:m.w4a#S^ꔖqj3Fvt'Q"M3m)R>Zj'KOHH컜7 ⋦|ZZ(Z<On=;(;= yV}Eb[mo#]#сx %)g/KP[>qo=G.܊ywrG^_5ꂘ]l(Zn:3e%P>rj [/)@0$c㣼,F㘖,)?0ySA 79ebʋR`$/3Wu$j^.a`CSvPe}]Nyז-3K]MdN"?Z&vm6?)Psim={('e豫qI9_eQo-DV7rg7ݼ(Ǖʇb;|9)Pt~SWuʷrR~^>_ ʪ'z \r>PB%[|1( ]/ ]eP߇Of( +yLL_YVa ̷Q&/+YՠCYafT9{(^R(?hgߎ/&tiI'8/oPrj_,_ tPT흈[^༅p},*Pʇ82sIO ,C2ٮ8U_ d٧j2 -Pf I{@Y"ZFt:A@P}ߜa(ˁ~t4D K[=KA1&_ Jk*!(]X@VBGO)(C =?+wzVk@iiNj$'#jCdL)-2`UG PԷ;u{2{b a@n2 h=;u,0ѩmM-|n| ,uWSC6W'=m^ծѷ{uj*A/2:PPRub&!x%ÆK,mu^׍7 .SK0JJ@?;A $@q ˁu-iYѤ?ʝ-N}Js;6 󺳘K}7(/@a[۾њnh "(#^nve]oҭit'A4NtnEI?jP#Y`éHvU"Sm{ݩ[MP}o;,z͢=J@#V7kLO T#wU&ÑZahͺSP&륃$ipoj~әCi@Ġb+ň!znI[]B&SYwA$V;ǖ9c߿z}ffscn;򾦴=-tEfBОqu[-~bvk)eIz@߷י\n"g&7.yUq7up;o3zα^-C |S6 gnucomm/title.png100664 765 765 15614 7513704522 12241 0ustar rsbrsbPNG  IHDRNcsBITODIDATxOlw+іMH,o=PĈ}!E$ m1JcHl &DHELP&b@0;;ϡy;;|y]? @H8Bp $! @H8`AO ? Bq1.Z[noBpp-$x|*S3*^%@WBO0–fqm%"* 3i* J`8t:!TXhpJ{:o q^HǤ*mNL% ۈU]{3ba=kIQ7T7u$ c.=aa1ΝRl3 UW_WHm"U\EskXhs*.ny꒟gnF&dF-QXmP}ee$& q6~@[]#9qd)L{ClkXշߩBD!l f !# 𨨍8 > kcsrqGXǠMǒxu)%mH-!TH.C`Pv c1#lvS,,NځldbhCj/!SV]n_z +w3y /}%-b6&iSMȂJRjyȗZA}^YGH8 @H8Bp $! @H8Bp $! @H8Bp $! ˮ.ɬmY+?W@9Q>3uXjZ-#,0#ViTv]]]###MNNwuu%W^199I 3Ykp>x2x`````@X*O];ѶHNkD];ީ,{F 8p@QNՅ| QPzUcHG4J hp弥%{';U Zŷ*H$$ ht/oB^WF3K%ǼnQihD.߂CK奵|9啧7Ha8n--oUH pNvQ; FtQ%;wZp9NR TaROx Rv,B Ϭ)PF3FFF ѷqY*k8"JP0l2rsiJ7]>{1ky4bj;R%qT&p6>!k)yO2D_*^y ⥖%-!M}Hur%4,myP*ISVI5#%l|f.=l{&^œ$ӵb⑤TTot疞V6+#JZ0a“N< сǾ7M"i!O*I];ݧg HF˜|(F95aةO0>^/sR4(e|הo cX}V 6jm@MyNO.KRp~^t xMʬU 57i!/1ZcnԬ̇@G # Bfr}?0*U !p͕y/m>6a\ڗ#ll%%]!Bá%v8d;m$SHTAK5%vx8DO))RI;rFPLWyK[i>iG &Υ)@|wXLEu&1lGDI^4~օb(͝ߡ𬓲ɯ"@_kG#e$~WQvU4)9%%n)4l?4 tnuZv34Fm9|| \;ƝT! ACmH6PڑTkё R(O';d 2qWO.UηG@yI%Rc /^)D25h@}hǘ=ovQݑy#;m% 8%Q.$͗q_n":[djsYDdHfs߀ hk2CMluog*Y"-   I~ƈ4|! >}i%Do;AvfI|Ox~ OyNBG~z囆<%dBƯ8Ӗ ;u6)sX*B|Vay )RK>c|V"m@e3j%qxm70P!IO^ZAfRn'oh"^>J#F##7dGY'y kU$^ZBr؃O}=]$r{*x ο)}3j&=vH=!)Qc kp>6O;;j<׎2Hc* Q\;{x7yT*ZJ $6,Җj1D=x#0P;Vg(>NBE@ <0ƞ؏6}P0S !?EϫLNNZ~ó !`C*/яGJኡ-H #x)Z&b ң@Q;/Jh.j_+\*A(9gV%MYR83 6D%F@ćk3TpbGVrJn `C XT@l '$٤fr(/ŊCKO{X`C̙3gΜ+7|/B8RkfffƍK,9} 6,XPm!!P}ĨFr7[ne">#͛7W%GX޽{ѣG}U^jn4˗/V&D!-߿_*v .dkk޽y :7l011=-ٹs_~Y !qɨ}駻w+l6 L>s1Uj sر;wݴiO?=ItҪU">Rxݻ'-y/^| R}<dlܸe]hQ6摊A0<<~K5M({Ztn߾]ծ\ҲￗwTj Ç{˗/cbA͛7㏖[XI.x@Cw}(r(w Dww/"-g,\ݻ[Z!僔pΝ+Vܺu+^= wе37o\hђ%Ktr@~#ܾe˖c vp'x"<ŋ!ƍϞ=̋:\]["'vffӹa !HJ.]v=zQmېP@҂;>WQ|n|= vQ6$ o]`,#ŇhbbM,ٻww}Go4 kÁ{!\ݻw/^yɓ'm&ݻxb.Qd6Dŋ߽{WH-^w…~42lGrf7Ht5kk!-y_|Ŗ<{7JvYfMznܸѡ.=VR~%K$J >0 vqشiyOH/9I )g6 GHiIf Ļhc91dEOO8eͩ ?vڭ[/Fϝ;7>>^{zzK Nzwy8up j||\۷|~mƪKU 񵃃f*^իWy%bC8isQsooڵkghײc)iu~z]0KHs]zU]-ߢ ڵkwgg͗ *?^-fKZQyccc͹!,$%7wBћ]NDmpĪnnv[:::Zj">B;w}Aީ^k Nt8f& !/hSY0$uCugE7]0c:;;XFmt#P4\k ߼^m[nNTdž)MeARmGh4r/`kCƗ7ͱ1֬<0v\2[E ڵH8~xOUIB NIy֯_Oawa~{!iyn۷o #9fyƍ;v&67Xzk׮={=CڄN:eS@ki}x!$bΊU3'N߿˖-[n5T{UR0̮[N$);"mMdϞ=NυXd*9j;ZC]:;;+ *i+AՒ=_X ;!O>|9Pͦxjxx8CD_QhmMGfYaYcBږ)TF٣P ̞.VвexCCCbcN,4荦 ظ.Ɇ0 J  ĘpFGG2y!Efjj+([^pԧ&QTDsh/4}zo>QfhhHi-?-z]U,:?v{zz#Rp/ay2pq w(m޷@x en.fS,4twwK"LX5l)~s{ɞfݭޛrLDybnkk{ꩧheha2שxZ Q8ܞ,ۄԀD75adB5o׵>?|̻zgudYA ۀXFҋ8'kO糓R i#ob$dp|XjۆUy5ap Fc8E.XWZڴAKph/D?{%o吪(e˩DHJ E/rl<EרZ`S/Q~7OxtHQh`< V iG{%~iIp C:aT'  FDndwL; uJ ҋ UwF=?iYRznOUK^GJEs*}RADPG| '!+wW'A2ACVtHtHtHtHtHtHtHtHtHtHtHtHtHtHtHtHtH;dmI6`ϓrpM9 M#".Ԑ5 ÓUEWO98Uw|jڋDjg?U6tR;~!'h UIm3{ZioEΖ1zJ^6Msv ^CR^~D%g\Gʱd3v]V2Vbb "搶c#Œ!rM"rl,Uef222XXlذ]X c >}Rp8\R%eItMw@2?G,%Wo=ŃX٨Njժ8p~>'8      <9qƪU~9~% $ZJ:$O֭k)IAAA8R,IHJJr劥$oC'55e &֜6 AϞ={J*ez[bbbaaգGzu~~~-ۇMbֲ<>s Bvl:d=ܵwW Y|yzsHsCʔ)؈R;DCohѢƍر#=֭[ҬZ*,[{u0nac+$9zձ+\hQMoKKKq3uDO.,,m0@ZjǎSxȑ5j-[IeEDgЦMF!vo^ކg#B'Yڵk?D#oߞ]f͚5k!x!!=:q{ɓ'K,PM䁛qҥM66m'!SNBU\h[஻*[,o[|'UT|r/.]x$IUTa֝"ɓ'eY.W\%/LixW/Nb3g>>.J͛7ߵkWWX6_\?$eՕ[nFP$I$i8|pʕH+W_q4CKeΜ9eyԩÆ HK՗.]ڪUٳgתUgHٵjղzr駝;wQd>P('OAݢEBP(JOOAC&Lm˗/o72o޼?ɓ'@%6mR{h/^!/]tR1Y`9|W|V=h X|VNNNNbbb8po[אu͚5$%%%޽OBo7n >ϟ?,,Y5kꐲ,84iRXXjXx1x;v,/rrr4hm۶z*/3( :Ə999իWI&;˖-#cƌkÇT7toeyʕ$(Q_;/VX#Gm,mȚ'/Y~\sM|PRFB$bϬZ;SO92k,x衇x>yy2y୷bY,6l9D̜֭9!|㐲,/[ J,w^^6ڵkId8h Ѽ @Haa5\"n)2YdԲeX \7lؐ O<(rAAAٴiԮ]Ν#g̘ J. #@/ C h_x:,ˋ-RJos ԯ_߷9QRrq޶X~#7:tr os\3g@n|%29,˝;wN:6{!ڵmk(!AiFǞrǏ.ʹs򶅉{Im۶|2os\f۶mdk"e\ G@,eyΜ9pג)D䈛VZe di:ux"(琲,wvQh"779 ddd:u?矿ǏC:4!9Bxۢϑ#GȆ]wuŋy9fz… ]5z׍&c5k ,YCDe *9s-j;VV-3PLbׯO۷o=ܣ8M7ߟ,J"k}`,Q x!}vv6K@r|Ɯ)}'yҥ*Zp!9l|/ӧKEEE_}N6 ZSKć /^<##TիWga7w\Rŋ{=޽RS@jjw(K.%wͨqxʕ=zeb?Ge lE3ϰ-**`ƌ]v;SE2cǎ*U yEEE={jժD9K\z;３lp! , |iܵ$X\k׮Ŋ&{2Wb\[\"j/^ͽt+TP^FfoժUsw,ܹsPXbSgw/%Ad…жm[i6`ܹ#FhҤ 9LKRRR^vSE`I&0`ŒWM6R%AsHK!дi3%Ijݺu.]{A=}p8/t{㐲,޽;))Io-OL(SL$I;Vѓ]%Ijڴرc׬Ycŋ/I5h Ƕ JR^{ 5XfMغuՄ$ZlwZtyf͚5y_}gϞu`ԩF) Zl9qDfIu:uTJAD/ln}Q;*MO.rQQт ^x6mڐSB:|2zas& } HII搲,ܹXb$[Ρ+V@vl}ꩧK.SլYC={0`O?=jԨ;Cz3+UԶm[ #Yk֬pe|`o&771P\ѣGF+Wz-2Ey}ܹsj>}$I z#Ӄ֭^C^z[o#F8C(;j7?lԨK/믿2&ܷoT/_ WjժJ$I2!eY駟Cƍm 0`{6fffgɒ$m۶Fr^:u ;@ɒ%~Sܥ]vpB.ڽ#)رcN:~~ںgy:w^۬ZqT[o%`ϳ> KLD2??oQFYJ'5B ?zd999III ꫯΝ;,7tf;,[n [wܩ  ddWm۷>'|-s߳gOކLHw,(92???r˗{հaÕ+W&&&o~ʔ) [L-_5;=z?A>s oC܆)yyydʌݻw9%K=zf|!4y5j?РAކLR匌p8ܳgi[2337O 6@fxbH^^9]O̞#G@ժUy2Y M61bDaaa~^}ٳ;vdȐ7n8==l#; ȅ KSb!K,9{P(4qğm۶/xK.%;eCJJJbbbNN/#![l}CXBuviѢСCOޯ_-[$&&9qO=W($I*Wӧ[lYD 2xCUc?> 7tܹs : 7pL0!;;; aqƲU}g߾}IaÆy2SC@rr~ضmW^y%%%yb63 sssCڵk#H$),,O\~!:D"ݻyb+9dddHвeT:4p;b@oӧׯOrN:E"yq4vɑHd'N\Yf̘ dGVZ6D1_}o[LXd \wu|Xr%BoyI([rR//N8 h"2.*BKaa!w̘1|-!l2V#UuHϑ4љ3g%IɚLhӦŋ9ZΖ-[BP(㏕#?S>vYYYd`G#/b!ɹ?0_35j4J.=iҤ`M)B|wСy??+$~.UTLnXyr9I7n\@G~7Q8q℟f'NRee{SLU ;ݔ'N[nIMM9rdٲewիW@jj[E;dVVهbĈ ?pF'r*{޽5$Wߝy)w}G"&MZСChXvofdff&6mR(S {5 #GYoľCQ[О)dJtnTd(EW:v옝=t;RJ=z #">3lذŋ߿B6>@٥% ҥKϘ1c˖-NZ`A 11OT#D")k!Yt\p~/x}ivLr8pzmY"q$!I_MwCܼysǎg͚Ş$''bq;V8uHRCVZʕ;jwUm3gΜzРA>(LY|94h^S$GXiu>3'BԩC3&Mٳ~QQ sWd!z?AZnw-[BNIW^嗴4zww}w믿uֶ N:$iJ(ciH2o<={(Htw>sC%sٍN%!eY&?c ֯Ŋkܸ1$$$L0|ɓ'm+@J֯_o)a߾}aÆա;w޽괲 8p=%~O?zt$&&^zuܸqdۥú:wj(((PXww^$EEEdY$I6l0-??ٲeƍ{wlC6U֮] iiio,J #Fvˢ"r8Lrr"DFE:Z$IjԨј1c[ݻwO4Rrr˹,2됲,o߾x0w\;uO?ٳgZ7xѣN<_ mIDATgX=ztСѽ%K]vZZڽ{GOHMMJq=ŋ9sPlSN.=zwުi@UTppAoF}-h';vrJf$پo3fҤIТEdz :Ϛ5kȐ!EEEӦM>|=EEE7n\~}rrrŊ}ј׀ӧO_p… yyy7Z*oA/_N:n%y܉缲9<}Hm r6&b/;yԷELX-#o0.*ՐF{4/ 8DžFu]t4ȢH5e /,QaTR6P2z#(eٛÒ@qR nNRUyEnUz;hRDi%kBeF4Ki)Y"٨Jct]mȖp~Fa8)c:^V#X{>]\1_n5FeIN W`74[+No+ ^m᮹@H,6X$4m!=W)lQ*I:]Z=jxoy21@B8ѶִMJ]F4uJVN:yٹUѭG۶?Iіi/yRҲk6;Z`.iu{DM%kMV(huXUF쥠:=TJ-U 8U z#±EX!D 0dE0qH^]"t#oңqwHAWC\'a0Τ[o6 P^`*!D F],]F3$ 1) >HwՌ!|| 'y(OD+C:d0({g'略]NܠrրuT끖 :E*<,?J)KViu'PKRzWV?QZɟa҆dDeRFyP[bUW-m+zCINyv`P .9y"Yp^)_~E u#]uzg?%r]G[zM#8:)4zyGwO7^YF'eҒ'=% u I*%+bZz)Z5ڣ䉢%a#VQ4ũG 2J6j51O"Yu0Tb7"OU%]+yeOye)7ZEy"mr ?$ N @Ao 6Bb!@`Ȋ            iqJ`'6'ܖ_Ҟh DRNZ<\~EE ֶټW|f7LGu< !v ݤvR2muk5ۣ]ehKal2ыn=6 TQ4ZnFKh?>##`ZKWZSІגҟ*?RJf:k:$ߦ-i'ů5ZU#`+dG6[K߆=bB< ih9eAy:a!bqӲW~vmV"I/fh\tbn,4S+JA{S[ʏ9bk%Zs7Q@E(Q1Ֆn/UAN}t7^5 Yi/{d+C\ lA8"huKi)Aw "!+)`G3Nݱ>A,vHqdO[4P$!D Γ`|N{J26)#3TW'v'<+Vٞ梵4YJat.Tϼy tMq;)iC0*2kjvɦZU$ zFPZ<~ULu9lÐ5Z4}6EU'RLdJiA(V2Z[i8K0')7;l bI2z%N?*]//8։Ujk]jX*\g#SI/UtXe1-/]~!fH^VsVcJ\|>y8K$>ݴMhWJ-o)"$7cT]=ZP~uʀnYŒ*MFiqb)ONJp^grkxDx'Xck 3G7 (XC"@`Ȋ xG`1%j~oi{g`Qߩuή!+DPCVӉDFETM5kd,I6;ƒziOb!0Φ[{v {Z],Mg4~UY2FX!ua|tS:TCeoHV\/ND$'!:b_qKPR;KӊPJ%~NeѪ^Ujo09oC>dEXAAAAAAAAAAAAAAAAѮstp[xqEْNvǍ1Lא,˺;glP1-liw\!0!uD!1I WFɦgkDH^gyݛÈI/+UCMkR-YW=\y"'xϠmJo!(7oeKDlһ7[y,շ-"#C7ÉTG5V+zHvyU}M{֭G2f2*׆XU峒֨σb,ljjULpy V!0ˊ _ "XC"@C"@C"@x;1 p8:{]^OF` L_y^k4M@WtHACVO> U.]gП^xɞFVEG Vgr#NjS;h?u$^jW9y@FWMe}V] z] 疾q͛d:ml䮷WaTgZ]M})N YMazL'y*AuH^%ozbCU+ORUjnx^-N]tz SzWW`w'<.Bx to4J +:y^F>RmioQB^.1xDwHHb ' CPoDBЂg=Js g:$'k{jIENDB`gnucomm/wheel100664 765 765 3422 7513704522 11413 0ustar rsbrsbQo6)WmLMګnh nF 2>lC$%&TBP8?6;EgW#,NJP̊/jre<~||Sd.@@4ecuxt=odX¤b'0c~5Z?+xT^Yi.Yz5`F3z[Pj͋DOWkΫ+ uAt|O+T+*7LXWpEO~G!*>B4)%Xx)gY-ŎkKn>WahHQM^V"pt$6CԡH)?eɋ%ZJ]⍞:>_.`4t6>yRE%=ڬN,f"~VG$4i啘 O^rl;Ns8,[Y'Zw ' `]xs:x %)FGAʒJ:e|;2A5q "?(NμSo|'e6گİC>f˰61a`꛿v*Xey8s9-HpX@#RzSJ$Kwfplڲ[IT@3Z)0!DĀ~|0_w\6̠},xѮG1ЧZf)0*o`,\&f[ɅD֞L<I@=_ګGD!jYXךt? Id"cRWGj8TmQ ۢ(S:{%L7t$6I{ 'ċi FJ8iHaH{˄N(]7lǧ-uDP7 z ˉZ5n6q=ɾG-QP/A8 *5x2B~91˵LIO`j ԋ*DEISH Bqf[EӔǃp Gj8VYm1(DOwR cCb:"-iMdd!U-{v d 4Qcq|mFk4jH1,߳,Gd|mIk&[gHxF&}/&pNHX#ҚHrw%!>7i||*oXoXjVN֠NB ]@CP*40|Djv&,[ôJ֌N.˫%ݧ .AH/yB'ܿfp`ZI/Q@ /95SO/?h|a80.3P#ĮWL*Y\=rqA[H71R|R"m".QkqZ:Gś47?x.>(태55ሴ&uOu>U :@$ډƺw(f;zlMk6T~LCmGMY1 u^Yԛ?M[5/@2(.5X=X֡Jow=Gi,ShIh XYvϳu?t%"ۢw;B꼃?FdM}j{&Dxb}ʳJҶo>mՌZP{~S O$#.o_&@Ullٿ߿"egnucomm/wheel.html100664 765 765 1452 7513704522 12357 0ustar rsbrsb
Bayonne and GNUComm - Rich Bodo





Bayonne and GNUComm


Rich Bodo



GNUComm Developer

gnucomm/wheel.png100664 765 765 41223 7513704522 12217 0ustar rsbrsbPNG  IHDR8\JSpsBITO IDATxy| &$Q""H[nAB]__WJ[_-uբjJQ4Έu$$ l1ggggw}=;3yfvg>h$r!u4!}^xIzNCWRWE`c' wNQb7? @Ph8q_'C~FXGods^]hɹ_k{d2jk4/,|Ώc-*%p)?>8O+Vn%;sGJ|vD5k#p.4 /AE @5PI+TXqkW I@EN󑑢@`N"+y҂>!^W(@Ő7WO%>p֖DۯlF @xE8Fa*g/wN@O/q'rqNܒ:S؍?E"J2V ̹-=eSpOD6FbYo(aL_CCYCȚF!FR !$*2|M,l4_R Qsj6ON/ʍ..Eb|b%SXd^G_j3`눻!8jƮBX86fϻ>f!qn !ԨYޢ6f>uq)͔C6ِTNn V<,@? !Q$n$V輯OБYP4$*nI&Sxk]ȓT>'t\ӛgg[pQD9幵%5y6nlN6?,.Kʶ6[q6Q\ef/ezБKcs om[lh~7zl[08/)\dH͉غ֦am˧d4j{{4XyV,xK,*gHZ>@$%BE[=N*ɢ@Qyʊ> mKٝ M@ΐ!^0zOOOFhʖ--u ?JTrqز|/^dZRʕ+WP'Ohڜ?~/_N͛7o޼yƍ;tФIP e"yb]6q䜨t:ݮ]RSSw}i h"""""""""j׮i3ѣGgϞr͛7O:uɼ<<<<:t/vر]ve˖uAT$=E @ITV\9mЮ]СCwNMMݿҴiVZEEEȧMӝ8qѣ.\8qիWMڷo߽{={8:E:Hp!e["¯%Bnnۓݫj7:vعswG y;zhJJʁRSSM+WnРAڵsgy$зA U2LTq䖨nݺe˖-[?~`004k֬gϞ=zҥ|Mhݻw'''oڴɓ'̛^^^Gܹ\7Pg$$&&nڴȑ#˔)ӽ{~++Wvq} ^<)c^7 d#=*7^ONN^nۋ!}5jT߾}ݧӁN۴i?pA7y#Gj{WQ;Sяq貳W^p-fݻw=z'?}+W<}4Nhhi&M$~D G?75=_$%%1(<<|رcǎ :4pڵkW^cBرcNZ^=g]a\ QqRI`0$&&.Z? x{{0`ҤI]tAmkzu6lpaO{שS'KveO$08Q8lz>!!aٹ'N믗-[ƌ|Ѹqٳg4H@s!N J%׬Y3o<&E~cǎE+ZmBB—_~yMBHZ,X0bpHTV)h4}QVV!yq~U\\vO>h׮ޡCP?e%D%mcǎ?ŋ ~'Dr^tҙ3g2\wɒ%aaaRfjNT{_zܸqOLL$TR/9reOZv…-*((1cƌ32"6Q9~iUIIɇ~W_zoo3gte%''磏>Z~`Z… G,4Qq6'B[Q*xJIIzF/BCCoKKK9r$ڱcף%@\k"0/9G3^e5&1_5ÇǍ׹sWFDDys'}Q>O*ׯ_o47onݺMJ(/ ʩى:M=zo_ұcDŽ ˗ w.`E:thnn￿`9s^ի׆ *M6*Th׮]۶m۴iPן]p[nw-S̖-[^~e#PUd[nh4 .|wٚ0aBBBOOϨvpSSz˞:,lѢERRitԑm: C/\xˍwm۶.]̙3d)BH54gdd?>??ĉճgϓ'O9s&22ܹs|S.D%k8PՎ;vΝAAAɿ`ΝϜ9dw v ?yd?~ܩSC (* K-x^'%;i d̙<;o޼5kֈTΝmjժ6oFITXq޽C޽;󬕸ibo?l`mi{Ws^=^R2 8Bڵk-=AAA{w ^8q"s$0RXZ'w1з\J5%ܯ…^Fja֭۶mDTJJbXXرcǺw.NA+V̙34..nݺu/E$*2k֬D~\ھ}=22Rܝf͚|rBȸq ͯ1-9ru355A jm(--=z4!|Gϛ>rBqw "Zb0֬Yù^MߖӸGg EZp \`00⊞ΝC\rBB¥KSF={`q Wh4˖-XґkPYI_򾵀mkoɔkD\\r)))"L#hf͚U\\̼_jUqFNԫ4MbbԱ+̘1w]re2e!uֵ(yᄐ#GGp/H , Q9_M޾}Xet0uq+,[,22233S=+͙3 :h4smٲeF111qy$$$ 6۷+V'Nt#GDEEIرcݺut}| V=zj 4ضm[ D)dhذa5k<~8ϱkT Ybbbx Qھ}{lllaa/?R,ȓN޽ѣG6mzq~qcp1pNj7oѻw襤$Q&|JLL1b^0a·~I###yf0bĈFmݺUzX^?k֬+W"K+:t(00011O>:(Dp*e T5*͞={ܹ/ɓ'_f͚ & 7xAY_z%F}v?-4*7w4T;v0 5B֭[=<<!_~%e5)m,Q 4?֠Aث X<_]l EL7olҤI~~ ;^z]TTd .Eh4~k޼c|h1Meml) m.el eOJhJJJ:uo۶mxb˖-u:o)7-[fffN}߿+\y8]u90ǭ)溃Ro8FU8FqƘ///0>ܵkWxȑmۚGJE(2NIqw)?Hg۷+顡J0yΝ3gΝ;5&8*֭[ TL .ԩSGpKyMvE9[(Kxɓ !wš8/-:`8qh>}(}݋z8W4Go3,Ç޽{~~ԩST$EiFx{nݺyfDDDaaÇ;t`i>t:۴i#u8N!;w̙3tRdz!dZvذaR`ӧI&zp eԨy0x5k۶m?5/^lܸիWk֬xVt:]ddWZ5~xjTL {dCYds)ٳgׯ_Ǟa՜9s;^R _|A裏t:OYқ9p)S˗OxiL[2 HTr䠠yREFq 0 /޽+u,"Cχ~Hw7zxx㥁;k׮݀K ȔљB&vѷoߐWN<ٽ{.])ܹs5k㓙 : jTv`FDR֭[/]T5nxС:w@ePk/RHHHVVL2{ڵ*UH8P⋹J}@ׯ?h Nxbcը;uĉ7n/_ӭZ*W\NNNr@Qh"Bɓ@Zl٭[+VH 8Z=lc/_uh4o߮\\bΝ}Z7D@ZQ5rMkbI.goV"K";<<<''=:(2QH9g2㯨(!![o .4 eˤ@o#X7n=ztttɓ'E ǏW^ʕ+RըL'Zk9]V\I0aaR@@Q!R*{_UobW*##A˗uB6m$u Q^ӟˤtԩv׮]:!k֬}Ν@Hy5* !R Pj^|EN믿J pHT O?D>|Ա7l0BHbbԁ?nL_xx+W@Uzxxܻw/ @p@֭[ !:wԩdΝR 7$*P~B@ 4q`Tݻw=(k] Trōgxxhļՠ,HT0vׯ`9l ʼnҼBfqTl(ź'hmk_b'JD̵k!uԱwCӝ 5ɔ94#RFE4їbw(:S<#8Qnu_{UYjq1tcZ#jժEq()ůdꙛ7oBj֬i{kf)9W-}>;sx3::L6]ʂDTqq{+W]hz9skXm& by-j%l DTNNhRvW6W^yvUY*U!wܱwCC ?%"8 \BHHHmyDi%`Fg0]Y#ElY4KXl˿6eA߿OXԁ8w zP:TijvuŅ Q=u=BHJD/sn *T \Ndؙ+La1fz1!$00PqDy5w[El^oMPzɓ'K W1LzpH g>DKq( jTO!QC[([,!y]Ul-*{6;G Q=!~~~RNgӚq9V@V0&QiZ:|v',$ǻ "kp3$ !>>>eP l•s/9۬T %R S$*ӅyG&8[fZjS͆)k۵<== !z^\5*p%'nq޵d%Dtnظ$Crh6 N-@Dh{3O8R;7.)o߳)آ49b/--%xy9"5;̝*aи$OzZ[47@ZJٵSL+Z!Q=tp+~<7.Ʉ#=y~E<i-'1L72Sn܂)wK RиrP4 (:"vBzʑD%o7ݮ9/q,ߴV=CiՑN gHTOR@јD=Xc@bfbO6.1S&2RQfpKϚ/ SܾK=~חg33++rcEQnOTHH!Ν;RDw%T\Y&;SFt;Y͎/\Q=啗WRR-u8NCR5q>g##]U-dxIȊ?B)OOϐT͛5jW3>:ossK-gfmצLFP OHTԬY_IܸqHTDL:u!׮]:g~:!v`$gD%u ΒI[ԁzB._,u $p3 K]v 5*P$gDOAz}xx83 R Q=XfBy@e.\@iԨԁ9M4!={V@rAzNӦM !gΜ:񥦦BZh!u AzNtt4!?:ӧOB7o.u,AzNV!'N+2իW^Ա9R ǏBbbbnJTC_vؑre;Fi۶ԁiҰH {}5:Dԩԁ2S0L;:w\&MBCC T ''Zj,t0̫Yj]ژ͊j \Ur[neddX@YGС(Deg9g3#5=ɦEZK'XI)pk4M׮] !{_rr2!GR sʼ93&{eRaɹ_mլHo^!;w@qCٳԁAGE?[^޴(mm`z^2(wܩVZ2e߿ DGGרQ@q6؅(ϢJ*-ZjwFD߿ԁ$sTndv#Yc ~_yB֭[*@mFׯԁ\2k|EhE)%_K9|ƍ_x\OOOL 4TPOkTF.(8ױߧN)_BHTTTXX؃$j˖-W^yY K^C(ʨQ!?ԁyfBȐ!C@8iP .DEEt FʅU5j֬ك{i&BСC@ѐh^uBw}'u v6l RY4Y.{UV]R%Ν;S~to{ 3aHhńwyGbdlܝ)6jx$FE0߱k[ڵkzjhhb$ԿjժݸqU5*'ʳeҥy #k+שSgȐ!_~ł !ve)_7oHqʢDlUlDhm&gϞm֬Y2eBBB} ߿[n*U~itdZ~>ZjXjJՙhE77-e`I& j .fϞMyw@MhwV+Rs5m/33Z @>+UU|y ZCƍ RXX8onZ g?ܣ[ժU !'NR.//O>!|Ww-oHTB׮];55T>Ǐ۷W^1_\B^xApM=zcǎΝ X)~F'<ڶF%РAzCчI׏?h4N6xҘfrh6fzZ]-Q wƍ=z]vRng3f̨[nzz{b8߷qZ6jTխ[w̙ѣGRիsh4VR A\7o<++?:p#z^+**ڵ+eMIq4rqA}PwTZZZtt^߿Ν… Mzܹ k٬Eos%55jTjڴG}d0^{GI_ff̙35իYP'?`dM>sC6&CJ:t8qDm&u8f:.::&MZ|jT"ڰaۿ;5?|DD&h֯_WLsխ[Wp@~!C0֫WOp\5*ь3fСjRj_;pBd)p+Qɓ'mڴtѣ{j۷?ep)ԨT|-[+WnÆ K.:)Y{ޓ((fĉgXXڵkՐDְaQѼ:ih|}HoRW_mܸ\r۷o:WC_>}>CfggK;T=!Wڵ+>>^O5: Sƞ={ݻ7""رc*T:"ױw4BO*v-[ϙ3g֬YR =8ۓ'O:v옖ֱcxzzJ82l͗n%;;m۶7n۷ݼf }.pf͚ݹsgĈ7npV}7 u>RQ\\ھ}{Id)]v2eHA1vQQQ޽SSS֭,nʹ5k/Xb޼yR 8bĈWVmϞ=nu\!11qĈz~Ḃ< 1clذB jܸH5*W:tU4M\\ʕ+Mg}>Kĉ7lP\ݻw#K0T2)GHYnݸq!6m1bြɓ'\lٲ;w$&Qacm[^e%xbꫯb&!0a„+WC0'A=mn.9B2իVX1agPZZqƲe&%%uUKaMM_;a1_5d͒qqqEEESL8q[ΝK_Mw߾}e˖ݻwo۶m@v$Q /ǔTlY8kygQ?>\O|xaa6mTlY{KEܹsfffŊSRR"##@Y8%QK|ѣGAAAÆ <,P~ݾ}aÆvYȗQs\rLL̩Sԩs֭[;w2AӮ]۷o7j(%%Y N=FeXL8~xDD[n{n2 ,x饗t:kv̙^xAN稈y?Ys/-3,1+%Ӌl3fBBBRSSG^~9s { +))6l؇~H믿;P=Ζ-[[o ޽{eʔ:"˗|…M6WJ^3bĈ׮]~BeuؼyѣKJJիcǎzI:̙3Z~z6m>#\I(V0aBlllIIɐ!CRSSL2%!!ҭ[M6HC |r2e/^>HO2tԩgΜApX.)H``={[EժU+11Q*^?k֬ƍ?~<(((99믿FMɢ2V,{M(4hPZZ!W^ׯRAsN:5~4F=(uPj 08FXXXjj+vb %Zu{mۦժUk߾}k֬A,elK%S 7ӑ)h&Nx%fɓ'7lC.Ih4.^F˗/7o˗t"u\"/:4Qyι0KT{9r{!ʒ%Kjժ0z-f(]~7 6:(EZΰx3٬XÎsCGgW=n߾p€m۶խ[w:N`ٳgӥKsUZ511q߾}RN"5.}lUPjT֒:Cnn9sVZUZZZl٩SN6 r;ݻwO~z;̛7c8g[r ND{ٳ.]j4N"]ի~}}}'OSY[\6Gmjp[*?'ѣ .Z$f͚'O;vlʕMϟP\\LRʛo9iҤ+[{¸Q nHG<ϭhO|Qڴiゑ5dH۵kתUJJJ!I5k`D%jTnpĻ{_~͚5;Ç6lX֭5JKKw޽k׮5k0OIk4Ν;ō9RZ&ӍG) n8Wjj?;+V8p^z%OOOiݣG~ݻw'&&2o6m4..7wwJg( HTnpĻ;x_~~:󦗗WN^zΝ;jCCm =w}:u~-F=v؀'Zp?YhmsϜ={6))رc̓C̛^^^{i߾}֭? `QQѯￛ*Oݺu{1|wS xPXXo8q")))##GTTTttt&MZl-ao޼;v󙙙K6mڳgݻweYsT*RT¦(?527H )]Y;_;m6Q֙=qCH)lԶ3IDATcΰyM ,*m6sMD; Ji\!kTʽa'I -\VnJ|:F[\5<KK??-tFf/@r[l.l,Y d(>U#% H? L_"o2?a,+_YI@>yk]ɮ̹B@rn2D%%u2#]A&wBzv)5F#kr./}%f/pU+ zhfe]tnfMΨ5!$*]+,ّp nq>s D OBmԥ78mV" QBJԭs63ʜGkZ @V!g-G#d *@@DH UCIENDB`index.html100664 765 765 1472 7513705630 10720 0ustar rsbrsb It is now safe to compile your phone system - Rich Bodo <BODY bgcolor=#ffffff> <!-- The text to be displayed when the browser does not support frames --> Your browser does not support frames. Try <A HREF="http://home.netscape.com/">Netscape Navigator 2.0 or later, or replace lynx with links!</A>. </BODY> index.html~100664 765 765 1442 7513705066 11116 0ustar rsbrsb Bayonne and GNUComm - Rich Bodo <BODY bgcolor=#ffffff> <!-- The text to be displayed when the browser does not support frames --> Your browser does not support frames. Try <A HREF="http://home.netscape.com/">Netscape Navigator 2.0 or later, or replace lynx with links!</A>. </BODY> vocal/ 40775 765 765 0 7513704154 7726 5ustar rsbrsbvocal/vocal_desc.html100664 765 765 1607 7513666111 13017 0ustar rsbrsb Vovida.org -- Your Source for Open Source Communication vocal/vocalsystem.gif100664 765 765 40107 7513663572 13115 0ustar rsbrsbGIF87av@ ` @ @@@`@@@@@` `@``````` @` @` @` @`@ @@@`@@@@@ @ @@ @` @ @ @ @ @@@ @@@@@`@@@@@@@@@@`@ `@@`@``@`@`@`@`@@ @@@`@@@@@@ @@@`@@@@@@ @@@`@@@@@@ @@@`@@@@@ @` @ ` @ @@@`@@@@@` `@``````` @` @`ࠀ @` @` @` @ ` @ @@@`@@@@@` `@``````` @` @` @`𠠤!,v H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜI͛8sɳϟ@ J(LH!"`ӧPJt [ʔׯ`ÊAѦ%˶۷p=kvk]s˷_w È+~kpㄏKLȐ'b̹eQnMGsTYM7ͻogNe+_Μ䀭6NDЅoν3{Ov˫_gz}o/?X4& 68Vf4jZ(|ԡai,P,h׌\ &]Iit c99FTI:#P2'dJD.WZyUHjГQIܔ9e;ni]i~)Y&^^bv\A`'mrYc*Zߠg嚒#(B駞mJjw*੬V@*JqzOF/!pϱ&,4G){fնnk:aC[teݶ(.Z/Mբ/ں/R;=p$=1aQI/3g=I$1RIH!KJlQnZ\R'pʁL9o-s<;Aw4Ͻ!@Q#.I2WD*8gTfXg&l㵻aO +M=RjwۯS=|$/2 w&KwʴGlFR NxiA#`lҡl>}]ߛstOv"XLg&vuQsG$|;l|k++;W)#ɸ7Vbr/ע-C;Q}̃6ѸvsCʦ%XI8!` <8x1+;H72xVe3P# =ab"Clm,XW>Zӡ B (W2g9ǭ,{RxEXpA¥vHm}j@ j ux)9&@-LIҶ@.pCR9F6"Vpd[8" Il(C;(HA %0GHJyC$Qmr,P2ϕ,g%S8.R„ 8j.V)9D6j{&U慐0Sb2}NeK-3@T:R>,;{r1Qb:B46mls||?Gcyy3*MM sT):B?zЃ0-r .EPm&ݻ!Zo[ngxCyajRFzНgszLB|}&GX}"sL^ݹkqS׏`=Ckbdx"TO~|q8oڶђ7 PHJI6e@K|@9ID y^b9dYQuvM, n 6n/gٗ~iusi-1) ]Y !=LYfYCd d4)cxď\I#s25IP)v<Ʉ&q7D4f2ٗ)])IgscKW@[8?)!tt=X͙NiUPIڗcg|!9cj0q9II;Yv7Xthi7FWasI줡6#^#%r9y748D.ي 9h⸉hi7_ *K ljz*9XR:TZ-+F4X>: ڸ縥JE{K L|1kv,CBifټ ܙY!9ܑ Ǫ¼J8&(LW3JYVu63ܑsƄ<Ȉl[TwRw&`|ZvKd ǘ\2rȅzə Ǜ Y|{E˲<˴\˶|˸\˞Z8\LPŪyΗ8 L˻<ͲVĤz|YʤiY ьJ|ؼ^},ZvB!IQ3vHυb7{ܑ )*/c)-Q}6-& " [(})}X?L5̐U3=m53Z1<͑Emy!ʔSMhuԔZG"^mj}fM8Nm="oq]vM8h׾7E\M?ƈ=zcMh"|+ͅ1Y\ٯ ٚݍ-Ċ=T~Ψ9ۯ-ќL33ǿbcV]ݍֽa lƬ/MO ׈1=͍߽m\w `84M͗EK~Zs9>Nlᣃ N&I<u'NT3[ 4fGXxy=BV؈.N8j^f>hn`toq"8jaitnl-$݈8yن狚iH2%K2IN=}TPEETRGoMSJĪ֗[ڔX5aLZj6fֆ; vܲgJ׮]n{#ޓk n`w Tdʕ-_ƌ)οjv7ܼX vڴ갫mƢmv;1n? |%ͧ[!g]tM-Z*|Π%v_Y^κw1K?ąG.FO>.Adr/8Br;O?={j>n l?h{1@1tlGA8C;2 uk .ķ# QG,9|DsDzl(L9 TE7߄326wlD.4N;ʹ.F(=钰CaT}L,:S T67uд5 孹H?$$5B\m@=7tۻOPTct ckKTbKSi)jTLm֡V [qVDrE7IheZ:w*:=6]{}Kp߁7뭨]3^`w_'.b=8V^tbxdi*duҸe8(>ueǕfݹbveN^0Qn7 pV{LZۭA :lfjno'SkWĶ-RNnJ^ƙ| p޾Nl~V|A[KWSg<4U%dܻ֔96q`ϒ?+ 7tdɩwHSW03"kAt4SJiJ~Vů뿯qMh{D|b5$GU\Ў-9 k"` +%S; O)k0> -*@%*QSxaDb(D c$azU.FxԬLFGjI,$ߐgIHuǚQwm|$rR},ޞv($-#K%v</]=j`L˂2cwL¤1MjVӚ&5?3M=7m&NI#\3Vi0h:Eلg<1nvLx"} uS$ez6T%tQ~]0؛W&DAjb(0m2EIe5}JS&(0= NM*REOwJX{êWjV Y :VbիȁhX˺֭Ljek\\re+]w3╭]*JJ/v :Q-Jӄ)^[*Xr:MRn:ZEEBYϺ _h;[ک6@]-k v\&H'U-kK\(T[ܷtQΞ\7}-P~]luvd%p@vW/}m8Hem|_~zX(XI )B!p5_T5%EIW(FȌc*FOr䛰6]\#u\<2'y'zS~tbsLukM1[cPza~uцc8j=e{Fv>Aئqp&]a'[ /ӽXkq?ܶwq'yз-/l#7}e|"M{s`uO}Q_e(yO *ytlƵk}0;!!&8).]w;7+Kz7!@۫Kz[?8I=S5<;6c?{3{:/ltd+٪;>T!̉7|A@4A+4A,Wè™AQ+k{CC-?t۪8:tAþCbB#D8$D8C6\&\DRC TBB/N*1R,O24&[xyH@$/Ԉk˦ȓiIk@ DHc)THmJR LSL̳dlJD.a$"$0TuYmYlUՆ>}WڙU|--얟׋Y-΍{VY:Rh([ ؂KX%֎[ϲ۬mȭ5գ M,P\˪>p۾e]Vk[%ݻ#]F}[]ZZ \[\ݧ]T5-۵MᕞݺY¢܁ێ\x^mҭX;eߜZ]u\D _s^V]8_ YJ^W _=6% Vߌ}ܯ}K[vK= 6 ]7a.R_K-KU^.0anHE亳  %Fޓ^+VŎ/#N24V5f6C${ pbs?7dAVdBb9JdEdF6(Hd=J.b3&dIc;YLe6eQUVVvGN2e=4WeO-$>΂8e>Jfe*~,k.ele\nfka_1n>NcO]!&{i⸭Mq&mgo[u`}grYg0& y>hg{gx>&YT`l^lᎦg{,hi۔ngGZc@邘&riiIifީrjj)N)hVj Nj>j6jikk)ki>v&l1FVlf:r쇁i֖Ɨlmmm2Qm{1m˦f"ضiz,ntQDՔȏtUelnn&WeMkH}Xk nnYnHoXyVv˭oo~Y搜8nn}zT-Tp0dG~ "7nm? FKfpnunnlHoΫm V\[o&խqt($p#G.Ĥj*O)Hqފ(1n0 :79eэWrIpsn-g:߯ sKm7J'B1W׻9otGG/rO6͘asqoIօtRGnSWBK(4Ft!rtuAAWs*Ouy5 vq):HZvgUtohivQ7v[p\Ǘqj ?T i'mvvF,qwz7wkG#W{q?oU/ՅkXǗ|z{g }WL37m򫼲e!+"8 byr\x2o"0u.?w,?͏|Zh ﳌ8'r.Hq*|*wUaO(S.uw1{YggZoڸzA_xoxv7?3ʟp|O…ذb&mG||7{Rm,}_3}-tȥ=tEp}O6^C5n(w~ev'ȏt06deK~ßLpg~_8#)Rl`  2l!Ĉ'RhbH #Ȑ "4#ʔ*/JvQ#G2g,ir%Έ'РB-j(ҤJ{dgMN}ZU՝Tb% '؇Hm*k,ڴjmy3,ܸr'UkYn+Kx_O2n1dQ:=HyV5k 1_ 1Ṝror,%s=,ԫrHIPNw =4]5|xdkgh[4|VyZyGv7Aʹ \۬UWwv7r'4GB:A]^-:7,~;).zk5 e;N^\]=b yvs}߷~CǏE>S=?Rq}`G 9πxA ݲFAq!"0QٓQHnk1C/(JV°Pp%4 3m cؘ jPh& sȹЃ!'+ D0N.$ SHD*⎴H 7j |2bώS1"ecQv>lD #9as:1@%ch)FbđW$n$9IM"+J:"*?H5*DeDiU2Yʉ+LY*Je.uiPA"48ȣj=LfOZ6o4}Im*\a2qI"gpY';MX3]<΢DMA~g)!lB ː2롷 GJ%A_-hŐ 9!9kɩ3G$>qM7ui!t]J/,~s]eՠyx\&حulc+؏nlQך,lk3ή mz5\iLkΧ^G7loWvav:m~WU7vû_/닟{FnQW|%/lWgx~;4a.qOnw.t젛vfNd[0G5đCVR>?$@8{r}-oɍo=}{*s'k|-Eq] y_n7,Fy t{7xv2Q²̟Qƞ>~n#~otyw֧~mMOS]>{_T`F7M R҉NH.TD~ `== MJ ~\8ɠCՠ R L  )`r!.X?'9a+I!&IvaRDe.RY!nJ!U zzM! "ad@ b:!ՠ"MgX $b&:&N$N!.(^%#jTM*z*:ftbbMTFIb,-d.΢/b."1[b/&0*N2b3Nc1#3V2J#4J#65F.v3#51:0'#JU!<ƠBa"A6d$gAC*I;#B6AEN$Gޟ JdGzHEd>HjdIJ@6JcFFFBZdJ$NH pOOXNIMKQL%S2N@eS,$CdMdVVW>S=܃]K$W"GRRYL*Q\^RXX&eB勽%[\%_fe%^aBZ&`Jdd>&f mDcjN0&ddevIf h?=&ZN=ˌkjzjn~FoaBԇlڕmpoMpRf:je.WރltOM('ud7iexJx~\Z'\e4مax'z~FtBt #W¨AHAg (hlɉ~ҧZbq~%}ggoeIb"q@h#V%qo$ڠ('\ g'(Qo\"^'vihHB\ցsF2(6jj(m)G>QG\PmJ(%in xʤgTΗ)Gv&ڰ'0J)V(Ω*6dc>ILM)"EKL ** jE>R^2"˾$L&NŦ"0ʩ/^B~)R)V(G~G楆jjr*j ?FD<njܕ@$(J+&G'j*R Qk괨kPl¾"zkЫj+N(6槼+)(75fczpcLFiVȜkj+YY P| )HS)r:gdgGbˆ 6ʅ(bW6ꎡn'H)n,E,*n,>b*$Vm&r.=t$+'{Fn-,,ƒJ6r)^=Zڪz tcqީhmHr>.Fe`,j,e0.,F).(jnb9Bn5fg.*=g( ookIlȜoVR.lm*bJobz'ZD[ -v6,_n  .fSm0uA? 0A ΆW0Vfpb/1k0Bq .1lcO/# #gkO /o±*Y_'(耞=?(qO @+gz"oz1..gO(2_38)hE73;7iw:3=sr̳=>1>3@'W@A}Wp}m:C.j2{JtǢ.B6Cw~c({E+/uWKzRG>Qka˹ϠCM4\MQ"ajd녴[æM9wT!s|Ye_Hq<0MeGo