Subject: [Ecrit] GRUUs for callbacks

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Dec 2011 14:47:27 +0000

Howdy,
So before people get too enamored with the idea of GRUUs, I would just like to point out that as far as I can tell GRUU support is quite rare.  I haven't checked in a year or so, but last time I checked: only a handful of SIP service providers in the World support GRUUs (and I mean literally countable by fingers on two hands).  This is only what my company sees and maybe it's only the providers we're in, and obviously this could have changed as well... but I doubt it. (and yes, this includes deployed 3GPP IMS networks, PacketCable networks, OTT providers, wireline and mobile providers, transit providers, and other flavors of Tier-1 through Tier-3 providers)

And there are actual technical problems with deploying GRUUs, which I tried to enumerate in:
http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Dec 2011 21:03:55 +0100

Hi,

> So before people get too enamored with the idea of GRUUs, I would just like to point out that as far as I can tell GRUU support is quite rare.  I haven't checked in
> a year or so, but last time I checked: only a handful of SIP service providers in the World support GRUUs (and I mean literally countable by fingers on two hands).  
> This is only what my company sees and maybe it's only the providers we're in, and obviously this could have changed as well... but I doubt it. (and yes, this includes 
> deployed 3GPP IMS networks, PacketCable networks, OTT providers, wireline and mobile providers, transit providers, and other flavors of Tier-1 through Tier-3 providers)

And, out of those who DO support GRUU, none of course support eGRUU :)

AFAIK, some countries do not require the callback to reach the same device as made the emergency call, so in such cases a non-GRUU Contact would of course work - assuming there is some other way to identity the callback, as special handling etc may still be required.

The advantage of using gruu for identification purpose is reduces the assumptions we make on the PSAP behavior, and if the gruu is unique (ie we don't include static values) it allows the home proxy to identity the callback. But, as I was told in Taipei, we actually have pretty good influence in defining PSAP behavior.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Dec 2011 21:03:58 +0000

Just to be clear - not supporting GRUUs doesn't mean the callback won't reach the same UA.  As far as I can tell, it is surprisingly uncommon for providers to support multiple registered UAs for the same AoR - some do, but they're a small minority afaict.  I don't know why that is in all cases (I know why in some cases), but the point is if the PSAP makes a callback to the AoR it will get to the same phone that made the previous PSAP call in most providers I know of today.

And frankly we kinda need that to be the case, because most PSAPs connect to providers over PSTN trunks, not native SIP - that PSTN trunk will be getting the callback from the PSAP, and the PSTN gateway will generate the SIP-based callback that ultimately reaches either a native SIP client, or an MTA or another gateway or whatever - so unless GRUU somehow works across the PSTN, we're not gonna be able to rely on it for the near future *anyway*.

An RPH header or something like one, on the other hand, could theoretically be generated by the PSTN gateway because it knows its trunk is connected to a PSAP; or we could use an ISUP-based indicator; or we could apply logic rules to add it - rules which don't depend on stored state about previous calls for hours/ever.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Dec 2011 22:28:34 +0100

Hi,

> Just to be clear - not supporting GRUUs doesn't mean the callback won't reach the same UA.  As far as I can tell, it is surprisingly uncommon for providers to support 
> multiple registered UAs for the same AoR - some do, but they're a small minority afaict.  I don't know why that is in all cases (I know why in some cases), but the point 
> is if the PSAP makes a callback to the AoR it will get to the same phone that made the previous PSAP call in most providers I know of today.

Correct.

I don't think reaching the terminal is the biggest issue (if there are cases which require gruu, we have the gruu mechanism). The bigger issue is to identity the callback.

> And frankly we kinda need that to be the case, because most PSAPs connect to providers over PSTN trunks, not native SIP - that PSTN trunk will be getting the 
> callback from the PSAP, and the PSTN gateway will generate the SIP-based callback that ultimately reaches either a native SIP client, or an MTA or another gateway 
> or whatever - so unless GRUU somehow works across the PSTN, we're not gonna be able to rely on it for the near future *anyway*.

Correct.

...unless you send the GRUU over ISUP UUI ;)

> An RPH header or something like one, on the other hand, could theoretically be generated by the PSTN gateway because it knows its trunk is connected to a PSAP; 
> or we could use an ISUP-based indicator; or we could apply logic rules to add it - rules which don't depend on stored state about previous calls for hours/ever.

Correct.

Regards,

Christer

---

From: Marc Linsner <[email-masked]>
Date: Thu, 01 Dec 2011 16:44:25 -0500

Hadriel,

