IETF
ecrit
ecrit@jabber.ietf.org
Wednesday, 16 November 2011< ^ >
martin.thomson has set the subject to: ECRIT
Room Configuration

GMT+0
[00:35:42] jgunn joins the room
[00:43:30] Martin Thomson joins the room
[01:25:34] RjS joins the room
[01:40:04] richard.barnes joins the room
[01:48:25] Hadriel Kaplan joins the room
[01:49:08] Jonathan Lennox joins the room
[02:01:56] <Hadriel Kaplan> Hello, I'm your virtual microphone. You can call me "Mr. Microphone".
[02:02:15] <Hadriel Kaplan> If you want something spoken at the microphone, please prefix your statement with "mic:"
[02:03:19] suzukisn joins the room
[02:05:48] Randall Gellens joins the room
[02:09:31] <jgunn> Would you please tell us which slide they are on, as they change. Thanks
[02:10:09] <richard.barnes> slide: Closing Open Issues
[02:10:17] <richard.barnes> (hadriel is at the mic)
[02:10:35] tsuichi joins the room
[02:21:05] <richard.barnes> slide: Closing Open Issues, Cont.
[02:21:16] <richard.barnes> Integration of "additional data" ….
[02:28:08] paul.beaumont joins the room
[02:33:51] pm joins the room
[02:43:36] pm leaves the room
[02:51:39] <Martin Thomson> If you go to NASP, then the access provider need only know about the set of LIS, LoST, PSAP and so forth for their coverage area.
[02:53:15] <Martin Thomson> mic: The service provider knows about their service area. It knows the (bounded) set of servers that NASP needs. It's true that coverage areas change in unpredictable ways, but those are manageable. The knowledge is available.
[02:53:46] <Martin Thomson> *that was PSAP service areas instead of "coverage areas"
[02:56:18] <paul.beaumont> For background only, please can you advise what RFC is the best one to read to understand IETF architecture for handling of emergency calls for a VOIP service provider?
[02:56:49] <Martin Thomson> paul: take a look at tools.ietf.org/wg/ecrit and look for the architecture doc...
[02:57:11] <paul.beaumont> Thanks Martin. Will do that.
[02:57:13] <Martin Thomson> http://tools.ietf.org/html/draft-ietf-ecrit-framework
[02:57:50] <richard.barnes> paul.beaumont: http://tools.ietf.org/html/draft-ietf-ecrit-framework
[02:58:26] <paul.beaumont> Thanks guys for the URL.
[02:59:10] <Hadriel Kaplan> Martin: do you still want me to say that at the mic for you?
[02:59:30] <Martin Thomson> Hadriel: don't worry, we missed the window
[02:59:34] <Hadriel Kaplan> k
[02:59:35] <Hadriel Kaplan> sorry
[02:59:51] <Hadriel Kaplan> it's hard to be a virtual mic when i'm also a physical mic
[02:59:53] <Hadriel Kaplan> :(
[03:00:14] <Martin Thomson> Hannes knows all about it already, he and Bernard should work it out
[03:06:29] <Martin Thomson> mic: this doesn't have to be a public gruu, it could be a temp gruu as far as I was aware. why not temp gruu?
[03:07:13] <richard.barnes> martin: otoh, why not a public gruu?
[03:07:24] <Martin Thomson> anonymity?
[03:09:35] <Martin Thomson> I think that Christer answered my question, so cancel that mic request
[03:11:26] <richard.barnes> slide: "PROCEDURE: REGISTRATION"
[03:11:36] <Martin Thomson> might it not be desirable for the registrar to authenticate the GRUU?
[03:13:17] <paul.beaumont> What is this trying to achieve ... A callback from a PSAP to someone who has contacted the Emergency Operator and hung up?
[03:13:55] <richard.barnes> paul.beaumont: Yes, special marking for those calls, so that the provider can handle them specially
[03:15:40] <paul.beaumont> Thanks. Why is it not normally addressed to the TO: ... Or does the GRUU/eGRUU give prioritisation through service provider network.
[03:18:20] <Randall Gellens> Not just for early termination / hangups
[03:18:45] <Randall Gellens> PSAP (or a responder) might want to do a call back during the emergency or afterwards, to get more information
[03:24:41] <paul.beaumont> Thanks. Apologies, but I haven't read the doc. But where is the CallBack mechanism documented? I want to see how it compares versus the Manual Hold type approach that I raised with Brian and others at Quebec IETF #81 and on the email list. Which is what the UK Association of Chief Police Officers (ACPO) would like to see perpetuated.
[03:25:17] <Martin Thomson> This is http://tools.ietf.org/html/draft-holmberg-ecrit-emergency-callback-id-00.txt
[03:25:50] <Martin Thomson> there is some callback stuff in http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback regarding requirements and other stuff in http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp
[03:26:23] <Randall Gellens> You need the ability to have a callback that bypasses call restrictions etc regardless of what else you have, since the call can terminate normally but the PSAP or a responder may still need to do a call-back
[03:26:29] <richard.barnes> also this one:
[03:26:29] <richard.barnes> http://tools.ietf.org/html/draft-holmberg-ecrit-emergency-callback-id-00
[03:27:01] <paul.beaumont> Thanks guys. I'll take a look.
[03:27:25] Randall Gellens leaves the room
[03:27:32] Randall Gellens joins the room
[03:28:57] <Martin Thomson> this solution *is* the token solution, it's just that this new GRUU type was never what I imagined
[03:29:18] RjS leaves the room
[03:29:27] <paul.beaumont> What does the token do Martin?
[03:30:24] <Randall Gellens> I think this solution is different from the token solution, because the token approach required that every entity in the outgoing path make note of the token, and recognize it on call-back. So, if the call-back takes a different path, the servers won't recognize the token.
[03:31:12] <Randall Gellens> To put it another way, this approach is a modification of the token approach that addresses some of its problems
[03:31:47] Hadriel Kaplan leaves the room
[03:32:06] richard.barnes leaves the room
[03:32:47] suzukisn leaves the room
[03:32:47] Randall Gellens leaves the room
[03:33:11] <Martin Thomson> sorry, paul...
[03:33:26] <paul.beaumont> Has there been a draft the puts forward the option of SUSpend and RESume as an alternative a service provider may elect to use for their endpoints (eg ONTs) that provides manual hold, ie B part asserts control.
[03:33:33] <paul.beaumont> No worries.
[03:33:38] <Martin Thomson> the token is passed out with the original call, so that callbacks can be identified
[03:33:44] Jonathan Lennox leaves the room: Computer went to sleep
[03:33:47] <paul.beaumont> Aha.
[03:34:00] <paul.beaumont> Can see the need I'd
[03:34:06] <Martin Thomson> the idea here is that the token is also the contact (or in the contact as it were)
[03:34:22] <paul.beaumont> If the callback disassociated from the callback.
[03:35:17] tsuichi leaves the room
[03:35:21] <paul.beaumont> I follow Martin. Is the EGRUU the proposed token then?
[03:35:44] <Martin Thomson> that was where it started. I think that Christer went in a different direction with it
[03:36:17] <Martin Thomson> my original idea was that the UA use a different GRUU for emergency calls, that's all
[03:36:25] <Martin Thomson> it didn't need to be "special"
[03:36:48] <paul.beaumont> Got it. Many thanks for the explanation Martin.
[03:37:57] <Martin Thomson> of course that's only necessary if there might be different treatment desired for callbacks
[03:38:31] <paul.beaumont> Indeed. Such as being given priority under overload conditions?
[03:39:21] <paul.beaumont> Presumeably could override line setting of Incoming Calls Barred too?
[03:39:34] jgunn leaves the room
[03:56:20] richard.barnes joins the room
[03:57:21] richard.barnes leaves the room
[03:57:32] richard.barnes joins the room
[04:25:23] suzukisn joins the room
[04:28:47] tsuichi joins the room
[04:33:18] suzukisn leaves the room
[04:33:21] suzukisn joins the room
[04:35:55] tsuichi leaves the room
[04:43:18] suzukisn leaves the room
[04:51:05] richard.barnes leaves the room
[04:51:57] RjS joins the room
[04:57:45] Randall Gellens joins the room
[04:58:30] Randall Gellens leaves the room
[05:04:05] richard.barnes joins the room
[05:05:48] richard.barnes leaves the room
[05:07:53] richard.barnes joins the room
[05:18:23] RjS leaves the room
[05:56:19] paul.beaumont leaves the room
[06:04:00] richard.barnes leaves the room
[09:16:59] Martin Thomson leaves the room