Subject: [Ecrit] Issue 5: Recognition of every Universal Identifier

From: "Roger Marshall" <[email-masked]>
Date: Thu, 8 Dec 2005 16:00:18 -0800

>From Issue 5 of the issue tracker, (ref. www.ietf-ecrit.org issues)

Requirements A1a (Id1) and A1b (Id2) specify a universal identifier.
Both requirements 
specify "one or more" but there are no requirements regarding protocol
actions 
when more than one is used.  If there are to be more than one universal 
identifier, do all network elements have to recognize all of them?

I don't think Andy's question was ever answered...

If this were clarified within a new requirement, it might read as:

"Idx.  Universal identifier(s), MUST be universally recognizable by any
network element which supports the ECRIT protocol."

Here are the referred to requirements from the draft, for reference:

Id1.  Universal Identifier - Setup: One or more universal
emergency identifiers MUST be recognized by any device or network 
element for call setup purposes.

Motivation: There must be some way for any device or element to 
recognize an emergency call throughout the call setup.  This is 
regardless of the device location, the application (voice) service 
provider used (if any at all), or of any other factor.  Examples of
these 
might include: 911, 112, and sos.*.

Id2.  Universal Identifier Resolution: Where multiple 
emergency service types exist, it MUST be possible to treat each 
emergency identifier separately, based on the specific type of 
emergency help requested.

Motivation: Some jurisdictions may have multiple types of emergency 
services available at the same level, (e.g. fire, police, ambulance), in

which case it is important that any one could be selected directly.

Roger Marshall.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Dec 2005 19:55:42 -0500

> network element which supports the ECRIT protocol."

Since we want to build robust systems, and since calls will get routed 
to strange places on occasion, I have a hard time seeing why we would 
want to encourage diversity or, worse, have identifiers that are 
recognizable in some places or not in others. I don't see any advantage 
to this "flexibility".

There is a related requirement, namely that one should be able to 
recognize a request as an emergency call even if one cannot recognize 
the specific emergency service requested. The motivation is, again, 
robustness and the ability to deploy new services incrementally, while 
still maintaining a fallback capability.

Henning