ECRIT deals with NG Emergency Calling which includes PSAPs that are IP
enabled, we're not particularly worried about legacy PSAPs.

The original requirement deals with dropped calls to the PSAP and/or the
PSAP call-taker needs additional information to affect emergency response.
 In these scenarios it's imperative the PSAP reach the same device that
made the original call within seconds/minutes, this use case isn't worried
about reaching the original caller hours/days after the fact.  Multiple
devices per AoR may not be today, but it's envisioned it may be a future
norm.

The eGRUU idea came from the fact that roaming IMS callers use visited
networks for emergency calls, the home network hasn't a clue about the
original emergency call. In this case, the home network, which could be in
a different country, needs to know the current call they are handling is
in fact a callback from an earlier emergency call.  If the home network
minted the eGRUU, they would recognize the call as coming from a PSAP.

I wasn't at the Taipei meeting and it's unclear what was discussed that
sidetracked the eGRUU idea.

I believe we've come full circle from when we had this discussion years
ago, giving the PSAP an RPH header that allows them 'god' status in the
network was concluded to be a bad idea for several obvious reasons.

I don't see the current lack of support for GRUU as a roadblock, if 3GPP
accepts the eGRUU architecture, it would behove them to make sure it's
implemented in their devices/networks.

Hope this clears up a few issues.

Carry on,

-Marc-

-----Original Message-----
From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Dec 2011 21:03:58 +0000
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] GRUUs for callbacks

>
>Just to be clear - not supporting GRUUs doesn't mean the callback won't
>reach the same UA.  As far as I can tell, it is surprisingly uncommon for
>providers to support multiple registered UAs for the same AoR - some do,
>but they're a small minority afaict.  I don't know why that is in all
>cases (I know why in some cases), but the point is if the PSAP makes a
>callback to the AoR it will get to the same phone that made the previous
>PSAP call in most providers I know of today.
>
>And frankly we kinda need that to be the case, because most PSAPs connect
>to providers over PSTN trunks, not native SIP - that PSTN trunk will be
>getting the callback from the PSAP, and the PSTN gateway will generate
>the SIP-based callback that ultimately reaches either a native SIP
>client, or an MTA or another gateway or whatever - so unless GRUU somehow
>works across the PSTN, we're not gonna be able to rely on it for the near
>future *anyway*.
>
>An RPH header or something like one, on the other hand, could
>theoretically be generated by the PSTN gateway because it knows its trunk
>is connected to a PSAP; or we could use an ISUP-based indicator; or we
>could apply logic rules to add it - rules which don't depend on stored
>state about previous calls for hours/ever.
>
>-hadriel
>
>
>>> So before people get too enamored with the idea of GRUUs, I would just
>>>like to point out that as far as I can tell GRUU support is quite rare.
>>> I haven't checked in
>>> a year or so, but last time I checked: only a handful of SIP service
>>>providers in the World support GRUUs (and I mean literally countable by
>>>fingers on two hands).
>>> This is only what my company sees and maybe it's only the providers
>>>we're in, and obviously this could have changed as well... but I doubt
>>>it. (and yes, this includes
>>> deployed 3GPP IMS networks, PacketCable networks, OTT providers,
>>>wireline and mobile providers, transit providers, and other flavors of
>>>Tier-1 through Tier-3 providers)
>> 
>> AFAIK, some countries do not require the callback to reach the same
>>device as made the emergency call, so in such cases a non-GRUU Contact
>>would of course work - assuming there is some other way to identity the
>>callback, as special handling etc may still be required.
>> 
>> The advantage of using gruu for identification purpose is reduces the
>>assumptions we make on the PSAP behavior, and if the gruu is unique (ie
>>we don't include static values) it allows the home proxy to identity the
>>callback. But, as I was told in Taipei, we actually have pretty good
>>influence in defining PSAP behavior.
>> 
>> Regards,
>> 
>> Christer
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Dec 2011 06:11:24 +0800

> minted the eGRUU, they would recognize the call as coming from a PSAP.

I'm finding this a little confusing.
Are you are saying that the UA making the emergency call will get an 
egruu from the registrar/scscf in the visited network, but the resulting 
call will be processed by the scscf of the home network?

I don't see how that would happen. If the gruu came from the visited 
network, then the callback from the psap would have no reference to the 
home network.

	Thanks,
	Paul

> From: Hadriel Kaplan<[email-masked]>
> To: Christer Holmberg<[email-masked]>
> Cc: "[email-masked]"<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Dec 2011 22:20:38 +0000

> enabled, we're not particularly worried about legacy PSAPs.

I'm not either, since I don't make PSTN equipment - but it's widely known that while some PSAPs are moving their internal nets to SIP, their connections to the providers will remain PSTN trunks for the foreseeable future.  It's not what I want to happen, but that's not my decision to make.

> minted the eGRUU, they would recognize the call as coming from a PSAP.

No, they wouldn't.  All they'd know is that a eGRUU they provided to a UA is now in the request-URI of an INVITE from someone else.  They can't assume the eGRUU wasn't given by the UA or its human to other UAs to make free calls to them.  The only thing that prevents those types of things from happening, is implicit trust and logging for fraud prevention folks to check out later.  But that's the same thing that would happen with RPH headers - they'd have to have trust in their peers to only use the RPH value when the call comes from PSAPs, and logging for fraud prevention later.  And that's the same thing that happens with P-Asserted-IDs, billing headers, etc.  This trust model isn't new - it's used every day by virtually every service provider on Earth, in both the PSTN and SIP.

> implemented in their devices/networks.

Ironically, 3GPP networks are exactly the types of networks which shouldn't be using GRUUs to begin with.  Their contacts aren't actually globally routable, and their domains/registrars aren't actually globally reachable.

You guy need a way to indicate a callback is a callback, and you need a way to believe/trust it - I grok that.
You also need a way to reach the same UA instance in deployments where such are possible - I grok that.
Tying those two requirements into the same solution of GRUU is a bad idea.  There's a solution for the first problem which is pragmatically deployable across all providers today; while there're problems with the solution to the second problem that we need to work on for SIP in general.

-hadriel

---

From: Marc Linsner <[email-masked]>
Date: Thu, 01 Dec 2011 17:30:01 -0500

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Dec 2011 06:11:24 +0800
To: <[email-masked]>
Subject: Re: [Ecrit] GRUUs for callbacks

>call will be processed by the scscf of the home network?

No, it was intended the eGRUU would be minted by the home network and
passed to the UA upon registration.

-Marc-

---

From: Brian Rosen <[email-masked]>
Date: Thu, 1 Dec 2011 17:38:43 -0500

> You also need a way to reach the same UA instance in deployments where such are possible - I grok that.
"Where such deployments are possible" because of design choices, deployment choices or impairments (congestion, failure, …)?

The latter is okay.  The former two are not. 

Brian

---

From: Marc Linsner <[email-masked]>
Date: Thu, 01 Dec 2011 18:07:09 -0500

-----Original Message-----
From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Dec 2011 22:20:38 +0000
To: Marc Linsner <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "[email-masked]"
<[email-masked]>

>I'm not either, since I don't make PSTN equipment - but it's widely known
>that while some PSAPs are moving their internal nets to SIP, their
>connections to the providers will remain PSTN trunks for the foreseeable
>future.  It's not what I want to happen, but that's not my decision to
>make.

And PSAPs that opt for that scenario will understand their capability
limitations.

But that doesn't change this thread, the requirement is for PSAPs
connected to the Internet and accepting IP sessions natively.

>No, they wouldn't.  All they'd know is that a eGRUU they provided to a UA
>is now in the request-URI of an INVITE from someone else.  They can't
>assume the eGRUU wasn't given by the UA or its human to other UAs to make
>free calls to them.  The only thing that prevents those types of things
>from happening, is implicit trust and logging for fraud prevention folks
>to check out later.  But that's the same thing that would happen with RPH
>headers - they'd have to have trust in their peers to only use the RPH
>value when the call comes from PSAPs, and logging for fraud prevention
>later.  And that's the same thing that happens with P-Asserted-IDs,
>billing headers, etc.  This trust model isn't new - it's used every day
>by virtually every service provider on Earth, in both the PSTN and SIP.

I'm thinking they believe they will have more control over the UA software.

We don't have requests/claims that callbacks from PSAPs are free.  That is
not the case in the majority of the US.  Hence the eGRUU would simply
negate features under control of the user anyway, so the point would be?
Resource priority is NOT a requirement germane to this solution.

>Ironically, 3GPP networks are exactly the types of networks which
>shouldn't be using GRUUs to begin with.  Their contacts aren't actually
>globally routable, and their domains/registrars aren't actually globally
>reachable.
>
>Tying those two requirements into the same solution of GRUU is a bad
>idea.  There's a solution for the first problem which is pragmatically
>deployable across all providers today; while there're problems with the
>solution to the second problem that we need to work on for SIP in general.
>
>-hadriel

I'm neutral to the eGRUU proposal.  It is basically a last minute issue to
an in-progress draft that was brought to the group by those claiming a
problem with 3GPP and our PSAP callback draft.

-Marc-

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Dec 2011 14:58:29 +0000

> The latter is okay.  The former two are not. 

I meant in deployments where there could be more than one UA instance for the same AoR.

But speaking for your general point of "they must do what we tell them and I don't care what the repercussions are" - I can't speak to that.  Personally I don't feel the IETF or NENA should be in the business of telling people how to design, deploy, run, manage, and charge for their services, regardless of the cost or impact that would have - but that's not a discussion for this mailing list.

Along those lines though, why aren't the ECRIT specs mandating IPv6 everywhere, and NATs or Firewalls must not exist?  I mean if you're going to dictate market forces by fiat, you might as well be thorough.  ;)

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 2 Dec 2011 10:30:32 -0500

I guess mostly because people can get hurt or die if we can't figure out how to get them the help they need when, under stress, they do something stupid like hang up before we got the info we needed.  It happens now (call back to device isn't something the PSTN does).  Want to be next to a PSAP call taker when they get voice mail on a call back?  Been there.  Not pretty.  You get this hopeless feeling that comes from knowing you could help, and not being able to provide help, because the system failed you.  First time I saw it, I was a lot more upset than the call taker.  She'd had it happen a lot.  It was new to me.  I'd like to fix that.  Of course I'd like to prevent the hang up in the first place, but the IETF, so far, has decided that call back is all we get.  If call back is all we have, then it has to work, IMO.

We don't need to ban NATs or require IPv6 to make callback work.

Neither IETF or NENA can tell people how to "deploy, run, manage, and charge for their services".  All we can do is write documents that say "MUST".   Doesn't seem to affect a lot of deployments, as you have pointed out.  

Regulators can.  Is that preferable?

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Dec 2011 15:37:16 +0000

> I'm thinking they believe they will have more control over the UA software.

Generally I've found they don't think that way, and for good reason.

> negate features under control of the user anyway, so the point would be?

I was under the impression that when a consumer receives a call-back from a PSAP, the consumer is not billed for that call - for example, if the user has a pay-per-minute or credit-based plan, they will receive a PSAP callback even if they have no credits/minutes left in their plan.  Is that not the case/goal?  (I know that for wireless non-subscribers today there's no callback, but I'm not clear if that is in/out-of-scope for ECRIT?)

> Resource priority is NOT a requirement germane to this solution.

Um... but it's been stated it was by others.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Dec 2011 15:51:09 +0000

> I guess mostly because people can get hurt or die if we can't figure out how to get them the help they need when, under stress, they do something stupid like hang up before we got the info we neede…

Right, and I'm completely on-board with that, and it's what I said at the mic too in Taipei.  The rub is *it has to work*.  Changing the fundamental nature of how SIP deployments are done is not a good path to getting it to work, imho.

> We don't need to ban NATs or require IPv6 to make callback work.

Ah, but wouldn't it make it far easier to do callbacks?  If there were no NATs and no Firewalls and everything was IPv6, then the PSAP could just call directly back to the SIP UA bypassing all proxies/b2buas/domains/etc.

But it's not practical to require that.  And likewise, it's not practical to require GRUUs be used by all SIP domains.  Supporting GRUUs is not some trivial little configuration knob on one system.  It requires a re-architecting of the whole network, significant changes on many systems used today, and a whole crap-load of testing.

-hadriel

---

From: Marc Linsner <[email-masked]>
Date: Fri, 02 Dec 2011 13:24:50 -0500

>Um... but it's been stated it was by others.

I believe 'others' are simply attempting to mark the call so it can be
recognized as coming from a PSAP.

911 calls have no priority treatment today in the PSTN and they haven't
asked for any on the public Internet.

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Fri, 02 Dec 2011 13:28:11 -0500

>I was under the impression that when a consumer receives a call-back from
>a PSAP, the consumer is not billed for that call - for example, if the
>user has a pay-per-minute or credit-based plan, they will receive a PSAP
>callback even if they have no credits/minutes left in their plan.  Is
>that not the case/goal?  (I know that for wireless non-subscribers today
>there's no callback, but I'm not clear if that is in/out-of-scope for
>ECRIT?)
>

PSAP callbacks today are from a normal POTS service.  If in fact those are
not charged, it's news to me.

There has been no requirement put forth in ECRIT for 'free' callbacks.

-Marc-

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 2 Dec 2011 13:38:39 -0500

It sounds like there's some disagreement about requirements here.  Would it be useful to have a requirements document?

--Richard

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Dec 2011 21:33:46 +0100

Hi,

The requirement is to be able to identify a PSAP callback.

