I define "unanticipated respondent syndrome" as the sense of surprise Alice gets when she calls Bob, only to have the call answered by Charlie. This is especially problematic if the sorts of security operations that depend on Alice having some sort of keying relationship with Charlie become important.
Alice is expecting: Alice--1-->Proxy--2-->Bob but instead she gets: Alice--1-->Proxy--2-->Charlie because Bob forwarded his phone to Charlie, or because Charlie, who is authorized to do so, registered as a contact for Bob, and Bob didn't answer (or has a lwoer qvalue, or whatever) RFC 4916 lets Alice find out who answered the phone in the most difficult of cases, and other techniques like P-Asserted-Identity in a response address simpler cases (or we can use endpoint- asserted RFC 4474 Identity when the keys are known or discoverable). So that's not a problem. Alice can figure out that she's talking to Charlie, once they get connected. The only problem is cluing in Alice that she's about to be talking to Charlie instead of Bob. In the cases I've identified above, the proxy knows that it is retargeting the request to Charlie, not rerouting the request to Bob. How does it know this? It either a) knows that the Call Forwarding feature has been activated, and that's always a retarget, or b) knows that the contact for Bob was registered by Charlie, who isn't Bob (but that Charlie is authorized to register for Bob's AOR). In fact, if this the case, it knows both Charlie's authentication identity and his contact. Since the proxy knows, it should be able to inform Alice. I therefore propose a provisional response from Proxy to Alice, which I'll provisionally call "121 (Retargeting)" A proxy executing a retargeting operation (by which we mean an operation that replaces the request URI such that the authenticated identity of the new request URI is different from the authenticated identity of the old one) SHOULD return a 121 (Retargeting) provisional response. The 121 response contains a Contact header field, the value of which is the new identity being targeted. Optionally, we might include some sort of "cause" parameter, explaining why the request is being retargeted (like "Bob's dead, talk to Charlie"). If a proxy doesn't know whether it is rerouting or retargeting, it SHOULD assume that it is retargeting, and send the appropriate 121 response. In conclusion, this preserves the proxy-mediated functionality required for draft-ietf-sip-outbound, while giving us the I-know-who-I- expect-to-reach function of a 302 (Redirect). Yeah, this should be an I-D. I'm now accepting volunteer co-authors to do the dirty work, assuming this idea gets any traction. -- 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
