I can't seem to find anything for an RTP conntracker in the current cvs, maybe it's outdated if it exists. Nevertheless, I think these are the relevant RFCs
SIP (Session Initiation Protocol) -- RFC 2543 SDP (Session Description Protocol) -- RFC 2327 RTP (Real-Time Transport Protocol) -- RFC 1889 Now I'm wanting to jump into this but I need a few pointers from people "in the know". I've just read Rusty's netfilter hacking howto, and understood some of it ;-). You say it's the classic H.323 problem recast in SIP and .Net isms. So would reaading and trying to understand the H323 conntrac and nat modules be the first step? Also, I have a question right off the bat about H323. When using netmeeting you have the option to put in the person's ip address or use a directory server. When using the directory server, is the directory server involved in setting up the connection like I have explained the .Net servers are with Windows Messenger, or are they simply repositories with the ip address of the clients? Am I right in understanding this logic behind doing connection tracking? The first protocol involved that needs to be messed with is SIP. Does netfilter simply examine every packet and if it sees a packet that matches what appears to be an SIP packet, it then hooks into the loaded SIP conntrack module (or is it the nat, or helper module, I'm still trying to make these distinctions). So I'm thinking the SIP conntrack module reads the protocol, grabs the IP address and UDP PORT, then passes the packet off to the nat code to change the IP address to the external ip address. This is where my confusion is and you guys should be able to help me out. This is my thinking, the conntracking modules are responsible for holding the reference to the connection, in other words, they retain information so that when a client behind the firewall sends a reply out, the netfilter code looks back into the conntrack module and finds the related connection and modifies it accordingly. The conntrack modules call the nat modules to perform and translation that needs to be done. If this is correct, then what exaclty do the helper modules do? I'm thinking I may need a helper module since I'm tracking 3 different protocols that are all related to the session, and they somehow need to work with each other. Thanks guys. I'm hoping I can get a grasp on this as much as possible. I see what I want to do, I just need to know more about the netfilter architecture. > -----Original Message----- > From: Reynolds, Alfred [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 04, 2002 4:39 PM > To: 'Glover George' > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [UPnP-SDK-discuss] UPNP Server/Application > Gateway for Linux > > > So, UPnP is independent from the messenger problem. > The messenger problem is the classic H.323 problem recast in > SIP and .Net isms. Conntracker modules need to be written to > support SIP and it should work (a RTP conntracker already > exists right?) > > Another solution to the problem is to implement the UPnP > spec. This would remove the need to contrack SIP because > messenger does it for you > (essentially) by using the UPnP answer in its stream setup messages. > > When I looked at SIP/SDP last year, it was a pretty simple > protocol (especially when compared to H.323, SIP is plain > text not ASN.1 :) perhaps thats a good option. Especially > considering that SIP is becoming a dominant VoIP protocol, > and not all SIP clients will implement UPnP. > > > > -----Original Message----- > > From: Glover George [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 05, 2002 4:22 AM > > To: 'Jeffrey Damick' > > Cc: [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: [UPnP-SDK-discuss] UPNP Server/Application Gateway for > > Linux > > > > > > (P.S. - I'm putting this at the top because everyone may > not want to > > read this but I'd like a quick answer on this point : I know how to > > use tcpdump to see packets, but what do I use to view the > > data in the packets? What's a tool that lets you specify something > > about the packets that you want to view the data of and them > > maybe write > > them to stdout or a file? TIA) > > > > Ok, now the real message: > > > > And I as well think UPnP would be a great way to tackle the > > problem, but > > writing a UPnP server is more of task than simply modifying and > > connection tracking the connections with netfilter. I see > > them being 2 > > equally solvable points though. From the netfilter point of > > view, lets > > take a look at this. > > > > I've actually sat there and watched this try to work on my XP box > > before. Look here for where I got this from: > > http://www.microsoft.com/technet/treeview/default.asp?url=/Tec > > hNet/prodt > > echnol/winxppro/evaluate/insid01.asp > > > > When a user on computer A presses his "Start Video" button a > > request is > > sent first to Microsoft's .NET servers, and then to user > B's messenger > > client. User B's messenger asks him to accept or deny, and > > if accepted, > > user B's messenger sends an accpetance message back to the > .NET server > > where it is relayed to User A's messenger client. Up to this, > > everything works fine with the nat boxes as they are now. > > Everything is > > TCP up to this point and there's no problem with natting. > If you open > > your Windows Messenger you will see it send your request to > the other > > user, the other user gets it and in your own client you see > Messenger > > tell you that the other user accepted the call. > > > > Now at this point, messenger A is ready to begin telling User > > B how the > > call is going to be set up. If any of you have notice, Messenger > > constanly hits your default gateway on port 1900 looking for a UPnP > > server. Of course it doesn't find one, so Messenger is > > /supposed/ to be > > looking at it's own NIC interface to figure out the source ip > > to pass to > > user B. Messnger gets it's ip (either UPnP or locally) and > > also grabs a > > random port to use locally to listen and passes these > through the .NET > > server to user B. After this , I believe the .NET server > is no longer > > involved, except possibly on the destroying of the call. > Messenger on > > user A then begins listening on that ip and port that it > passed for a > > SIP INVITE from B. When B recieves this, it sends off a > SIP INVITE to > > B, and includes it's own ip and ports which it expects to > receive the > > RTP stream (data) from A on. B then starts listening on > this address > > and ports for the RTP traffic here. > > > > A then acknowledges the session ivite to B, and passes it's dynamic > > ports for RTP data via SDP (session description Protocol). A final > > acknowledgement is sent from B to A and the session is now in place. > > > > So from the netfilter point of view. When Messenger grabs > its local > > interface ip address (which doesn't matter if it's dhcp or not, > > because it's been assinged) and it's ports, netfilter needs to see > > this and remember the ports that windows messenger on A is > planning to > > listen to > > so that it can open these ports. Also, netfilter needs to > modify this > > source ip address in this packet (which could be > 192.168.xxx.xxx) and > > give it it's external ip. > > > > So if I'm thinking right, now that side A has sent of it's > connection > > information, and netfilter has opened the ports that A is > wanting to > > listen on, the only problem now is knowing which ip address > that comes > > in is the session info destined for A so that netfilter can pass it > > through to the internal A machine. This is probably what > you guys at > > netfilter have the most experience in and maybe someone > could throw me > > a bone here. I'm not sure if the .NET server ever passes > any of this > > information during the call initiation and acceptance to > > machine A about > > B. Otherwise, A's firewall is just going to have to accept > > whatever is > > destined for these ports regardless of who it's from (which probably > > isn't too secure!!). > > > > Shouldn't this work? > > > > Now from the writing a UPnP server point of view. Like you say, it > > would require hooking specific programs like the dhcp > server (which I > > would just shoot for isc's version if there's no arguments there). > > Like you, I haven't gotten too far into the UPnP stuff, but > it should > > be possible for the UPnP server to be modularized, and it would just > > require writing hacks for whichever dhcp server or firewalling code > > you'd like to use. I'm not sure exactly why you'd want to > > hook into the > > dhcp server on the firewall (other than its part of the spec) > > because if > > the windows machine got the ip from the dhcp server, then > its going to > > use it anyway. What exactly do we need the dhcp server for > again? (I > > need to reread some of the UPnP stuff). But regardless of the UPnP > > server or not, netfilter (ipchains whatever) needs to read > > these packets > > or be told by the UPnP server about the ports to open and > the ip's to > > allow/accept for those ports. > > > > So my thinking is we get something going in the netfilter > arena first, > > because it doesn't look to bad. Maybe I'm mistaken, but I > think this > > is much easier fix in the near term. With the experience gained > > here, and > > the experience from the UPnP people, we could start on a UPnP > > implementation for linux. Of course we need to get with > > netfilter, ISC > > (Bind), etc and talk to them about UPnP, their feelings on > it, and how > > best we might implement this with their products. > > > > I'm waiting on comments. Thank you. > > > > > > > > > -----Original Message----- > > > From: Jeffrey Damick [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, April 04, 2002 9:27 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [UPnP-SDK-discuss] UPNP Server/Application > > > Gateway for Linux > > > > > > > > > Hi, > > > > > > I believe UPnP would be the preferred way to tackle this > > > problem. There > > > is an IGD (internet gateway device) spec. that would make > > > this possible, > > > the only problem is the number of components that UPnP > > would have to > > > touch in order to meet the spec. I guess one question is > > which dhcp > > > server, fw/nat interface iptables, ipchains, do we support, > > > since we'd > > > have to have some kind of hooks into all of them.. don't get > > > me wrong > > > it's very possible to do, and i've actually been researching this > > > lately, but i dont have anything solid and ready to go right now.. > > > > > > > > > > > > -jeff > > > > > > > > > > > > [EMAIL PROTECTED] wrote: > > > > > > >Hello, > > > > > > > > It recently hit me that with all the h.323 work being > > > done with the > > > >netfilter team to pass NetMeeting traffic, there hasn't been > > > a general > > > >discussion on getting Microsoft Windows Messenger to work > > with linux > > > >firewall/NAT boxes. So I've just spent the better part of a day > > > >looking for answers on how to make this work. It has come to my > > > >understanding that the only way to do this is to either > modify the > > > >session initiation protocol (SIP), the real time transport > > protocol > > > >(RTP), and the remote desktop protocol's(RDP - same as > > > windows terminal > > > >services) internal data structures. Sorry if that's > > confusing, but > > > >what I mean is the Windows Messenger client looks either > > via UPNP to > > > >discover a NATing devices external (public) address that > > the client > > > >will be mapped to and encapsulates this address in the > > SIP, RTP, and > > > >RDP protocols respectively, or it simply looks at the ip > addresses > > > >assigned to the local NIC card. Herein lies the problem > > of private > > > >network addresses (or any NAT'ed addresses) being sent to > > > the receiver > > > >and therefore the receiver has no way to communicate > back with the > > > >client. > > > > > > > >Now I am very new to this, and just now getting my feet wet > > > so I wanted > > > >to ask everyone's opinion on what the preferable solution > > for linux > > > >would be. Also I may be wrong, after all my information > on Windows > > > >Messenger did come from the Microsoft site ;-) I don't > see a UPNP > > > >Server/Application Gateway on the net anwyhwere to use to > > implement > > > >UPNP on a linux machine. Am I missing something? IS there > > > in fact a > > > >solution out there? If not, is anyone working on one? I > > > would be more > > > >than happy to help, and if not, more than happy to start > a project > > > >implementing this. > > > > > > > >The questions is, is there a substantial need for UPNP on > > > linux? I can > > > >only think off the top of my head of a few, but I'm sure > > it would be > > > >very useful. Otherwise the only way I see in solving our > > immediate > > > >problems, is a netfilter module to modify these protocol > > packets (if > > > >indeed this is all it requires). > > > > > > > >Which leads me to my main question for the netfilter team: > > > Has there > > > >been any work, or is anyone working on trying to implement > > > something to > > > >make Windows Messenger video, audio, etc work? If so, > > please let me > > > >know their contact info. > > > > > > > >Thank you for taking the time to listen, and I would like to > > > offer my > > > >thanks in advance to any suggestions or comments. > > > > > > > >Glover George > > > >Systems/Networks Admin > > > >Gulf Sales & Supply, Inc. > > > >(228) 762-0268 > > > >[EMAIL PROTECTED] > > > >http://www.gulfsales.com > > > > > > > > > > > > > > > >_______________________________________________ > > > >UPnP-SDK-discuss mailing list > > [EMAIL PROTECTED] > > > >https://lists.sourceforge.net/lists/listinfo/upnp-sdk-discuss > > > > > > > > > > > > > > >
