Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Feb 2008 08:28:11 -0500

I have some conflicting thoughts on this.  It should be possible for a phone
to send the call itself direct to the PSAP URI.  The emergency call system
should be able to handle that.

On the other hand, carriers are generally thought of as useful partners by
the emergency call system, and a recommendation that they be bypassed won't
be appreciated by those folks even if there is an engineering argument that
it's more efficient.

Part of the reason is track and trace.  Part of the reason is subscriber
name and address.  The big one is identity.  Carriers provide reasonably
verified identity.

So, on balance, I think phonebcp should say, as it does now, that phones
pass emergency calls to wherever they normally pass outbound calls.
Frankly, the number of special processing steps we're asking phones to do
for emergency calls is getting too high.  I'd rather figure out ways to
remove some special processing, not add more.

Presently phones have to:
*Get location and do LoST lookups
*Watch for emergency dial strings
*Add Geolocation headers, PSAP URIs and service urns
*Disable some features
*Not send bye

If anything, that list is too long.  As with most things like it, the more
special stuff you do for emergencies, the less likely it is to actually work
in an emergency.

Generally, I think phones knowing where they are is a good thing in the big
picture, and having the phone do all dial plan interpretation is the right
thing also.  So the real special processing is the last three.  

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Thursday, January 31, 2008 11:31 PM
> To: Brian Rosen; Hannes Tschofenig; [email-masked]; ECRIT
> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering
> 
> We need to note the points where we are actually in agreement. Perhaps
> there was an inference that we weren't with respect to the following:
> 
> 1. The access network provider (the one that gets you onto the Internet)
> should not be responsible for providing any kind of emergency call
> processing.
> 
> 2. The access network provider does need to provide a location service
> that can be used for emergency call processing
> 
> 3. The LoST service with the translations for that point of access needs
> to be available from that point of access. Somebody is actually
> responsible for the physical infrastructure that supports it but it
> doesn't have to be the access provider - just so long as it's
> discoverable from the access.
> 
> I am in agreement with these principles - nothing I said below was
> inconsistent with them.
> 
> Direct to PSAP-URI calling is a supported mode of operation, yes? What
> distinguishes between the circumstance where a device does this versus
> trying to send the call through its VSP? It may be because the specific
> implementation of the VoIP client that the caller is using simply
> decides to do that. This includes the possibility that the client
> doesn't know its actually an emergency call and leaves it up to the VSP
> to do the digit analysis. It includes the case where the VoIP client
> doesn't know anything about ECRIT and just sends all calls to the VSP.
> 
> I don't think in this decision that's governed by the nature of the
> access is there? If not, discussion about NATs etc seem irrelevant to
> me. In fact, my standard "nomadic" VoIP service is Skype. In my office,
> our IS masters don't let Skype work. It's very difficult to guarantee
> that arbitrary VSP access is going to work from arbitrary access points.
> It's much simpler to guarantee that SIP calling directly to the relevant
> PSAP URIs for those points of access will always work. I think details
> such as whether an enterprise VoIP server is the thing that makes the
> PSAP call is just that - a detail. In such an environment, the clients
> and the server are part of the same package anyway. It's not at all the
> same situation as bringing Vonage, for example, into the picture when an
> emergency call is made.
> 
> When it comes to phone BCP, it should be quite possible to say that the
> phone client should always work to the local network and direct the call
> directly to the PSAP. This, in my view, is what pure-ECRIT should be
> about. It should also be possible to say that if the phone can only dial
> digits that are processed by the VSP, then subsequent behaviour is out
> of scope (but here's some suggestions). The NENA i2 architecture already
> has this covered and it's being picked up internationally anyway. It's
> an interim architecture; it'll go away as jurisdictions implement LoST
> and IP PSAP services and VoIP clients learn to use those functions. It
> would be preferable that, when the interim solution does disappear, that
> VSPs no longer need to have a role or responsibility for providing
> emergency access. It would be better for all concerned if they did not.
> 
> Here's the logic:
> 
> 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke
> i2.
> 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2
> 3.Phone can find LIS and LoST - call PSAP directly
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, 1 February 2008 3:56 AM
> To: Dawson, Martin; 'Hannes Tschofenig'; [email-masked]; 'ECRIT'
> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering
> 
> First my response to the original question:
> 
> IMS is special because the visited network is in the call path.  When
> the
> visited network has active elements in the call path, it makes sense to
> have
> the visited network handle emergency calls.  Note that there are lots
> and
> lots of complications with this.  Take for example, call back.  What you
> want is to have both a Contact URI that will route back to the device
> that
> placed the call, and you need a real AoR you can use to reach the caller
> later on.  The visited network would have to provide both.
> 
> When the visited network is not in the call path, you have to use the
> VSP.
> 
> 
> Then my response to Martin:
> > It's been said that the emergency service wants the subscriber details
> > from the VSP. A caller can have subscriptions to lots of Internet
> > services that also don't need to be involved in the call. Should we
> also
> > make emergency calling dependent on them?
> No.  However, involving the actual carrier that provides the service
> that is
> placing the call is essential.  Bypassing the carrier that provides the
> service that places the call is pretty tough, except in unusual
> circumstances.  IMS is an example of an unusual circumstance because
> they
> put the visited network in the call path.  Very few other systems do
> that.
> 
> I'm very conscious of what we must ask the access network to provide.
> This
> has lots of implications on engineering as well as cost and liability.
> Unless the device itself can locate itself without assistance of the
> access
> network, we ask the access network to provide location (or at least
> location
> assistance).  We ask them to provide access to a LoST server.  I want to
> stop there.  That's all they have to do.
> 
> >
> > I don't think it has to be the same as IMS. IMS requires a
> co-operative
> > E-CSCF that is actually part of the access network. With LoST and a
> > suitable emergency proxy, there doesn't have to be any dependency on
> the
> > access network to also provide call processing.
> IMS is different as discussed above.
> 
> >
> > Not involving the VSP in the call does not mean that the caller cannot
> > provide callback details (in principle, they could provide multiple
> > callback options). I'd also be interested in a discussion around
> > providing an automatic presence subscription from the emergency
> network
> > itself - with a temporary callback number. As long as the emergency
> > calling device is attached to the Internet, it should be able to stay
> > registered with that temporary subscription and also do regular
> location
> > updates to it.
> I think the notion that we can define the characteristics of an
> emergency
> proxy that works for all devices is not feasible.  Let me cite a few
> examples:
> 
> Emergency call from AOL/MSN/Yahoo.  We would have to require the device
> to
> implement SIP/SIMPLE.
> 
> Emergency call from OnStar.  Who is the emergency proxy provider?
> 
> Emergency call from "Help I've fallen and I can't get up" buttons with
> two
> way audio.  They would have to meet all of the phonebcp requirements.
> 
> Call backs are an issue.  You can get a contact URI, but you can't get
> an
> AoR you have any trust in for any call.
> 
> But the biggest problem is that I think any attempt to give the access
> network the obligation and the liability to totally handle emergency
> calls
> will not fly.
> 
> 
> >
> > Many of the most convoluted issues that have arisen in this forum have
> > been around the challenges that having the VSP involved in call
> routing
> > introduces (the need for forest guides etc). Since direct-calling is a
> > valid option, I know I'd prefer an emergency calling client that
> always
> > worked that way.
> 
> 
> 
> --------------------------------------------------------------------------
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------------------
> ----------------------
> [mf2]

_______________________________________________
Speermint mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/speermint

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Feb 2008 12:18:37 -0500

comments near end.

> thing also.  So the real special processing is the last three.  

???

 > *Add Geolocation headers, PSAP URIs and service urns

If you expect the phone to be the one that knows where it is, then how 
can you delegate adding the geoloc headers to somebody else?

 > *Disable some features

Well, features that are provided by the SP can be disabled by the SP. 
But features provided by the phone have to be disabled there.

 > *Not send bye

I don't understand what you have in mind here. If you don't disable 
sending bye, then it will be sent on hangup. There is nothing you can do 
in the network to prevent it.

As I see it, the key things the phone must do itself are:
- obtain its location
- recognize the dial string(s) that identify emergency calls and insert 
service URN & geoloc info
- disable features that are implemented on the phone.

The rest could be done by some server on the path.

The recognition of emergency numbers could be a shared responsibility. 
If a number wasn't recognized by the phone, an upstream entity that is 
in a position to recognize it as such could return a 3xx containing the 
service URN. That would clue the phone in to trigger the special processing.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 Feb 2008 08:56:11 -0500

I think we will have to agree to disagree.  I noticed you ignored identity.

Anyone else think the only way emergency calls should (normally) work is to
have all devices place emergency calls direct to PSAPs with (normally) no
proxies?

Brian

> Sent: Sunday, February 03, 2008 10:20 PM
> Hi Brian,
> This seems to suggest that there's a complexity argument for saying
> phones should pass emergency calls however they "normally" make calls.
> 
> If we have a precept that says it must always be possible to make a call
> directly to the PSAP URI from a given point of access, then also
> supporting call routing via the VSP can only add complexity. Issues such
> as how do VSPs that don't use SIP work, or recognizing dial strings when
> the VSP doesn't know what the intent and regional conventions are, or
> the VSP finding the right LoST server when it's not in a position to
> perform local discovery are all complexities that arise by not sending
> the call directly to the PSAP URI. They are all things that make the
> handling of an emergency call more brittle.
> 
> The question of what is "normal" can only become more fuzzy over time as
> well. Increasingly we just have IP-enabled multimedia devices that can
> have an arbitrary number of service clients/subscriptions hosted on
> them. I think this is really the environment that ECRIT should be
> focussed on. It's the device that should know how to initiate and
> support emergency calling - not the potential multitude of other service
> clients hosted on that device.
> 
> Ideally, all devices should have practically the same implementation
> that knows how to do local location and LoST service discovery and to
> subsequently contact the local emergency service. Dedicated VSP client
> devices could integrate such a reference implementation, provide a
> mechanism to call it, and only invoke VSP-specific emergency handling if
> (as I described below) the local network does not appear to support the
> necessary ECRIT functions. This should result in less complexity over
> time with more and more consistent implementations from the device
> perspective as well as the network perspective. As long as the reference
> client works, then the network is doing the right thing.
> 
> "Track and trace" become Internet access issues. We get to the point
> where we have optimal assurance that the access is local to the
> emergency jurisdiction and we have all the same wherewithal with respect
> to this function as we do with the PSTN - without needing to think that
> VSPs are important to it.
> 
> I think everything that ECRIT has is just about right. I just think that
> the mantra about "normal call processing" has things the wrong way
> around. i.e I have the opposite view to what you expressed, Brian.
> Ultimately, I think VSP involvement should go away - and not actually be
> the recommended approach in perpetuity. The VSP considerations should
> become recommendations that are ultimately deprecated.
> 
> Note - I understand very well that redoing documentation and recanting
> on policy is a demotivator. However, now is always the best time to
> change if we don't have things quite right.
> 
> Cheers,
> Martin
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Saturday, 2 February 2008 12:28 AM
> Subject: Re: [Ecrit] Emergency Calls & VoIP Peering
> 
> Ecrit mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Duane <[email-masked]>
Date: Tue, 05 Feb 2008 05:02:14 +1100

> have all devices place emergency calls direct to PSAPs with (normally) no

(sorry if I have duplicated what others have written, I'm trying to
catch up on emails/this thread)

This is a double edged sword, it reduces the risk or problems caused
when any of the hops in the middle fail especially if there is a lack of
redundancy, this would/should have better call quality if there is no
codec conversions occurring in the middle as well.

That said however setups I'd suggest putting the smarts at the emergency
side of things rather then the phone and you could deal with calls in
some kind of smart fashion ideally utilising geoip information so that
only people within x km distance can make those calls, otherwise extra
work would be generated for no ones benefit due to abuse.

You could go one step further and have calls go to a central switch that
redirects the SIP calls based on IP location etc.

Also I really like how all GSM carriers honour (or were forced to
honour) calls to 112, which can redirected to the local emergency number
and I really wish carriers the world over could come up with a similar
thing, not just for VoIP but all phone services in general, because as
the number of international travelers increase, how many keep up with
the local emergency number?

Then of course you could possible handle multilingual services this way
too, although for the local language you shouldn't have to wait for the
full prompt.

Even with the above limitations in place you would probably need some
ISP industry consensus on procedures with respect to localised abuse,
this would need to cover things like bot infested PCs generating calls.

No doubt as others have pointed out this would need some kind of
subscriber authentication/information and one way would be real time, or
near real time to subscriber information based on the IP address similar
to databases that store phone number and subscriber information used by
law enforcement agencies etc to cover IPs. Which is just another
slippery slope, especially for countries already in the grips of police
like states.

-- 

Best regards,
 Duane

http://www.freeauth.org - Enterprise Two Factor Authentication
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 4 Feb 2008 19:20:21 +0100

The access network in 3GPP is the part of the network that provides the
radio access and the first level of mobility management. 

From there you have the access network and part of the core network
providing IP connectivity to the first element that appears at the SIP
layer. That IP connectivity can end you up in the local network or the
home network.

I would suggest you are probably looking for something like IMS local
network.

Regards

Keith 

> Sent: Thursday, January 31, 2008 5:10 PM
> To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; 
> [email-masked]; 'ECRIT'
> I made the same assumption, which I know to be wrong.  Thank 
> you for correcting us.  Is "3GPP Access Network" the right 
> terminology for the kind of network where the visited network 
> provides the E-CSCF?
> 
> Brian
> 
> > From: Stark, Barbara [mailto:[email-masked]]
> > Sent: Thursday, January 31, 2008 12:05 PM
> > To: Dawson, Martin; Hannes Tschofenig; [email-masked]; ECRIT
> > snip...
> > > IMS requires a co-operative
> > > E-CSCF that is actually part of the access network.
> > 
> > This is not true. Please don't confuse "IMS" with "3GPP 
> Access Network"
> > and early 3GPP IMS definitions. They aren't the same. It's 
> absolutely 
> > possible to have an IMS core that exists only on the Internet, and 
> > that makes no assumptions about access networks.
> > Barbara
> > 
> > *****
> > 
> > The information transmitted is intended only for the person 
> or entity 
> > to which it is addressed and may contain confidential, proprietary, 
> > and/or privileged material. Any review, retransmission, 
> dissemination 
> > or other use of, or taking of any action in reliance upon this 
> > information by persons or entities other than the intended 
> recipient 
> > is prohibited. If you received this in error, please contact the 
> > sender and delete the material from all computers. GA622
> > 
> > 
> > 
> > https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> https://www1.ietf.org/mailman/listinfo/ecrit
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 Feb 2008 13:32:59 -0500

> codec conversions occurring in the middle as well.
Putting proxies in the middle doesn't imply something is in the middle of
the media path.  It often is, but the discussion we're having doesn't depend
on that.  Your double edged sword applies to codecs.  How many codecs can we
expect the PSAP to reasonably implement?  Are you forcing ALL devices to
implement at least one of those codecs?  History suggests this won't work.

> work would be generated for no ones benefit due to abuse.
That makes no sense to me.  The PSAP can't enforce any form of admission
control unless it's under attack, and x km distance doesn't work at all
--service boundaries don't depend on distance from a caller, they depend on
jurisdictional boundaries that are absolute.

> redirects the SIP calls based on IP location etc.
There is no "central switch" in the Internet.  That is the point of the
Internet.

> the local emergency number?
Please go back and look at the archives in this list for discussions on
local and home dial strings.  Despite the appeal of the entire world
accepting 1-1-2 as the sole emergency number, it won't happen in your
lifetime.

> too, although for the local language you shouldn't have to wait for the
At the moment, that is outside the scope of the work in ecrit.  In NENA, we
plan to allow routing that depends on the language headers in the SIP
messages.

> this would need to cover things like bot infested PCs generating calls.
As I said, identity is the big problem with a direct connection from caller
to PSAP.

> slippery slope, especially for countries already in the grips of police
So you propose to have credential based authorization to get on the local
access network, map that to some kind of identity that can be put on a SIP
call, assume all bad devices will do that, and check it on entrance to a
PSAP? 

In the end, are you in favor of a direct connection from calling device to
PSAP (no proxy servers other than in the emergency services IP networks)?

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 Feb 2008 13:35:05 -0500

I'm looking for a term of art when a local access network is IMS aware, and
the local network provides the E-CSCF.  Not all IMS systems do that, right?

Is "IMS local network" a known term of art where I can expect an E-CSCF to
handle emergency calls rather than forwarding to the home domain?

Brian

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, February 04, 2008 1:20 PM
> To: Brian Rosen; Stark, Barbara; Dawson, Martin; Hannes Tschofenig;
> [email-masked]; ECRIT

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 04 Feb 2008 19:39:51 +0000

My assumption is that "local network" is fairly well understood to mean
"the network with which the IP-CAN to which the user is currently
attached, is associated".  In other words the local network is the
visited network if you're roaming, your home network otherwise.  

Do all IMS networks provide an E-CSCF?  I doubt any do at the moment,
because the standards are pretty new and not all details are resolved.

If there were an E-CSCF in the "IMS local network" I would expect it to
behave per TS 24.229, which indicates that the call is directed to the
PSAP by the E-CSCF and is NOT forwarded to the home network.  

Tim

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Monday, February 04, 2008 12:35 PM
> To: 'DRAGE, Keith (Keith)'; 'Stark, Barbara'; 'Dawson, 
> Martin'; 'Hannes Tschofenig'; [email-masked]; 'ECRIT'

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Feb 2008 17:03:49 -0500

Duane wrote:

> I am, but it's a very delicate situation that has to extend beyond
> boundaries to try and cover the globe, remember my little pipe dream
> about 112?

I don't buy into your pipe dream. If I want to have a dial plan in my 
office in the USA that uses office numbers as extension numbers, then I 
want to be able to call office 112, and telling me I can't have office 
number 112 because of emergency dialing conventions in Germany isn't 
going to fly with me.

Also, is it just a *complete* string of 112, or is it any number that is 
prefixed with 112? That makes it worse.

IMO my phone should have a dial plan that works the same no matter where 
I take it. If I am in Germany and want to dial somebody in Germany then 
I will do so using the same dialing conventions I use to dial that 
person in Germany when I am at home in the US. And if I have an 
emergency I will invoke that the same (911) no matter where I am, 
because that is the way I expect my phone to work. (Dialing 911 ought to 
get me the local German PSAP if I happen to be in Germany.)

But I am sure Brian has been thru this many times, and what *I* want 
doesn't matter.

	Paul

---

From: Duane <[email-masked]>
Date: Wed, 06 Feb 2008 10:50:38 +1100

> I don't buy into your pipe dream. If I want to have a dial plan in my

I'm not in Germany :P

However that small issue aside, any GSM mobile phone any where can dial
112 and it just works, although it doesn't have to be 112, do you also
setup 911 as an extension for kicks too? :)

