From: "=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=" <[EMAIL PROTECTED]>
> In any case, for the purposes of DERIVE, none of that matters: > Any failure response to the SUBSCRIBE, or a NOTIFY that does not > list the call in question, results in call rejection. But this behaviour would deny calls from devices not supporting RFC4235 (receiving a SUBSCRIBE Event: dialog).AFAIK this draft says that if the SUBSCRIBE is replied with 200 thenthe dialog exists and identity verified, if 481 then the devicesupports RFC 4235 and it's a suspicius call, and for any other failureroute it could mean that the device doesn't support RFC 4235 or anykind of "protection" in an intermediary proxy. In the last case, thereceptor of the INVITE should choose to accept or deny the call, hecannot know if the sender is really the From (or if he is not). In my experience, it's very difficult to accurately distinguish between "authentication mechanism is not supported by the correspondent" and "authentication mechanism denies the correspondent's identity". The only cases where that distinction can be made accurately are where both ends of the communication specifically signal the presence/absence of the authentication mechanism. In the case of DERIVE, the goal is for the recipient to be able to authenticate the caller in a large fraction of cases without requiring the caller to specifically implement a mechanism to do so. Given the high variability of SIP implementations, one cannot reliably impute meanings to failure response codes. I would expect that many SIP implementations would not handle Event parameters (filtering) correctly, and would just return all dialogs present at the UAC. So the UAS will have to inspect the event body to see if its dialog is listed. Dale _______________________________________________ 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
