Subject: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 12 May 2008 19:40:53 +0300

Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents.

Would be interesting to hear your feedback.

-------- Original Message --------
Subject: 	3GPP2 TSG-X Corr to IETF re ECRIT/WGLC
Date: 	Mon, 12 May 2008 03:30:19 -0400
From: 	Andrew Dryden <[email-masked]>
To: 	Hannes Tschofenig <[email-masked]>
CC: 	TSG-X Chairman's reflector <[email-masked]>, Victoria 
Bosserman <[email-masked]>, <[email-masked]>

Dear Hannes:

Please see attached correspondence from 3GPP2 TSG-X to IETF.

Many thanks,

Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair)

Andy Dryden

3GPP2

2500 Wilson Blvd., Suite 300

Arlington, VA 22201

Phone: +1 703-907-7702

Fax: +1 703-907-7728

http://www.3gpp2.org

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 May 2008 12:25:38 -0500

wow...

I'm curious if all of these "requirements they don't support" are because:

- they leaning or dependent on legacy/circuit-switched infrastructures,
- which of the requirements they ever plan on adopting (in full or in 
part), or
- which of the requirements they do not see the desire to ever support?

In other words, giving the list of requires they simply want to list 
as non-compliant is a good start, but stating why ("not yet", "not 
ever", or "only if this one is changed" (hopefully also pointing "in 
this (X) way")) would obviously be what I would like to read next from them.

James

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 May 2008 12:45:02 -0500

At 12:30 PM 5/12/2008, Hannes Tschofenig wrote:
>I asked them how they want the feedback to their comments.
>
>I was easy to see that someone would come up with further questions...

Initially, I just want them to categorize where they see each 
requirement. Someone (of a group) obviously went through what's in 
both docs and said:  "no , no, no, not yet, not that way, not that 
way, not yet, wish we could - but we can't (for whatever reason), no, 
not yet, not ever, etc, etc..." to the list of reqs. I just want to 
know which category each req is in.

Having a blanket "not ever" (which is how that list comes across) 
isn't good enough, because it lacks the information they likely 
already have (i.e., the category) from their notes or emails)...

James

>Ciao
>Hannes
>James M. Polk wrote:
>>- which of the requirements they ever plan on adopting (in full or 
>>in part), or
>>In other words, giving the list of requires they simply want to 
>>list as non-compliant is a good start, but stating why ("not yet", 
>>"not ever", or "only if this one is changed" (hopefully also 
>>pointing "in this (X) way")) would obviously be what I would like 
>>to read next from them.
>>
>>James
>>
>>>CC:     TSG-X Chairman's reflector <[email-masked]>, 
>>>Victoria Bosserman <[email-masked]>, <[email-masked]>
>>>
>>>
>>>
>>>Dear Hannes:
>>>
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 12 May 2008 20:48:23 +0300

I fully understand your reasoning.

I hope that they can some 3GPP2 members are interested to join for this 
discussion

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 12 May 2008 20:30:32 +0300

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 12 May 2008 14:50:04 -0400

I would say that we have to design for the Internet, and systems that work
in walled gardens may not need everything that a general Internet device
would.

Specifics:
ED-5 is devices must recognize local dial strings.  I believe 3GPP does
this.  I don't know what 3GPP2 does.  ED-5 is also SP-4.  It's possible we
could water down this to say where the SP knows for certain where the
location of the devices is at all times, then it can handle the recognition
of dial strings and not require the end device to do that.  I'd rather not
do that.

ED-7 local dial strings should be determined from LoST.  It's a should.
There is no exception condition, but I would say access network knowledge
and any other mechanism is what the exception would be.

ED-12 Endpoints, Intermediate Devices and Service
   Providers MUST be prepared to handle location represented in either
   civic or geo form.  
This is an interesting one.  If the device knows it's on a mobile network
and always gets geo, what does this mean?  Should we alter the text?  What
do they actually do if the device is a dual WiFi/mobile and roams to a WiFi
network that reports civic?

ED-15 Devices, intermediate Devices and/or access networks
   SHOULD support a manual method to "override" the location the access
   network determines.  

It's a "should".  This has always been a controversial requirement.  We've
discussed the tradeoffs.  You can argue for a known mobile device with a
network that knows it always using GPS wouldn't do this.  Same question on
WiFi roaming.

ED-16 Devices MAY support end-system measured location.  Its definitely a
MAY, but of course this is the usual 3GPP determination method (A-GPS)

ED-17 Devices that support endpoint measuring of location
   MUST have at least a coarse location capability (typically <1km
   accuracy when not location hiding) at all times for routing of calls.
   This mechanism MAY be a service provided by the access network.
They do this.  Why are they complaining?

ED-18 Endpoints SHOULD configure their own location
It's a SHOULD.  Do 3GPP2 systems assume no fixed devices?  In 3GPP, the
fixed devices are expected to do endpoint location configuration.  Maybe
they haven't gotten to that point yet

ED-24 This is "supply an API to get location for apps that need it"
I think they are dead wrong.  AIM on a 3GPP2 phone needs a location API.

ED-25 Endpoints SHOULD obtain location immediately after
   obtaining local network configuration information
It's a should.  I happen to think they should do this, but that's just me.  

ED-26 If the device is configured to use DHCP for
   bootstrapping, it MUST include both options for location acquisition
   (civic and geodetic), the option for LIS discovery, and the option
   for LoST discovery
Huh?  Since they don't support DHCP, this is a don't care

ED-37 For calls sent with location-by-reference, with a SIP or
   SIPS scheme, the server resolving the reference MUST support a
   SUBSCRIBE [RFC3265] to the presence event [RFC3856].
Huh?  So far, they aren't saying what they will support.  It will have to be
SIP or HELD in the U.S.

ED-47 Endpoints MUST support one or more mechanisms that allow them
   to determine their public IP address.
We may want to change this.  If the device does LoST or LIS discovery, it
needs its IP address.  If it doesn't do LIS or LoST discovery, it doesn't
need it.  On the other hand, they have the AOL problem.  They need a
solution for that, and it may be LIS and/or LoST discovery.