-- 

Best regards,
 Duane

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Feb 2008 19:21:17 -0500

>> I don't buy into your pipe dream. If I want to have a dial plan in my

Sorry. I wasn't intending to suggest that you were. I only used germany 
as a place where I thought (I'm not certain) 112 was valid.

> 112 and it just works, although it doesn't have to be 112,

I hope it at least must be "112<send>", rather than it initiating the 
call after you press the "2" in "112" ??? At least then it only takes 
one sequence out of play, rather than all sequences with that as a prefix.

If you started imposing such a rule on land lines then I fear it would 
be restricted as a prefix, because many people don't expect to type a 
special <send> key on traditional phones.

> do you also

I can see how a hotel where 911 isn't special might want to use 911 to 
dial room 11 on the 9th floor.

My primary point is that reserving particular numbers in one dial plan 
because of decisions made in an unrelated context is a very bad idea in 
general. I'm pretty sure that 112 and 911 aren't the only emergency 
numbers in the world. Should we reserve 666 everywhere because somebody 
somewhere decided to use that as their emergency number?

I do have some sympathy for this concept in places like hotels that 
provide phones for use by travelers. They already typically have a 
private dial plan, and can adjust it carefully to allow for all these 
reserved numbers that their guests might be inclined to try.

But I find it less than compelling that *my* cell phone needs to 
recognize 112 because somebody else might try to use it to make an 
emergency call.

	Thanks,
	Paul

---

From: Duane <[email-masked]>
Date: Wed, 06 Feb 2008 14:10:14 +1100

> recognize 112 because somebody else might try to use it to make an

That wasn't even my original point, I was pointing out travelers, ie
you, go somewhere different, ie Europe or Australia and take your GSM
mobile phone with you and you don't need to know or care what the local
emergency number is, you just have to remember 112.

-- 

Best regards,
 Duane

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 6 Feb 2008 16:07:39 +0100

GSM phones have a multilayered approach to this process, and the
distinction only works for numbers that are used in conjunction with a
public telecommunications number.

-	Firstly 112 and 911 are always recognised by the phone itself.

-	Secondly a batch of numbers can be configured on the SIM or
UICC. The principle here is that these are the local service numbers
that are used for emergency in foreign countries, but are not used for
other local service number purposes in the home network.

-	Thirdly if the SIM or UICC is not present, then the following
numbers also act the same as 112 and 911, that is 000, 08, 110, 999, 118
and 119.

-	Fourthly the protocol used between the network and the phone
also allows the downloading of emergency numbers, which are assumed to
be the valid emergency numbers for the local network.

However as soon as you get to private numbering plan numbers, then these
will frequently conflict, unless you have a means of distinguishing
numbers that appear in the private number plan from local service
numbers that appear in the public number plan. This can be done in ISDN,
and for tel URIs, but cannot be performed for an analogue phone sending
LD or DTMF.

For them not to conflict, any potential emergency number has to be
assigned as a valid number in that particular private numbering plan as
well as being a local service number in the public numbering plan. This
is something that owners of hotels, for example, are unlikely to do
without rebuilding the hotel minus room 112.

Finally, in response to Paul

>	I hope it at least must be "112<send>", rather than it
initiating the call after you 
>	press the "2" in "112" ??? At least then it only takes one
sequence out of play, rather 
>	than all sequences with that as a prefix.

Treating "112" and "1120" as two different valid numbers is something
that I have heard of only being used in the US. It has taken ages to
explain that people sometimes do it to colleagues outside the US.

Regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Duane
> Sent: Wednesday, February 06, 2008 3:10 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering
> 
> Paul Kyzivat wrote:
> 
> That wasn't even my original point, I was pointing out 
> travelers, ie you, go somewhere different, ie Europe or 
> Australia and take your GSM mobile phone with you and you 
> don't need to know or care what the local emergency number 
> is, you just have to remember 112.
> 
> -- 
> 
> Best regards,
>  Duane
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 12:24:20 -0500

> emergency number is, you just have to remember 112.

But us provincial Americans don't remember 112 as an emergency number.
[If God had meant 112 to be the emergency number then he wouldn't have 
given us 911.] :-)

