Re: submission of a new I-D: "Dialog Event foR IdentityVErification"
Iñaki Baz Castillo <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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