El Viernes, 31 de Octubre de 2008, Victor Pascual Ávila escribió:
> Hi Iñaki,
>
> On Fri, Oct 31, 2008 at 2:03 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> > 2008/10/31 Michael Procter <[EMAIL PROTECTED]>:
> >>> Shall DERIVE be extended to support non-INVITE requests (e.g. MESSAGE)
> >>
> >> I'm not sure it can. RFC4235 is defined for INVITE-initiated dialog
> >> usages only. Yes, it could be extended, but I'm not convinced that is
> >> necessarily the best way forward from here!
> >
> > Also note that MESSAGE doesn't establish a dialog, it just an
> > independent transaction.
>
> Do you mean that we should provide a reasonable assurance that the
> "Caller-ID" is not misleading ONLY for dialog-forming requests?
Well, the problem is that DERIVE wouldn't work for non INVITE dialogs since
RFC 4235 just involve INVITE dialogs.
DERIVE is a good proposal since it reuses existing (and *really* implemented)
features (as Dialog Event Package), but verifying Caller-ID in non INVITE
requests must be subject of a new and independent proposal.
IMHO, the best behaviour would be something as Juha's proposal (not sure if
it's something as follows):
bob alice
F1 MESSAGE -------------->
<----------------- F2 INFO
200 (INFO) -------------->
<------------ 200 (MESSAGE)
- F1:
MESSAGE sip:[EMAIL PROTECTED] SIP/2.0
From: <sip:[EMAIL PROTECTED]>;tag=1234
Call-ID: abcd
- F2:
INFO sip:[EMAIL PROTECTED] SIP/2.0
Require: callerid-verify
CallerID-Verify: call-id=abcd;from-tag=1234
Content-Length: 0
bob would reply "481 Call/Transaction doesn't exist" if it's not a request
from him, a "200 OK" if it's, "420 Bad Extension" if it doesn't support this
feature, and any other 4XX if bob (or a proxy in the middle) can't answer it
(so the response is undefined).
This would work with INVITE, MESSAGE and any kind of request, but it wouldn't
work inmediately with devices already supporting RFC4235, so we'd have again
a exotic specification with no real implementation.
--
Iñaki Baz Castillo
_______________________________________________
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