ED-48 Endpoints MUST support LIS discovery as described in
   [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as
   described in [I-D.ietf-ecrit-dhc-lost-discovery].
Same as above

ED-49 The device MUST have a configurable default LoST server
   parameter.
Same as above

ED-50 Endpoints who obtain their own location SHOULD perform LoST
   mapping to the PSAP URI.
It says "endpoints who obtain their own location".  Otherwise, same as above

ED-51 Mapping SHOULD be performed at boot time and whenever location ...
Same as above

ED-52 The endpoint MUST attempt to update its location at the time of
   an emergency call
Same as above

ED-53 The endpoint SHOULD attempt to update the LoST mapping at the
   time of an emergency call
Same as above

SP-4 Local dial strings MUST be recognized
Can't have it both ways folks.  Either the endpoint does it or the service
provider does it (see ED-5)

SP-6 Local emergency dial strings SHOULD be determined from LoST
It's a should for this reason.

SP-10 Endpoints, Intermediate Devices and Service Providers MUST be
   prepared to handle location represented in either civic or geo form.
See above on ED-12

SP-17 If a proxy is attempting to insert location but the UA conveyed
   a location to it, the proxy MUST use the UA's location for routing
   and MUST convey that location towards the PSAP.
I more or less understand them, but I disagree.  I think they say that they
insert location, and if an endpoint sends them location, they ignore it.  I
think they are wrong; if the endpoint says it's somewhere, you are best to
believe it.  The network can add what it thinks the location is to the call.

SP-18 All location objects received by a proxy MUST be delivered to
   the PSAP.
Again, I think this is incorrect.  If the device sends location, it should
be sent to the PSAP.

SP-32 SIP Proxy servers processing emergency calls:
   1.  If the proxy does interprets dial plans on behalf of user agents,
       the proxy MUST look for the local emergency dial string at the
       location of the end device and MAY look for the home dial string.
       If it finds it, the proxy MUST:
       *  Insert a Geolocation header as above.  Location-by-reference
          MUST be used because proxies must not insert bodies.
       *  Include the Geolocation "inserted-by=server" and "used-for-
          routing" parameters.
       *  Map the location to a PSAP URI using LoST.
       *  Add a Route header with the PSAP URI.
       *  Replace the Request-URI (which was the dial string) with the
          service URN appropriate for the emergency dial string.
       *  Route the call using normal SIP routing mechanisms.

   2.  If the proxy recognizes the service URN in the Request URI, and
       does not find a Route header with a PSAP URI, it MUST run LoST
       routing.  If a location was provided (which should be the case),
       the proxy uses that location to query LoST.  The proxy may have
       to dereference a location by reference to get a value.  If a
       location is not present, and the proxy can query a LIS which has
       the location of the UA it MUST do so.  If no location is present,
       and the proxy does not have access to a LIS which could provide
       location, the proxy MUST supply a default location (See
       Section 6.11).  The location (in the signaling, obtained from a
       LIS, or default) MUST be used in a query to LoST with the service
       URN received with the call.  The resulting URI MUST be placed in
       a Route header added to the call.
   3.  The "inserted-by=" parameter in any Geolocation: header received
       on the call MUST NOT be modified or deleted in transit.
   4.  The proxy SHOULD NOT modify any parameters in Geolocation headers
       received in the call.  It MAY add a Geolocation header.  Such an
       additional location SHOULD NOT be used for routing; the location
       provided by the UA should be used.
   5.  Either a P-Asserted-Identity [RFC3325] or an Identity header
       [RFC4474], or both, MUST be included to identify the sender.
I think this is pretty close to what they do, although they don't
(currently) do anything with LoST.  They would have to do this for NENA i3.

SP-34 Unitialized devices SHOULD have a persistent URI in a
   P-Asserted-Identity: header if there is some way to assign such an
   identifier to the device
This shouldn't be a problem.  It's SHOULD, and it says "if possible".  The
ability to call back an unitialized device is important.  

<I stopped at the end of the SP requirements, I'll respond to AN and the
rest later>

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Monday, May 12, 2008 12:41 PM
To: 'ECRIT'
Subject: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

-------- Original Message --------
Subject: 	3GPP2 TSG-X Corr to IETF re ECRIT/WGLC
Date: 	Mon, 12 May 2008 03:30:19 -0400
From: 	Andrew Dryden <[email-masked]>
To: 	Hannes Tschofenig <[email-masked]>
CC: 	TSG-X Chairman's reflector <[email-masked]>, Victoria 

Dear Hannes:

Many thanks,

Andy Dryden

3GPP2

Arlington, VA 22201

Phone: +1 703-907-7702

Fax: +1 703-907-7728

http://www.3gpp2.org

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 May 2008 14:15:06 -0500

While I appreciate what my co-author has offered (as far as details 
are concerned), I want to hear what 3GPP2 thinks, and at least the 
categorization (see previous email today about this) of why they will 
not support each of the 44 requirements they listed.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 12 May 2008 19:52:51 -0500

Hi Brian,

I think I disagree with some of your assessments below, and my rationale
is included inline.

Cheers
James

> Brian Rosen
> Sent: Tuesday, 13 May 2008 4:50 AM
> To: 'Hannes Tschofenig'; 'ECRIT'
> Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]
> 

[AJW] I think what is important is that the SP knows the what the user
is intending. I think that in a great many case, a user plugging into a
foreign network, but communicating back to a home SP will use home SP
dial strings. I want to make sure we allow this for several reasons. The
first is that it makes it MUCH easier for the SP to behave in a manner
that the caller expects without the SP having to become aware of the
location and associated call semantics associated with that environment.
Secondly, like it or not, people are creatures of habit, they want to
dial the same thing to get the same service no matter where they are.
Yes, part 2 can be addressed with UI and device mapping stuff, but then
you arrive at having to provide a solution for problem 1. Simply
allowing the SP to know the service based on the notion of "home dial
strings" avoids this whole can of worms.

