Subject: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed!

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 Nov 2010 14:31:13 +0200

Hi all, 

we had a fairly good discussion at the last meeting on the PSAP callback topic triggered by a review from Cullen. As a summary the question came up whether we couldn't fall back to a "token-based solution approach".

This token-based approach roughly works as follows: When the emergency call is initially made then the calling device attaches some blob (called the token here) that is then stored at intermediate devices along the path (for a limited period of time; such as 2 hours). Then, when a callback is made the same blob is attached. When checking for the callback the received blob is compared with the stored one and if they match better treatment is provided to the callback (otherwise the call would be treated as any other call that has no marking attached at all). 

The implication of this design is the following: Section 1 of http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 lists a couple of cases where the currently described solution from the PhoneBCP document does not work. With the token based approach the following assumptions have to be made regarding the synchronization of the token between different entities: 

_ Section 1.1:  Route Asymmetry

   The token has to be shared between the inbound and the outbound proxy.  

- Section 1.2: Multi-Stage Resolution

   No additional considerations 

- Section 1.3:  Call Forwarding

   In a call forwarding scenario the token needs to be forwarded as well. 

- Section 1.4:  PSTN Interworking

  In this scenario the token would not be forwarded to the PSTN device and hence may not be available for the callback. As such, the token has to be shared between the two PSTN-VoIP gateways. 

- Section 1.5:  Network-based Service URN Resolution

   No additional considerations 
 
If there are no objections with the suggested approach (nor with the potential requirement for state synchronization) then I will make the changes with the next draft update. 

Please respond by the end of the week if you have objections!

Ciao
Hannes

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Nov 2010 09:49:42 -0500

ISTM that a token could be inserted by any element in the path, and there could be more than one of them.

Trying to make the device fabricate the token may or may not make sense, depending on the circumstances.

I think that the only implications are at the PSAP: the PSAP has to include the token(s) in call forwarding or call back situations.

Brian

On Nov 22, 2010, at 7:31 AM, Hannes Tschofenig wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 22 Nov 2010 19:29:24 +0200

It is theoretically possible to let an intermediary insert the token.
Note: When the device does not insert the token then it will not be able
to check it when it receives it. Providing special call treatment on the
end device is very likely going to be necessary. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Brian Rosen
> Sent: Monday, November 22, 2010 4:50 PM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - 
> Feedback needed!
> 
> ISTM that a token could be inserted by any element in the 
> path, and there could be more than one of them.
> 
> Trying to make the device fabricate the token may or may not 
> make sense, depending on the circumstances.
> 
> I think that the only implications are at the PSAP: the PSAP 
> has to include the token(s) in call forwarding or call back 
> situations.
> 
> Brian
> 
> > we had a fairly good discussion at the last meeting on the 
> PSAP callback topic triggered by a review from Cullen. As a 
> summary the question came up whether we couldn't fall back to 
> a "token-based solution approach".
> > 
> > This token-based approach roughly works as follows: When 
> the emergency call is initially made then the calling device 
> attaches some blob (called the token here) that is then 
> stored at intermediate devices along the path (for a limited 
> period of time; such as 2 hours). Then, when a callback is 
> made the same blob is attached. When checking for the 
> callback the received blob is compared with the stored one 
> and if they match better treatment is provided to the 
> callback (otherwise the call would be treated as any other 
> call that has no marking attached at all). 
> > 
> > The implication of this design is the following: Section 1 
> of 
> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 
> lists a couple of cases where the currently described 
> solution from the PhoneBCP document does not work. With the 
> token based approach the following assumptions have to be 
> made regarding the synchronization of the token between 
> different entities: 
> > 
> >  In this scenario the token would not be forwarded to the 
> PSTN device and hence may not be available for the callback. 
> As such, the token has to be shared between the two PSTN-VoIP 
> gateways. 
> > 
> > If there are no objections with the suggested approach (nor 
> with the potential requirement for state synchronization) 
> then I will make the changes with the next draft update. 
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 23 Nov 2010 10:42:29 +0800

Having tokens added by intermediaries is a better idea.  For one, it can help avoid the problem where intermediaries have to accumulate state in order to recognize later callbacks.

I think that call forwarding is a simple enough case, and finding an appropriate place to attach the token should ensure that it stays attached to the forwarded call.  (Not to pre-empt a solution, but it occurs that a Contact URI parameter might work in the same way as GRUU.)

The route-asymmetry is more difficult, but it might be made easier by an assumption and a little sophisticated state management.

