Dean, I like your proposal. I think return calls should work too. If sent to the URI (complete with lack-of-trust parameter), it should cause the request to route to the same gateway (or another in the same domain), which can simply ignore the lack-of-trust parameter and route to PSTN (or even do an ENUM look-up and route onwards in SIP if that turns out to be possible).
Also an intermediate SIP entity might ignore the domain part and route only on the phone number, but again I think no harm is done. John > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: 14 March 2008 14:48 > To: Adam Roach > Cc: Elwell, John; IETF SIP List > Subject: Re: [Sip] The thing we're missing in the RFC 4474 > andDTLS-SRTPdiscussion > > > On Mar 14, 2008, at 10:17 AM, Adam Roach wrote: > >>> > >> [JRE] Many phones do recognise P-Asserted-Identity and use that in > >> preference to an unsigned From URI. It is difficult to find a > >> solution > >> that will not upset any existing deployed device, but we > can at least > >> try to make it work acceptably with a sizeable population. > >> > > > > So we've gone from warning "don't implement > internet-drafts" to "don't > > implement RFCs"? It seems folly to pull the rug out from under > > existing > > user agents when we've already identified at least one approach that > > seems to satisfy the keying requirement without breaking existing > > deployed equipment or making assertions that can't be > verified by the > > asserter. > > I think this is just another caveat on existing equipment. Some > phones, if P-A-ID is present, will preferentially display it. Some > will do this even in the presence of an Identity-signed From: field > that contains conflicting information (inasmuch as they ignore > Identity completely and prefer P-Asserted-Identity to From). > > This is simply something that happens. We have to analyze the > situation from a backward-compatibility perspective. > > Proposal: Include a usage disclaimer parameter on the URI in > the From: > field of a request to which we apply RFC 4474 authentication > service, > resulting in an Identity header that signs the request > (including the > URI part of the From: field). > > Case 1: Somebody in the loop is RFC 2543 and not 3261 > > Result: Proposal breaks because RFC 2543 nodes may fail when proxies > change From: fields. This doesn't bother me at all. > > > Case 2: Receiver doesn't understand RFC 4474 or this proposal: > > Subcase 2a: Receiver prefers From: field > > Result: Contents of From: field are rendered. This MAY inform a > knowledgeable user of the lack-of-trust, but probably won't. > > Subcase 2b: Receiver prefers P-A-ID > > Result: Contents of P-A-ID are rendered. So this results depends on > how P-A-ID was populated, which is up to the implementation. > > > Case 2: Receiver understands RFC 4474 but not this proposal: > > Result: Contents of From: field are rendered as verified. > Depending on > the rendering, this may either inform a knowledgeable user, > or display > as verified information that we know is not verified. > > > Case 3: Receiver understands RFC 4474 and this proposal (and DTLS- > SRTP) : > > Result: Contents of From: field are rendered as unverified. Media is > encrypted. Media is verifiably bound to signaling. All is good. > > -- > Dean > > > _______________________________________________ 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