> network that reports civic?

[AJW] With the introduction and deployment of femto cells I think that
civic for 3GPP devices, at least packet-based devices is a reasonable
thing. I think assuming geo here is a bit short-sighted.

> network that knows it always using GPS wouldn't do this.  Same
question on

[AJW] I am not a fan of this requirement, but its not a battle that I am
prepared to put the energy into trying to win. At least on in this
forum... ;)

> MAY, but of course this is the usual 3GPP determination method (A-GPS)
[AJW] This seems an odd requirement for 3GPP2 to not support. I think
that the priory solution deployed in these networks is MS-Assisted, but
is there no MS-based deployed at all anywhere?

> They do this.  Why are they complaining?

[AJW] I really hate the parenthetical as in many cellular cases,
particularly for omni-cell systems this is not practical, and if it is
for routing, it may not even be necessary. I think I have asked before
for this to be removed, and if I haven't I am definitely and strongly
asking now.

> they haven't gotten to that point yet

[AJW] I think for your comment on 3GPP fixed solutions a clear document
reference to this information very important for any response to 3GPP2.
It isn't a requirement in 3GPP that I am aware of, so I wouldn't mind
seeing it also.... ;)

> I think they are dead wrong.  AIM on a 3GPP2 phone needs a location
API.
[AJW] I think that this is going to be more of a handset and carrier
issue. Handset vendors and handset OS definers need to make APIs
available, certainly Android is doing this (though I don't like the
level it is pitched at). Carrier need to make it possible for the
necessary applications to get access this information in their networks,
until now putting third-party applications on some network operator
phones was essentially impossible. I am not sure that defining a
standard API in 3GPP(2) is the right thing to do.

> It's a should.  I happen to think they should do this, but that's just
me.

[AJW] This one I think just highlights the fundamental difference in
assumed architectures. The Internet model is putting near total control
at the end-point, 3GPP(2) still assumes that a single entity owns access
and service, owns it by proxy using roaming agreements. The Internet
model can work in the 2GPP(2) architecture, but the converse is not
true. I think ultimately that the Internet model will prevail as roaming
agreements and their associated complexities will drown under their own
weight, but until that happens I think we need to accepts that not all
network will make location available directly to the end-point when it
attaches to the network.

> Huh?  Since they don't support DHCP, this is a don't care

[AJW] Should just be not applicable then.

> Huh?  So far, they aren't saying what they will support.  It will have
to
> be

[AJW] At present I, and a number of other people, remain unconvinced
that the current event packages and presence filter options for SIP meet
the needs of subscribing for location in this way. We probably need to
decide if we an a generic change of a specific one. I tend to think a
specific one is better since I don't see an application outside of
location at this point, so the "generic" component doesn't really have a
point of reference. 

> solution for that, and it may be LIS and/or LoST discovery.

[AJW] LIS discovery does not always require you to know the external IP
address. Similarly I don't believe that LoST discovery does either.

>    described in [I-D.ietf-ecrit-dhc-lost-discovery].

[AJW] Reference update to LIS discovery si required.

> provider does it (see ED-5)

[AJW] See my note above.. I think you can definitely have it both ways.

> insert location, and if an endpoint sends them location, they ignore
it.
> I

[AJW] A proxy can't insert location it goes against the rule in 3261.
Either we change this to a location URI, or we change the text to say
B2BUA, the term proxy is incorrect without a normative change to SIP.

> Again, I think this is incorrect.  If the device sends location, it
should

[AJW] Delivered does not mean delivered in-band. I2, for example, would
meet this requirement, but the location will not be sent to the PSAP
in-band.

> (currently) do anything with LoST.  They would have to do this for
NENA
> i3.
[AJW] Uninitialized devices that have an IP address and general access
to the Internet. I really hate this term because it so ambiguous as to
what the device has rights to use.

> 2500 Wilson Blvd., Suite 300

------------------------------------------------------------------------------------------------
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: Tue, 13 May 2008 12:07:59 -0400

Snipped to deal with James' comments, with my responses in line

<BR>Let's not start this again.
Local dial strings are required.  Home dial strings are optional.  That's
the way it works now, that's the way the PSAPs want it.  You are speculating
that home strings are a good idea.  Whether I believe you or not doesn't
matter.  It doesn't work that way now although in GSM systems, 9-1-1 and
1-1-2 always work, so if those are your home strings you are in luck.  It is
unacceptable to require home dial strings in lieu of local dial strings.

Since local strings are required, this requirement is necessary.

[AJW] I really hate the parenthetical as in many cellular cases,
particularly for omni-cell systems this is not practical, and if it is
for routing, it may not even be necessary. I think I have asked before
for this to be removed, and if I haven't I am definitely and strongly
asking now.
<BR> Because we have to provide some guidance.  So, we did.  "Typically" is
guidance, and not a hard requirement.

[AJW] I think for your comment on 3GPP fixed solutions a clear document
reference to this information very important for any response to 3GPP2.
It isn't a requirement in 3GPP that I am aware of, so I wouldn't mind
seeing it also.... ;)
<BR>TISPAN, now brought to you by 3GPP.  I don't have the doc reference.
Hannes?

<BR>But isn't the text correct?  There has to be a way.

<BR> Does text need to change?  I don't think so.

[AJW] Should just be not applicable then.
<BR>Right, no text change.

to

<BR>I disagree, but since at present, all we have is 3856, that's what we
cite.

[AJW] LIS discovery does not always require you to know the external IP
address. Similarly I don't believe that LoST discovery does either.
<BR>Some change is needed.  The next requirement is LIS/LoST discovery.
Perhaps we just drop the requirement and assume it's in ED-48, or perhaps we
augment ED-48 to point out the potential need to get your own IP address.

<BR>Okay

it.

[AJW] A proxy can't insert location it goes against the rule in 3261.
Either we change this to a location URI, or we change the text to say
B2BUA, the term proxy is incorrect without a normative change to SIP.
<BR>I was assuming a proxy inserts a reference.  I can change this easily
enough.

[AJW] Delivered does not mean delivered in-band. I2, for example, would
meet this requirement, but the location will not be sent to the PSAP
in-band.
<BR>Are you arguing for a change in text?  I don't think we need to.
"Received by a proxy" is in-band.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 May 2008 17:04:44 -0500

Hi Brian,

Not quote certain people. "but just because that's way it works now is
not a good reason to make it work that way next time".

Some comments inline, only one Salvo over the bow though I think, and
maybe some small arms fire in the background.

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 14 May 2008 2:08 AM
> To: Winterbottom, James; 'Hannes Tschofenig'; 'ECRIT'
> Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]
> 
> > of dial strings and not require the end device to do that.  I'd
rather
> not
> 1-1-2 always work, so if those are your home strings you are in luck.
It
> is
[AJW] Seriously, our entire ECRIT, i2 and i3 architectures are
fundamentally different to the way in which GSM and UMTS networks
operate. In the latter two, call service functions, all of them, are
handled in the visited network, the ECRIT, i2 and i3 architectures
don't. In the NENA and ECRIT architectures only the local access and
location services are immediately used, call handling as it were, is
handled by a home VSP, call-server, proxy, call it what you will. That
home service then either routes, or determines the route to the PSAP. It
is totally unclear to me how the dial-string even enters into this as
long as the correct service URN is present, and that mapping doesn't
need to be managed by an end-point. Since the home VSP knows its home
dial string it can map that to the appropriate service URN when making a
LoST request, it just works. 

I don't think that the current network analogies hold up under scrutiny,
can you please provide reasonable rationale given that the routing
trombones through a home service?

> <BR> Because we have to provide some guidance.  So, we did.
"Typically"
> is

[AJW] I think no guidance is fine here since it will jurisdictional, and
the jurisdictions will layout what needs to be provided. This is a bit
like suggesting what civic fields need to populated, we haven't done
this because we couldn't in any meaningful way.

> <BR>TISPAN, now brought to you by 3GPP.  I don't have the doc
reference.
[AJW] I would like to see this. If you say it is in TISPAN that may be
enough for me to go on if nobody has it handy.

> <BR>But isn't the text correct?  There has to be a way.
[AJW] yup, there does.

> > It's a should.  I happen to think they should do this, but that's
just
> <BR> Does text need to change?  I don't think so.
[AJW] I think that I would change the text to say location information,
that way a location URI is okay.

> <BR>I disagree, but since at present, all we have is 3856, that's what
we
[AJW] I think the wording needs a little clean up then, because I
totally misread this. I think something like the reword below might
address my goofy-eyed problem:
"Where a sip or sips URI scheme is used for a location reference, the
server resolving the reference MUST support a SUBSCRIBE [RFC3265] to the
presence event [RFC3856]."

> > We may want to change this.  If the device does LoST or LIS
discovery,
> it
> Perhaps we just drop the requirement and assume it's in ED-48, or
perhaps
> we
> > I more or less understand them, but I disagree.  I think they say
that
> > they
> > believe it.  The network can add what it thinks the location is to
the
> > call.
[AJW] I am arguing that this requirement is already covered in any
3GPP(2) architecture that delivers a location to the PSAP today. No text
change required.

> > This shouldn't be a problem.  It's SHOULD, and it says "if
possible".
> The

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 13 May 2008 21:16:10 -0400

James,

> > 
> [AJW] Seriously, our entire ECRIT, i2 and i3 architectures 
> are fundamentally different to the way in which GSM and UMTS 
> networks operate. In the latter two, call service functions, 
> all of them, are handled in the visited network, the ECRIT, 
> i2 and i3 architectures don't. In the NENA and ECRIT 
> architectures only the local access and location services are 
> immediately used, call handling as it were, is handled by a 
> home VSP, call-server, proxy, call it what you will. That 
> home service then either routes, or determines the route to 
> the PSAP. It is totally unclear to me how the dial-string 
> even enters into this as long as the correct service URN is 
> present, and that mapping doesn't need to be managed by an 
> end-point. Since the home VSP knows its home dial string it 
> can map that to the appropriate service URN when making a 
> I don't think that the current network analogies hold up 
> under scrutiny, can you please provide reasonable rationale 
> given that the routing trombones through a home service?

Proxies/call agents are not a required element in the SIP model, hence, no
guarantee of 'trombones through a home service'.  Knowing local emergency
dial strings solve the UI issue (the sign on the passing bus that says 'in
case of emergency, dial 1234'), regardless of where the mapping is done.  

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 May 2008 21:01:24 -0500

Ummm perhaps I am misunderstanding what has been said then.
I was under the impression that somebody vehemently objected to the notion of a call going directly to a PSAP URI.
I will be watching very carefully to the answer to this one.

I will also point out that dial string are only of importance when:
1) The service local to the user to user is handling the actual service determination
2) A service URN isn't already known.

I think at best it is a should, is probably only a may.

Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Tue 5/13/2008 8:16 PM
To: Winterbottom, James; 'ECRIT'
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]
 
James,

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 08:58:08 -0400

I have no idea where the "objected to the notion of a call going directly to
a PSAP URI" comes from.  I want the call sent on the normal call path.  If
that is direct to the R-URI/Route header, then do that.  If you normally
send all outbound calls to an outbound proxy, do that.

The item under discussion is ED-5, devices must recognize local dial
strings.  In that situation, the normal way to invoke an emergency call is a
dial string (special buttons are discouraged).  You want home strings to be
recognized.   I claim that is a nice to have, not a requirement, where local
strings are a clear requirement (it's regulated in some countries).  In that
circumstance the service URN isn't already known.  I don't know what
"service local to the user" means.  The service that usually handles calls
is handling the call, one way or another.  That might be the visited network
in 3GPP wireless, or the home network for most other systems.  If there is
no service provider (Marc's self installed home proxy is handling the call),
then there is no local service other than that.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Winterbottom, James
Sent: Tuesday, May 13, 2008 10:01 PM
To: Marc Linsner; ECRIT
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Ummm perhaps I am misunderstanding what has been said then.
I was under the impression that somebody vehemently objected to the notion
of a call going directly to a PSAP URI.
I will be watching very carefully to the answer to this one.

I will also point out that dial string are only of importance when:
1) The service local to the user to user is handling the actual service
determination
2) A service URN isn't already known.

Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Tue 5/13/2008 8:16 PM
To: Winterbottom, James; 'ECRIT'
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]
 
James,

-Marc-

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 09:54:17 -0400

Well, ED-5/SP-4, which is where the comments came from, is "Local
dialstrings must be recognized".  In the corresponding section
of -framework it says:
   ....                                     Users are not expected to
   "dial" an emergency URN.  Rather, appropriate emergency dial strings
   are translated to corresponding service URNs, carried in the Request-
   URI of the INVITE request.  Such translation is best done by the
   endpoint, among other reasons, because emergency calls convey
   location in the signaling, but non emergency calls do not normally do
   that.  If the device recognizes the emergency call, it can include
   location.  Dial string recognition could be performed in a signaling
   intermediary (proxy server) if for some reason the endpoint does not
   recognize it.

To me, this is all clear.  Best to do it at the endpoint.  If you don't, you
could do it at a proxy.  The requirement is on both to get it done.

Brian

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2008 9:33 AM
To: Brian Rosen; Winterbottom, James; Marc Linsner; ECRIT
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

I think the clarification - for me anyway - is that this is about the
*device* recognizing that the user wants to invoke an emergency call.
That is, the device, on initialization and however frequently
periodically, learns the local emergency code(s) from the LoST server
and "programs" itself to recognize the number sequence(s) as an
emergency call invocation (even if the user previously understood that
code to mean something else).

I'm OK with that - I'd previously understood that there was some sort of
a requirement on the proxy/home-service/VSP to recognize the local dial
string(s) as an emergency call invocation. This had a problematic
catch-22 aspect that bothered me - and I didn't even see why it was
necessary. Dial strings should only be relevant to the VSP for an
i2-style invocation and then it's really only reasonable to expect the
VSP to recognize home emergency dial strings - plus whatever
quasi-universal (e.g. 112) strings that it might also choose to observe.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Wednesday, 14 May 2008 10:58 PM
To: Winterbottom, James; 'Marc Linsner'; 'ECRIT'
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

I have no idea where the "objected to the notion of a call going
directly to
a PSAP URI" comes from.  I want the call sent on the normal call path.
If
that is direct to the R-URI/Route header, then do that.  If you normally
send all outbound calls to an outbound proxy, do that.

The item under discussion is ED-5, devices must recognize local dial
strings.  In that situation, the normal way to invoke an emergency call
is a
dial string (special buttons are discouraged).  You want home strings to
be
recognized.   I claim that is a nice to have, not a requirement, where
local
strings are a clear requirement (it's regulated in some countries).  In
that
circumstance the service URN isn't already known.  I don't know what
"service local to the user" means.  The service that usually handles
calls
is handling the call, one way or another.  That might be the visited
network
in 3GPP wireless, or the home network for most other systems.  If there
is
no service provider (Marc's self installed home proxy is handling the
call),
then there is no local service other than that.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of
Winterbottom, James
Sent: Tuesday, May 13, 2008 10:01 PM
To: Marc Linsner; ECRIT
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Ummm perhaps I am misunderstanding what has been said then.
I was under the impression that somebody vehemently objected to the
notion
of a call going directly to a PSAP URI.
I will be watching very carefully to the answer to this one.

Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Tue 5/13/2008 8:16 PM
To: Winterbottom, James; 'ECRIT'
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]
 
James,

> given that the routing trombones through a home service?

Proxies/call agents are not a required element in the SIP model, hence,
no
guarantee of 'trombones through a home service'.  Knowing local
emergency
dial strings solve the UI issue (the sign on the passing bus that says
'in
case of emergency, dial 1234'), regardless of where the mapping is done.

-Marc-

------------------------------------------------------------------------
----
--------------------
------------------------------------------------------------------------
----
--------------------
[mf2]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 14 May 2008 10:03:23 -0400

Brian,

Just to state the obvious..... 

> 
> Well, ED-5/SP-4, which is where the comments came from, is 
> "Local dialstrings must be recognized".  In the corresponding 
> section of -framework it says:
> To me, this is all clear.  Best to do it at the endpoint.  If 
> you don't, you could do it at a proxy.  The requirement is on 
> both to get it done.
> 

If the UA is emergency call illiterate, which implies the UA *may* also be
location illiterate, then it's inconceivable how the proxy can be emergency
call literate such that it recognizes local dial strings.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 May 2008 08:32:42 -0500

Cheers,
Martin

-----Original Message-----

Brian

-----Original Message-----

Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Tue 5/13/2008 8:16 PM
To: Winterbottom, James; 'ECRIT'
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]
 
James,

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 10:11:50 -0400

Well, yes.  It's actually very hard for a proxy to recognize local dial
strings, because, in general, it doesn't know where the device is, so it
can't determine what the local dial strings are, whether the device is
location literate or not.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2008 10:03 AM
To: 'Brian Rosen'; 'ECRIT'
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Brian,

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 May 2008 10:55:00 -0400

I'm guessing you are assuming that the proxy is somehow configured  
with the devices home location. (We probably don't want the proxy to  
recognize dial strings local to its physical location, unless it knows  
that all of its customers reside in the same area. In some cases, that  
may be true, e.g., because the VSP only serves customers in one  
country.)

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 May 2008 18:12:58 +0300

Unless it is a proxy that has a relationship with the access networks, 
as envisioned by the 3GPP with their P-CSCF...

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 May 2008 11:32:24 -0700

>may be true, e.g., because the VSP only serves customers in one

I had been thinking that would be the case for many enterprise-as-VSP
cases, since they would know whether or not mobile devices could be
connected to the network or not (for example, enterprises with no
VPN connecitivity or which did not permit VPN devices to use the telephony
service).  Would that fit with your thinking?

				Ted

---

