[Wifidog] Teliphone

Wed Jan 19 20:16:31 EST 2005

	I believe the Teliphone tunnels backwards to it's server, but I
haven't fired up tcpdump to find out for sure. Daniel D knows, but I
believe he signed an NDA with them.

Alex

On Wed, Jan 19, 2005 at 02:25:35PM -0500, Pascal Leclerc wrote:
> Date: Wed, 19 Jan 2005 14:25:35 -0500
> From: Pascal Leclerc <leclerc.pascal at ireq.ca>
> To: The WiFi Guard Dog project <Wifidog at isf.waglo.com>
> Subject: Re: [Wifidog] Teliphone
> 
> Note: I know that some people do not understand french, you can use 
> babelfish.altavista.com to translate and get the main idea of the 
> discussion. Don't be shy and ask volunteers for a better translation. 
> Sorry for my bad english, but I think it's easier to understand then 
> french  ;-)    The main subject is the support of wireless (802.11B) 
> phone by the wifidog gateway (wifidog will not ask the users for a 
> validation and allow users to receive incoming calls) .
> --------------------------
> 
> Wifidog supporte très bien Teliphone : Guillaume à reçu un appel sur son 
> téléphone sans fil à l'Utopik mercredi soir au meeting.
> 
> Pour le coté technique et le fontionnement, Alexandre C-V est 
> probalement le plus apte à répondre à tes questions puisque c'est lui 
> qui a ajouté le support Teliphone. En fait il a ajouté la possibilité 
> d'ajouter des règles (FirewallRuleSet) dans la config.
> 
> Regarde le fichier de config de wifidog 
> http://cvs.sourceforge.net/viewcvs.py/wifidog/wifidog/wifidog.conf?rev=1.22&view=auto 
> et tu devrais comprendre le fonctionnement.
> 
> Je n'ai pas compris tous les détails pour le moment, mais je vais m'y 
> attarder prochainement en ajoutant ce support à l'interface web de 
> Wifidog dans OpenWRT.
> 
>     Pascal
> 
> Yanik Crépeau wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Toujours dans la même veine:
> >
> > Source: http://www.intertex.se/upfiles/IntertexSIPWhitePaper.pdf
> >
> > Initiating communication from the public Internet to a device on a 
> > private LAN
> > is by definition a complex task for a firewall to handle. Supporting 
> > media
> > streams (voice and video) transported over separate ports negotiated 
> > in the
> > session setup, further adds to the complexity. Furthermore, the 
> > location of
> > individual users on a private protected LAN also has to be handled. 
> > Transparent
> > SIP traversal through firewalls and NATs requires specific handling of 
> > these issues.
> >
> > SIP initiates multimedia sessions carried over other protocols, for 
> > example RTP.
> > This means that when a SIP session has been started, various other 
> > protocols are
> > used as well, usually transmitted over TCP or UDP and using an arbitrary,
> > dynamically assigned, port number. This is a problem for a firewall that
> > generally opens up certain protocols and ports
> > in advance. But since the ports are dynamically assigned, which ports 
> > are to be
> > opened? Current firewalls do not support tunneling of dynamically 
> > allocated
> > media streams. Handling the SIP media streams through a firewall by 
> > opening a
> > wide range of ports is, of course, unacceptable from a security point 
> > of view.
> > Instead, a firewall that understands SIP can open up the ports for the 
> > right
> > protocols just when the SIP traffic needs it.
> >
> > A SIP message is destined for a specific user and therefore includes IP
> > addresses of the session participants in header fields. This is a 
> > problem if a
> > SIP session should be established through a firewall using NAT. The IP 
> > address
> > on the hidden side (which appears in the SIP headers) will not be the 
> > same as
> > the one that the clients on the outside should use. This problem can 
> > be resolved
> > in several ways. One is to make the SIP endpoints aware of NAT and let 
> > them
> > discover what IP addresses and port numbers they can use. This has a
> > several drawbacks. First, every SIP endpoint application needs to be 
> > modified ?
> > new software has to be written for them. Second, the NAT discovery is
> > problematic since different NATs work in different ways. Thirdly, this 
> > solution
> > works only for NAT since the firewall blocks IP packets not allowed to 
> > pass.
> > There is a suggested extension of the SIP protocol to handle this 
> > situation (NAT
> > Friendly SIP).
> >
> > A more general way is to integrate a SIP proxy server that rewrites 
> > the SIP
> > messages using proper global and local addresses on the respective 
> > public and
> > private sides. The proxy server can also control the NATing firewall 
> > and open up
> > for SIP initiated media streams.
> >
> > A third problem is to find the specific user on a private LAN using 
> > private IP
> > addresses. Onsuch LANs, all SIP-signaling is normally addressed to 
> > port 5060 on
> > the single global IP address of the Firewall. Thus, to handle incoming 
> > calls,
> > the firewall must cooperate with a location function having a register 
> > of all
> > SIP users inside the firewall. The location function can either be 
> > separate or,
> > as in the Intertex and Ingate products, be integrated in the firewall in
> > form of a SIP registrar.
> >
> > Handling these three issues in a firewall is necessary to allow users 
> > to use SIP
> > standard applications as they are designed today, no matter with whom 
> > they
> > communicate.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> >
> > iD8DBQFB7p800OgIseWq58IRAjdmAJ9E6DYzDXo1cNJcVn/zhoQeeIPKoACcDLcQ
> > 2Hq6GlQdprQ4cYCj7qhBS1Q=
> > =n+aC
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Wifidog mailing list
> > Wifidog at isf.waglo.com
> > http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.co
> > m
> 
> 
> 
> _______________________________________________
> Wifidog mailing list
> Wifidog at isf.waglo.com
> http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com

_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com