[Wifidog] Teliphone

Pascal Leclerc leclerc.pascal at ireq.ca
Wed Jan 19 14:25:35 EST 2005

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 
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.


Yanik Crépeau wrote:

> 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.
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> iD8DBQFB7p800OgIseWq58IRAjdmAJ9E6DYzDXo1cNJcVn/zhoQeeIPKoACcDLcQ
> 2Hq6GlQdprQ4cYCj7qhBS1Q=
> =n+aC
> _______________________________________________
> 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

More information about the Wifidog mailing list