From: <[email-masked]>
Date: Wed, 14 May 2008 22:07:11 +0300

Yep. 

The enterprise case is a more restrictive case than the 3GPP IMS
scenario since in IMS one would talk to a proxy associated with the
access even when you are roaming. 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Ted Hardie
>Sent: 14 May, 2008 21:32
>To: Henning Schulzrinne; Brian Rosen
>Cc: 'ECRIT'
>>I'm guessing you are assuming that the proxy is somehow 
>configured with 
>>the devices home location. (We probably don't want the proxy to 
>I had been thinking that would be the case for many 
>enterprise-as-VSP cases, since they would know whether or not 
>mobile devices could be connected to the network or not (for 
>example, enterprises with no VPN connecitivity or which did 
>not permit VPN devices to use the telephony service).  Would 
>that fit with your thinking?
>
>				Ted
>
>
>
>
>>
>>> Well, yes.  It's actually very hard for a proxy to recognize local 
>>> dial strings, because, in general, it doesn't know where the device 
>>> is, so it can't determine what the local dial strings are, whether 
>>> the device is location literate or not.
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 16:40:12 -0500

*BUZZZ** Okay let me try again!

I think you are making a leap here which isn't required.
Let me try and describe the scenario and configuration first, and then you can try and tell me why I need local dial strings.

Andy is caller.
Andy uses a VSP called Veronica
Veronica is based in Vermont
Veronica recognizes the emergency dial string 911. For the point of the argument, let's say that that is all that Veronica recognizes.
Veronica has a pet LoST server Lucy
Veronica will send any mapping requests to Lucy
Lucy is responsible to find the correct mapping.

Andy travels Sierra-Leone
Andy Connects to the local access network
Andy gets a location
Andy's room gets broken into, and he calls Veronica!
Andy is in a panic, so he calls 911 (which is a good thing since that is all that Veronica understands)

I expect this just to work, and this is why.
Veronica has a simple trigger looking for 911
Veronica can then have a standard query set to send to Lucy
Location (from call) + fixed service URN (sos.. etc)
Lucy manages the mapping to destination URI
Andy's call gets directed to the local emergency centre

Here is where it breaks down

The local emergency centre doesn't understand a word of english

In this scenario I don't need local dial-string, at all ever.
I believe that for quite some time this will be a very common configuration.
Hence local dial strings are a may, not a must from an end-point needing to understand them point of view.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Henning Schulzrinne
Sent: Wed 5/14/2008 9:55 AM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

On May 14, 2008, at 10:11 AM, Brian Rosen wrote:

> dial

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 May 2008 15:13:51 -0700

At 2:40 PM -0700 5/14/08, Winterbottom, James wrote:
>*

English is the official language of Sierra Leone, so this seems unlikely.

On another note, would  you mind relating this interesting tale of Andy,
Veronic, and Lucy back to 3GPP2's liaison statement?  Just to help those
of us having trouble keeping up.

			thanks,
				Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 May 2008 17:23:34 -0500

Sure - but either the enterprise is small/constrained as Ted describes -
and the home dial strings correspond with the local dial strings anyway
- or it supports use cases where the users could be dialing from
arbitrary global jurisdictions in which case it's not really any
different to a VSP.

Either the device has explicitly indicated to the proxy that it's
requesting an emergency call (in which case, the proxy will want to go
straight to LoST for the destination URI - and not care about dial
strings) or there is nothing in the call signalling indicating that it's
an emergency call and the proxy will have to decide based on the dial
strings. In the latter case, unless LoST is going to be queried for
every call (even leaving aside the question of whether location might be
in every call), the proxy isn't in a position to recognize anything but
its preconfigured emergency codes. That's the catch-22 I referred to.

I don't think the intent is for proxies to query LoST on every call is
it?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, 15 May 2008 5:07 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Yep. 

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 May 2008 18:32:57 -0400

Yes, it would work for the enterprise case you mention. In other  
cases, a proxy would have to detect the presence of location  
information and then do dial string detection via LoST, under the  
assumption that emergency calls have location information and "normal"  
calls do not. Not a particularly pleasant thought.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 18:17:02 -0500

Hi Ted,

My point is that this doesn't work in a 3GPP case at all.
In the 3GPP case you need to have local dial strings. To change the
setting a little for 3GPP(2):

Veronica only handles calls made in Vermont.
Veronica has special relationships with VSPs in other places.
These relationships allow Veronica's customers to make calls using
different VSPs when the customer is near that VSP.
Similarly, Veronica may allow customers of a different VSP to make calls
through her equipment if they are making a call while visiting Vermont.
The classic roaming agreement.

Veronica has a roaming agreement with Sandy in Sierra Leone.
Andy's softphone doesn't register with Veronica, it registers instead
with Sandy.
Andy's call therefore goes to Sandy.
If 911 in Sierra Leone means directory assistance, then Andy is getting
to get a bit of shock when he is calling for emergency assistance.
Sandy was expecting 655 for emergency calls.

Factual calling codes aside for a minute, my points are these:

Dial strings are used to map to service URNs.
The dial string used needs to be consistent with where that mapping
happens.

If the mapping happens in Vermont, then the dial string needs to be a
Vermont recognized dial string.

If the mapping happens in Sierra Leone, then the dial string needs to be
a Sierra Leone recognized dial string.

This is the case regardless of where the call is ultimately terminated.

If the calling device is doing the mapping, then why does it care what
the local dial string is at all?

Ultimately, the only case where local dial strings matter is where the
service mapping is performed in the network local to the caller. 3GPP(2)
are the largest users of this type of deployment, local dial strings are
large irrelevant in the home network mapping and device mapping
scenarios.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Thursday, 15 May 2008 8:14 AM
> To: Winterbottom, James; Henning Schulzrinne; Brian Rosen
> Cc: ECRIT
> >Andy is in a panic, so he calls 911 (which is a good thing since that
is
> all that Veronica understands)
> >
> >Hence local dial strings are a may, not a must from an end-point
needing
> to understand them point of view.
> >
> >Cheers
> >James
> >
> >
> >
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 19:18:31 -0400

Police in Sierra Leone is 999.   If Andy calls 999, it MUST be an emergency
call.  The fact that 9-1-1 worked may be a good thing, but it's not required
to work.  9-9-9 is.

I have no problem if Veronica implements 9-1-1 as an emergency call for Andy
while he is traveling to Sierra Leone.  I require, somehow, between Andy and
Veronica, that 9-9-9 work.  I recommend that Andy's device do a LoST query
with the location it got, find out that 999 (and 019, for fire) is the dial
string, and recognize it as such.

Brian

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2008 5:40 PM
To: Henning Schulzrinne; Brian Rosen
Cc: ECRIT
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

I think you are making a leap here which isn't required.
Let me try and describe the scenario and configuration first, and then you
can try and tell me why I need local dial strings.

Andy is caller.
Andy uses a VSP called Veronica
Veronica is based in Vermont
Veronica recognizes the emergency dial string 911. For the point of the
argument, let's say that that is all that Veronica recognizes.
Veronica has a pet LoST server Lucy
Veronica will send any mapping requests to Lucy
Lucy is responsible to find the correct mapping.

Andy travels Sierra-Leone
Andy Connects to the local access network
Andy gets a location
Andy's room gets broken into, and he calls Veronica!
Andy is in a panic, so he calls 911 (which is a good thing since that is all
that Veronica understands)

In this scenario I don't need local dial-string, at all ever.
I believe that for quite some time this will be a very common configuration.
Hence local dial strings are a may, not a must from an end-point needing to
understand them point of view.

Cheers
James

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 19:19:57 -0400

The liaison statement claims that ED-5/SP-4 (which is "Local dial strings
MUST be recognized") is not a requirement.

Brian

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2008 6:14 PM
To: Winterbottom, James; Henning Schulzrinne; Brian Rosen
Cc: ECRIT
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

			thanks,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 18:22:28 -0500

Why?

The solution I have describe is:
1) more simple
2) Works every time
3) Only requires Andy to remember things that are close to home in a
stressful situation when try to remember something different is hard.

