Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2012 15:20:53 +0200

Hi,

Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value?

Could a PSAP use Priority:emergency for non-callback calls?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 15. toukokuuta 2012 18:19
To: [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically:

- the UA, when placing an emergency call, can use a temp gruu.
   Its possible to get as many temp gruus as you like, so the UA
   can reserve one for this purpose. This doesn't require any
   new capabilities in registrars.

- when the UA receives a call addressed to a temp gruu that it
   had previously used for an emergency call, it can give it
   special treatment as an emergency callback. It can decide how
   long after the emergency call to grant this special treatment
   as a matter of policy. The special treatment can include dropping
   existing calls, special alerting, etc.

- the PSAP, when placing the emergency callback, can indicate that
   *it* considers this call important using the Priority:emergency.
   If appropriate it can also use other existing headers, such as
   Resource-Priority. It call also use callerprefs to indicate that
   it prefers the real UA and does not wish an automaton.

- middleboxes in the path of the callback can choose to honor the
   Priority:emergency, and use that to condition their behavior.
   For instance, a home proxy could decide that an emergency call
   to a temp gruu should not be diverted. (Though the fact that it is
   to a gruu should typically bypass that anyway.)

- abuses of Priority:emergency by callers can be dealt with by the
   called UA, because it can reject such calls if not to a temp
   gruu previously used for an emergency call. This can cause *some*
   disruption, but only to the extent of handling an incoming INVITE
   and rejecting it. If the frequency of that rises to a level where
   it becomes a problem then it should be dealt with as a DOS attack.

	Thanks,
	Paul

On 5/15/12 7:05 AM, Christer Holmberg wrote:
> Hi,
>
> Once again, I would like to see whether there is a way for us to move 
> forward on the callback indicator issue.
>
> There are two requirements:
>
> 1.Indicate the callback
>
> 2.Be able to route the callback to the user that made the emergency 
> call
>
> Regarding the indication, it has been suggested that the indicator 
> value is per user, and is provided to the user upon registration.
>
> We also discussed whether the value could change over time, but the 
> problem was that the emg call may be done using an old value, and the 
> callback using a new value (because there was some time between the 
> emg call and the callback, during which the user was given a new value).
>
> To avoid that, the registrar would always provide the same value to a 
> given user.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2012 11:30:57 -0400

> Could a PSAP use Priority:emergency for non-callback calls?

I suppose these questions may deserve further discussion.

IMO Priority:emergency is appropriate for the callback, assuming it 
should be treated as an emergency. (OTOH, if the psap decides to call 
back the next day just as a followup, to see if all is well, then 
perhaps it isn't an emergency.)

I don't understand what the use case might be, but if the psap felt a 
need to initiate a call that was not a callback to a prior emergency 
call, and it felt the call was indeed an emergency, then I see no reason 
why it should not tag it with Priority:emergency.

In the latter case, the call might not get the same treatment on the 
receiving end. In this case the callee has nothing to help it 
distinguish a justified use of Priority:emergency from an unjustified 
one. So it might not give the call any priority treatment. But I think 
that is fine.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2012 19:33:00 +0200

Hi,

> one. So it might not give the call any priority treatment. But I think

OTOH, defining a new Priority value is not a very difficult task :) 

Also, in this case I guess the semantics of a callback already exists, so we wouldn't need to work much on that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2012 13:48:17 -0400

> Also, in this case I guess the semantics of a callback already exists, so we wouldn't need to work much on that.

My preference would be to use the existing values when they have the 
right semantics, which "emergency" seems to do right now. The fact that 
its a callback isn't really very interesting - that its an emergency *is*.

The callback part of this is really a perspective of the callee - that 
it might be expecting an emergency call if it has lost the one it was 
in. The primary purpose there is simply as a screening device for 
fraudulent use of "emergency".

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 4 Jun 2012 17:56:31 +0000

A new RPH=SOS (versus SOL) that is honored based on a trust model/relationships 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, June 04, 2012 1:33 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2012 14:03:46 -0400

> A new RPH=SOS (versus SOL) that is honored based on a trust model/relationships

I had originally noted that we could use a number of existing 
indications. Resource-Priority would perhaps be good in environments 
that do something with it. This would be complementary to the 
Priority:emergency, which is an indication of how the caller perceives 
the call. The Resource-Priority, when used, may be subject to other 
controls, and mostly impact intermediaries, rather than the callee.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2012 20:05:46 +0200

Hi,

> controls, and mostly impact intermediaries, rather than the callee.

Well, as we've discussed before, we DO need an indicator which is used by intermediaries to give special treatment to the callback.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2012 16:26:28 -0400

> Well, as we've discussed before, we DO need an indicator which is used by intermediaries to give special treatment to the callback.

Well, I guess it depends on what sorts of treatment you are talking 
about. If you are talking about resource prioritization, then the 
Resource-Priority header is probably what you want.

If you are talking about bypassing various sorts of treatment, such as 
call diversion, then I don't think Resource-Priority is the right thing. 
Those are generally discretionary anyway. Honoring the caller's wishes, 
expressed via Priority and perhaps callerprefs, seems to make more 
sense. In such cases, there is a question of whether to honor the 
caller's preferences, or the callee's policies. It's my personal opinion 
that if the caller says he only wants to talk to a human, not an 
automaton, then one should honor that, and either let the human's phone 
ring or else simply reject the call. And I'm suggesting that from a 
provider perspective that means passing the call to the UA and letting 
it decide.

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 4 Jun 2012 20:31:32 +0000

Paul,

I agree that this is not a priority service, and thereby RPH is likely not appropriate.

Martin

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, June 04, 2012 4:26 PM
To: Christer Holmberg
Cc: DOLLY, MARTIN C; [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Jun 2012 11:39:25 +0200

Hi,

>>> Priority:emergency, which is an indication of how the caller 
>>> perceives the call. The Resource-Priority, when used, may be subject 
>>> to other controls, and mostly impact intermediaries, rather than the callee.
>>
> Well, I guess it depends on what sorts of treatment you are talking about. If you are talking about resource prioritization, then the Resource-Priority header is probably what you want.
>
> If you are talking about bypassing various sorts of treatment, such as call diversion, then I don't think Resource-Priority is the right thing. 
> Those are generally discretionary anyway. Honoring the caller's wishes, expressed via Priority and perhaps callerprefs, seems to make more sense. In such cases, there is a question of whether to honor the caller's preferences, or the callee's policies. It's 
> my personal opinion that if the caller says he only wants to talk to a human, not an automaton, then one should honor that, and either let the human's phone ring or else simply reject the call. And I'm suggesting that from a provider perspective that 
> means passing the call to the UA and letting it decide.

It's not only about bypassing diversion. Even if the call will reach the correct human, one may still want to bypass services etc in the network.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jun 2012 09:38:23 -0400

> It's not only about bypassing diversion. Even if the call will reach the correct human, one may still want to bypass services etc in the network.

I find it hard to have this discussion in the abstract.
Can we talk about the specific sorts of services you have in mind? I 
suspect that different sorts of treatment may need to be addressed in 
different ways.

ISTM there is a fundamental issue here of whether it is expected that 
intermediaries must understand the purpose of the incoming call to 
decide how to handle it, or if the caller should simply indicate how he 
would like it handled (or not handled).

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 6 Jun 2012 11:37:15 +0100

Paul, Christer,

1  I inserted a use case below in Paul's email to hopefully assist with the discussion about priority indicators.

2  PSAP callback is certainly an important subject for PSAPs in the UK, as callbacks are used to help manage emergency calls in an appreciable number of cases (though I don't currently have any stats for % of occasions, which may in any case change when moving off TDM networks to IP networks........).

Regards

John

John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | Email: [email-masked] |

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 04 June 2012 16:31
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

IMO Priority:emergency is appropriate for the callback, assuming it should be treated as an emergency. (OTOH, if the psap decides to call back the next day just as a followup, to see if all is well, then perhaps it isn't an emergency.)

I don't understand what the use case might be, but if the psap felt a need to initiate a call that was not a callback to a prior emergency call, and it felt the call was indeed an emergency, then I see no reason why it should not tag it with Priority:emergency.

[John Medland] Another Use Case (separate from callback to the end user who needs help) would be where one PSAP needs to pass incident details to a second PSAP where the second PSAP is needed to provide additional assistance.  An example would be where first PSAP is the Police but second PSAP is the Fire Service needed to free people trapped in a motor accident.    

In the latter case, the call might not get the same treatment on the receiving end. In this case the callee has nothing to help it distinguish a justified use of Priority:emergency from an unjustified one. So it might not give the call any priority treatment. But I think that is fine.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Jun 2012 13:25:18 -0400

We distinguish between two kinds of call back:
1. Call back to the device that placed the call.  This happens within minutes of the original call.
2. Call back to the caller.  This happens later

The former uses Contact, the latter uses AoR.  The former may need some services bypassed, the latter doesn't.

Priority:Emergency is okay with me
Just for reference, 3261 says:
   The Priority header field indicates the urgency of the request as
   perceived by the client.  The Priority header field describes the
   priority that the SIP request should have to the receiving human or
   its agent.  For example, it may be factored into decisions about call
   routing and acceptance.  

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Jun 2012 21:00:14 +0200

> 1  I inserted a use case below in Paul's email to hopefully assist with the discussion about priority indicators.

John - can you clarify your use case further?
You say the first psap (police) calls a 2nd psap (fire) for help on the 
call.

Did you mean the call from police to fire is the one to be tagged as an 
emergency? Or did you mean that subsequently the fire psap wants to call 
the original user? If the latter, then I guess it is a judgement call 
whether this is a callback or not.

Also, this brings up some interesting issues. Suppose the user is still 
on the line with the police when the fire psap calls. What should 
happen? Should the user's phone hang up the call to police to answer the 
one from fire? Or reject the one from fire? Merge the calls?

It sounds to me like it would be better for the police to treat this as 
a consult, followed by a consultative transfer. If so, then there would 
be no callback at all.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jun 2012 20:55:00 +0200

Hi,

> suspect that different sorts of treatment may need to be addressed in

Any type of service (diversion is one example) that normally would be applied to the called user. Typically, in IMS, the S-CSCF would not forward a terminating callback requests to Application Servers providing such services.

> would like it handled (or not handled).

The intermediareis must understand the purpose of the incoming call.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jun 2012 21:02:39 +0200

Hi,

So, would anyone object to using Priority: Emergency?

Regards,

Christer

________________________________________
From: Brian Rosen [[email-masked]]
Sent: Wednesday, June 06, 2012 8:25 PM
To: [email-masked]
Cc: [email-masked]; Christer Holmberg; [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

Brian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 11 Jun 2012 22:26:54 +0200

Depends what for.

For information to the end user, no problem.

But as in my view it is an end-to-end header field, I do not envisage any processing in intermediate entities on it.

Regards

Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 11 June 2012 20:03
To: Brian Rosen; [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

Hi,

Regards,

Christer

Brian

---

From: <[email-masked]>
Date: Mon, 11 Jun 2012 21:33:11 +0100

Paul - I've tried to answer briefly below.  Regards

John 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 10 June 2012 20:00
To: Medland,JD,John,MLC12 R
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

John - can you clarify your use case further?
You say the first psap (police) calls a 2nd psap (fire) for help on the call.

Did you mean the call from police to fire is the one to be tagged as an emergency? 
[John Medland] Yes that was the scenario I had in mind.

Or did you mean that subsequently the fire psap wants to call the original user? If the latter, then I guess it is a judgement call whether this is a callback or not.
[John Medland] I'd not considered this but it could (more rarely) also be helpful.

Also, this brings up some interesting issues. Suppose the user is still on the line with the police when the fire psap calls. What should happen? Should the user's phone hang up the call to police to answer the one from fire? Or reject the one from fire? Merge the calls?
[John Medland] Possible, but unlikely scenario, as Police would most likely tell Fire that they were still in contact with caller so Fire Service would not try.

It sounds to me like it would be better for the police to treat this as a consult, followed by a consultative transfer. If so, then there would be no callback at all.
[John Medland] Sorry, but not sure what's meant by a "consult"?   May be OK but also needs priority treatment (to indicate dealing with arranging an emergency response).

	Thanks,
	Paul

>>> Once again, I would like to see whether there is a way for us to 
>>> move forward on the callback indicator issue.
>>>
>>> problem was that the emg call may be done using an old value, and 
>>> the callback using a new value (because there was some time between 
>>> the emg call and the callback, during which the user was given a new value).
>>>
>>> To avoid that, the registrar would always provide the same value to 
>>> a given user.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Jun 2012 10:28:21 +0200

Hi, 

> But as in my view it is an end-to-end header field, I do not envisage any processing in intermediate entities on it.

The text referenced by Brian talks about "agent of user", so one could claim that is a network function.

If not, do you have another suggestion for intermediaries?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 11 June 2012 20:03
To: Brian Rosen; [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

Hi,

Regards,

Christer

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2012 21:32:26 +0200

> But as in my view it is an end-to-end header field, I do not envisage any processing in intermediate entities on it.

Here are some excerpts from the text from 3261:

    its agent.

Note "the receiving human *or its agent*".

So this applies in some sense to all the infrastructure associated with 
the callee, such as the called party S-CSCF and APs, and the called 
party P-CSCF.

    For example, it may be factored into decisions about call
    routing and acceptance.

The above seems to have direct bearing on this discussion.

    The Priority header field does not influence the use of
    communications resources such as packet forwarding priority in
    routers or access to circuits in PSTN gateways.

We've already noted this. Resource-Priority would be applicable to these.

    It is RECOMMENDED
    that the value of "emergency" only be used when life, limb, or
    property are in imminent danger.  Otherwise, there are no semantics
    defined for this header field.

This certainly scopes its use in a suitable way.

I'm not convinced that you *want* to bypass *all* services. But I do 
think every service should have a policy of whether and how it applies 
to emergency calls. And very likely many/most of them will have a policy 
of "do not apply" to emergency calls.

The elephant in the room is: what if the caller lies, and tags a call as 
an emergency when it is not? (Since it can be coming from an unreliable 
source.)

In large part, I think this is a risk to be tolerated, unless doing so 
can be demonstrated to cause great harm. So what sort of harm can come 
from this?

- user defined policies, such as various sorts of call diversion,
   might not be honored. But I've suggested that the phone itself
   could have policies to deal with this. E.g. it could refuse the
   call, or treat it with lessened priority, if it isn't "expecting"
   an emergency callback. And conversely, it can give the call
   enhanced priority if it is expecting an emergency call. (E.g. it
   can bypass disabled ringing and use a special ring tone, plus
   vibrate, plus flash, etc.)

   Given these mitigating actions, this doesn't seem to cause great
   harm.

- provider defined policies, carrying out the interests of the
   provider even if not in the interest of the user, might not be
   honored. The most obvious of these might be allowing calls to
   a user that has been "barred" for non-payment. I don't have a
   good answer to this one. Certainly it is a target for fraud.
   But perhaps the solution to this one is legal rather than
   technical. Such calls could be logged, and if a significant
   number of them are noted then action can be taken against the
   caller.

- services that are "transparent" to the call, need not be bypassed
   at all if desired.

	Thanks,
	Paul

> On Jun 6, 2012, at 6:37 AM,<[email-masked]>  <[email-masked]>  wrote:
>
>> Paul, Christer,
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2012 21:32:21 +0200

> Any type of service (diversion is one example) that normally would be applied to the called user. Typically, in IMS, the S-CSCF would not forward a terminating callback requests to Application Serv…

"Any type of service" doesn't do it for me.
Maybe it would if I had a list of the services that are typically 
offered. But I don't.

> The intermediareis must understand the purpose of the incoming call.

Well, if we use the Priority:emergency header, then we know the caller 
asserts its an emergency call. Do you need to know more about the 
purpose of than that?

I'll say more in reply to one of the other messages in this thread.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2012 21:42:53 +0200

> [John Medland] Yes that was the scenario I had in mind.

OK. Then I guessed wrong.

If this is the case you have in mind, then it hardly seems "special" at 
all. How is it different from the police calling the fire department 
emergency number because the police station is on fire?

> [John Medland] Sorry, but not sure what's meant by a "consult"?   May be OK but also needs priority treatment (to indicate dealing with arranging an emergency response).

Well, this was based on a wrong guess by me about what you meant.

I thought that was standard terminology.

In a normal case that means you put one call on hold, and call somebody 
else for a "consultation" - to get info for your first call. Then you 
might decide to either:
- transfer the original caller to the consultant,
   dropping yourself out of the call.

- conference the caller, yourself, and the consultant together.

But in the case of emergency calls I gather psap practices may require 
the original answerer to stay in the call, which would forbid 
forwarding. And forwarding without assuring that the handoff had been 
successfully accomplished would no doubt be forbidden. So establishing a 
conference might be the first step, and then *maybe* the police could 
drop out once it was established that the fire dept had fully taken 
responsibility for the call. In any case, none of this would require a 
callback.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jun 2012 10:43:25 +0200

Hi,

> Maybe it would if I had a list of the services that are typically

At the moment, diversion and call barring are typical examples.

But, there are also services which are typically not enabled during call setup, but for which application servers are still inserted in the call path, in case users would enable the service later. E.g. services that include mid-call network provided anouncements. In the callback case, you want to bypass those application servers.

> asserts its an emergency call. Do you need to know more about the

I think Priority:emergency would be good enough, but Keith's issues seems to be whether the semantics of Priority "allows" intermediaries to use it.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jun 2012 05:19:19 +0200

> But, there are also services which are typically not enabled during call setup, but for which application servers are still inserted in the call path, in case users would enable the service later.…

I guess that's your business. I would think it to be relatively harmless 
to leave them in the path. But as I posted elsewhere, ISTM that this 
should probably be a per-service policy.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jun 2012 08:50:37 +0200

Hi,

>>>>> Can we talk about the specific sorts of services you have in mind? 
>>>>> I suspect that different sorts of treatment may need to be 
>>>>> addressed in different ways.
>>>>
>> But, there are also services which are typically not enabled during call setup, but for which application servers are still inserted in the call path, in case 
>> users would enable the service later. E.g. services that include mid-call network provided anouncements. In the callback case, you want to bypass those application servers.
>
> I guess that's your business. I would think it to be relatively harmless to leave them in the path. But as I posted elsewhere, ISTM that this should probably be a per-service policy.

Yes. And, that's the reason why the caller (the PSAP in this case) doesn't tell how to handle the call. It simply includes the callback indicator, and networks then handle the request (read: give special treatment) based on whatever policies.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jun 2012 22:11:03 +0200

> Yes. And, that's the reason why the caller (the PSAP in this case) doesn't tell how to handle the call. It simply includes the callback indicator, and networks then handle the request (read: give s…

Well, clearly a Priority:emergency header isn't a *callback* indicator.
Its an indicator that the caller considers this an emergency call, 
whether or not its a callback. But its still reasonable to think that 
each service has a policy for what to do in that case.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jun 2012 22:20:14 +0200

Hi,

> each service has a policy for what to do in that case.

Correct.

Regards,

Christer

---

From: <[email-masked]>
Date: Sat, 16 Jun 2012 20:53:50 +0100

Paul - a few more clarifications inserted below.

Best regards

John

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 12 June 2012 20:43
To: Medland,JD,John,MLC12 R
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

If this is the case you have in mind, then it hardly seems "special" at all. How is it different from the police calling the fire department emergency number because the police station is on fire?[John Medland] 

[John Medland] Both cases are dealing with an emergency : I'm concerned to make sure there's a way of indicating this to be so without making another 911/112 call, which invokes other facilities that would not be appropriate (like providing location of the Police PSAP rather than end caller) 

In a normal case that means you put one call on hold, and call somebody else for a "consultation" - to get info for your first call. Then you might decide to either:
- transfer the original caller to the consultant,
   dropping yourself out of the call.

But in the case of emergency calls I gather psap practices may require the original answerer to stay in the call, which would forbid forwarding. And forwarding without assuring that the handoff had been successfully accomplished would no doubt be forbidden. So establishing a conference might be the first step, and then *maybe* the police could drop out once it was established that the fire dept had fully taken responsibility for the call. In any case, none of this would require a callback.

[John Medland] Agreed, and as you say, PSAPs do not put callers on hold, but handoff in such a way that caller has reassurance of hearing what is happening.

	Thanks,
	Paul