Subject: [Ecrit] Interim Meeting Notes

From: "Roger Marshall" <[email-masked]>
Date: Tue, 16 Feb 2010 10:08:38 -0800

All:
I'm forwarding my raw (non-summarized) notes from the ECRIT interim
meeting held on 2/11/2010.

Please send back any corrections as you see fit.

-roger marshall.

***

ECRIT Interim Meeting, 2/11/2010 8:00AM Eastern US Timezone

Attendees:
Andrea Forte
Bernard Aboba
Cullen Jennings
Dan Romascanu
Geoff Thompson
Janet Gunn
John Elwell
Keith Drage
Marc Linsner
Hannes Tschofenig
Roger Marshall

Hannes - meeting opening

Roger - status of drafts

in IESG review:
in AD review:
expired: rph-namespace
active: 

expired, rph-namespace, 
Cullen - we talked about it way back, but don't remember exactly at this
point

plus special AD-direct handling of sos-parameter draft
Milan - to have a revised draft by the end of the week

Keith - now we're talking about an option type which some don't think is
necessary.

Cullen - need to think through carefully the difference between "do what
I mean" vs. "do what I say".

Cullen - if 3GPP needs bits on the wire, 

Cullen - Be careful that you don't put an extra parameter there if you
don't fully explain it - because, in that case, it won't fly.

Milan - you don't need to know it if it's not supported, it will then be
backward compatible.

Keith - ordinary registration will replace emergency registration.

Milan - the doc is ready to move forward.

Keith - the option tag breaks SIP.

Cullen - I don't remember saying that we needed an option tag.

Cullen - suggest not to add an option tag.

end of sos-param discussion

next - callback

Hannes - sent email to the list yesterday, proposing some things.

Hannes - 3 types of approaches

1. response to a previous emergency call.

2. PSAP
a. Identity as a PSAP
b. in the role of a PSAP, regardless of my Identity

3. 

Hannes - feedback on this proposal?

(nothing)

Hannes - is there any interest from these on this call?

John Elwell - description is good.

Milan - may need to be a combination of more than one of these.

Hannes - John's proposal.

Milan - maybe leverage urn:service:sos

Cullen - discussion in the weeds here, if you are going to do this
requirement, bits in are ok, but now you need to verify authenticity of
the call.

Cullen - wishing away the hard part here.

Hannes - some ideas, 

a. you would need a registry of something, list of PSAPs is one possible
way.

b. if not on this list, then might be treated as a normal call.

Hannes - the other way might be role based assertion (might have much of
this already there, would just need to leverage it).

c. local relationships (white list).

Cullen - in review, the coherent thing heard so far.

a. white list.

b. white list w/cert.

c. walled garden.

Marc - want to make sure that the mechanism doesn't get too complicated.

Hannes - they don't know complexities

Marc - they don't care about costs (they are gov't people) 

(one hour is all we need)

Hannes - also what is missing is to provide what Marc just said

John - may be some other reasons to know that it is a PSAP calling.

Hannes - yes, we need to combine with something else.

e.g., if contacted with SIP would it be ok to return with xmpp?

John - yes, can't assume that the device supports other modes.

Cullen (as individual) I'd say that the device would be assumed to
support phonebcp requirements.

Keith - it'd be nice, but I don't think you can assume...

Marc - but that's the ground rules

Janet Gunn - you'll have to make some assumptions.

Keith - PSAPs can make other calls, don't constrain capabilities that
the PSAP has (extra)

(?) Dan - what if "do not disturb"

Hannes - never have heard of this requirement

Cullen - that's how we split before - different working group - under
authority-to-citizen.

Marc - phonebcp talks about disabling do not call, etc.

Hannes - there is a requirement in phonebcp.

Keith - 

Hannes - sos gets replaced by PSAP URI by the E-CSCF

(Storage) of requirement

Keith - don't know how this would work.

Hannes - could be even in the device.

Keith - you need to make this work in the CS domain as well.

Hannes - right, no token to pass back - wouldn't work.

Keith - we do have a token in i2.

Roger - called an ESQK

Marc - this is just a token for ALI info.

Hannes - 

Marc - So, if in SIP (not 3GPP) LoST gives me the country level to state
to PSAP.  Is there anything in SIP that shows where in the hierarchy?

Cullen - if the PSAP sends an updated Identity.  Otherwise, no.

Marc - then you could use that Identity, say not to block.  Simpler
without all this other stuff.

Cullen - has all (some) of that under the covers, including a Cert.

Marc - Do we all agree to a 1 hr max timer allowance?

Hannes - yeah, when to start the timer and how precisely do you want to
keep that state?

Phonebcp doesn't say that specific entity.

Marc - Ok, we could go back and say must be from the same device?

Keith - Be careful - make sure of a global solution, not just a NENA
one.

Marc - sure we can solicit, but NENA provides 90% of our input.

Hannes - others' thoughts?

Keith - other calls like prepaid calls might be blocked.

Keith - call could get blocked.

Marc - other cases like uninitialized calls - can't call back - no TN.

*Janet - Could be down a different path - many other elements - may not
have awareness that the original call was an emergency call.

Cullen - get the previous statement into the notes.

Marc - return path different, then the UA has to know about it and would
need to say, shut all of this stuff off for psap1234.

Hannes - can't do that, a UA in a local domain has its own set of
policies vs. the network domain policies.

--

--

SIP Identities carry across international borders?

(?) Dan - 

Keith - how to know between office phone and regular phone?

John - this is a case where forking is used.

Hannes - where are we?

Marc - need to decide requirements - whether to decide if applicable to
i2, IMS, etc., or just SIP ECRIT.

Keith - If PSAP calls override forking, then you've got the general SIP
case.

Marc - why we mark the call.

Keith - 

John - think there are solutions in that space.

John - what I've heard today is that you want to go back to original
device, but if you can't then, ______

Cullen - call back phone number or device?

Marc - in phonebcp, use the contact header

Cullen - then it's the device.

Keith - yes, the device.

Marc - more confusing or less?

Hannes - more confusing.

Hannes - not sure how to table this.

Summary assumption: messaging direction, forward vs. backward - might
take a different path, do we agree?

Marc - yes.

Hannes - If true, then it would be hard to store state at the entities.

Fixed phone or other device.

Hannes - So, callback can happpen during a definite amount of time.

Does it matter whether a callback is from any PSAP or the same PSAP.

Keith - 2 requirements then...

PSAPs can make ordinary calls or falls back to go on to ordinary
forking.

John - we've delivered two pieces of info contact the GRUU and the AoR
(From, or PAI).

Hannes - It works for me it needs to work for both.

John - would the requirement be met if it says it,

a. fails, then it can make a second call to ____

b. _____

Keith - getting into solutions

John - 

Geoff - Be careful to putting too much automation (to not spring this on
them)

Marc - We don't have to build too much into this (no god status)

Geoff - 

*Keith - 

Geoff - think we're trying to get too much into the callback.

Hannes - to talk a little about possible solution helps some of us think
about what requirement

forking, IMS, other things.

John - point is if callback is addressed back to the original device,
then wouldn't be subject to call forwarding.

Keith - yes, if IP PSAP, not for CS connected PSAP.

Hannes - how would you scope it?

John - wouldn't need to scope it.

Keith - Still have a requirement in enterprise.

Marc - don't think we need to include legacy PSAPs.

Janet - in ISUP there are some specific call parameters that may mark it
as an emergency call.

Keith - for any requirement, let's say whether or not it's applicable to
a legacy PSAP.

Marc - if list traffic generated, then we'll discuss it at IETF77.

/end of discussion around callback

next topic, service URN draft

John - list issues one per email to the list.

Andrea - policy around approving service URNs

Cullen - IESG thought idea of expert review approval may not have
adequate level of expertise present.

Cullen - just a ontology exercise, something that may already exist
elsewhere, or from some other group.

/end.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.