Subject: [BLISS] Comments on draft-procter-bliss-call-park-extension-04 (Privacy Interactions)

From: "Scott Orton" <[email-masked]>
Date: Tue, 28 Apr 2009 16:22:09 -0500

Michael,
   I have been thinking about how call park and privacy interact. I
think there is an issue with the parking and retrieval of a call when
the user that is being parked has applied privacy in the initial call. 

Lets take for example a case where Alice calls bob. Alice is using
privacy as defined in RFC 3325. In this case the from header and the
contact for Alice will anonymous. The contact is likely just an IP
address and the from header will be sip:[email-masked]. The
contact header being an IP address is enough to exchange messages in a
dialog but is unlikely to be enough to route a new call to the Alice. If
it was enough then you privacy is not very good as nothing is preventing
the user from returning a private call. 

So when a Refer is generated to the Call park server the referTo in the
Refer will not be routable. 

I really want to be able to park a call with an anonymous originator.
The only way that I can see to reliably do this it to Refer Alice to the
callpark server rather than send a unsolicited Refer to the call park
server.  This also leads to an interesting scenario. If the call park
server and Alice's proxy which is applying privacy for her are the same
server. Then once the call is parked the CallPark server has to be sure
to apply privacy to the dialog notify that it sends back to Bob. The
other issue this brings up is that we may want to specify that the
Notify for the Refer needs to include the orbit parameter in the contact
in the case that Alice is referred to the callpark server. 

So the question is do we want to have two call flows to park a call one
to the park server and one to the client being parked. I think it is
better to settle on one and in order to support parking a call with
privacy enabled I think the flow needs to show the Refer going to the
client being parked. 

Of course if we go with this flow there is now an issue of how to
retrieve the parked call. Since the call is private there is no way to
send an Invite with replaces back to  Alice to retrieve the call. One
solution to this would be for the callpark server to act as a Third
party call control device and in the park dialog event specify itself in
the dialog event. Then when the call is attempted to be retrieved the
Invite would go to the call park server. It could then either send a
Refer to the parked call to connect it to the retrieving party or act as
a BBUA and send a reinvite to the parked party with the SDP of Bob's
retrieving request.

As an example of why this is necessary, lets take a real world example
of a car dealership. A call comes in for the sales floor from an
anonymous caller. The attendant answering the call needs to be able to
park the call and let a salesman retrieve the call. 

I can provide call flows. But I have not had a chance to work them up. 

Scott

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 30 Apr 2009 17:30:03 -0400

On Tue, 2009-04-28 at 17:22 -0400, Orton, Scott (RICH1:B620) wrote:
> address and the from header will be sip:[email-masked].
> The contact header being an IP address is enough to exchange messages
> in a dialog but is unlikely to be enough to route a new call to the
> Alice. If it was enough then you privacy is not very good as nothing
> is preventing the user from returning a private call. 

If you want to use anything approaching "endpoint call control", that
is, anything more complex than an in-dialog REFER, then the anonymized
Contact has to route to Alice, or rather, the privacy service fronting
for Alice.  So it would have to be similar to a "temporary GRUU" (see
draft-ietf-sip-gruu-15), a URI which is secretly mapped to a unique
target but for only a limited time.

But assuming that the privacy service can provide such Contacts, I think
the proposed parking method (out-of-dialog REFER sent to the Park Server
so that it sends INVITE-with-Replace to the caller) should work.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 30 Apr 2009 16:32:53 -0500

Why do we send the REFER to the Park server (to replace the call to the other user),
as opposed to sending the REFER to the other user to direct him/her to the Park 
server? 

> -----Original Message-----
> From: Worley, Dale (BL60:9D30) 
> Sent: Thursday, April 30, 2009 14:30
> To: Orton, Scott (RICH1:B620)
> Cc: Michael Procter; Audet, Francois (SC100:3055); [email-masked]
> Subject: Re: Comments on 
> draft-procter-bliss-call-park-extension-04(Privacy Interactions)
> 
> If you want to use anything approaching "endpoint call 
> control", that is, anything more complex than an in-dialog 
> REFER, then the anonymized Contact has to route to Alice, or 
> rather, the privacy service fronting for Alice.  So it would 
> have to be similar to a "temporary GRUU" (see 
> draft-ietf-sip-gruu-15), a URI which is secretly mapped to a 
> unique target but for only a limited time.
> 
> But assuming that the privacy service can provide such 
> Contacts, I think the proposed parking method (out-of-dialog 
> REFER sent to the Park Server so that it sends 
> INVITE-with-Replace to the caller) should work.
> 
> Dale
> 
> 
>