Re: [Sip] Preventing unanticipated respondent syndrome when retargeting

[Bob Penfield <BPenfield at acmepacket.com>]

I think this could mess up User Agents that do not understand the new response code and treat it like any other 1xx. In this situation, the Proxy is acting as the UAS for the 121 response, and RFC 3261 requires that it have a to-tag. The UAC will create an dialog for the 121 response.

The problem is that the Contact does not meet the criteria required for a provisional response in that it does not reach the UAS (the Proxy) that established the dialog.

What will happen to any in-dialog requests sent by the UAC on the early dialog?

cheers,
(-:bob

-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Dean Willis
Sent: Friday, April 04, 2008 3: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