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

From: Michael Procter <[email-masked]>
Date: Fri, 1 May 2009 12:41:30 +0100

Hi,

2009/4/30 Dale Worley <[email-masked]>:
> 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.
>

As Dale notes, this isn't a call-park specific problem, but a more
generic call control problem.  And he also notes that Alice should
implement temporary GRUUs or some similar feature.  These sorts of
issues are discussed more fully in draft-ietf-sip-ua-privacy-09, and a
UA hoping to achieve private operations should consider the mechanisms
discussed in there to achieve it.

Michael

---

From: Michael Procter <[email-masked]>
Date: Fri, 1 May 2009 12:43:51 +0100

2009/4/30 Francois Audet <[email-masked]>:
> 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?

Section 2 of my draft discusses this.  Here is an extract:

   By following the Call Park model, we ensure that Bob has visibility
   over the success or failure of the park attempt.  We also ensure that
   Bob does not rely on Alice to correctly pass the orbit parameter back
   from the Park Server for the centrally-allocated orbit number
   situation.  Finally, because Bob sends the REFER to the Park Server,
   we give the Park Server the opportunity to challenge Bob and ensure
   that appropriate authorisation exists for the feature.

Michael

---

From: "Scott Orton" <[email-masked]>
Date: Tue, 5 May 2009 08:40:49 -0500

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-masked]
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-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.

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: "Scott Orton" <[email-masked]>
Date: Tue, 5 May 2009 08:50:23 -0500

Michael,
   Can this also be addressed by subscribing to the dialog event? We
might want to specify in a subscription to the dialog event that we want
to be informed of any call parked by the subscribing user. This is a
change from the current draft and would require a new uri parm in the
Subscription. This way we can send the refer to the party being parked
instead of using the unsolicited refer. 

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Michael Procter
Sent: Friday, May 01, 2009 6:44 AM
To: Audet, Francois (SC100:3055)
Cc: [email-masked]; Orton, Scott (RICH1:B620)
Subject: Re: [BLISS] Comments
ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

2009/4/30 Francois Audet <[email-masked]>:
> 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?

Michael
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 13 May 2009 18:01:27 -0400

> instead of using the unsolicited refer. 

That would require extending the dialog event specification, and require
the executing phone and the park server to support that extension.

It would also not quite work, since there might be two calls from the
same subscriber being parked on the same park server at the same time.  

A better approach would be for the calling phone to send, in its NOTIFYs
for the REFER-created subscription, not just the status lines but also
the To, From, and Call-Id headers.  Then the executing phone would know
the dialog identifiers of the parked call dialog.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 13 May 2009 18:03:25 -0400

> to parking the call will work for all scenarios without causing another

In the sipX project, which is a non-centralized PBX system, our
experience is that having proper Contact addresses is mandatory for most
sophisticated call-control activities.  The project hasn't addressed
sophisticated privacy questions at all.  So we are already expecting
that all UAs will support "public GRUUs", and from that point of view,
we don't see it as burdensome to expect that a UA that supports proper
privacy (and the proxy that fronts for it) also supports "temporary
GRUUs".  We expect that to be the least of the tasks needed to support
proper privacy.

The benefit of the current draft's signaling flow is that it allows an
extremely clever way of having a park server that assigns park orbits to
transmit the orbit identifier to the executing UA.

Dale

---

From: Michael Procter <[email-masked]>
Date: Thu, 14 May 2009 07:12:31 +0100

Scott,

Apologies for the delay.

> instead of using the unsolicited refer.

As Dale has just pointed out, it won't work without extensions to the
dialog event package and/or changes to the parked UA.  Since all this
is to work around a parked UA that doesn't provide a usable contact,
it seems that putting more requirements on it is unlikely to make the
problem better!

On balance, I think we are better off staying with the approach in the
draft.  I will be updating the draft shortly, in light of the comments
raised (I am waiting for one last set of comments offlist).

Regards,

Michael

---

From: "Scott Orton" <[email-masked]>
Date: Thu, 14 May 2009 11:13:37 -0500

