Subject: [Geopriv] Transferring a call with Geolocation

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 26 Jul 2013 16:08:46 +0000

Suppose a call with a Geolocation header on it lands at some UAS (say, for example, a PSAP call taker) and the UAC wishes to transfer the call to someone else with the location of the caller.

If it's an attended transfer, the transfer sequence involves several SIP transactions with a bridge.  Where would the Geolocation header be put?  

Can it go on the REFER to the bridge so the bridge knows the location?
Can the bridge put it on the INVITE to the bridge?

In both of those cases, the target would have no relationship whatsoever to the UAC.  It's the location of the original caller.

For the example case of the PSAP, you really would not want it to be as late as the final INVITE/Replaces that ends the transfer (off of the bridge to a 2 way between transferee and transfer target).

Or maybe that really is a bad idea altogether, and we should have another way to inform the transfer target of the location of the caller, since at no time is the caller sending its location to the transfer target.

The latter is my conclusion, but others think it's perfectly okay to include it as an escaped header in the REFER that results in it being in the INVITE from the bridge.

Brian

---

From: Richard Barnes <[email-masked]>
Date: Fri, 26 Jul 2013 14:28:51 -0400

Could you perhaps elaborate on the call flow you're envisioning?

On Fri, Jul 26, 2013 at 12:08 PM, Rosen, Brian <[email-masked]>wrote:

> Suppose a call with a Geolocation header on it lands at some UAS (say, for
> example, a PSAP call taker) and the UAC wishes to transfer the call to
> someone else with the location of the caller.
>
> If it's an attended transfer, the transfer sequence involves several SIP
> transactions with a bridge.  Where would the Geolocation header be put?
>
> In both of those cases, the target would have no relationship whatsoever
> to the UAC.  It's the location of the original caller.
>
> For the example case of the PSAP, you really would not want it to be as
> late as the final INVITE/Replaces that ends the transfer (off of the bridge
> to a 2 way between transferee and transfer target).
>
> Or maybe that really is a bad idea altogether, and we should have another
> way to inform the transfer target of the location of the caller, since at
> no time is the caller sending its location to the transfer target.
>
> The latter is my conclusion, but others think it's perfectly okay to
> include it as an escaped header in the REFER that results in it being in
> the INVITE from the bridge.
>
> Brian
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: James Polk <[email-masked]>
Date: Fri, 26 Jul 2013 14:01:57 -0500

BRian

