> 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.
Agreed. But in order for me to get a postmark that says "San Jose", I need to drop my mail into a San Jose post office. And if you see my package arrive with my San Jose address, but you see a Wasila, Alaska postmark, you might be more suspicious about it than usual. > 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. You're right. (I might wonder aloud how well all of SIP's features work with 3rd party call control. But we know the answer is "not all".) I will note that for RFC4474 to operate in that same scenario, PECC would need to be inside of Alice's domain (in order that Alice's domain creates the necessary RFC4474 signature over the [spoofed] INVITE emitted by PECC). > 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. I'm just desiging in this email, but it may well be sufficient, for the case you describe above (and maybe others?) if PECC were to inform Alice of the impending automated call to Bob. Alice would probably want to know this, anyway. Afterall, seeing or hearing "Bob is online right now; initiating call" and seeing or hearing call progress indications is more reasonable than Alice suddenly hearing Bob's voice saying "Hi, Alice, it's good you called me. Let's talk about the weather." Such a notification to Alice could be as straightforward as the PECC sending Alice a NOTIFY, so that when Alice receives the RRC message (e.g., [INFO|SUBSCRIBE|OPTIONS]), she has the necessary dialog information to respond correctly to the RRC. -d _______________________________________________ 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
