[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Preventing unanticipated respondent syndrome when retargeting
Is this any different then 181 Call Is Being Forwarded from RFC3261?
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Dean Willis
Sent: Friday, April 04, 2008 9:30 AM
To: sip at ietf.org List
Subject: [Sip] Preventing unanticipated respondent syndrome when
retargeting
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
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip