> -----Original Message----- > From: Paul Kyzivat [mailto:[email protected]] > Sent: Friday, April 03, 2009 8:56 PM > To: Dan Wing > Cc: 'Francois Audet'; 'Dean Willis'; 'Jiri Kuthan'; 'SIP > List'; 'Uzelac, Adam' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > When I am calling you, if I can discover that transcoding is > required to establish the call,
How would you do that? -d > then I can establish a relationship with a > transcoding service that I trust. If I use 3pcc to bring the > transcoder > into the call, then my call to you is still from *me*, and I > vouch for > the media source even if it is actually the transcoder. So the > transcoding scheme can be as secure (or insecure) as any > other. That of > course assumes that the means for setting up the secured > media session > is something that can be set up using 3pcc without my > necessarily having > to relay the media.) > > Thanks, > Paul > > Dan Wing wrote: > >>> But if some service provider in the middle needs to drop the > >>> call to <some spiffy codec> which isn't supported by Alice's > >>> SP nor by Bob's SP -- what would that service provider do? > >>> Not deploy that spiffy new codec, even though it would save > >>> them thousands of dollars a day in satellite bandwidth fees? > >> Well, no. You just can't do end-to-end media security in this > >> case. > > > > Ok. Then in that case a way to downgrade to RTP -- which we need > > in any event -- would be needed. > > > >> I don't understdand at all the claim that if transcoding is > >> allowed, there would be any point in doing media security, or > >> even Secure identity for that matter. I'm just saying if > transcoding > >> or media mucking-around is allowed, then just stick with P-AI. > > > > So that the victim (user2) can distinguish between a > service provider doing > > transcoding for the legimate user1 versus the identity > spoofing of user3 > > (diagram taken from > > > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-impor > tant-03): > > > > user3/UA3 > > | > > +------+------+ > > | enterprise3 | > > +------+------+ > > | > > +----------+ +----+-----+ +----------+ > > +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ > > | +----------+ +----------+ +----------+ | > > | ITSP-A ITSP-B ITSP-C | > > | | > > +------+------+ +------+------+ > > | enterprise1 | | enterprise2 | > > +------+------+ +------+------+ > > | | > > user1/UA1 user2/UA2 > > > > -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 > > _______________________________________________ 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
