Re: [Geopriv] Comments on draft-winterbottom-ecrit-direct

["Dawson, Martin" <Martin.Dawson at andrew.com>]

-----Original Message-----
From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On Behalf Of Cullen Jennings
Sent: Friday, 6 November 2009 11:43 AM
To: GEOPRIV
Subject: [Geopriv] Comments on draft-winterbottom-ecrit-direct


Is this an alternative to doing phone-bcp or does it require the UA
also do phone-bcp?
[[MCD]] It's compatible with phone-bcp as far as I can tell; so that wouldn't make it an alternative.

It seems like the point of the REGISTER is to get a GRU, why does the
register need to deal with any location information?
[[MCD]] Fair point - as far as I can tell. It's good for PSAPs to know where emergency calls are coming from; their own/jurisdiction's policy can govern whether the location is recorded. Devices can't presume what's appropriate/required in the jurisdiction. I take the point that the location comes with the call in any case, so it's being duplicated in the registration. Belts and braces?

  Why not just do location by value in the INVITE?
[[MCD]] ditto

Why would the Emergency service run the registrar? If you believe this
is going to be legislated into existence, it seems far more likely the
network operator would be forced to do it. If you don't believe it
will be legislated into existence, I don't see why anyone would do it.
[[MCD]] Please define "network operator". I can't interpret your point without further definition of this term.

The user interface contemplated in section 5 sounds absolutely
horrendous. I can imagine the blind user having a heart attack
listening to the IVR from hell. Press 1 if your emergency involves
animal control, press 2 if you are having a fire, press 3 if you need
mountain rescue, press 4 if you are contemplating suicide by this
point in the IVR and so on.
[[MCD]] I guess that's just a piece of btw commentary? A full haptic feedback screen with brail generated from LoST data would certainly be nicer. Nevertheless; it's not the goal of the draft to specify the ultimate UI; it's just an example. You meant section 4?

It's unclear to me if you expect this register to happen for devices
that have a GRUU (perhaps though normal home registration). The idea
that we have a huge code path that is only ever used when you make an
emergency call seems like a plan we have done our best to avoid in the
past.
[[MCD]] I think it's useful for devices to provide whatever "call back" alternatives that they think are reliable - as well as getting a dynamic registration with the PSAP. With respect to "huge" code paths - hyperbole aside - there is specific code for the emergency calling use case. Moving the problem around doesn't change that. It's an illusion to think it's a "normal call" for a VoIP provider. I think this draft actually does facilitate a reduction in code development. One reference client implementation, available in open source, tested to death and embedded in every Internet connected operating system. Shaken out time and again against the reference ESRP implementation - and not hashed and hacked over on every proprietary and semi-proprietary VoIP service client and proxy back end.

Lets talk about outbound some time - I think the text here might be a
bit confused.

Strongly disagree with the idea that the INVITE has to have SDP. This
makes it impossible to have call coming in from some voip systems
including ones that might be a gateway from say H.323.
[[MCD]] Isn't it just saying the same as phone-bcp... for the same reasons? I didn't realize it was contentious.

I don't see why caller preferences are a SHOULD? At a minimum you need
to say what caller preferences are a SHOULD.


Cullen <in my individual contributor role>





_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv