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

["Scott Orton" <[e-mail]>]

 Dale,
   I agree that if we use the temporary GRUU it will work. But my
concern is that we are now adding another requirement to the draft. If a
UA is requesting privacy either from its Proxy or by itself then they
have to also support draft-ietf-sip-gruu. Where making a simple change
to parking the call will work for all scenarios without causing another
draft to be implemented.

If the Refer is sent to the party being parked there is no need for a
special contact.  But both can be handled without a change to a client.
In addition the client does not even have to know that it is being
parked. 

Sending the Refer to the client means that any client that supports
Refer can support being parked. I think we are adding complications by
requiring that a client support the draft-ietf-sip-gruu draft in order
to be parked.

To me Parking a call should require no development on the client being
parked since we do not want the functionality of the call park to be
dependant on the party being parked. As I do not necessarily control the
client being parked, I have no way of enforcing what that client
implements. If a user from the Yahoo domain calls a user in the Example
domain. The user in the Example domain needs to be able to park a call
from the user in the Yahoo domain. But I as a user in the example domain
will have no control over the clients in the Yahoo domain. 

I really think it will be a mistake to try to enforce another draft as a
requirement to park a call. If the parking user subscribes to the dialog
event for calls that it parks then the park server could deliver the
orbit to the parking party. 

In this way there is no need for the parked client to support any
particular draft except for Refer. 

Scott  

-----Original Message-----
From: Worley, Dale (BL60:9D30) 
Sent: Thursday, April 30, 2009 4:30 PM
To: Orton, Scott (RICH1:B620)
Cc: Michael Procter; Audet, Francois (SC100:3055); [e-mail]
Subject: Re: Comments on
draft-procter-bliss-call-park-extension-04(Privacy Interactions)

On Tue, 2009-04-28 at 17:22 -0400, Orton, Scott (RICH1:B620) wrote:
> 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:[e-mail].
> 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