Personally I see the solution being described below as providing
complexity for complexities sake. Yes, it is a solution, and yes it
should be catered, but that only makes the requirement a MAY and not a
MUST.

Cheers
James

> Sent: Thursday, 15 May 2008 9:19 AM
> To: Winterbottom, James; 'Henning Schulzrinne'
> Cc: 'ECRIT'
> I have no problem if Veronica implements 9-1-1 as an emergency call
for
> Andy
> while he is traveling to Sierra Leone.  I require, somehow, between
Andy
> and
is
needing

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 18:25:02 -0500

I agree, and I think I said that it was totally absurd for 3GPP(2) to
say this.

I don't however agree that the ECRIT requirement is a MUST, unless by
local you mean local to the location of the VSP handling the call. I
think you mean local to the call originator and in this case I cannot
agree with the requirement as written.

Cheers
James

> Sent: Thursday, 15 May 2008 9:20 AM
> To: 'Ted Hardie'; Winterbottom, James; 'Henning Schulzrinne'
> Cc: 'ECRIT'
is
needing
--
> ---------------------
--
> ---------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 19:31:56 -0400

Because the PSAPs, and in some cases, regulation, requires it.

It's that simple.

It doesn't really matter if you think, or even if I think, it makes more
sense to require home dial strings work.  Local dial strings MUST work. 

We could have a discussion of whether home dial strings MUST work.  We could
decide that they should.  The PSAPs, and the regulators, wouldn't care.
However, we can't decide that local dial string support is optional.  It's
not, it's required. 

When you are in the U.S., 9-1-1 MUST work.
When you are in Sierra Leone, 9-9-9 MUST work.

Among other things, if Jasmine, a native Sierra Leonian, picks up Andy's
phone while he is in Sierra Leone and dials 9-9-9 for him, it has to work.

Brian

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2008 7:22 PM
To: Brian Rosen; Henning Schulzrinne
Cc: ECRIT
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Why?

Cheers
James

for
Andy
is
needing

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 18:36:32 -0500

I am sorry but this work for me because I may not use a dial string at
all, I may just use the service URN. This requirement is a may.

> Sent: Thursday, 15 May 2008 9:32 AM
> > with the location it got, find out that 999 (and 019, for fire) is
the
> > Let me try and describe the scenario and configuration first, and
then
> you
> > > can't determine what the local dial strings are, whether the
device

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 18:43:27 -0500

And to further add to this.
What you are saying below is that in some national variants, the local
emergency dial string is required by the PSAP. What do you expect to be
the behaviour if this is not provided, will you simply not accept the
call?

I believe that this requirement is a MAY, but I would settle for a
SHOULD. Under no circumstance is it a MUST as it is not enforceable or
required in the majority of cases.

Cheers
James

Of
> Winterbottom, James
> Sent: Thursday, 15 May 2008 9:37 AM
> > We could have a discussion of whether home dial strings MUST work.
We
> > could
> > > call.  The fact that 9-1-1 worked may be a good thing, but it's
not
> > > required
> > > Veronica, that 9-9-9 work.  I recommend that Andy's device do a
LoST
> > query
> > > Veronica recognizes the emergency dial string 911. For the point
of
> > > > strings, because, in general, it doesn't know where the device
is,
> > > > so it
> ----------------------
> ----------------------

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 May 2008 16:50:43 -0700

>large irrelevant in the home network mapping and device mapping

But this is an ED requirement, right?  It says:

