Subject: [Ecrit] Architecture comparisons

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Jun 2007 09:38:05 -0400

I think it would help things if we compare apples to apples. We seem  
to agree that both VSP and ISP will run a LoST resolver (and contact  
other LoST servers). There are two cases based on the proposals:

(1) ISP makes the LoST information available via LoST

(2) ISP makes some LoST information (partially) available via some  
yet-to-be-specified extension to HELD

We then have a second dimension: whether LoST resolution is done by  
the UA or the VSP.

*** UA resolution case

For the UA resolution case, we presence of the FG makes no  
difference. If resolution by the foreign VSP fails, the UA will  
contact the ISPs LoST server. (Which LoST servers to contact first is  
something that the Phone BCP would presumably cover.)

If there is no FG, for Solution 1, the foreign VSP gets rough  
location information and can thus at least restrict those callers to  
domestic calls within that country by matching E.164 prefixes, rather  
than offer worldwide free long distance calls. In countries where the  
VSP has LoST information (see below), validation is possible.

For Solution 3, the VSP has no means of distinguishing the caller's  
girl friend in Haiti from a PSAP.

*** VSP resolution case

This isn't an option for Solution 3, since it relies on UA resolution.

For Solution 1, the resolution will work for all countries where the  
VSP has established a LoST presence. (A VSP with an international  
customer base, such as Skype, could run its own 'private' FG until  
such time that there is a public one.)

With Solution 4, it will work even for those cases where only the ISP  
has LoST information.

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Jun 2007 12:08:44 -0400

I don't understand the line:
> ....If resolution by the foreign VSP fails, the UA will
> contact the ISPs LoST server. 
This sentence is in "UA resolution".  The UA would FIRST try using the LoST
server suggested by its ISP (which should be local to it), and failing that
would try a LoST server suggested by its VSP.

I am glad you pointed out that Solution 3 doesn't permit the VSP to route.
While it would be rare, I think, for the UA to have location, but not be
able to route, I think we have to allow for that case.  The VSP should be
able to route if the UA fails to route.  I am uncomfortable with the access
network saying that the UA has to use the route it supplies, or the system
fails.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, June 18, 2007 9:38 AM
> To: ECRIT
> Subject: [Ecrit] Architecture comparisons
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Jun 2007 12:32:47 -0400

> would try a LoST server suggested by its VSP.

I admit not checking the current text in the phone-bcp before writing  
my note and agree that checking locally first makes sense. I don't  
think this changes the basic thrust of the discussion.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 18 Jun 2007 18:17:47 -0500

Perhaps I am missing something here.

We have a local LoST server that provides PSAP URI when given location.
We have a forset guide in Sierra Leone that knows how to find this LoST
server.

We have a UA that asks the LIS for location.
The LIS gets location, performs  LoST lookup, and returns the PSAP URI.

Please tell me how the VSP is going to do any better even if we give it
location, given that the forest guide it uses will take it to the same
LoST server.

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, 19 June 2007 2:09 AM
> To: 'Henning Schulzrinne'; 'ECRIT'
> Subject: RE: [Ecrit] Architecture comparisons
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Jun 2007 21:19:33 -0400

Are you having the same problems Martin did?

The assumption is that the endpoint cheats.  What it supplies as a PSAP URI
is not what it gets from LoST.  We hope indeed that the forest guide takes
it to the same server the endpoint used (or should have used).

VSP will get the real one, not what the endpoint claims. 

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Monday, June 18, 2007 7:18 PM
> To: Brian Rosen; Henning Schulzrinne; ECRIT

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 18 Jun 2007 20:27:30 -0500

No Brian, I am not having the problem that Martin had as I set him
straight.

If there is no forest guide, then the VSP cannot check if the end-point
is cheating, EVEN IF A LOCATION IS PROVIDED. As Barbara has pointed out
several times now, and you choose to ignore, forest guides will not be
universally deployed for quite some time (please read years), so until
they are, solution 1 provides nothing better than solution 3 from a VSP
stop-the-cheaters perspective, but does place a lot of burden on
location providers. 

Given this, the VSPs can only do one of three things, drop the call,
bill for it, let it go for free. Solution 1 does not solve this unless a
sizeable percentage of the coverage area has forest guides, and this
will not be the case for some time.

Itso facto solution 3 is better for location providers and provides no
disadvantage to VSPs over option 1 for the near to medium term.

Cheers
James

