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 2009/5/14 Scott Orton <[email protected]>: > 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 protected]] > Sent: Thursday, May 14, 2009 1:13 AM > To: Orton, Scott (RICH1:B620) > Cc: Audet, Francois (SC100:3055); [email protected] > Subject: Re: [BLISS] Comments > ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) > > Scott, > > Apologies for the delay. > > 2009/5/5 Scott Orton <[email protected]>: >> 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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
