headers
Michael Procter | 1 May 2009 13:41
Picon
Favicon

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

Hi,

2009/4/30 Dale Worley <dworley@...>:
> 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
Permalink | Reply | 0 comments |
headers
Michael Procter | 1 May 2009 13:43
Picon
Favicon

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

2009/4/30 Francois Audet <audet@...>:
> 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
Permalink | Reply | 5 comments |
headers
Shida Schubert | 4 May 2009 09:18
Favicon

Re: Comments ondraft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)

Unless the feature is broken to start with without whatever it is
people are claiming is necessary, I would like people to keep
the spec simple so we are more likely to see the spec's adaptation.

.. Focus on basic level of interoperability..

Though that's not to say that we should withhold ourselves
from  adding text describing why the feature currently deployed
out there may be unsafe with some description of what
implementers can do to make it more secure..

Regards
  Shida

On 29-Apr-09, at 10:22 PM, Elwell, John wrote:

> I agree - I would like something to be said about it.
>
> John
>
>> -----Original Message-----
>> From: bliss-bounces@... [mailto:bliss-bounces@...]
>> On Behalf Of Francois Audet
>> Sent: 28 April 2009 16:13
>> To: Michael Procter; Hutton, Andrew
>> Cc: bliss@...; Scott Orton
>> Subject: Re: [BLISS] Comments
>> ondraft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)
>>
>> Basically, I think a CallPark without an autoretrieve is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Orton | 5 May 2009 15:40
Favicon

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

 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scott Orton | 5 May 2009 15:50
Favicon

Re: Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

 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: bliss-bounces@...
[mailto:bliss-bounces@...] On Behalf
Of Michael Procter
Sent: Friday, May 01, 2009 6:44 AM
To: Audet, Francois (SC100:3055)
Cc: bliss@...; Orton, Scott (RICH1:B620)
Subject: Re: [BLISS] Comments
ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

2009/4/30 Francois Audet <audet@...>:
> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dale Worley | 14 May 2009 00:01
Favicon

Re: Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

On Tue, 2009-05-05 at 08:50 -0500, Scott Orton wrote:
> 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. 

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
Permalink | Reply | 0 comments |
headers
Dale Worley | 14 May 2009 00:03
Favicon

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

On Tue, 2009-05-05 at 09:40 -0400, Orton, Scott (RICH1:B620) wrote:
> 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.

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
Permalink | Reply | 0 comments |
headers
Michael Procter | 14 May 2009 08:12
Picon
Favicon

Re: Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

Scott,

Apologies for the delay.

2009/5/5 Scott Orton <orton@...>:
>  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

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
Permalink | Reply | 2 comments |
headers
Scott Orton | 14 May 2009 18:13
Favicon

Re: Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

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:michael@...] 
Sent: Thursday, May 14, 2009 1:13 AM
To: Orton, Scott (RICH1:B620)
Cc: Audet, Francois (SC100:3055); bliss@...
Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

Scott,

Apologies for the delay.

2009/5/5 Scott Orton <orton@...>:
>  Michael,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Procter | 15 May 2009 09:36
Picon
Favicon

Re: Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions)

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane