Suppose, for the sake of argument, we go with Hadriel's draft and OPTIONS, e.g., global call ID in INVITE request, sent back in OPTIONS request with global call ID to URI obtained from receive From.
Now suppose the initial From URI is sip:[EMAIL PROTECTED];user=phone and this gets modified by callee's service provider to sip:[EMAIL PROTECTED];user=phone. Callee UA sends OPTIONS request to the latter URI. B2BUA in sp.net acts as UAS for the OPTIONS request and returns 200 OK, on basis that it recognises the global call ID. What does this give me? Basically that the call arrived via my service provider, which I know anyway if it arrives over a TLS connection for which I have authenticated the service provider. The problem is, I don't know that sp.net has terminated the OPTIONS request. Even if the service provider has not acted in this way and the OPTIONS request has gone all the way back to the caller UA (or at least to its domain proxy/B2BUA), I have no evidence that this is so. Now contrast this with RFC 4474. With RFC 4474, sp.net can change the URI as above and re-sign (insert a new Identity header field). At least my UA can see that the only guarantee I have is that the call arrived via sp.net. On the other hand, if sp.net has not intervened in this way I can see where the call has really come from (subject to B2BUAs not breaking the signature). In other words, RFC 4474 tells me who is asserting that it sent the INVITE request, whereas DERIVE just tells me that someone is asserting that it sent the INVITE request. John _______________________________________________ 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
