[Wifidog] Teliphone

[Pascal Leclerc]

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