I'm trying to work through what you want...

   Alice              PSAP             PSAP             Transfer
                   ESRP/B2BUA        Call Taker          Target
     |                 |                 |                 |
     | INV (w/Alice's Geo)               |                 |
     |---------------->|                 |                 |
     |                 |INV (w/Alice's Geo)                |
     |                 |---------------->|                 |
     |                 |200 OK           |                 |
     |                 |<----------------|                 |
     | 200 OK          |                 |                 |
     |<----------------|                 |                 |
     | ACK             |                 |                 |
     |---------------->|                 |                 |
     |                 | ACK             |                 |
     |                 |---------------->|                 |
     |                RTP                |                 |
     |<=================================>|                 |
     |                 |                 |                 |
     |                 | REFER (Refer-to: Transfer Target and 
Require: Geolocation)
     |                 |<----------------|                 |
     | REFER (Refer-to: Transfer Target and Require: Geolocation)
     |<----------------|                 |                 |
     | 200 OK (REFER)  |                 |                 |
     |---------------->|                 |                 |
     |                 | 200 OK (REFER)  |                 |
     |                 |---------------->|                 |
     | NOTIFY          |                 |                 |
     | 200 OK (NOTIFY) |                 |                 |
     |                 |                 |                 |
     | INVITE (Alice's Geo)              |                 |
     |---------------->|                 |                 |
     |                 | INVITE (Alice's Geo)              |
     |                 |---------------------------------->|
     |                 |                 |                 |
            Scenario 1. Geolocation goes in REFER

The major downfall to scenario 1 is we would be forcing Alice's UA to 
be a media mixer in a 3-way adhoc conference (because you stipulate 
attended transfer which means the original PSAP call take is never 
put on HOLD, and remains actively on the call).

or

   Alice              PSAP             PSAP             Transfer
                   ESRP/B2BUA        Call Taker          Target
     |                 |                 |                 |
     | INV (w/Alice's Geo)               |                 |
     |---------------->|                 |                 |
     |                 |INV (w/Alice's Geo)                |
     |                 |---------------->|                 |
     |                 |200 OK           |                 |
     |                 |<----------------|                 |
     | 200 OK          |                 |                 |
     |<----------------|                 |                 |
     | ACK             |                 |                 |
     |---------------->|                 |                 |
     |                 | ACK             |                 |
     |                 |---------------->|                 |
     |                RTP                |                 |
     |<=================================>|                 |
     |                 |                 |                 |
     |                 | REFER           |                 |
     |                 |<----------------|                 |
     |                 |                 |                 |
     |               what's next?        |                 |

            Scenario 2. Geolocation goes (where else?)

I'm not sure where else you can have it that makes sense. I think you 
are assuming that Alice never sees another transaction wrt this call, 
but how else do we identify a location as "Alice's location" and not 
the "transferor's location" (because that can be of value in some cases?

At 11:08 AM 7/26/2013, Rosen, Brian wrote:
>Suppose a call with a Geolocation header on it lands at some UAS 
>(say, for example, a PSAP call taker) and the UAC wishes to transfer 
>the call to someone else with the location of the caller.
>
>If it's an attended transfer, the transfer sequence involves several 
>SIP transactions with a bridge.  Where would the Geolocation header be put?
>
>In both of those cases, the target would have no relationship 
>whatsoever to the UAC.  It's the location of the original caller.
>
>For the example case of the PSAP, you really would not want it to be 
>as late as the final INVITE/Replaces that ends the transfer (off of 
>the bridge to a 2 way between transferee and transfer target).
>
>Or maybe that really is a bad idea altogether, and we should have 
>another way to inform the transfer target of the location of the 
>caller, since at no time is the caller sending its location to the 
>transfer target.
>
>include it as an escaped header in the REFER that results in it 
>being in the INVITE from the bridge.
>
>Brian
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 26 Jul 2013 19:21:39 +0000

You use a bridge.  Start with a 2 way between caller and PSAP, then:
1.     PSAP creates a conference on the bridge (INVITE)
2.     PSAP REFERs the caller to the bridge (REFER/Replaces to bridge, INVITE/Replaces from bridge to target)
3.     PSAP tears down the original PSAP-Caller leg (BYE)
4.     PSAP REFERs transfer target (secondary PSAP for example) to the conference (REFER to bridge, INVITE from bridge to transfer target)
5.     PSAP tears down its leg to the conference, the secondary PSAP and the caller remain (BYE)
6.     Secondary PSAP REFERs the caller to it (REFER/Replaces to caller, INVITE/Replaces from caller to transfer target
7.     Secondary PSAP terminates the conference.

The caller will have media to him muted for step 4.  Very often the SBC/B3BUA would actually be the REFER actor - the caller won't see any it.

I have detailed call flows if they would be helpful.

Brian

The question is how the transfer target gets the location of the caller.
On Jul 26, 2013, at 3:01 PM, James Polk <[email-masked]> wrote:

>    |                 | REFER (Refer-to: Transfer Target and Require: Geolocation)
>    |                 |<----------------|                 |
> The major downfall to scenario 1 is we would be forcing Alice's UA to be a media mixer in a 3-way adhoc conference (because you stipulate attended transfer which means the original PSAP call take is never put on HOLD, and remains actively on the call).
> 
> or
> 
>  Alice              PSAP             PSAP             Transfer
> I'm not sure where else you can have it that makes sense. I think you are assuming that Alice never sees another transaction wrt this call, but how else do we identify a location as "Alice's location" and not the "transferor's location" (because that can be of value in some cases?
> 
>

---

From: James Polk <[email-masked]>
Date: Sat, 27 Jul 2013 00:49:09 -0500

>1.     PSAP creates a conference on the bridge (INVITE)

Now I get your context of a bridge. I should think that one would be 
easy to convey the meaning of, and gather (i.e., write) a standard 
(lowercase "s") practice of doing this operation. Do we need or want 
to write it down in a draft? Does that draft need to progress to an 
I-RFC, kinda like RFC 3665?

James

>2.     PSAP REFERs the caller to the bridge (REFER/Replaces to 
>bridge, INVITE/Replaces from bridge to target)
>4.     PSAP REFERs transfer target (secondary PSAP for example) to 
>the conference (REFER to bridge, INVITE from bridge to transfer target)
>6.     Secondary PSAP REFERs the caller to it (REFER/Replaces to 
>caller, INVITE/Replaces from caller to transfer target
>The caller will have media to him muted for step 4.  Very often the 
>SBC/B3BUA would actually be the REFER actor - the caller won't see any it.
>
> > The major downfall to scenario 1 is we would be forcing Alice's 
> UA to be a media mixer in a 3-way adhoc conference (because you 
> stipulate attended transfer which means the original PSAP call take 
> is never put on HOLD, and remains actively on the call).
> >
> > or
> >
> >  Alice              PSAP             PSAP             Transfer
> > I'm not sure where else you can have it that makes sense. I think 
> you are assuming that Alice never sees another transaction wrt this 
> call, but how else do we identify a location as "Alice's location" 
> and not the "transferor's location" (because that can be of value 
> in some cases?
> >
> >
> (say, for example, a PSAP call taker) and the UAC wishes to 
> transfer the call to someone else with the location of the caller.
> >>
> >> If it's an attended transfer, the transfer sequence involves 
> several SIP transactions with a bridge.  Where would the 
> Geolocation header be put?
> >>
> >> For the example case of the PSAP, you really would not want it 
> to be as late as the final INVITE/Replaces that ends the transfer 
> (off of the bridge to a 2 way between transferee and transfer target).
> >>
> >> Or maybe that really is a bad idea altogether, and we should 
> have another way to inform the transfer target of the location of 
> the caller, since at no time is the caller sending its location to 
> the transfer target.
> >>
> >> The latter is my conclusion, but others think it's perfectly 
> okay to include it as an escaped header in the REFER that results 
> in it being in the INVITE from the bridge.
> >>
> >> Brian
> >>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Jul 2013 08:53:46 +0000

You do the transfer this way so you always have the caller audio/video/text open to the call taker (you mute the media towards the caller in step6).  It's documented in the NENA/EENA standards.  Not sure it needs an RFC.

However, I do need to decide how to transfer the location.

If it makes sense for the bridge to send the location of the caller in step 6 using Geolocation, we can do that.  We have another way - we have a data structure called an EIDD (Emergency Information Data) which explicitly has a location of the caller element (as a PIDF-LO) in it.  It's used to send what one agency knows about an incident to another.  We send it with a Call-Info.  We can use that.  It's a bit odd to use it in a slightly different scenario where ALL calls are answered at a bridge.   Some implementations do this.  They have the call logger on the bridge and they add and delete other legs to the bridge as the call progresses.  It has some advantages and some disadvantages, but it's a common way to handle a PSAP.  In that scenario, the bridge would have to create an EIDD as the way to send the location of the caller to the PSAP for the initial call.  Not a huge problem, but not quite as obvious as just including the Geolocation header in that INVITE leg from bridge to call taker.

Brian

On Jul 27, 2013, at 1:49 AM, James Polk <[email-masked]> wrote:

> Now I get your context of a bridge. I should think that one would be easy to convey the meaning of, and gather (i.e., write) a standard (lowercase "s") practice of doing this operation. Do we need or want to write it down in a draft? Does that draft need to progress to an I-RFC, kinda like RFC 3665?
> 
> James
>