Important to note that in route-asymmetry (and PSTN interworking) cases that the only times that an intermediary needs to have access to a token is when it treats the incoming call differently.  (Bypassing voice mail, that sort of thing.)  I expect that most SIP providers on the path wont need to treat this call specially, so access to the token isn't necessary.

The most likely need for token access is for the service that a user subscribes to.  The service that operates the domain of their AoR.  This service is the only one likely to do policy-based treatment of calls (voice mail, redirect to alternative contact and so forth).  This means that for route asymmetry we can assume that a provider on the callback path only is unlikely to need to subject the call to special handling.  If this assumption is good, then this tagging scheme works.

So, on the outbound emergency call the intermediary identifies that the call is an emergency call (urn:service:sos tree or by locally defined means).  They tag the call with a special token.  If it were me, I'd include the time, any supplementary information they want to save (maybe encrypted to shield from prying eyes), and some form of integrity protection.

On the callback, a different intermediary gets the callback, but they know about the tagging and have the means to identify the integrity-protected tag (and to decrypt the necessary data).  They extract this information and apply local policy that now has this additional input (the time of the call, etc...).  Thus, callback is achieved (or not, as local policy dictates).

The condition here is that different intermediaries operated by the same provider are all configured with the same secret key information necessary to check the integrity of the token (and decrypt).

This works, though I have to wonder if the additional mechanism is not more complicated than what was proposed in -ecrit-direct.

--Martin

On 2010-11-23 at 01:49:42, Brian Rosen wrote:
> I think that the only implications are at the PSAP: the PSAP has to
> include the token(s) in call forwarding or call back situations.
> 
> Brian
> 
> > we had a fairly good discussion at the last meeting on the PSAP
> callback topic triggered by a review from Cullen. As a summary the
> question came up whether we couldn't fall back to a "token-based
> solution approach".
> >
> > This token-based approach roughly works as follows: When the
> emergency call is initially made then the calling device attaches some
> blob (called the token here) that is then stored at intermediate
> devices along the path (for a limited period of time; such as 2 hours).
> Then, when a callback is made the same blob is attached. When checking
> for the callback the received blob is compared with the stored one and
> if they match better treatment is provided to the callback (otherwise
> the call would be treated as any other call that has no marking
> attached at all).
> >
> > The implication of this design is the following: Section 1 of
> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 lists a
> couple of cases where the currently described solution from the
> PhoneBCP document does not work. With the token based approach the
> following assumptions have to be made regarding the synchronization of
> the token between different entities:
> >
> >  In this scenario the token would not be forwarded to the PSTN device
> and hence may not be available for the callback. As such, the token has
> to be shared between the two PSTN-VoIP gateways.
> >
> > If there are no objections with the suggested approach (nor with the
> potential requirement for state synchronization) then I will make the
> changes with the next draft update.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Nov 2010 09:17:27 +0100

Hi,

In my opinion the "blob" approach would not work for IMS. The reasons are:

1. In the beginning, the vast majority of the cases will be PSTN breakouts. 