I don't think of my self as provincial, but even though I travel out of 
the country a modest amount, I can't remember the last time I used a 
phone that was homed in another country and had a foreign dial plan, so 
I really have little interest in what other emergency numbers are except 
in discussions like this about implementing emergency services.

Emergency numbers are designed to work with a particular dial plan. If 
you import a number designed to work with one dial plan, into an 
unrelated dial plan, then you mostly get a mess.

In reality 112 is perhaps a fortuitous accident in that I don't think it 
conflicts with anything in the North American Numbering Plan.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 12:32:20 -0500

> without rebuilding the hotel minus room 112.

They can do that at the same time they leave out room 666 and the 13th 
floor. :-)

> explain that people sometimes do it to colleagues outside the US.

Funny, because the concept is alien in the US. I thought it was only in 
places like Germany and France where that sort of thing was in common 
use. I have just recently had a discussion of how to implement overlap 
dialing to support this somewhere. We keep hoping it will go away 
because of phones with <send> keys enabling en bloc dialing. But that 
argument doesn't seem to be winning yet.

I only bring it up because if you want to bring in a particular number 
that may otherwise conflict with the local dialing plan, then it has a 
larger potential impact if it preempts all numbers with that prefix than 
it has when it only preempts itself.

With en bloc dialing, 112 would only bother hotels with three digit room 
numbers. Hotels with with 4 digit room numbers wouldn't have to block 112*.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 7 Feb 2008 12:57:09 +0100

