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
