RE: [Ecrit] Review of draft-ietf-ecrit-lost-03.txt - part 1

["Brian Rosen" <br at brianrosen.net>]

We could cover some normative behavior for emergency calls in -phonebcp

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> Sent: Thursday, February 01, 2007 6:22 AM
> To: shida at ntt-at.com
> Cc: ECRIT
> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-lost-03.txt - part 1
> 
> Shida,
> 
> thanks for your comments; please see some initial responses and
> questions inline. I'll skip items that I'll try to integrate directly.
> 
> On Feb 1, 2007, at 5:25 AM, Shida Schubert wrote:
> 
> >> For example, what is client to do if it receives any of the
> >      errors in section 12.1? If we don't provide some sort of
> >      recommendation, things are likely to get messy and simply not
> > work.
> >
> 
> I don't know what one can say in this case. In some cases, the client
> has to fix the address submitted, possibly with human input. In other
> cases, such as a system failures, a client will either have to retry
> later or use stale cached data. It seems fairly obvious in most cases
> what behavior is appropriate; we have been rightly admonished that
> the spec is somewhat wordy as is, so I'm reluctant to belabor the
> obvious. Can you identify places where an implementor would be in
> doubt what to do?
> 
> 
> >  2. Errors shouldn't be sent on its own.
> >> I strongly believe that for some of the errors either it
> >      should be recommended to attach a default URI for the service
> >      requested(notFound,loop) or send the error with the
> >      potential redirect targets(serviceNotImplemented,
> >      locationProfileUnrecognized,internalError,loop,notFound).
> 
> I don't understand what you're suggesting here. Unless you posit a
> general worldwide emergency call service, where you can send calls if
> all else fails, I don't see how this can work. If a LoST system
> doesn't understand an address at all, for example, it has no clue
> whether you are in England or Estonia. I think provider-specific fall-
> back call center information should probably be conveyed outside of
> LoST, as it is SIP-level configuration.
> 
> 
> >
> >  3. Do we really want to send an error at all?
> >> I vaguely remember the talk about sending a default PSAP URIs
> >      rather than sending an error and stalling an emergency call.
> 
> See above. I think the phone BCP should specify what happens if a
> device has no usable mapping at the time of an emergency call. As
> noted above, I think that will mean falling back to a VSP-provided
> call center URL.
> 
> 
> >
> >    * 2 and 3 may not be a problem if the client(UA) is not trying
> >      to contact the LoST server directly. In which case resolver is
> >      likely to have some useful cache. I am worried about a case where
> >      UA boots up and has no cache, sends a query to LoST server and
> >      fails. Where does it go then?
> 
> Again, see above.
> 
> To be continued.
> 
> Henning
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit