More netmeeting woes w/ gnugk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
    I hope that there is someone out there who isn't sick of "my
netmeeting isn't working," that is willing to lend me an ear.

I've been playing around with openh323gk for about a week now,
trying different versions and patches, and reading the mailing
list.  I've stumbled across this page, which (I think) accurately
describes what I'm seeing:

http://www.openh323.org/pipermail/openh323/2000-October/041422.ht
ml

But it seems to be a dead end, I can't find any more information
about this.  Can anyone confirm/deny this?

Perhaps those are the same symptoms, but not the same problem.
I'll describe in my own words what I'm trying to achieve.

To give you a run down of our set-up here, we've got a few public
IPs, and an internal network.  The internal IPs are NAT'd.  I've
got the gnugk gateway software to run on a FreeBSD router here.
It is bound to a different external IP address than what our NAT
map uses, and (hopefully) will act as a level III (as described
in the user manual) proxy.

I've set up our internal hosts to use the (h323) gateway to be
the private address of the router (192.168.1.40 for now).

I currently have a test machine (alias tracker) on the internal
network using netmeeting "logged into" our gnugk using the
advanced calling method.  If I set up another machine on the
internal network using the same method, I can establish a call,
no problem.  The problem occurs when I try to get the second
machine to use my gateway not through the advanced properties
method, but through the callto: protocol.  So I uncheck "use a
gatekeeper...," and restart netmeeting.  I then click a href with
the url:

callto:tracker+gateway=192.168.1.40

The test machine (tracker) receives the request, and I accept it
on the test machine, at which point the calling netmeeting gets
the message "The other party did not accept your call."

The call log (which is attached) states the reason:

admissionReject {
    requestSeqNum = 3
    rejectReason = routeCallToGatekeeper <<null>>
  }

Which I interpret to mean the test machine is telling the caller
to use the Gatekeeper as a proxy, and the caller is just seeing
that as a flat out reject.

It could be that I have it set up all wrong, as well.  :)

I've attached my latest gnugk config, as well the log
with -ttttt.  I'm currently using 2.0.8 cvsup'd on May 24th, but
I'm not adverse to 2.0.7, or 2.2b3...

The value that I'm looking to acheive is for much of the general
public to be able to call in to us via our website, so we can
have the cams going.  It's just a neat thing to have on the
website.  My purpose for using netmeeting is that it is already
installed on let's say 90% of our website's visitors, vs. any
other VoIP/video software.

If this is a limitation in netmeeting, does anyone have an
alternative method to acheive the above value?

I know I've seen nothing but headaches with netmeeting from
looking around, and this is a long-winded post, but I'd like to
give the full story.

Thanks!

Derek
(beware my return address, thanks)

gnugk netmeeting nat gateway callto routeCallToGatekeeper

Attachment: gnugk.log
Description: Binary data

Attachment: gnugk.ini
Description: Binary data


[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux