Re: francois' comments and why RFC4474 not used in the field

 

> -----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