Michael,
   I think we are making a mistake in relying on the temporary GRUU draft to handle privacy. There are way too many clients and Gateways already in the field that will not be following this draft. I think this is going to cause issues in deployments where there are older clients already in the field as we will not be able to park these existing deployments if they have privacy enabled. 

If the major concern is the concern is making extensions to the Dialog event package then maybe the solution is to create a Callpark event package. 

I realize that I seem to hold the minority opinion on interacting with clients and privacy, so at a minimum can we add a section on the issues with private clients and routing and the recommendation that all clients in the network have to support draft-ietf-sip-gruu-15 or there will be park failures.

I can write up the issues if that would help. 

Scott

-----Original Message-----
From: Michael Procter [mailto:[email-masked]] 
Sent: Thursday, May 14, 2009 1:13 AM
To: Orton, Scott (RICH1:B620)
Cc: Audet, Francois (SC100:3055); [email-masked]
Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

Scott,

Apologies for the delay.

2009/5/5 Scott Orton <[email-masked]>:
> might want to specify in a subscription to the dialog event that we 
> want to be informed of any call parked by the subscribing user. This 
> is a change from the current draft and would require a new uri parm in 
> the Subscription. This way we can send the refer to the party being 
> parked instead of using the unsolicited refer.
>
> Scott

As Dale has just pointed out, it won't work without extensions to the dialog event package and/or changes to the parked UA.  Since all this is to work around a parked UA that doesn't provide a usable contact, it seems that putting more requirements on it is unlikely to make the problem better!

On balance, I think we are better off staying with the approach in the draft.  I will be updating the draft shortly, in light of the comments raised (I am waiting for one last set of comments offlist).

Regards,

Michael

---

From: Michael Procter <[email-masked]>
Date: Fri, 15 May 2009 08:36:14 +0100

Scott,

I think we may be getting hung up on the 'must support GRUU' part.
Let's quickly review the scenario that is causing problems.

Alice calls Bob, and Bob tries to park the call at the park server.
The problem occurs when Alice provides a Contact URI that is not
usable outside the context of the dialog to Bob.  This may occur for a
number of reasons, including Alice's UA being broken and Alice's UA
attempting to remain private.  As others have pointed out, this
behaviour will cause problems with a number of features, and not just
call park.

My response, which appears to have been echoed by others on this list,
is that a UA attempting to remain private should consider
draft-ietf-sip-ua-privacy.  This gives guidance on how to achieve a
degree of privacy whilst still providing a usable contact, using
temp-gruus.  This is the 'correct' approach within the context of a
'normal' SIP trapezoid configuration.  Not all deployments are like
this of course!

Many deployments use B2BUAs, in various guises (e.g. App Servers and
SBCs).  One function that they often perform is to ensure that
external traffic does not contain any local IP addresses, by removing,
obscuring or changing any occurrences into global IP addresses,
typically pointing to themselves.  In this way, contact URIs are
'corrected' so that they are globally routable, and so will work in
our particular scenario.

Ultimately, we need to assume a certain base level of functionality in
Alice's UA.  I want to assume a valid contact URI, and the ability to
handle INVITE/replaces.  You indicate you would prefer to assume
in-dialog REFER handling, and the ability to round-trip extra
information in the corresponding NOTIFYs (specifically the park
server's contact, which will contain the orbit).

In passing, I note that under your approach, the Park Server must be
reachable by external callers, and that the orbit needs to be
protected/encrypted to prevent some entertaining 'social engineering'
attacks.  These are not unresolvable issues, but would need to be
addressed.

It is my belief that the the requirements on Alice that the draft
assumes are more easily achieved, and are in fact already achieved in
many situations.  In particular, no additional requirements are needed
over and above those for (for example) directed pickup.

It is also my belief that the requirements of your approach are not
currently met anywhere (because we haven't defined what we need to
round-trip the orbit securely), and are also specific to call park.
Therefore, I suspect that there would be slower take-up of such an
approach, which will lead to poorer interoperability.

If I have mis-represented your thoughts in the above, please correct me.

Best regards,

Michael