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); [email protected] 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:[email protected]. > 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 _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
