[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Preventing unanticipated respondent syndrome when retargeting
Dean,
We already have 181 Call is Being Forwarded, which has a very similar
meaning. Of course, we don't specify use of the Contact header field in
that response, but can't we add it?
John
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Dean Willis
> Sent: 04 April 2008 08:30
> 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