Re: Comment on DERIVE and B2BUAs

On Oct 30, 2008, at 2:43 PM, Jiri Kuthan wrote:
>
> I'm wondering if other WG participants would agree with me that  
> "verifying
> who is sending me this SIP request is who he claims to be in the  
> simplest
> possible way (i.e., without other protocols and infrastructures) by  
> reverse
> lookup" would be an appropriate goal.
>

Leaving aside the question of whether the success of the DERIVE RRC  
answer's the question you've asked above (I don't think it does; it  
merely verifies that the a node reachable at the AOR to which the  
request is attributed has particular knowledge of the SIP request in  
question), let's ask if we understand the unintended consequences.

There are fundamental assumptions in this sort of RRC model that the  
node initiating the dialog request is in fact reachable by some sort  
of AOR, and that this is the AOR that will be presented in the request  
as that of its originator. This is not universally true.

Envision a presence-enabled call controller (PECC) employed by Alice.  
Alice wants to call Bob, whenever Alice and Bob are both on-line.

So PECC subscribes to Alice and Bob.

Eventually Alice and BOb are both on-line, so PECC sets up the call.

What's in the From" going to Bob? It's probably Alice's AOR, as PECC  
is working on her behalf, and there's some reason to think that Bob is  
willing to accept calls from Alice. But PECC cannot REGISTER as Alice,  
for obvious reasons.

Bob uses DERIVE, and sends a SUBSCRIBE to Alice that references the  
dialog that is between PECC and Bob.

Can Alice's UA respond appropriately? I think not.

There are other ways to construct the type of application I'm talking  
about, that might work with DERIVE. Do we want to force a redesign of  
SIP applications so that return-routability to the originating AOR is  
required? This might not be a bad thing, but I think it is a very  
primal thing, and is potentially quite disruptive to application  
scenarios. That might be OK, but we need to understand the  
consequences before we go down that road.

--
Dean




_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip