Dean Willis wrote:
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,
Indeed -- that's a known limitation. There is a variety of reasons why
derive leaning on backwards routing for a subscription can fail:
UAC is unregistered, UAC has permanent call-forwarding set up, UAC
chose to make itself known as "anonymous", the UAC does support SUB-NOT,
tel-URI is not assignable to the originating UAC, ....
In summary, we gain a good deal of certainty in case it works and that's
it. If it does not work, we know that we don't know, like before.
Actually applicability should have been stated already in the abstract,
that's an important point -- sorry about that.
and that this is the AOR that will be presented in the request as
that of its originator. This is not universally true.
Agreed too, that should be clearly stated under known limitations too.
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.
The point is DERIVE tells you here "we know that we don't know". It
can label the incoming call grey (as opposed to green if it worked)
and leave it to the callee's discretion how to handle it. (deny-all,
deny-this,answer-this,what-have-you).
The 3pcc case you are mentioning is certainly not the only one we
could add to the list of failure reasons mentioned above.
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?
Well -- I don't think this is about us/ietf, it is about the actual users
and deployments choosing how to put things together. In the actual
deployments I'm aware of, non-reverse-routeable URIs are not a concern
for the adopters (except tel URI), unsolicited traffic begins to be.
Obviously, in environments building upon 3pcc, derive can produce little
value.
How the balance develops between UAS users relying on derive-like
mechanisms for "trash separation", and UAC users using it to increase
the chance of their calls to get through -- difficult to say now.
DNS reverse verification has apparently taken off, even though I'm sure
there were similar limitations.
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.
Understanding the known limitations and applicability is for sure one
of the most important pieces here.
-jiri
--
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
