[Wifidog] Teliphone

[Yanik Crépeau]

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