Subject: Re: [Sipping] "GRUU Issue" thread

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Feb 2005 00:45:16 -0500

inline.

Paul Kyzivat wrote:

> 
> 
> Rohan Mahy wrote:
> 
>> Hi Folks,
>>
>> <chair>
>> Those who are participating in the "GRUU Issue" thread, please try to 
>> keep the following in mind:
>>
>> 1) We started the GRUU work with a set of requirements which are still 
>> in the GRUU document (see Section 11). We had pretty solid consensus 
>> on the requirements for several months, so if you think something is 
>> wrong with the mechanism, please look carefully at the requirements so 
>> we can figure out if a) the proposed GRUU mechanism does not address 
>> an existing requirement, b) the GRUU requirements are missing or 
>> incorrect,  or c) you have additional requirements which is not really 
>> specific to GRUU but doesn't seem to work the way the GRUU mechanism 
>> is specified now.
>>
>> 2) If you think there is problem because of 1b or 1c, it is possible 
>> that your problem/requirements might be out of scope.
> 
> 
> Thanks Rohan.
> 
> I believe the entire thread is postulated on a *potential* *new* 
> requirement. Here is a swag at that requirement:
> 
> REQ 11: When a GRUU is bound to a UA instance that is also bound to an 
> AOR, it SHOULD be possible for a holder of the GRUU to recover the 
> corresponding AOR. (Even if the GRUU binding has been severed, and 
> possibly even if the AOR itself has been undefined.)
> 
> You are right that it is important to nail down whether this is agreed 
> to be a valid new requirement, and whether it can/should be added at 
> this time. The basic justification for this is that there was resistance 
> to using GRUUs (especially in presence tuples) because they lacked this 
> property.

I think Paul has properly worded the requirement.

Do we need it? I think the answer is yes. Without it, we will have 
interactions with other systems that rely on the request-URI for any 
kind of processing; call logs, authorization systems, etc. For example, 
lets say I have a feature that prevents me from making outbound calls to 
a 900 number. I call bob. Bob calls that 900 number (as he has no such 
restriction), and then transfers me to it.

With this requirement, the proxy providing the outbound screening can 
know that the call is being initiated to this 900 service via a transfer 
or some kind of reference provided by someone else, and can allow or 
block it based on policy. Without this, the gruu effectively provides an 
anonymization service, thus allowing the call to proceed even though it 
should have perhaps been prevented.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 1 Feb 2005 04:13:51 -0800

inline (as an individual)

On Jan 31, 2005, at 21:45, Jonathan Rosenberg wrote:

> inline.
>
> Paul Kyzivat wrote:
>
>> Rohan Mahy wrote:
>>> Hi Folks,
>>>
>>> <chair>
>>> Those who are participating in the "GRUU Issue" thread, please try 
>>> to keep the following in mind:
>>>
>>> 1) We started the GRUU work with a set of requirements which are 
>>> still in the GRUU document (see Section 11). We had pretty solid 
>>> consensus on the requirements for several months, so if you think 
>>> something is wrong with the mechanism, please look carefully at the 
>>> requirements so we can figure out if a) the proposed GRUU mechanism 
>>> does not address an existing requirement, b) the GRUU requirements 
>>> are missing or incorrect,  or c) you have additional requirements 
>>> which is not really specific to GRUU but doesn't seem to work the 
>>> way the GRUU mechanism is specified now.
>>>
>> REQ 11: When a GRUU is bound to a UA instance that is also bound to 
>> an AOR, it SHOULD be possible for a holder of the GRUU to recover the 
>> You are right that it is important to nail down whether this is 
>> agreed to be a valid new requirement, and whether it can/should be 
>> added at this time. The basic justification for this is that there 
>> was resistance to using GRUUs (especially in presence tuples) because 
>> they lacked this property.
>
> kind of processing; call logs, authorization systems, etc. For 
> example, lets say I have a feature that prevents me from making 
> outbound calls to a 900 number. I call bob. Bob calls that 900 number 
> (as he has no such restriction), and then transfers me to it.
>
> know that the call is being initiated to this 900 service via a 
> transfer or some kind of reference provided by someone else, and can 
> allow or block it based on policy. Without this, the gruu effectively 
> provides an anonymization service, thus allowing the call to proceed 
> even though it should have perhaps been prevented.

I am a bit dubious that we need this requirement.  I think in fact that 
its use may be dangerous to REFER which I consider the original 
motivator for the GRUU work, going back to the 1st SIP interim in Las 
Vegas.

In the use case that JDR mentions here, the underlying reason folks 
block 900 services in the US (and comparable special toll numbers in 
the rest of the world) is because of some billing issue (calls to these 
numbers cost [more] money).  If Bob calls a 900 number and therefore 
selects a gateway of his choosing and then transfers me to that 
gateway, he is providing me with a SIP URI corresponding to a call he 
already made on a gateway that I may not have credentials with.  If the 
service maintains a billing model similar to PSTN call forwarding and 
call forwarding/transfer billing with a PBX, Bob will continue to pay 
for the call to the 900 service. I am just calling a SIP URI provided 
to me by Bob.  If Bob really wants me to call a 900 number on the PSTN 
using a gateway of *my* choosing, then I fell he should redirect or 
refer-to a tel URL.  My UA and/or proxy will use different 
authorization rules for the tel URI.

To be clear, I don't think the 900 number is an AOR, and therefore 
wouldn't really be helped by this requirement.  The motivation behind 
900 blocking is avoiding absurd costs, not an underlying requirement to 
control which parties you reach.

thanks,
-rohan

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 01 Feb 2005 09:55:42 -0800

Paul's Requirement is not a requirement, it is more or less a mechanism.
What is the requirement for this?

If we are going to argue it is needed for billing - well then we need to
start with the requirements for billing and I would not want to hold up GRUU
for figuring out sip billing. The desired behavior billing during a transfer
has always been complicated in all protocols. I seems to me that either of
the solutions being discussed here will not make billing any easier or
harder. 

More inline....

> restriction), and then transfers me to it.

Can you get specific about what you are talking about here. Are you saying
the proxy blocks requests where the request URI is say tel:+1-900* or the
sip equivalent? If so I don't see how this has any bearing on what is in the
To header.

> should have perhaps been prevented.

Does your proxy block you getting on a conference with someone who
conferences in a 900 number? I think you are trying to solve an impossible
problem here. Consider a GW to be a conference focus with two call legs, if
a UA replaces one of the call legs with a REFER/Replaces, it has no idea
what is on the other call leg. Keep in mind this has nothing to do with
calling a 900 number, if I was going to call a 900 number, I might use a
different GW and I might end up talking to a complete different person that
answered the 900 call.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2005 13:11:14 -0500

> What is the requirement for this?

I think it is a plausible requirement on GRUU as written. It is a 
mechanism requirement because GRUU itself is a mechanism requirement. So 
yes, perhaps there is a need for a meta-requirement too. But I don't 
know where that would go - its not clear it belongs in the GRUU draft.

> the solutions being discussed here will not make billing any easier or

I don't think the meta requirement is about billing. The simplest way of 
stating that requirement is in the title of the original thread - "Who 
did I call?". It might also be broadened to include "Who am I calling?".

And I do believe the meta requirement can probably be solved with 
mechanisms other than GRUU changes. But a change to GRUU *might* be a 
good solution - we need to figure that out.

	Paul