> -----Original Message----- > From: Adam Roach [mailto:[email protected]] > Sent: Tuesday, April 14, 2009 3:59 PM > To: Dan Wing > Cc: 'Anthony D Pike'; 'Cullen Jennings'; 'Jon Peterson'; > [email protected]; 'Francois Audet'; 'DRAGE, Keith (Keith)'; 'Dean Willis' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > [with my individual contributor hat on] > > Dan Wing wrote: > > On SIP networks today we have intermediaries modifying > SDP in transit. It's > happening now, on real networks. I am really > interested in preserving > identity over those networks. > > > > And I have HTTP proxies that I'd love to send RTP through. At > some point, we've got to realize that certain types of old > dogs aren't even remotely suited for particularly demanding > new tricks -- at least, not without software upgrades. > > I think it's important to distinguish among three classes of > solutions in this space: > > > > 1. Identity that works through existing B2BUAs > 2. Identity that might not work through existing B2BUAs, > but that B2BUAs can be modified to work with > 3. Identity that precludes the presence of B2BUAs > > > There are clearly approaches that fit into each of these > three categories. There are a number of people (and I count > myself among them) who find the security properties of the > proposals that fit into #1 to be odious. There are also > people who clearly find proposals in class #3 unacceptable > for their lack of pragmatism. > > Now, there are also a number of people who have historically > staked out extremist positions that state that only solutions > in category #1 (or only solutions in category #3) are > acceptable, and that neither of the other two options could > possibly be acceptable. I think we need to ignore people > arguing from either of these extreme positions, because their > positions are mutually exclusive, and can never be rectified > with each other. > > At the risk of suggesting compromise, I'll point out that > there *is* a way to mutually satisfy those people who reject > solutions in class #1 and those people who reject solutions > in class #3. I suspect that useful progress lies in that > direction only.
Agreed. And I also prefer #2. There have been 3 solutions on the table that provide e2e identity with small changes to those B2BUAs (essentially: permit such-and-such header fields to pass), and accomplish this without an appreciable CPU impact on those intermediaries. All three of those proposals are in the #2 category. -d _______________________________________________ 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