> Sent: Tuesday, 19 June 2007 11:20 AM
> To: Winterbottom, James; 'Henning Schulzrinne'; 'ECRIT'
> The assumption is that the endpoint cheats.  What it supplies as a
PSAP
> URI
> > > This sentence is in "UA resolution".  The UA would FIRST try using
the
> > > LoST
> > > server suggested by its ISP (which should be local to it), and
failing
> > > that
> > > I am glad you pointed out that Solution 3 doesn't permit the VSP
to
> > route.
> > > While it would be rare, I think, for the UA to have location, but
not
> > be
> > > able to route, I think we have to allow for that case.  The VSP
should
> > be
> > > able to route if the UA fails to route.  I am uncomfortable with
the
> > > access
> > > network saying that the UA has to use the route it supplies, or
the
> > system
> > > > contact the ISPs LoST server. (Which LoST servers to contact
first
> > is
> > > > than offer worldwide free long distance calls. In countries
where
> > the
> > > > With Solution 4, it will work even for those cases where only
the
> > ISP
------------------------------------------------------------------------
> --
> > ----------------------
------------------------------------------------------------------------
> --
> > ----------------------

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 19 Jun 2007 08:35:15 -0400

All,

In my attempt to follow this thread, I've concluded that there is a belief
the access provider will have information wrt LoST authoritative servers
that VSPs won't have.

Is my assumption correct?

Is it not true that the architecture we've adopted depends on the forest
guide to 'find' the authoritative LoST server?  So, this raises the
question, short of a working forest guide, how does the access provider find
the authoritative LoST server and why can't the VSP use the same such
mechanism?

Just curious,

-Marc-

> Sent: Monday, June 18, 2007 9:28 PM
> No Brian, I am not having the problem that Martin had as I 
> set him straight.
> 
> If there is no forest guide, then the VSP cannot check if the 
> end-point is cheating, EVEN IF A LOCATION IS PROVIDED. As 
> Barbara has pointed out several times now, and you choose to 
> ignore, forest guides will not be universally deployed for 
> quite some time (please read years), so until they are, 
> solution 1 provides nothing better than solution 3 from a VSP 
> stop-the-cheaters perspective, but does place a lot of burden 
> on location providers. 
> 
> Given this, the VSPs can only do one of three things, drop 
> the call, bill for it, let it go for free. Solution 1 does 
> not solve this unless a sizeable percentage of the coverage 
> area has forest guides, and this will not be the case for some time.
> 
> Itso facto solution 3 is better for location providers and 
> provides no disadvantage to VSPs over option 1 for the near 
> to medium term.
> 
> Cheers
> James
> 
> 
> 
> 
> 
> > > Please tell me how the VSP is going to do any better even 
> if we give
> it
> > > > > ....If resolution by the foreign VSP fails, the UA 
> will contact 
> > > > > the ISPs LoST server.
> > > > > I think it would help things if we compare apples to 
> apples. We
> seem
> > > > > We then have a second dimension: whether LoST 
> resolution is done
> by
> > > > > the UA or the VSP.
> > > > >
> > > > > *** UA resolution case
> > > > >
> > > > > For Solution 1, the resolution will work for all 
> countries where
> the
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.
> > >

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 08:36:26 -0400

I don't agree that forest guides will be years in the making, unless you
mean a single, guaranteed to work always forest guide.  It's a percentage
game.  I think VSPs will start out with 80-90% coverage, and expand from
there.

Barabara's statement on forest guides was:
 I think reverse LoST would be a nice feature, but I don't see it as 
 necessary. Initially, the utopian view of a worldwide LoST network won't
 exist, anyway. It will be possible for a VSP to get a call to a completely 
 valid foreign PSAP URI, but not be able to validate that URI either 
 through reverse LoST or through regular LoST look-up of a coarse location.
 If the Forest Guide pointers (or whatever they are) don't exist for a VSP 
 to get to the correct foreign LoST server, then the VSP will be unable to 
 validate the URI. I'm pretty sure I've read somewhere on this list that 
 Forests will most likely initially grow in disconnected clumps -- but 
 please correct me if I'm wrong here.

I agree with her.  VSPs won't have access to worldwide LoST coverage any
time soon, and forest guides will start out in disconnected clumps.  That is
still a percentage game.  If 90% of their emergency calls happen from places
they CAN validate, then their fraud problem is considerably smaller than if
they had no way to validate.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 08:44:15 -0400

The data comes locally (from the local emergency services authorities).  It
is reasonable to assume that the access network is more likely to have
access to the data than some far away VSP.  If the VSP is also local, then
they will have equal access, but I think you have to assume the access
network is more likely to have the data.

I think as a practical matter that most access networks will arrange to have
a replica of the LoST database that they keep in their network, that the
local emergency authorities supply with data.  LoST includes mechanisms to
make this possible, although I suspect that other ways will be more common
(traditional database replication routines).  VSPs may also make such
arrangements, but they have more of them to worry about unless they prohibit
nomading.

The forest guides should work; I think they will work quite well actually;
it's in everyone's best interest to see that they do, and even if there are
a few clumps, it should be easy for a VSP to arrange access to each of the
clumps.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2007 8:35 AM
> To: 'Winterbottom, James'; 'Brian Rosen'; 'Henning Schulzrinne'; 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Jun 2007 10:25:16 -0400

I'll ad to the crystal ball gazing sessIon:

I think the evolution will depend on who will be running LoST servers  
and how data is distributed. One model is that the PSAP or other  
government authorities will make data available, but LoST servers  
will be run by private enterprises. Another is that these authorities  
will run it themselves. The depth of the trees will presumably depend  
on the level of federalism in the respective country, with some  
countries, like France, presumably going national immediately, while  
others, such as the United States and Germany, maybe starting bottom  
up, with some progressive states going first.

Regardless, as long as these trees make coverage information  
available or such information can be derived, it's not too hard for  
either a larger VSP or some third-party service company to aggregate  
this information and offer a "private" FG. After all, the boundaries  
of states and countries don't change all that often. In some  
countries, the incumbent ISP will presumably try to make life  
difficult for third-party VoIP customers until forced to by  
regulators, so I wouldn't count on having "open" access to PSAP URIs  
courtesy of the ISP, either, but we'll see.

To echo what Brian said, the likelihood that we'll have Zimbabwe,  
Taiwan and North Korea all happily in one FG run by the UN is  
probably a ways off, just after the black helicopters have landed.  
However, for most people, almost all the time, things will work, as  
long as we have some good will. (For example, avoid decade-long legal  
fights about data ownership.)

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 10:19:06 -0500

There's probably a reality check in order in this discussion as well.
I'd be interested in what opinions are out there.

How many valid "PSAP URIs" exist anywhere in the world today? I'll take
a wild stab and suggest... zero. That's certainly approximately correct.

When any significant jurisdiction does IP enable their emergency call
centers (and aren't they likely to be doing it before "insignificant"
jurisdictions do?) I suspect it'll make the industry news.

Just how fast is this likely to happen? Is it the case that it will
actually be reasonably straightforward to keep track of countries that
IP enable their emergency call centers as they emerge? And could this
not be the case to the extent that any suitably diligent party could
build a global database of PSAP URIs that was 95+ percent correct just
by monitoring the industry? Ideally, of course, each jurisdiction would
have an actual authority who would formally publish this information
(ideally publishing it into a forest guide infrastructure eventually,
though this wouldn't be necessary at the outset).

Do people think it's more or less likely that UA's will actually just
universally route to the PSAP themselves rather than go via the VSP
anyway before any need for this global infrastructure emerges? Is there
any reason, in the long term, for devices to route via the VSP if the
PSAP is directly reachable?

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 12:25 AM
To: Marc Linsner
Cc: ECRIT
Subject: Re: [Ecrit] Architecture comparisons

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 11:56:43 -0400

Actually, most of the world already has them, depending on how you define
most.  Most PSAPs are only reachable via e.164s, for which we have tel or
sip URIs readily mintable.

The forest guide IS the jurisdiction publishing its data.  That's the
purpose.  There is no point in publishing it a different way.

Please also remember that for most countries (excepting the U.S. and Canada)
the entire LoST database is a couple of records.  We'll probably have the
LoST data way before we have the PSAPs on an IP network.  It would actually
be quite useful to publish the geo boundaries.

There are very few VSPs which can be bypassed.  UAs don't ever route direct.
They send all outbound calls to their outbound proxy.  That's the VSP's
proxy.  Even the free services (FWD for example) are done that way.  We
could try to have emergency calls not do that of course, but I think that's
a very big change.  -phonebcp doesn't say that.  I don't think it should.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2007 11:19 AM
> To: Henning Schulzrinne; Marc Linsner
> Cc: ECRIT

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 11:06:11 -0500

Oh for pity's... that wasn't the spirit of my question.

OK, how many PSAP URIs exist which will permit the location object or
location reference to be delivered with the call?

And doing PSTN bridging doesn't work in the US... that's i1 and it's not
acceptable. It doesn't work in any other country where emergency calls
are not carried on the PSTN.

Why don't you think the BCP should recommend that a UA which knows it's
doing an emergency call just route directly? What actual value does the
VSP add, out of curiosity? Is this in order to enforce some sort of
subscriber identity audit trail? I don't think that would work for
foreign VSPs anyway; is it something that ECRIT has decided is a goal?

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 1:57 AM
To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Architecture comparisons

Actually, most of the world already has them, depending on how you
define
most.  Most PSAPs are only reachable via e.164s, for which we have tel
or
sip URIs readily mintable.

Please also remember that for most countries (excepting the U.S. and
Canada)
the entire LoST database is a couple of records.  We'll probably have
the
LoST data way before we have the PSAPs on an IP network.  It would
actually
be quite useful to publish the geo boundaries.

There are very few VSPs which can be bypassed.  UAs don't ever route
direct.
They send all outbound calls to their outbound proxy.  That's the VSP's
proxy.  Even the free services (FWD for example) are done that way.  We
could try to have emergency calls not do that of course, but I think
that's
a very big change.  -phonebcp doesn't say that.  I don't think it
should.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 12:25:48 -0400

But the point is that if the e.164 is in the database, the right thing
happens if the PSAP is only reachable by the PSTN.  They don't get addresses
from the endpoint (if they get them at all, it's an internal phone book).  A
VoIP endpoint conformant to phonebcp would be able to successfully complete
an emergency call to such a PSAP if the data is put in a LoST server it can
get to.  

Realistically, it would be very possible to make most VSP systems correctly
handle 3 digit emergency calls, albeit nomadic users wouldn't have correct
location.  The VSP would have to route a call to the right 3 digit gateway.
A U.S. "i2" solution, but if you nomaded to the U.K., we could get the right
thing to happen there (probably have to use their mobile location stuff).
I'm not seriously suggesting it, just noting that if you had the correct
boundary data, and internal route infrastructure, the whole mechanism can be
made to work pretty well without putting PSAPs on IP networks.

Outbound routing is usually pretty tough.  One example is NAT traversal for
media.  Unless the UA does STUN/TURN, it's usually an SBC in the VSP that
fixes the media.  Signaling outbound is sometimes a problem (outbound SIP on
port 5060 is often blocked).  It has nothing nefarious; just the likelihood
of working, where special procedures only used for emergency calls may not
work.  

Also, we're expecting the VSPs to often have VPN connections to the ESRP,
rather than taking the calls from the Internet.  Where there is QoS, we can
maintain it.  We also get some DDoS protection.  That won't work when you
nomad afar, but it does work for the normal case.

Brian

> Sent: Tuesday, June 19, 2007 12:06 PM
> To: Brian Rosen; Henning Schulzrinne; Marc Linsner
> Cc: ECRIT

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 12:25:48 -0400

Brian

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 19 Jun 2007 13:15:55 -0400

I agree with Brian that NAT traversal and the possibility of a VPN 
tunnel from VSP to ESRP are good reasons to suggest (in phonebcp) that a 
UAC routes emergency calls through its outbound proxy. (We don't want 
emergency calls to fail unnecessarily just because someone is blocking 
outbound SIP on port 5060.)

Additionally, providing a meaningful identity to the PSAP whenever 
possible is a good thing. I know that a subscriber identity with a VSP 
in Sierra Leone might not be meaningful to a PSAP in Kansas. However, 
iin most cases the VSP's subscriber information is a useful tool for 
PSAPs who wish to audit fraudulent calls.

- Matt L. :->

Brian Rosen wrote:

><snip>
>>>How many valid "PSAP URIs" exist anywhere in the world today? I'll
>>>      
>>>
>>take
>>    
>>
>>>a wild stab and suggest... zero. That's certainly approximately
>>>      
>>>
>>correct.
>>    
>>
>>>by monitoring the industry? Ideally, of course, each jurisdiction
>>>      
>>>
>>would
>>    
>>
>>>anyway before any need for this global infrastructure emerges? Is
>>>      
>>>
>>there
>>    
>>
>>>>the authoritative LoST server and why can't the VSP use the same
>>>>        
>>>>
>>such
>>    
>>
>>>>mechanism?
>>>>
>>>>Just curious,
>>>>        
>>>>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 12:28:43 -0500

I find a number of assumptions in your response surprising and/or
puzzling... I think a lot must be to do with me not appreciating the
inherited of developing wisdom about how VoIP will be provided.

The i2 architecture was defined to support the out of band delivery of
location information when calls have to be terminated on legacy switch
circuits. However, there's no such thing as a "PSAP URI" in the sense of
something that a UA would ever see in that architecture. Yes, you could
provide the i2 proxy function as a PSAP service - which would
effectively turn the PSAP into an IP one. However, that's the thing
isn't it? How many PSAPs have actually done that - and how long will it
take? Without that the UA never sees any such thing as a PSAP URI, which
is why it does rely on the VSP to do the routing and for the VSP to
ensure that location is properly delivered care of a VPC.

Your explanation of why you'd have to call via the VSP versus direct
sounds quite complicated. I use a SIP provider for my residential VoIP -
they are an Australian VSP but they have no relationship with my ISP. I
don't know how my ISP could possibly tell the difference between a call
initiated through my VSP or one to a SIP server operated by emergency
services... my ATA does STUN anyway.

The situation you describe sounds very much like a VSP which is closely
tied to the access provider with a proxy co-located with the access
(otherwise the call does go over the Internet before the VSP even sees
it right? And otherwise how can SIP be blocked for everyone else?). This
ends up being so close to the 3GPP model as makes no odds. I find these
puzzling assumptions on which to make value judgements about the best
way forward. It seems to assume a very conservative model about VoIP
services. And I really don't know what would qualify as "far" when it
comes to nomad'ing (when did that become a verb?). 

Surely taking my PDA/VoIP-client across town or across the state is
going to eliminate the cozy relationship my VSP may have had with my
nominal "home" location. In fact I just have to switch from my preferred
home DSL provider to my preferred WiMAX provider when I step out of the
door to change who my ISP is. If the answer is that the VSP has to have
a proxy in the WiMAX access as well, then I smile wryly to myself at the
irony - given VoIP was supposed to dismantle all the established power
structures associated with telephony services. I think I'll stick with
Skype... (isn't it VoIP too?)

I'm mostly asking all this for my own illumination, but perhaps others
will find the information useful as well.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 2:26 AM
To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Architecture comparisons

But the point is that if the e.164 is in the database, the right thing
happens if the PSAP is only reachable by the PSTN.  They don't get
addresses
from the endpoint (if they get them at all, it's an internal phone
book).  A
VoIP endpoint conformant to phonebcp would be able to successfully
complete
an emergency call to such a PSAP if the data is put in a LoST server it
can
get to.  

Realistically, it would be very possible to make most VSP systems
correctly
handle 3 digit emergency calls, albeit nomadic users wouldn't have
correct
location.  The VSP would have to route a call to the right 3 digit
gateway.
A U.S. "i2" solution, but if you nomaded to the U.K., we could get the
right
thing to happen there (probably have to use their mobile location
stuff).
I'm not seriously suggesting it, just noting that if you had the correct
boundary data, and internal route infrastructure, the whole mechanism
can be
made to work pretty well without putting PSAPs on IP networks.

Outbound routing is usually pretty tough.  One example is NAT traversal
for
media.  Unless the UA does STUN/TURN, it's usually an SBC in the VSP
that
fixes the media.  Signaling outbound is sometimes a problem (outbound
SIP on
port 5060 is often blocked).  It has nothing nefarious; just the
likelihood
of working, where special procedures only used for emergency calls may
not
work.  

Also, we're expecting the VSPs to often have VPN connections to the
ESRP,
rather than taking the calls from the Internet.  Where there is QoS, we
can
maintain it.  We also get some DDoS protection.  That won't work when
you
nomad afar, but it does work for the normal case.

Brian

> > > In my attempt to follow this thread, I've concluded that there is
a
> > > belief

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 13:57:06 -0400

I2 makes this silly assumption that ALL calls go to a U.S. PSAP.  Clearly
not true.  You could filter out 9-1-1 and route to a VPC (the i2 emergency
call processor).  You could also just use the whole ecrit mechanism and put
the URI of your VPC in the LoST service (really, a generic US VPC URI, which
you resolve to a specific one).  The point being you could have something
different that would make 999 in London work, and 116 in France, etc.

Clearly we WILL do this.  It will be part of the transition from i2 to i3.
If you have a phonebcp compliant client on a system that only supports i2,
we'll make it work.

My ATA is configured to use an outbound proxy.  Don't know about yours.  My
ATA doesn't do STUN.

The "normal" way we expect the Next Generation 9-1-1 system to work (to use
the U.S. and hopefully Canada as an example), is that the VSP will maintain
VPN connections to ESRPs operated by the 9-1-1 authorities, probably at the
state level.  A normal call from a high volume VSP when the caller is "home"
will go through that path.  If there is a nomadic caller, operating outside
the area the VSP normally serves a lot of customers, then the call will
route over the Internet.  The routing is simply by PSAP URI.  The route will
either take the tunnel or not based on the IP address with normal IP
routing.  If the tunnel fails, the Internet should work.

It has nothing to do with the ISP.  You can change the ISP and it still
works.  Of course QoS may depend on the ISP, but we're only being
opportunistic about that.  If QoS is available, we'd like it on the tunnel.

Brian

> Sent: Tuesday, June 19, 2007 1:29 PM

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Jun 2007 15:19:57 -0500

I'm not aware of anything in i2 that has a built in assumption about the
destination being a US PSAP. The VSP queries its selected VPC for a
route - the route could be to anywhere.

You may recall that I originally responded sympathetically to the
question of how the ECRIT VSP would know which LoST server to query
because the i2 VSP would have the same dilemma with respect to which VPC
to query. Location hiding causes the same problem for an i2 VSP in this
respect. I've been talking to the UK interconnect forum; I think that
the UK will adopt i2 as well.

In the end both ECRIT and i2 wrestle with exactly the same issues - i2
really just includes the specifics about how to deliver the location
information out of band (via E2 in the US case). In fact, apart from
this additional "location relay" function, and from a VSP perspective, a
VPC is semantically the equivalent of a LoST server.

I'm truly fascinated by the assumptions around VSP topology. Skype
doesn't bear any resemblance to these assumptions. I wonder what it is
that is making people assume that VSPs will end up being regional to any
significant extent - even if they start out that way. Does Vonage
configuration use proxies?

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 3:57 AM
To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Architecture comparisons

I2 makes this silly assumption that ALL calls go to a U.S. PSAP.
Clearly
not true.  You could filter out 9-1-1 and route to a VPC (the i2
emergency
call processor).  You could also just use the whole ecrit mechanism and
put
the URI of your VPC in the LoST service (really, a generic US VPC URI,
which
you resolve to a specific one).  The point being you could have
something
different that would make 999 in London work, and 116 in France, etc.

Clearly we WILL do this.  It will be part of the transition from i2 to
i3.
If you have a phonebcp compliant client on a system that only supports
i2,
we'll make it work.

My ATA is configured to use an outbound proxy.  Don't know about yours.
My
ATA doesn't do STUN.

The "normal" way we expect the Next Generation 9-1-1 system to work (to
use
the U.S. and hopefully Canada as an example), is that the VSP will
maintain
VPN connections to ESRPs operated by the 9-1-1 authorities, probably at
the
state level.  A normal call from a high volume VSP when the caller is
"home"
will go through that path.  If there is a nomadic caller, operating
outside
the area the VSP normally serves a lot of customers, then the call will
route over the Internet.  The routing is simply by PSAP URI.  The route
will
either take the tunnel or not based on the IP address with normal IP
routing.  If the tunnel fails, the Internet should work.

It has nothing to do with the ISP.  You can change the ISP and it still
works.  Of course QoS may depend on the ISP, but we're only being
opportunistic about that.  If QoS is available, we'd like it on the
tunnel.

Brian

> > > > Is it not true that the architecture we've adopted depends on
the
> > > > forest

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Jun 2007 16:26:55 -0400

> configuration use proxies?

Yes. They happen to be B2BUAs. (I'm not advocating any architecture  
here, just stating what I know.) Same is true for sipgate.de, the  
provider I use.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Jun 2007 17:23:20 -0400

> here, just stating what I know.) Same is true for sipgate.de, the  

True enough.  Most VSPs, both direct and indirect (using the  
SPEERMINT terminology) use B2BUAs.

Of course, that has nothing to do with the regions they serve.

-andy