"Local dial strings MUST be recognized" but the ED marker makes that
mean "by the edge device".  In a network where the service mapping is
performed in the network local to the caller, why does the edge device
have to know it is a local dial string for an emergency service?  Won't
the network note that, and go forward from there (in a 3gpp2 network,
doesn't it even determine the location for the terminal?)  ?  Sure, it is great if
the edge device does realize that, and I'm happy LoST will provide that data. 
But it seems like the 999 call will go through in Sierra Leone if the local
network does the mapping, whether the edge device recognizes it is a
local emergency dial string or not.

What am I missing?

			Ted

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 14 May 2008 19:54:17 -0400

James,

You are comfortable denying Andy emergency care because he performed per the
instructions on the back of his hotel room door that states: "In case of
emergency, dial 9-9-9." ??

-Marc-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Winterbottom, James
Sent: Wednesday, May 14, 2008 7:37 PM
To: Brian Rosen; Henning Schulzrinne
Cc: ECRIT
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

I am sorry but this work for me because I may not use a dial string at all,
I may just use the service URN. This requirement is a may.

> We could have a discussion of whether home dial strings MUST work.  We 
> could decide that they should.  The PSAPs, and the regulators, 
> wouldn't
care.
> > call.  The fact that 9-1-1 worked may be a good thing, but it's not 
> > required to work.  9-9-9 is.
> >
the
then
> > Veronica will send any mapping requests to Lucy Lucy is responsible 
> > to find the correct mapping.
> >
> > Andy Connects to the local access network Andy gets a location 
> > Veronica has a simple trigger looking for 911 Veronica can then have 
> > a standard query set to send to Lucy Location (from call) + fixed 
> > service URN (sos.. etc) Lucy manages the mapping to destination URI 
> > > dial strings, because, in general, it doesn't know where the 
> > > device is, so it can't determine what the local dial strings are, 
> > > whether the
device
> --
> > --
> > --------------------
> > 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.
> >
>
> --
> --------------------
> 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.
>

----------------------------------------------------------------------------
--------------------
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: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 18:58:46 -0500

I am uncomfortable with expecting Veronica to know all codes for every
service on Earth, which is what the extension to what is being
requested.

I expect Andy to use codes he knows and is familiar with when he is in a
real pickle and doesn't want to have to think.

I think that this is a may not a must, but I am offering a compromise of
should.

Cheers
James

> Sent: Thursday, 15 May 2008 9:54 AM
> To: Winterbottom, James
> Cc: 'ECRIT'
> You are comfortable denying Andy emergency care because he performed
per
Of
> all,
We
not
LoST
of
immediately
and

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 18:59:07 -0500

I think what you are saying is fine.
All I am saying is that that edge-devices don't always need to
understand local dial strings, and that the requirement says that they
have to.

Cheers
James

> Sent: Thursday, 15 May 2008 9:51 AM
> doesn't it even determine the location for the terminal?)  ?  Sure, it
is
> great if
> the edge device does realize that, and I'm happy LoST will provide
that
> data.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 20:02:23 -0400

There are no protocol police.

There is no way for the PSAP to know what invoked the call.

I think it has to be a MUST. 

Brian

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2008 7:43 PM
To: Winterbottom, James; Brian Rosen; Henning Schulzrinne
Cc: ECRIT
Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Cheers
James

Of
We
not
LoST
of
is,

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 19:05:21 -0500

If there is no way for the PSAP to know
There is no way to enforce it
It is not required in all cases

How can it be anything other than a SHOULD?

> Sent: Thursday, 15 May 2008 10:02 AM
> > > It doesn't really matter if you think, or even if I think, it
makes
> > more
> > > However, we can't decide that local dial string support is
optional.
> > It's
> > > phone while he is in Sierra Leone and dials 9-9-9 for him, it has
to
> > work.
> > > should be catered, but that only makes the requirement a MAY and
not
> a
> > > > Police in Sierra Leone is 999.   If Andy calls 999, it MUST be
an
> > > > I'm guessing you are assuming that the proxy is somehow
configured
> > > > with the devices home location. (We probably don't want the
proxy
> > > > that all of its customers reside in the same area. In some
cases,

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 May 2008 20:06:03 -0400

Andy's device knows where it is.  It uses LoST to find the local dial
string.  Veronica doesn't need to do anything if the device does the right
thing.

Location aware, emergency unaware devices are possible I suppose, but I
don't see any reason to bend the system to make that work.  If Andy's device
can find out where it is, it can query LoST to get the local dialstring and
recognize it.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Winterbottom, James
Sent: Wednesday, May 14, 2008 7:59 PM
To: Marc Linsner
Cc: ECRIT
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Cheers
James

per
Of
We
not
LoST
of
immediately
and

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 May 2008 19:15:46 -0500

>code to mean something else).

Martin -- playing catch on this thread.  What you say above is what 
was thought by at least some of us from the beginning.  The UAC needs 
to be the one that recognizes the visited string to know this is an 
emergency call (to include location and do all the other things in 
the phonebcp).

I do think that sometimes, we get caught up (i.e., talking past each 
other without realizing it) in what's meant by "local" vs. "visited" 
vs. "home" string/address.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 16 May 2008 11:14:46 +0100

> emergency, dial 9-9-9." ??

Since this thread is filling my mailbox, I'm going to stick in my
two-penn'orth.

(1) Where I live, 999 is the emergency dial string. If I take my device
abroad with me, it would be really really nice if 999 still worked.

(2) If I'm somewhere where 08 is the emergency dial string, then it would
be really really nice if a passerby can pick up my device while I'm lying
injured in the street, dial 08, and have it work.

My understanding is that (2) is a regulatory requirement in many places.
It naively seems obvious to me that (1) can be programmed into the device,
but no doubt there are issues that are causing this thread.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 16 May 2008 21:58:14 -0400

Yah, that's what I think.

You can provide the home dial string via provisioning (we usually think SIP
Configuration) by the home network.  You discover the local dial string via
LoST.

As long as the device does this, no problem.

We observe that it may be possible for a proxy to do it, but it's really
hard, because the proxy doesn't know the location of the device usually.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Clive D.W. Feather
Sent: Friday, May 16, 2008 6:15 AM
To: Marc Linsner
Cc: 'ECRIT'
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 16 May 2008 22:47:31 -0500

Yes, but nice is not a must, it is a should!

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Fri 5/16/2008 8:58 PM
To: 'Clive D.W. Feather'; 'Marc Linsner'
Cc: 'ECRIT'
Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC]

Brian