Subject: [Ecrit] New ID to get emergency dialsting into UA

From: "James M. Polk" <[email-masked]>
Date: Thu, 09 Mar 2006 19:21:42 -0600

ECRIT

This isn't really near the charter at the moment, but this is the most 
appropriate WG to have it individually for now.

This ID calls for an extension into SIP to retrieve the appropriate 
"visited" emergency dialstring, ISO country code, and service identifier 
(for those countries with more than one emergency number) to a UA upon 
device registration and registration refresh. Here is the URL:

http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt

I have another new ID into DHCP on this topic because that technology is 
tied to the access infrastructure of where a UA is to be able to know which 
national emergency dialstrings are appropriate.  The above is the SIP 
version of the DHCP ID here:

http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring-option-00.txt 

I will be presenting the DHCP ID in that WG for now.

The idea behind the ECRIT Dialstring ID is that this:

When a device boots, it will learn its location (a fundamental assumption 
we need to make for a lot of all this to work).  The UA generates a PIDF-LO 
and includes it in a SIP REGISTER Request message, seeking the appropriate 
dialstring for the UA's location.  This will either be ignored or 
successfully returned in a 200 OK to the REGISTER request.  The UA can have 
its digitmap modified based on this response, because it is just as likely 
a local user will dial for an emergency and not understand the UA is from 
another country, so the local (or "visited" from the UA's pov) numbers will 
have to function as expected.

In both IDs I allow for just a country code to be downloaded to the UA.

Comments to the ECRIT ID are welcome on this list.

Please direct any DHCP-related comments to the DHC list, thus showing 
interest there.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 9 Mar 2006 21:52:03 -0500

James,

thanks for all the draft contributions.

I will pick on this one, however. My general concern is that there is  
a danger of having too many ways to do roughly the same thing. SIP  
and surrounding protocols already suffer from the problem and  
perception of having specs that approach the Manhattan phone book in  
size (and in the likelihood that somebody will read them cover-to- 
cover).

The danger of having multiple ways to do the same thing is that  
implementors will implement a set with an empty intersection when  
clients and server meet. Plus, every new protocol and mechanism means  
more interoperability testing, more possible buffer overflows,  
dealing with contradictory information, non-uniform capabilities ("I  
can express X in mechanism A, but not in B") and more code foot print.

We already have a SIP configuration mechanism, being discussed in  
SIPPING. Adding another special-purpose mechanism just for dial  
strings (or PSAPS URIs) seems sub-optimal. I think there was some  
general agreement that we'd like to avoid emergency-specific mechanisms.

I believe we should take a minimalist approach - one mechanism per  
problem, universally implemented, and as generic as possible, with a  
strong preference to mechanisms that are useful beyond emergency  
calling (since that will speed their implementation and testing).

I find the two proposals particularly unsatisfactory since they  
require knowledge of dial strings far beyond the natural expertise of  
the owner of the DHCP server or proxy. Your local Asterisk PBX owner  
that had it installed by Joe's Computer & Hair Salon isn't going to  
remember to change the dial string for Serbia when that location  
adopts 112.

For dial strings, I believe the simplest mechanism already exists:

- End system determines location, at least at the country level,  
e.g., through DHCP. (Works for geo or civic).

- Invoke the mapping protocol, using the information maintained by  
people responsible for the information. In many cases, the end system  
has to do that anyway.

Henning

On Mar 9, 2006, at 8:21 PM, James M. Polk wrote:

> ECRIT
>
> This isn't really near the charter at the moment, but this is the  
> most appropriate WG to have it individually for now.
>
> "visited" emergency dialstring, ISO country code, and service  
> identifier (for those countries with more than one emergency  
> number) to a UA upon device registration and registration refresh.  
> Here is the URL:
>
> I have another new ID into DHCP on this topic because that  
> technology is tied to the access infrastructure of where a UA is to  
> be able to know which national emergency dialstrings are  
> appropriate.  The above is the SIP version of the DHCP ID here:
>
> When a device boots, it will learn its location (a fundamental  
> assumption we need to make for a lot of all this to work).  The UA  
> generates a PIDF-LO and includes it in a SIP REGISTER Request  
> message, seeking the appropriate dialstring for the UA's location.   
> This will either be ignored or successfully returned in a 200 OK to  
> the REGISTER request.  The UA can have its digitmap modified based  
> on this response, because it is just as likely a local user will  
> dial for an emergency and not understand the UA is from another  
> country, so the local (or "visited" from the UA's pov) numbers will  
> Please direct any DHCP-related comments to the DHC list, thus  
> showing interest there.
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 09 Mar 2006 23:21:05 -0600

Henning

Comments in-line  (with a **H-I-G-H**L-E-V-E-L** of sarcasm in all below   ;-)

At 09:52 PM 3/9/2006 -0500, Henning Schulzrinne wrote:
>I will pick on this one, however.

you picked on more than one, btw...   ;-)

>  My general concern is that there is
>a danger of having too many ways to do roughly the same thing.

fair comment - so maybe there is more than one way to do something.  But 
two is more than one, and yet not as complex as 5 or 10.  I wrote all these 
to have a discussion, not to be attacked as if I believe every one of them 
MUST BE IMPLEMENTED.... I'm not that outta touch.  Maybe one resonates with 
a certain type of infrastructure organization, i.e. Cable or DSL or 
Enterprise or SMB or...

>SIP
>size (and in the likelihood that somebody will read them cover-to- cover).

that's cuz it's so extensible.... didn't you design that into SIP?  ;-)

>can express X in mechanism A, but not in B") and more code foot print.

OK, fine, so are you suggesting we don't talk about any other way of doing 
something than the one, obvious choice?  Learning a locally significant 
dialstring doesn't have such a protocol right now, so there isn't "one" 
choice to make.

That said, and you're done this many times yourself, I wrote these IDs to 
cause discussion.  Do I think all of them are going to become PSs?  I 
really don't think so; but I have been wrong about a lot of things and I'm 
not sure really which of these ideas are going to resonate and which ones 
aren't.  Is anyone really sure until discussion occurs?

These IDs could serve the purpose of focus for that discussion.

>general agreement that we'd like to avoid emergency-specific mechanisms.

Well, how do you suggest this very real problem get fixed?  It's real and 
some areas are calling for a solution.

>problem,

Voice signaling has more than one protocol, so why haven't all others 
stopped begin developed beause SIP is the *obvious* choice going forward? I 
really don't believe any of the others have stopped being developed, have 
they?  Even MGCP is getting extended.  I know H.248 is; as is H.323....

>universally implemented,

Everything involving ECRIT is not a proven technology because it has not 
been coded yet, not been deployed yet, not been used yet, not been stress 
tested yet, why are we so willing to reduce our possible solutions to one 
offering?

This is interesting, but nothing, and I mean ZERO of what I've proposed is 
an alternate to LoST.  Nothing I wrote replaces or does anything more than 
*invoke* LoST, does it?

learning a locally significant dialstring and LoST retrieving a PSAP-URI 
are two different problems.  Now, should SIP be used to download that 
dialstring, eh... I'm even skeptical.  But that doesn't mean some might not 
say "boom, there it is, the perfect answer to our problems"....

Or are we better killing all ideas that might offer another way of doing 
mapping before they are really ever thought of?

That might sound a little too much like narrowmindedness   ;-)   and 
preventing innovative thought processes, and I'm too stubborn to sit in the 
corner because someone doesn't want me to ask questions and propose 
alternate theories this early in the game.

>and as generic as possible, with a

DHCP is useful beyond emergency services, and might have predated emergency 
services  ;-)

  The ID proposes an extention to an existing protocol, and I don't agree 
that is a reason to kill the idea.

>the owner of the DHCP server or proxy.

Well.... I don't think the owner of a DHCP server has the natural expertise 
of location either, particularly in either format (GPS or civic), but I 
wrote a document about that, which is an RFC now.  You did too, and it's 
going to become an RFC.

Where did Joe learn about GPS to the point he could implement a system that 
depends on it?  How does he know XML?

>Your local Asterisk PBX owner

These nationally specific dialstring changes don't happen overnight... they 
sometimes take a decade or more years. So I think that's fairly 
safe.  Plus, it will only take one emergency call to Joe to fix the 
dialstring in that Serbian location before it is corrected and stable for 
the next few decades, or till dialstrings are no longer relevant.

Any system that can't take one failed call is one that isn't worth 
designing in the first place...

>- Invoke the mapping protocol,

hmmm.... invokve the mapping protocol.... to a URL right? Any how did that 
UA learn this URI of a mapping server?  Is this address hardcoded?

hmmm.... what dialstring is whichever user to use to call for help that 
will be understood by that UA so that it includes location in the INVITE?

If my phone is in France and someone else uses it to call for emergency 
help, what number are they likely to use? How did my phone, from the land 
of 911=help, know that "other" number meant the same thing?

I am going to South Africa the week after IETF.  911 doesn't work down 
there.  What number does?  My GSM phone will work cuz it did last year.

