Subject: Re: [Ecrit] I3, I4, I8

From: "Stastny Richard" <[email-masked]>
Date: Fri, 27 May 2005 22:51:38 +0200

I basically like this approach, because it also contains the
possiblitly to deviate at any point to national specifics and
also to feed into national specific TDM solutions via ESRP 
acting as gateways, hiding the mapping and routing required
totally from IP based emergency calls.
 
Just a minor question (maybe I missed it, I was recently busy
with other things and trying to catch up):
 
What is the meaning of the somebody and foo userparts in the
sip URI.? Shouldn't this be sos or sos:fire?
 
best regards
Richard

________________________________

Von: [email-masked] im Auftrag von Henning Schulzrinne
Gesendet: Fr 27.05.2005 17:46
An: Ted Hardie
Cc: [email-masked]
Betreff: Re: [Ecrit] I3, I4, I8

At least in the SIP case, I don't see how this would be needed. To make
this concrete, a fictitious example:

- Caller uses ECRIT mapping protocol to translate "123 Main Street,
Anytown, Jefferson County, NY, USA" to sip:[email-masked],
the NY state emergency services ESRP.

- Routes calls to sip:[email-masked] (ESRP), using standard
SIP mechanisms.

- ESRP at sip:[email-masked] takes address and converts (via
mapping protocol, but a different "private" database) this to
sip:[email-masked]. Call gets routed there by standard SIP
mechanisms.

- ESRP at sip:[email-masked] repeats process and gets
sip:[email-masked], the PSAP.

Quite a few emergency services folks have asked for this type of
iterative resolution.

Thus, no resolution indicators are needed. It's obvious from the SIP
request URL. Adding one would simply add a failure case, namely
contradiction between apparent and claimed resolution.

> So this might be used in any protocol that appears in a contact URI
> that might be returned by the mapping server?  It might be worth
> capturing that.
>
> The example I'm thinking of is one in which the user experiencing the
> emergency constructs a special-purpose indicator that tells the
> next-upstream
> network element that it had not yet done the mapping and that it needed
> the mapping done for it.  So a SIP URI with a target like sos:fire, or an
> XMMP URI with a similar target.  But the ESRP you reach by each contact
> method is likely to be distinct.
>
> It seems like almost everything about the ESRPs will need to be passed
> back to the protocol-specfic groups, though.
>                 regards,
>                     Ted

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 May 2005 17:27:38 -0400

> sip URI.? Shouldn't this be sos or sos:fire?

Not necessarily. The 'sos' designation is only necessary until the call 
reaches the first ESRP. After that, the receiving ESRPs presumably can 
recognize the limited set of URLs as being an emergency service vs. the 
general PSAP administrator. Obviously, there's nothing wrong with using 
sip:[email-masked].

Implementations clearly have to be careful not to lose information, 
e.g., about the emergency service originally requested, for 
jurisdictions where fire and police, for example, use different 
identifiers. The media feature tag (sip.emergency-service) described in 
the 'sos' draft can ensure that.