> 
> Funny, because the concept is alien in the US. I thought it 
> was only in places like Germany and France where that sort of 
> thing was in common use. I have just recently had a 
> discussion of how to implement overlap dialing to support 
> this somewhere. We keep hoping it will go away because of 
> phones with <send> keys enabling en bloc dialing. But that 

My only known example of the use of this is in the US, in local service numbers. If I can think back to about 1980 and a very hazy memory, it was used where xxx represented the local service number for operator assistance generally and xxx followed by an area code represented operator assistance specifically for that area. To distinguish required a shorter timeout between the two elements of the number in DTMF and LD phones.

Germany (and Austria) has variable length numbers but 112 and 1120 never coexist. Rather adjacent numbers in the numbering plan may be of different length, e.g.

1230
12310
123111
123112
123113

Regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, February 06, 2008 5:32 PM
> To: DRAGE, Keith (Keith)
> Cc: Duane; [email-masked]
> > numbers also act the same as 112 and 911, that is 000, 08, 
> 110, 999, 
> > 118 and 119.
> > 
> > However as soon as you get to private numbering plan numbers, then 
> > these will frequently conflict, unless you have a means of 
> > distinguishing numbers that appear in the private number plan from 
> > local service numbers that appear in the public number 
> plan. This can 
> > be done in ISDN, and for tel URIs, but cannot be performed for an 
> > analogue phone sending LD or DTMF.
> > 
> > assigned as a valid number in that particular private 
> numbering plan 
> > as well as being a local service number in the public 
> numbering plan. 
> > This is something that owners of hotels, for example, are 
> unlikely to 
> > do without rebuilding the hotel minus room 112.
> 
> They can do that at the same time they leave out room 666 and 
> the 13th floor. :-)
> 
> Funny, because the concept is alien in the US. I thought it 
> was only in places like Germany and France where that sort of 
> thing was in common use. I have just recently had a 
> discussion of how to implement overlap dialing to support 
> this somewhere. We keep hoping it will go away because of 
> phones with <send> keys enabling en bloc dialing. But that 
> I only bring it up because if you want to bring in a 
> particular number that may otherwise conflict with the local 
> dialing plan, then it has a larger potential impact if it 
> preempts all numbers with that prefix than it has when it 
> only preempts itself.
> 
> With en bloc dialing, 112 would only bother hotels with three 
> digit room numbers. Hotels with with 4 digit room numbers 
> wouldn't have to block 112*.
> 
> 	Thanks,
> 	Paul
> 
> > Regards
> > 
> > 
> > Keith
> > 
> > 
> travelers, ie 
> >> mobile phone with you and you don't need to know or care what the 
> >> local emergency number is, you just have to remember 112.
> >>
> >> --
> >>
> >> Best regards,
> >>  Duane
> >>
> >> --
> >> This message has been scanned for viruses and dangerous content by 
> >> MailScanner, and is believed to be clean.
> >>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 15 Feb 2008 09:20:47 -0500

We're finalizing the IETF 71 agenda now.  Do we want to add this
discussion topic to the meeting, and if so who wishes to speak and what
document will we review?

Jason