From owner-freebsd-stable@FreeBSD.ORG Sun Oct 10 00:56:33 2010
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id CB6451065674
for <freebsd-stable@freebsd.org>; Sun, 10 Oct 2010 00:56:33 +0000 (UTC)
(envelope-from jherman@dichotomia.fr)
Received: from mail.dichotomia.fr (hydrogen.dichotomia.net [91.121.82.228])
by mx1.freebsd.org (Postfix) with ESMTP id 8E5248FC14
for <freebsd-stable@freebsd.org>; Sun, 10 Oct 2010 00:56:33 +0000 (UTC)
Received: from [192.168.0.18] (bgn92-1-81-57-223-72.fbx.proxad.net
[81.57.223.72]) (Authenticated sender: kha)
by sslmail.dichotomia.fr (Postfix) with ESMTPSA id 8563C3DD062
for <freebsd-stable@freebsd.org>; Sun, 10 Oct 2010 02:38:07 +0200 (CEST)
Message-ID: <4CB10AEF.1000605@dichotomia.fr>
Date: Sun, 10 Oct 2010 02:38:07 +0200
From: Jerome Herman <jherman@dichotomia.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr;
rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: freebsd-stable@freebsd.org
References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <slrni8c5gj.1eap.vadim_nuclight@kernblitz.nuclight.avtf.net> <4C8627A6.1090308@icyb.net.ua>
<opviol28ky17d6mn@nuclight> <L9x6yD.1M0q@citylink.dinoex.sub.org> <20101008091231.GS2532@e-Gitt.NET>
<20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no>
In-Reply-To: <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5
(sslmail.dichotomia.fr); Sun, 10 Oct 2010 02:38:07 +0200 (CEST)
Subject: Re: ISDN4BSD removal
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Oct 2010 00:56:33 -0000
Le 08/10/2010 18:12, Torfinn Ingolfsen a écrit :
> Another thing about VoIP calls: have they solved the "emergency call
> needs a location" problem? Here (again: in Norway) they are still
> working out how to solve this: if you call emergency services (police,
> fire department, etc.) from yout VoIP number; how do the emergency
> center locate you? I mean; how do they know that you are at home,
> and not at say, a cabin half across the country? With old landlines,
> there is no problem; it is always installed at an address.
>
> Just my point of view.
The solution here in France are a mix of many moves, though they are
actually more recommandations than laws
- If it is a fixed place VoIP you have two solutions :
1) Emergency calls are routed to a plain old analog line
2) Your system have at least one localized caller-id (sends an
actual phone number instead of sip profile)
3) Fire alarms and elevators alarms have to be set up using POTS
(this part is actually a law)
- If it is a split VoIP (for exemple an in house virtualized PBX for a
company) :
1) The different places the virtualized PBX is managing can have
localized caller-id
2) The caller-id is replaced with the public IP address of the
place (tricky as the number can be mistaken for a real phone nuber.)
3) Caller name is replaced with the actual address (but again not
every system is configured to display caller-name properly, most ss7
installation trashes it)
- If it is a roaming VoIP (for exemple going through a VPN from your
laptop in a remote place)
1) You're screwed - some systems try to grab the public address
(through NAPT for exemple) but it doesn't work well
In fact more than a technical solution, it is a legal solution that is
needed. Bascially VoIP system should have a way to request for a local
physical address on the network. And then there should be a way for
firemen and policement to get this informations.
It is neither hard to do, nor does it impair in any way VoIP system. But
there is need for a norm, and right now there are no consortium debating
what should be done that I am aware of.
This said aquiring one localized number per site and playing with
routing tables solves 99% of cases.
Jerome Herman