From owner-freebsd-questions Tue Apr 13 9:51:20 1999 Delivered-To: freebsd-questions@freebsd.org Received: from fast.cs.utah.edu (fast.cs.utah.edu [155.99.212.1]) by hub.freebsd.org (Postfix) with ESMTP id 08F2C14D53 for ; Tue, 13 Apr 1999 09:51:18 -0700 (PDT) (envelope-from vanmaren@fast.cs.utah.edu) Received: (from vanmaren@localhost) by fast.cs.utah.edu (8.9.1/8.9.1) id KAA15386; Tue, 13 Apr 1999 10:48:56 -0600 (MDT) Date: Tue, 13 Apr 1999 10:48:56 -0600 (MDT) From: Kevin Van Maren Message-Id: <199904131648.KAA15386@fast.cs.utah.edu> To: cshenton@uucom.com, vanmaren@cs.utah.edu Subject: Re: H.323 support for natd Cc: freebsd-questions@FreeBSD.ORG Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Kevin> Is anyone working on adding support for H.323 (used for video > Kevin> conferencing, like M$ netneeting, and Intel video cameras) to > Kevin> libalias? > > H.323 is a nightmare of a protocol, obviously designed by committee, > not coders. There are a couple random ports selected where the client > and server rendezvous to then decide on which ports they really want > to use for the data. Client/server address and port are transmitted > in the payload rather than the IP header. This means the NAT (or > proxy) would have to follow this gross port negotiation by grubbing > through the payload. The protocol is yet another ITU production so the > specs aren't on line like RFCs. I knew about the port problem -- I ran tcpdump when natd under FreeBSD wasn't working. But the specs not being available was what I was afraid of...but it is based on RTP, which apparently is RFC 1889. I don't have time right now to reverse-engineer what is going on, but maybe this summer I'll finally get annoyed enough that my Intel camera SW doesn't work behind my FreeBSD natd to try... I'll read the paper your wrote. I know some of the commercial natd/fw products support it, and I was hoping it was just another module for libalias (like ftp) that someone had written but not committed yet... > We insisted on decent security before we'd deploy because NetMeeting's > application sharing gives remote users access to anything on your > machine or LAN that you have access to, trivially, and there's > nothing like strong user-level authentication built into it. Really? Now that's a problem. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message