I don't believe this area of your response is answering my questions or 
solving the problem at hand.  What do I dial and how did I learn that?

>using the information maintained by

lots of questions to your comments, and it's funny how vendors want to do 
things just a little differently than designers, which is a little 
differently than customers want, because not everyone is the same or wants 
things exactly the same way.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Mar 2006 09:26:43 -0500

>
> fair comment - so maybe there is more than one way to do  
> something.  But two is more than one, and yet not as complex as 5  
> or 10.  I wrote all these to have a discussion, not to be attacked  
> as if I believe every one of them MUST BE IMPLEMENTED.... I'm not  
> that outta touch.  Maybe one resonates with a certain type of  
> infrastructure organization, i.e. Cable or DSL or Enterprise or SMB  
> or...
>

Many, if not most, UAs will end up being deployed across different  
types of access networks. I have a Cisco 7960 phone at home...

>
> That said, and you're done this many times yourself, I wrote these  
> IDs to cause discussion.  Do I think all of them are going to  
> become PSs?  I really don't think so; but I have been wrong about a  
> lot of things and I'm not sure really which of these ideas are  
> going to resonate and which ones aren't.  Is anyone really sure  
> until discussion occurs?
>

Having a concrete proposal is always helpful. Consider this to be  
part of the discussion you were asking for...

> Well, how do you suggest this very real problem get fixed?  It's  
> real and some areas are calling for a solution.

See below.

> Where did Joe learn about GPS to the point he could implement a  
> system that depends on it?  How does he know XML?

He wouldn't. He'd fill out a web form with the street address. He  
probably managed to do that when filling out the form at eBay to  
place his last order for vintage toasters.

> These nationally specific dialstring changes don't happen  
> overnight... they sometimes take a decade or more years. So I think  
> that's fairly safe.  Plus, it will only take one emergency call to  
> Joe to fix the dialstring in that Serbian location before it is  
> corrected and stable for the next few decades, or till dialstrings  
> are no longer relevant.

If this were the only option, we might have to live with this. I  
don't think it is.

> hmmm.... invokve the mapping protocol.... to a URL right? Any how  
> did that UA learn this URI of a mapping server?  Is this address  
> hardcoded?

No. The LoST and URN drafts talk about discovery and propose  
mechanisms. They need to be fleshed out, but are fairly straightforward.

>
> hmmm.... what dialstring is whichever user to use to call for help  
> that will be understood by that UA so that it includes location in  
> the INVITE?
>
> If my phone is in France and someone else uses it to call for  
> emergency help, what number are they likely to use? How did my  
> phone, from the land of 911=help, know that "other" number meant  
> the same thing?

If it knows its location, it got it along with the PSAP URI.

>
> I am going to South Africa the week after IETF.  911 doesn't work  
> down there.  What number does?  My GSM phone will work cuz it did  
> last year.

As you may know, I've strenuously argued for the need to know both  
home and visited dial strings. There is no disagreement on that  
score, I think, just on mechanism.

>
> I don't believe this area of your response is answering my  
> questions or solving the problem at hand.  What do I dial and how  
> did I learn that?

Let me repeat what I wrote before in slightly more detail:

(1) Determine LoST server URL, using the mechanisms described in the  
LoST and service URN drafts. (This may involve either DHCP or using  
the SIP AOR's domain, followed by a NAPTR lookup.)

(2) Use LoST and provide rough location in either civic or geo (based  
on cell tower, DHCP civic or geo, etc.).

(3) Obtain <dialstring>, as shown in the example in the LoST draft.

A system that wants to do end-system resolution has to perform these  
steps in any event, so the additional effort is close to zero.

Henning