Re: [Sip] [RFC 4235 & draft-kuthan-sip-derive] 481 "Call doesn't exist" for initial SUBSCRIBE ?

[Dale.Worley at comcast.net]

   From: "=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=" <ibc at aliax.net>

   > 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip