Subject: AW: Re: AW: [ECRIT]: Caller Identityrequirements: replacementtext foremptysection in ECRIT req doc.

From: [email-masked]
Date: Thu, 27 Oct 2005 11:18:35 +0100

hi henning, 

thanks for the summary. i think your list shows quite well that we are covering most aspects since we can benefit from work in other ietf working groups (e.g., geopriv). 

regarding the architectural issues. sure, it is true that it is difficult to agree on architectures. however, i think that we do not need to agree on an architecture but we need to understand what implications the different architectures have for our work. even if you favor a different architecture then you still might want to use certain building blocks that are currently being developed.  

regarding issue (0) it is true that we still have some open issues. 

ciao
hannes
-- Ursprüngl. Mitteil. --
Betreff:	Re: AW: [ECRIT]: Caller Identityrequirements:	replacementtext foremptysection in ECRIT req doc.
Von:	Henning Schulzrinne <[email-masked]>
Datum:		26.10.2005 22:10

One of the problems could be that we have different pictures in mind 
when the word "architecture" is mentioned, e.g., whether this is for the 
whole emergency call lifecycle or just the lookup part.

At one level, I hope it's pretty simple:

(0) The end system learns local emergency numbers [not currently 
discussed, but there are proposals that trivially extend the existing 
lookup/mapping work] and learns its own location [geopriv work, plus 
others such as LLDP or GPS]

(1) User on end system places emergency call; UA recognizes digits based 
on step (0) and emergency call is identified by something [in scope, in 
progress, with drafts]

(2) Either the end system or some signaling proxy asks for a translation 
of location to a PSAP URL. This request may have happened earlier for 
non-mobile systems. The same system does validation in some way. [core 
part of ECRIT; 3 proposals]

(3) The call is routed to the URL returned, with the location 
information attached in PIDF-LO [geopriv profile work]. The request 
contains callback information (Contact/From), an identifier labeling 
this as an emergency call [as in (1)]. If necessary, repeat (2) if the 
original destination was some intermediary, such as a state-wide PSAP 
routing box. [standard SIP routing; nothing special and no need for 
additional work]

(4) The end system may implement some special handling for services, 
such as BYE or REFER [sipdev-req?].

Is there anything missing? Would it help to have a two-page version of 
this written up?

Henning

Tschofenig, Hannes wrote:
> hi all, 
> 
> a complete solution providing emergency service requires a number of things to be in place and some of them are even outside the ietf. 
> 
> we develop important parts of the entire solution space.
> i think that there is no problem with this. 
> 
> ciao
> hannes
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: [email-masked] [mailto:[email-masked]] 
>>Im Auftrag von Andrew Newton
>>Gesendet: Mittwoch, 26. Oktober 2005 18:57
>>An: Tom-PT Taylor
>>Cc: [email-masked]
>>Betreff: Re: [ECRIT]: Caller Identity requirements: 
>>replacementtext foremptysection in ECRIT req doc.
>>
>>
>>Given this message: http://www1.ietf.org/mail-archive/web/ecrit/ 
>>current/msg01077.html
>>Perhaps the scope of ECRIT is even more restrictive in that we are  
>>not even suppose to contemplate the other pieces that make the total  
>>solution.
>>
>>I understand the IESG's reluctance to grant working group charters  
>>for work that seems open ended, prone to rat holes, and quite 
>>easy to  
>>drive into the weeds.  But I also think it equally unwise to be so  
>>restrictive as to generate incomplete and/or unworkable solutions.
>>
>>-andy
>>
>>On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote:
>>
>>
>>>I think you're under the mistaken impression that ECRIT is  
>>>producing a complete solution to emergency service calling.  That  
>>>simply isn't so. The complete solution has to be worked in bodies  
>>>that create architectures and not just protocols.
>>>
>>>Tim DUNN wrote:
>>>
>>>
>>>>The PSAP needs is a location and a call back.  Not providing both  
>>>>is a reduction in existing capabilities in place for circuit  
>>>>switched and mobile 911 calls.  Both need to be accounted for  
>>>>somewhere in this overall set of requirements/architecture.
>>>>
>>>
>>>
>>>_______________________________________________
>>>Ecrit mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/ecrit
>>>
>>
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ecrit
>>
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

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

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