Setting up SRTP-only calls and using one or all of those techniques would certainly be a way to learn how often intermediate transcoders are needed and cannot be invoked. Someone should try those techniques against some SIP peers.
I suspect even more interoperability issues would be encountered, but I am only guessing. -d > -----Original Message----- > From: Paul Kyzivat [mailto:[email protected]] > Sent: Saturday, April 04, 2009 2:00 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 > > > > Dan Wing wrote: > > > > > >> -----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? > > There are a number of possibilities: > > 1) I could send an offerless invite, and await an offer from > you. Then > if it isn't something I can do myself I can recruit a > transcoder to help. > > 2) I could send an invite with offer, and the callee could > recruit the > transcoder if needed. > > 3) I can send an invite with offer, and if you can't handle it, and > don't have a transcoding alternative, you could send a 18x with an > answer that refuses the media stream, but mentions the codecs you do > support. > > 4) like 3, but use the sdp capability stuff to express the > codecs that > are supported in each direction. > > 5) I send invite with offer, you reject it with 488 because you can't > support the codecs offered. The 488 indicates the codecs you > do support. > Then I recruit a transcoder and try the call again, offering > somthing I > expect you will be able to support. > > Thanks, > Paul > > > -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