Whatever specfic treatments etc are then given to PSAP callbacks by different networks, and how/if PSAP callbacks are charged, is out of the scope.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Richard L. Barnes [[email-masked]]
Sent: Friday, December 02, 2011 8:38 PM
To: Marc Linsner
Cc: [email-masked]
Subject: Re: [Ecrit] GRUUs for callbacks

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 02 Dec 2011 15:48:07 -0600

At 02:33 PM 12/2/2011, Christer Holmberg wrote:

>Whatever specfic treatments etc are then given to PSAP callbacks by 
>different networks, and how/if PSAP callbacks are charged, is out of the scope.

Through "the networks" may be out of scope (because ECRIT defines 
things way above layers 3 & 4), but you have to address congestion 
within SIP servers if you are also attempting to adjust endpoint behavior.

Thus, you need to articulate two additional requirements

req #2 - that endpoints behave a certain way (e.g., don't DND or 
divert callback)

and

req #3 - something about SIP server processing *not* leading to SOC 
defined mechanisms in which the callback never reaches (or times out 
before getting to) the original 911/112 caller.

Now, req #2 could be covered within phonebcp, but req #3 isn't, and 
for an effective callback scenario, req #3 needs to be addressed.

James

>It sounds like there's some disagreement about requirements 
>here.  Would it be useful to have a requirements document?
>
>--Richard
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 04 Dec 2011 00:04:49 +0800

> passed to the UA upon registration.

So, if the UA was registered normally, to its home scscf, then it would 
get the gruu from there? But the emergency call might not traverse the 
home scscf? But the callback, because it uses a gruu from the home 
scscf, will traverse that one?

In such a case, the home scscf won't know that an emergency call has 
been made (as Hadriel mentioned). And while it could apply some 
expiration time to the gruu, the clock for that would start ticking when 
the registration that minted the gruu was done. That could be a long 
time ago. (I gather it is not considered desirable to force a special 
registration just prior to the emergency call - due to the extra time it 
might take and the possibility that it might fail.)

OTOH, IIUC  for some IMS cases its also necessary to support emergency 
calls from SIMless devices that don't have a normal registration. In 
that case I gather there will be an emergency registration, possibly to 
a visited network. That is probably the easier case.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Dec 2011 11:40:09 -0500

We seem to have difficulty finding a single mechanism that meets all requirements (such as non-forgeability and reach-the-same UA) in all situations:
- SBCs that destroy session identity
- UAs and/or proxies that don't support GRUUs
- call route divergence (route asymmetry), where the initial outbound emergency call and the call back traverse different paths.

Thus, maybe we need a more probabilistic approach that will work in most situations, relying on *multiple* markers and indicators. We may not achieve 100% coverage, but I suspect that the only way of doing that would be a 100% deployment of an end-to-end cryptographic mechanism that is recognized by all parties. (Since it seems close to impossible for the caller to convey an element that survives round-trip, you would probably have to identify the PSAP, not the call, since there's nothing that can be signed by the caller and be recognized by third parties.)

I can think of a few ingredients that are plausible and "survive" under different circumstances, two of which we have been discussing before:

(1) normal GRUUs, where the inbound proxy remembers that the outbound call was an emergency call; may fail under some route asymmetry cases and is subject to GRUU deployment issues.

(2) In-Reply-To and Priority; does not require any GRUU or new SIP elements, but fails with call-ID mangling SBCs and does not address asymmetric call paths.

(3) ARID (draft-ono-dispatch-attribute-validation), which allows entities on the call path to validate that the call originated from a PSAP, with pretty minimal infrastructure.

(4) PSAP-signed calls (see below).

I suspect there are others, but the basic goal seems to be that the caller, the only one knowing reliably that an emergency call was placed, needs to tell various elements responsible for inbound call handling to provide special handling for a specific call, identified by some element that survives the trip to and from the PSAP. If there was a standard protocol that allowed a UA to request per-call features, we could leverage that, but I haven't heard of such a thing. (Just to illustrate the spirit: The caller could create a CPL rule that bypasses call treatments just after placing the emergency call, but it seems fanciful to suggest this as a general mechanism, given the additional complexity in lots of places.)

The usual other way of proving yourself is a challenge-response mechanism, but that assumes that all the call handling elements share a secret with the caller. I can't think of a way to build such a system without a whole lot of new protocol machinery.

I also wonder whether for the more complicated IMS scenarios, it wouldn't be easier to just rely on PSAP signed requests, given that the number of IMS operators is likely to be not that large and that they are likely to be reasonably sophisticated operators. In other words, we don't try to identify return calls, just PSAP-originated calls.

Henning

On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote:

> So, if the UA was registered normally, to its home scscf, then it would get the gruu from there? But the emergency call might not traverse the home scscf? But the callback, because it uses a gruu from the home scscf, will traverse that one?
> 
> In such a case, the home scscf won't know that an emergency call has been made (as Hadriel mentioned). And while it could apply some expiration time to the gruu, the clock for that would start ticking when the registration that minted the gruu was done. That could be a long time ago. (I gather it is not considered desirable to force a special registration just prior to the emergency call - due to the extra time it might take and the possibility that it might fail.)
> 
> OTOH, IIUC  for some IMS cases its also necessary to support emergency calls from SIMless devices that don't have a normal registration. In that case I gather there will be an emergency registration, possibly to a visited network. That is probably the easier case.
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 04 Dec 2011 00:52:17 +0800

> Whatever specfic treatments etc are then given to PSAP callbacks by different networks, and how/if PSAP callbacks are charged, is out of the scope.

Based on the discussion, that doesn't seem to be a sufficient 
requirement. Specifically, it doesn't address *which* elements must be 
able to discover that the call is a psap callback.

I am guessing your intent is that every server on the path be able to 
discover this by examining the indication in the signaling. But the 
mechanisms that have been discussed fall short in this regard:

- the proposal to have a special uri parameter in an egruu allows
   anybody along the path to note this, until the egruu is translated.
   But most can't verify this is a valid marking. Only elements
   coordinated with the registrar issuing the gruu have much of a
   chance of determining that.

- And elements downstream of the egruu
   translation can only detect this via H-I. If H-I isn't used they
   can't determine this.

- The egruu itself doesn't guarantee that the call is a psap callback.
   If the egruu is only generated at the time an emergency call is made,
   and an expiration timer is started then, its possible to reduce the
   probability of fraud. But its not a very strong check. And I'm not
   sure how you guarantee that a UA doesn't request an egruu, use it
   in a non-emergency call, and then get the other end to call back on
   that egruu in order to get the benefits.

ISTM that we trust the psap more than the UA making the emergency call. 
So ISTM it would make more sense to have the psap UA initiate the 
indication, without involvement of original calling UA. This suggests 
something like GETS.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 04 Dec 2011 01:11:42 +0800

Why not forget about detecting and verifying that the call is a 
*callback* to an emergency call. Instead, simply give the psap a way to 
initiate a "priority" call to some URI. Then expect the elements on the 
path to take special action on these, such as bypassing features like VM.

We can rely on policy to restrict such calls to callbacks, or comparably 
compelling reasons.

There is still work to be done to satisfy this, but some hard things are 
avoided.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Dec 2011 12:28:56 -0500

That's roughly what I said below (last paragraph), so I'm a bit confused by your response. Both the ARID and the signed call mechanism rely on identifying the privileged caller (PSAP), rather than identifying a callback. However, from a deployability perspective, this requires significant changes in a number of places. If we're complaining about GRUUs not being widely deployed, we can't exactly call deploying a completely new solution an improvement.

This is why I'm trying to suggest that searching for a single magic solution that is

- secure
- works everywhere
- works with broken implementations
- works with no changes anywhere

is a fool's errand. Rather, by combining solutions, we might allow different providers/enterprise/UAs to pick their own trade-off and migrate to better solutions over time.

Henning

On Dec 3, 2011, at 12:11 PM, Paul Kyzivat wrote:

> Why not forget about detecting and verifying that the call is a *callback* to an emergency call. Instead, simply give the psap a way to initiate a "priority" call to some URI. Then expect the elements on the path to take special action on these, such as bypassing features like VM.
> 
> We can rely on policy to restrict such calls to callbacks, or comparably compelling reasons.
> 
> There is still work to be done to satisfy this, but some hard things are avoided.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 04 Dec 2011 03:13:07 +0800

> is a fool's errand. Rather, by combining solutions, we might allow different providers/enterprise/UAs to pick their own trade-off and migrate to better solutions over time.

Its possible we are not disagreeing much, but just thinking about things 
differently, or focusing on different things.

But I am a bit concerned that a scatter gun approach, where providers 
pick the pieces they like, may just result in needless differences and 
systems that don't work well.

If we agree that it isn't feasible to get an ideal system that meets all 
our wishes, then perhaps we can get a general agreement on a lesser set 
of requirements. E.g.

- its most important for the psap to be able, on explicit request,
   to achieve expedited access to an arbitrary AOR.
   (This might be a callback to an emergency call, via Contact AOR
   or From AOR, or whatever of the emergency call. It might also
   be some other AOR.)

- its nearly as important that the expedited access be able to reach
   devices that have recently made an emergency call but are normally
   not permitted or able to receive calls.

- its important (but less so) to minimize fraud by preventing non-
   psaps from getting the sort of expedited access mentioned above.

- it may be desirable that callees not be charged for receiving these
   expedited calls. (Decisions about this are based on policy.)

If we were to agree to the above, then we could start identifying 
mechanisms to support each. But some of them might be incomplete.

For instance, to achieve the first, we come up with a mechanism to 
indicate this is a psap expedited call. (e.g. urn:sos in From or P-A-ID.)

For the second, maybe nothing else is required in signaling if the 
contact address is reachable - just some policy adjustments. In other 
cases it might require allowing some sort of emergency registration, and 
then would only work as long as that registration remains in effect.

Some might not bother to minimize fraud at all. Others might depend on 
transitive trust to prevent unauthorized parties from making the 
indication for a psap expedited call. Or something like ARID might be used.

The disabling of fees could presumably be driven by one of the above 
mechanisms if desired.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 5 Dec 2011 10:46:44 -0500

phonebcp and NENA i3 docs differentiate between callbacks that are immediate (within minutes of the call) and later.

The former is (currently) to Contact, and the latter is to AoR (P-A-I  or From, ideally with Identity).

The requirement for the former is pretty simple - that which is in Contact gets back to the device that made the call.  That's basic 3261 isn't it?

While priority is a nice to have, and free is a nice to have, neither is essential, and if they were available, they would only apply to the URI in Contact.

It doesn't matter to the emergency call system what is in Contact.  It's just a URI that if called, gets to the right device.  phonebcp says it should remain valid for several minutes beyond the call unless the subscription expires and is not renewed.

It would be straightforward in my opinion to have PSAPs sign (Identity) for callbacks if that would be helpful.  Any reasonable marking (some urn in R-URI with actual target in Route, the particulars of the Identity header, or anything else straightforward is fine.  They can have any RPH, any Priority header, and populating In-Response-To is easy.

None of that applies to the later call back to P-A-I or From.  They are just calls.

Brian

On Dec 3, 2011, at 2:13 PM, Paul Kyzivat wrote:

> Its possible we are not disagreeing much, but just thinking about things differently, or focusing on different things.
> 
> But I am a bit concerned that a scatter gun approach, where providers pick the pieces they like, may just result in needless differences and systems that don't work well.
> 
> If we agree that it isn't feasible to get an ideal system that meets all our wishes, then perhaps we can get a general agreement on a lesser set of requirements. E.g.
> 
> If we were to agree to the above, then we could start identifying mechanisms to support each. But some of them might be incomplete.
> 
> For instance, to achieve the first, we come up with a mechanism to indicate this is a psap expedited call. (e.g. urn:sos in From or P-A-ID.)
> 
> For the second, maybe nothing else is required in signaling if the contact address is reachable - just some policy adjustments. In other cases it might require allowing some sort of emergency registration, and then would only work as long as that registration remains in effect.
> 
> Some might not bother to minimize fraud at all. Others might depend on transitive trust to prevent unauthorized parties from making the indication for a psap expedited call. Or something like ARID might be used.
> 
> The disabling of fees could presumably be driven by one of the above mechanisms if desired.
> 
> 	Thanks,
> 	Paul
> 
>> Henning
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Dec 2011 00:43:16 +0800

> The requirement for the former is pretty simple - that which is in Contact gets back to the device that made the call.  That's basic 3261 isn't it?

Yep, its basic 3261. But GRUU was an admission that people weren't 
implementing basic 3261. The lack of widespread support of GRUU may mean:
- some don't see it as important to support out-of-dialog callback
   to the contact of a dialog
- a perceived alternate way of implementing that makes the callback
   to the contact work without gruu. (E.g. an SBC substituting an
   address and supporting callbacks to it for some time, or supplying
   the AOR as the contact address in the call.)

Maybe Hadriel will comment on what he has seen in the wild, or Robert 
will comment on what he has seen at sipit.

> While priority is a nice to have, and free is a nice to have, neither is essential, and if they were available, they would only apply to the URI in Contact.

Is there an expectation that the psap will try a callback to the AOR if 
callback to the Contact fails? ISTM that would be an expedient strategy. 
If so, it would be good if the callback to the AOR also could request 
priority, and to suppress features. Perhaps this could be at the 
discretion of the psap caller.

> It doesn't matter to the emergency call system what is in Contact.  It's just a URI that if called, gets to the right device.  phonebcp says it should remain valid for several minutes beyond the ca…

If GRUU is not supported, and the native contact of the calling UA isn't 
globally routable, then callback to the contact might not work at all, 
or it may only work while the dialog is still up.

> It would be straightforward in my opinion to have PSAPs sign (Identity) for callbacks if that would be helpful.

I guess the problem with this is that it likely won't survive transit 
through an SBC.

> Any reasonable marking (some urn in R-URI with actual target in Route, the particulars of the Identity header, or anything else straightforward is fine.  They can have any RPH, any Priority header, and populating In-Response-To is easy.

I figured that was the case. The trick is to find something that has a 
high probability of working in real deployments. (Possibly with 
adjustments to SBC policies to make it work.)

This perhaps needn't be unforgeable, if the consequences of forging it 
are acceptable. That probably means that a forgeable mark not bestow 
free calls.

A forgeable mark providing priority and/or bypassing call blocking on 
the receiving side might be tolerable. Conceivably the provider could 
only allow this some limited number of times to mitigate it.

A forgeable mark bypassing features that screen callers or otherwise 
limit direct access to the callee is more problematic. Possibly this 
could be handled by the emergency caller's UA itself - by remembering 
that it made an emergency call recently or not. It could then reject 
calls with this marking if it hasn't recently made an emergency call. 
This isn't ideal, since it bothers the UA, but it avoids bothering the 
user. (But it still provides a vector for a DOS attack on the UA.)

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 5 Dec 2011 12:21:05 -0500

> Is there an expectation that the psap will try a callback to the AOR if callback to the Contact fails? ISTM that would be an expedient strategy. If so, it would be good if the callback to the AOR also could request priority, and to suppress features. Perhaps this could be at the discretion of the psap caller.
Yes, that's likely what would happen.  It would be good to have priority and suppress features, but it's not really required.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Dec 2011 14:30:28 -0500

Having spent some time in lawyer land, I think we have to be a bit careful with dismissing those concerns. A carrier might be very reluctant to dismiss a self-proclaimed PSAP callback on "too many already" grounds, given that guessing wrong could have serious consequences, including liability. On the other hand, telemarketing with fake caller ID, often from non-US sources, is becoming an increasing issue. Each of those perps typically only calls once and then disappears. There is some chance to catch those at the proxy, based on aggregate statistics. There's essentially no chance to do this at the UA. (This is similar to what's happening in spam filtering for email, where the receiver has essentially no hope of filtering this stuff.)

I do agree that having a strongly UA-verifiable callback mechanism is extremely helpful, since it allows a bit more room for error at the proxy.

What we need is a UA-setable nonce that survives the round trip at least for emergency calls. There are a few options:
- Call-Id - already discussed
- From tag?
- New header specific to emergency calls
- GRUU

Thus, given the environment we live in, I'd be really uncomfortable if the solution does not allow for reasonably-strong validation. I'm not worried about bad guys intercepting the original emergency call or rogue proxies (both seem more movie plot scenarios than probable), but anything that allows random far-away parties to fake such calls seems to invite mischief. Given the "far away" part, relying on the threat of prosecution is also unlikely to be a deterrent.

Henning

> 
> A forgeable mark providing priority and/or bypassing call blocking on the receiving side might be tolerable. Conceivably the provider could only allow this some limited number of times to mitigate it.
> 
> A forgeable mark bypassing features that screen callers or otherwise limit direct access to the callee is more problematic. Possibly this could be handled by the emergency caller's UA itself - by remembering that it made an emergency call recently or not. It could then reject calls with this marking if it hasn't recently made an emergency call. This isn't ideal, since it bothers the UA, but it avoids bothering the user. (But it still provides a vector for a DOS attack on the UA.)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Dec 2011 04:52:06 +0800

> Thus, given the environment we live in, I'd be really uncomfortable if the solution does not allow for reasonably-strong validation. I'm not worried about bad guys intercepting the original emergen…

OK, I buy your reasoning here.
So we need some way to convey a nonce. This could potentially be 
something generated and remembered by the UAC as part of the emergency 
call. I guess other elements on the call path could remember it if they 
want.

The mechanism for requesting suppression of services that interfere with 
the call reaching the UA remains an issue.

It would be nice if this could be a more general mechanism. (In general, 
when in a call, I might want to hand out a right to make a callback, and 
give a resulting callback different treatment than an unanticipated 
call.) But maybe that is too much to try for.

	Thanks,
	Paul

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 6 Dec 2011 13:20:23 -0800

ECRIT meeting minutes for IETF82 have been posted at link:
http://www.ietf.org/proceedings/82/minutes/ecrit.txt

Many thanks go to Jean Mahoney, who did a great job in capturing the
comments and action items from the meeting.

-roger marshall.

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.