(I think a solution that doesn't support PSTN would be useless in lots of non-IMS networks also.)

2. Emergency is a local service, and in roaming scenarios the only node that could store this "blob" is the P-CSCF in the visited network. But, the psap emergency callback must be detected before it reaches the visited P-CSCF, already in the home network (e.g. in order to disable services), which will receive the callback and then route it back to the visited network where the calling user is located.

Regards,

Christer 

> On Behalf Of Hannes Tschofenig
> Sent: 22. marraskuuta 2010 14:31
> To: ECRIT
> Cc: Hannes Tschofenig
> Subject: [Ecrit] PSAP Callback: Pending Draft Update - 
> Feedback needed!
> 
> Hi all, 
> 
> emergency call is initially made then the calling device

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Nov 2010 10:29:58 +0200

Item (2) is the feedback I recall from discussions earlier this year that had lead us to explore solutions beyond the token-based approach. 

For the callback there is, however, the question whether this would indeed be routed through the home network or rather through the visited network. Furthermore, why wouldn't the visited and the home network be able to share the token given that they share many other things as well. 

The PSTN case is a bit more complicated particularly since the current PSTN does not have a solution that would be equivalent. So, is it useful to have a solution for the PSTN case at all?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Nov 2010 13:09:24 +0100

Hi,

>Item (2) is the feedback I recall from discussions earlier this year 
>that had lead us to explore solutions beyond the token-based approach.

So, based on what is it now suggested that ECRIT should consider Item (2) as a non-valid case to solve?

>For the callback there is, however, the question whether this would 
>indeed be routed through the home network or rather through the visited 
>network.

I am not sure I understand. Maybe such networks exists somewhere, but the networks I am aware of works as following:

1. The callback will be made towards the number from where the emg call was made, using normal SIP routing procedures, and ENUM/SIP-URI will always point towards the home network.

2. A PSTN network has no clue in what visited network the calling IMS user is located, so the callback will always be routed towards the home network.

>Furthermore, why wouldn't the visited and the home network be able to 
>share the token given that they share many other things as well.

First, it is not enough to share the token. There must also be a way for the home network to associate a specific callback with a specific token. So, the token would need to be associated with the number of the calling UA, so that the callback made towards that number can then be associated with the blob associated with that UA.

Second, it is not enough to be able to associate the callback with the token. The home network needs to know that the call is a callback in the first place. 

In some cases the MGCF determines that based on received ISUP indicator.

In other case the MGCF determines that based on number analysis.

So, yes, the MGCF could probably determine that the call is callback, and insert the token, rather than a generic callback indicator. But, that would require that not only the home S-CSCF, but also the home MGCF(s) (and maybe other border nodes in the home network) have the token/UA_number information, which makes things even more complex.

Technically it might be possible to come up with a solution for this, but I don't see why the token solution as such is so superior that it would be worth all the trouble. But, maybe I've missed something.

>The PSTN case is a bit more complicated particularly since the current 
>PSTN does not have a solution that would be equivalent. So, is it 
>useful to have a solution for the PSTN case at all?

As I said, I think that PSTN breakout will be the most common case for a considerable time to come, and a solution that doesn't support that is not feasible in real networks.

Regards,

Christer

> > (I think a solution that doesn't support PSTN would be 
> useless in lots 
> > of non-IMS networks also.)
> > 
> > 2. Emergency is a local service, and in roaming scenarios 
> the only node that could store this "blob" is the P-CSCF in 
> the visited network. But, the psap emergency callback must be 
> detected before it reaches the visited P-CSCF, already in the 
> home network (e.g. in order to disable services), which will 
> receive the callback and then route it back to the visited 
> network where the calling user is located.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Hannes Tschofenig
> >> Subject: [Ecrit] PSAP Callback: Pending Draft Update - Feedback 
> >> needed!
> >> 
> >> Hi all,
> >> 
> >> emergency call is initially made then the calling device attaches 
> >> some blob (called the token here) that is then stored at 
> intermediate 
> >> devices along the path (for a limited period of time; such as 2 
> >> hours). Then, when a callback is made the same blob is 
> attached. When 
> >> checking for the callback the received blob is compared with the 
> >> stored one and if they match better treatment is provided to the 
> solution from 
> >> the PhoneBCP document does not work. With the token based approach 
> >> the following assumptions have to be made regarding the 
> >> synchronization of the token between different entities:
> >> 
> PSTN device 
> >> and hence may not be available for the callback.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Nov 2010 14:16:38 +0200

Hi Christer, 

> So, based on what is it now suggested that ECRIT should consider Item (2) as a

This was the suggestion that was raised during the meeting. Hence, I have
posted a mail to discuss this issue on the list.

> I am not sure I understand. Maybe such networks exists somewhere, but the
> networks I am aware of works as following:
> 
> 1. The callback will be made towards the number from where the emg call was
> made, using normal SIP routing procedures, and ENUM/SIP-URI will always point
> towards the home network.

We have to differentiate between the AoR and the GRUU.

> 
> 2. A PSTN network has no clue in what visited network the calling IMS user is
> located, so the callback will always be routed towards the home network.

Let us treat the PSTN case different from the other scenario.

> First, it is not enough to share the token. There must also be a way for the
> home network to associate a specific callback with a specific token. So, the
> token would need to be associated with the number of the calling UA, so that
> the callback made towards that number can then be associated with the blob
> associated with that UA.

Not necessarily. The suggestion was to use a token and not necessarily to
tie it to any identifier

> 
> Second, it is not enough to be able to associate the callback with the token.
> The home network needs to know that the call is a callback in the first place.

You mean there additionally needs to be a marking that the call is indeed a
callback related to an emergency. That's OK.

> So, yes, the MGCF could probably determine that the call is callback, and
> insert the token, rather than a generic callback indicator. But, that would
> require that not only the home S-CSCF, but also the home MGCF(s) (and maybe
> other border nodes in the home network) have the token/UA_number information,
> which makes things even more complex.
> 
> Technically it might be possible to come up with a solution for this, but I
> don't see why the token solution as such is so superior that it would be worth
> all the trouble. But, maybe I've missed something.

The difference is the security story around it.

> As I said, I think that PSTN breakout will be the most common case for a
> considerable time to come, and a solution that doesn't support that is not
> feasible in real networks.

I am not sure how the PSTN case is supposed to work given that the first
VoIP-PSTN gateway by magic has to determine whether the outgoing call is a
callback or any other call that happens to come from the PSTN.

Ciao
Hannes

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Nov 2010 14:25:27 +0100

Hi,

>This was the suggestion that was raised during the meeting. 
>Hence, I have posted a mail to discuss this issue on the list.

I was not able to participate in the ECRIT session, but I will take a look at the minutes for the reasoning.

>>>indeed be routed through the home network or rather through the 
>>>visited network.
>> 
>>I am not sure I understand. Maybe such networks exists somewhere, but 
>>the networks I am aware of works as following:
>> 
>>1. The callback will be made towards the number from where the emg 
>>call was made, using normal SIP routing procedures, and ENUM/SIP-URI 
>>will always point towards the home network.
> 

In IMS even a gruu will be routed via the home network.

>>2. A PSTN network has no clue in what visited network the calling IMS 
>>user is located, so the callback will always be routed towards the 
>>home network.
> 

Fair enough, but I hope that we will not end up defining a separate mechanism for PSTN. For example, gruu does not work with PSTN.

>>First, it is not enough to share the token. There must also be a way 
>>for the home network to associate a specific callback with a specific 
>>token. So, the token would need to be associated with the number of 
>>the calling UA, so that the callback made towards that number can then 
>>be associated with the blob associated with that UA.
> 
>Not necessarily. The suggestion was to use a token and not necessarily 
>to tie it to any identifier

So, a specific network would use the same token value for all emergency calls? But, even in that case the home network entity that determines that the call is callback needs to know in which visited network the call is going to end up, in order to insert the token value associated with that network. The border entities (MGCF/IBCF) do not have that information.

>You mean there additionally needs to be a marking that the call is 
>indeed a callback related to an emergency. That's OK.

Yes. The home network needs to know, in order to e.g. disable services that normally would be enabled for the UE.

>>So, yes, the MGCF could probably determine that the call is callback, 
>>and insert the token, rather than a generic callback indicator. But, 
>>that would require that not only the home S-CSCF, but also the home
>>MGCF(s) (and maybe other border nodes in the home network) have the 
>>token/UA_number information, which makes things even more complex.
>> 
>>Technically it might be possible to come up with a solution for this, 
>>but I don't see why the token solution as such is so superior that it 
>>would be worth all the trouble. But, maybe I've missed something.
> 

Are you talking about the case where a normal use could fake a callback by inserting the indicator?

If the home network uses number analysis to determine that a call is fallback, then it will also detect fake callbacks. This is no different from other types of priority calls.

>>>The PSTN case is a bit more complicated particularly since the 
>>>current PSTN does not have a solution that would be equivalent. So, 
>>>is it useful to have a solution for the PSTN case at all?
>> 
>>As I said, I think that PSTN breakout will be the most common case for 
>>a considerable time to come, and a solution that doesn't support that 
>>is not feasible in real networks.
> 
>I am not sure how the PSTN case is supposed to work given that the 
>first VoIP-PSTN gateway by magic has to determine whether the outgoing 
>call is a callback or any other call that happens to come from the 
>PSTN.

In some ISUP variants there is an indicator. In other cases, number analysis is used.

Regards,

Christer

> >> the only node that could store this "blob" is the P-CSCF in the 
> >> visited network. But, the psap emergency callback must be detected 
> >> before it reaches the visited P-CSCF, already in the home network 
> >> (e.g. in order to disable services), which will receive 
> the callback 
> >> and then route it back to the visited network where the 
> calling user 
> >> is located.
> >>> 
> >>> Regards,
> >>> 
> >>> Christer
> >>> 
> >>> 
> attaches 
> >>>>   The token has to be shared between the inbound and the 
> outbound 
> >>>> proxy.
> >>>> 
> >>>>   In a call forwarding scenario the token needs to be 
> forwarded as 
> >>>> well.
> >>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Nov 2010 15:33:35 +0200

What are the properties of the design in the PSTN case?

Based on what information is the PSTN-VoIP gateway going to put a callback
marking on the call?

On 11/23/10 3:25 PM, "ext Christer Holmberg"
<[email-masked]> wrote:

> Fair enough, but I hope that we will not end up defining a separate mechanism
> for PSTN. For example, gruu does not work with PSTN.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Nov 2010 14:48:09 +0100

Hi,

>Based on what information is the PSTN-VoIP gateway going to 
>put a callback marking on the call?

Unfortunately I don't have details of that available. I think the information elements have different names depending on countries etc.

And, as I said, if no such information element is available, number analysis can be used.

Regards,

Christer

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Nov 2010 09:05:44 -0500

In every nation I know the details of (which isn't many), the PSTN affords no special processing to call backs.

Having the gateway aware that a call was a call back is not useful in those countries.

Brian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Nov 2010 15:14:45 +0100

Hi Brian,

Do you agree that the home network in general needs to know (based on whatever information) that the call is callback (e.g. in order to disable services etc)? 

Regards,

Christer

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: 23. marraskuuta 2010 16:06
> To: Christer Holmberg
> Cc: Hannes Tschofenig; Hannes Tschofenig; ECRIT
> In every nation I know the details of (which isn't many), the 
> PSTN affords no special processing to call backs.
> 
> >> Based on what information is the PSTN-VoIP gateway going to put a 
> >> callback marking on the call?
> > 
> > Unfortunately I don't have details of that available. I 
> think the information elements have different names depending 
> on countries etc.
> >

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Nov 2010 09:28:41 -0500

In the present system, this isn't done.

I agree it should be done, and therefore, I do want call backs to be marked.

I personally think the token mechanism is the best way to link the outgoing call with the incoming call for security purposes.  I think that the home/local issue can be solved reasonably.

In North America, we will have a PKI which could be used to identify the emergency services.  I'm not sure that will actually be practical everywhere, so something much more "local" is desirable.  

Brian

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 23 Nov 2010 11:05:25 -0500

[email-masked] wrote on 11/23/2010 08:25:27 AM:

> [image removed] 
> Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed!
> Christer Holmberg 
> to:
> Hannes Tschofenig, Hannes Tschofenig 
> 11/23/2010 08:25 AM
> Sent by:
> [email-masked]
> Cc:
> ECRIT
> 
> Hi,
> 
> If the home network uses number analysis to determine that a call is
> fallback, then it will also detect fake callbacks. This is no 
> different from other types of priority calls.
> 
I am not sure which "priority calls" you are referring to, but the ones I 
am familiar with do NOT use "number analysis" to "determine that a call is 
priority".

They may use number analysis to identify a REQUEST for a priority call. 
But once the priority has been granted/authenticated/authorized, there is 
nothing in the number analysis that will tell you it is a priority call.

Janet

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Nov 2010 20:33:30 +0100

Hi,

>I am not sure which "priority calls" you are referring to, but the ones I am >familiar with do NOT use "number analysis" to "determine that a call is priority". >

Yes, that is what I meant. Sorry for the confusion.

Regards,

Christer

  But once the priority has been granted/authenticated/authorized, there is nothing in the number analysis that will tell you it is a priority call.

Janet

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Nov 2010 19:49:11 +0100

Hi,

>I personally think the token mechanism is the best way to 
>link the outgoing call with the incoming call for security 
>purposes. I think that the home/local issue can be solved reasonably.

Ok, so I guess the first question is then whether the group agrees to cover the home/local issue. I think it would also be useful for 3GPP to know.

Regarding the callback indication from PSTN, I hade a chat with some of our ISUP guys.

There is no global ISUP standard for callback indication. However, there are national ISUP variants where this kind of information can be inserted in the ISUP ample space. Other mechanisms involve making the decission based on CPC, or to use reserved trunks for emergency and callback (e.g. use a specific set of CIC values/B-channels as indicator). Such informatino is normally not sent to the S-CSCF (I don't want to require ISUP encapsulation for this :)

A possible way to allow this could be to allow the MGCF to insert an "empty" token. The home S-CSCF could then insert the value of the called UA, before forwarding the INVITE. I don't think that would have any impacts on security.

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 25 Nov 2010 04:01:22 +0100

Surely the IETF work is to enable the original user with an emergency to be IP connected. 

Giving the caller the benifit of the callback experience should be possible whether the PSAP is IP connected or connected via the PSTN. In many countries we expect to see PSAPs connected via the PSTN for a long time, while the users are increasingly IP connected.

Therefore whether the PSAP is IP connected or connected via the PSTN should not affect the way callbacks occur to that user. Whether there are technical problems with providing a solution or not, the use case is equally valid.

regards

Keith

> On Behalf Of Brian Rosen
> Sent: Tuesday, November 23, 2010 2:06 PM
> To: Christer Holmberg

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Nov 2010 13:54:23 +0200

I understand the desire to have that use cases covered. 

I was interested to hear more about the desire properties because there are security implications that we may not want to ignore. 
The implication I see that it is difficult for the PSTN-IP gateway to decide whether an outgoing call is a callback or not. 
I am curious to hear whether there are mechanisms on the PSTN side that would allow such "callback marking" to be signaled to the gateway.