I think we've ruled out the gatekeeper being the problem. two workstations, mine and a teammate. both FC4 boxes, his works, mine doesn't :-( ok, here is the gatekeeper log from when my GM attempts to register: 14159:10:10:52 _________________________________________________________________________block 27106 14160:10:10:52 New message recv <- Gatekeeper Request from ip 127.0.0.1:1038 14161:10:10:52 locateStatic located endpoint 'undefined' 14162:10:10:52 locateDynamic located endpoint 'undefined' 14163:10:10:52 < >| rgutilAssignRegistration found vacant entry 14164:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| (sending event approvedGRQ)reg 7 changed from vacant to receivedMessage 14165:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| previous highestOccupiedEntry: 6 14166:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| new highestOccupiedEntry: 7 14167:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| previous highestOccupiedEntry: 7 14168:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| new highestOccupiedEntry: 7 14169:10:10:52 inside snmpFlags 14170:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| received reply RGIcontinue on state receivedMessage with reason default 14171:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| (sending event sendingMessage)reg 7 changed from receivedMessage to sendingMessage 14172:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| received reply RGIcontinue on state sendingMessage with reason default 14173:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| gk sending GCF back to endpoint: 14174:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| (sending event transIdle)reg 7 changed from sendingMessage to transIdle 14175:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| received release transaction 14176:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| (executing releaseTransaction)reg 7 changed from transIdle to dataHandle 14177:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| closed open RAS handle 14178:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| sending event noPendingTrans 14179:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| sending event regVacant 14180:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| gkrgiCloseHandle 14181:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| (iutilCloseHandle)reg 7 changed from dataHandle to noHandle 14182:10:10:52 <r:7 undefined ras:0.0.0.0:0 cs:0.0.0.0:0 al: >| clearing the registration 14183:10:10:52 < >| previous highestOccupiedEntry: 7 14184:10:10:52 **** performing computeHighestOccupiedEntry **** new highestOccupiedEntry: 6 14185:10:10:52 < >| previous highestOccupiedEntry: 6 14186:10:10:52 evRASRequest success 14187:10:10:55 one of my team members is also running GM on FC4, and his client registers successfully. here is his gatekeeper log: 3790:10:10:12 _________________________________________________________________________block 27095 13791:10:10:12 New message recv <- Gatekeeper Request from ip 129.82.100.14:5011 13792:10:10:12 locateStatic located endpoint 'undefined' 13793:10:10:12 locateDynamic located endpoint 5 13794:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| located endpoint has the following parameters: 13795:10:10:12 No.|Type |RAS Add. |Call Signalling Add.|Phone |Terminal ID. 13796:10:10:12 5 |terminal |129.82.100.14:5011 |129.82.100.14:1720 | | Curtis Brown 13797:10:10:12 | |Trans. Name |Party Num. |EMail |URL 13798:10:10:12 | | | | | 13799:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| (sending event approvedGRQ)reg 5 changed from dataHandle to receivedMessage 13800:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| received reply RGIcontinue on state receivedMessage with reason default 13801:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| (sending event sendingMessage)reg 5 changed from receivedMessage to sendingMessage 13802:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| received reply RGIcontinue on state sendingMessage with reason default 13803:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| gk sending GCF back to endpoint: 13804:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| (sending event transIdle)reg 5 changed from sendingMessage to transIdle 13805:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| received release transaction 13806:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| (executing releaseTransaction)reg 5 changed from transIdle to dataHandle 13807:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| closed open RAS handle 13808:10:10:12 <r:5 terminal ras:129.82.100.14:5011 cs:129.82.100.14:1720 nm:Curtis B >| sending event noPendingTrans 13809:10:10:12 evRASRequest success 13810:10:10:12 13811:10:10:12 _________________________________________________________________________block 27096 On Mon, 2005-12-19 at 22:40 +0100, Damien Sandras wrote: > Le lundi 19 décembre 2005 à 14:32 -0700, Anthony DeNardo a écrit : > > I am using Fedora Core 4. gnomemeeting was installed with my > > "everything" install. > > Can you check your gatekeeper logs? > We have several users using Gatekeepers with GM from FC4 and nobody reported a problem. -- ========================================================= | Anthony DeNardo III | | Network Multimedia Architect | | Academic Computing & Network Services | | Colorado State University | | 970-297-3710 | | ad3 ColoState EDU | =========================================================
Attachment:
signature.asc
Description: This is a digitally signed message part