Subject: RE: [Speermint] Secure RTP

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 4 Aug 2006 11:42:08 -0400

Agree, that certain media related items will get negotiated by the
signaling layer.

As for trying to get everyone globally to agree, that is an idealistic
goal.  Expecting this to work at some lowever level (federations) is
more realistic.  Business interests will drive those federations to
choose the right core pieces, therefore, I don't think we need to go
down that rat-hole here.

Mike

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 8:41 PM
> To: Michael Hammer (mhammer); 'Brian Rosen'
> Cc: [email-masked]
> Subject: RE: [Speermint] Secure RTP
> 
> So you're saying they MUST implement such a policy exchange 
> mechanism??  ;)
> 
> To me the srtp and codec "policy" exchange is already there: SDP.
> 
> We will probably need MUSTs for some things, because we need 
> 2 speermint-supporting peers to interop.  If two speermint 
> federations can pick their own MUSTs for basic issues, then 
> they may not interop.  They can discover each other's 
> policies all day long, but if there's no match we've screwed 
> up.  I don't put codecs into that basic issues list, because 
> that's different and dependent per UA.  It could be 
> "normalized", but that's not easy to get consensus on.
> 
> -hadriel
> 
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Thursday, August 03, 2006 3:13 PM
> > To: Hadriel Kaplan; Brian Rosen
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Secure RTP
> > 
> > The focus of Speermint should be centered around whether one can 
> > discover the policies of a potential peer and whether those 
> policies 
> > can systematically describe the requirements on multiple 
> levels that 
> > will need to be supported to have a successful 
> communication with that peer.
> > 
> > It is not about specifying X, Y, Z, or <name your favorite 
> MUST here>
> > 
> > Is is about whether the policy can be stated so one knows 
> that X, Y, ...
> > is required to peer.
> > 
> > I suspect that each federation will select different MUSTs for each 
> > category of choices we come up with.
> > 
> > Mike
> > 
> > 
> > > -----Original Message-----
> > > From: Hadriel Kaplan [mailto:[email-masked]]
> > > Sent: Tuesday, August 01, 2006 4:09 PM
> > > To: 'Brian Rosen'
> > > Cc: [email-masked]
> > > Subject: RE: [Speermint] Secure RTP
> > >
> > > But there are currently 11(?) proposed SRTP key exchange 
> mechanisms, 
> > > some using SDP, some not - none of which interoperate.  So 
> > > "interoperability" is impacted there, and part of it is a 
> signaling 
> > > issue.  In that sense it may well be reasonable for a 
> speermint BCP 
> > > to pick one preferred mechanism, but I'm sure that will be yet 
> > > another rat-hole.
> > > And I recommend we stay out of those when we can.  :) 
> (besides, the 
> > > RTPSEC-BOF group is assigned that Herculean task)
> > >
> > > -hadriel
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:[email-masked]]
> > > > Sent: Tuesday, August 01, 2006 3:33 PM
> > > > To: 'Andrew Newton'
> > > > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > > > Subject: RE: [Speermint] Secure RTP
> > > >
> > > > Sure, but does the peering touch the media?  I claim it 
> doesn't, 
> > > > at least normally.  "Getting it right" means that when the 
> > > > signaling happens, the resulting SDP will work.  That part (the 
> > > > SDP part) matters to us, because we have to make sure that when 
> > > > that
> > > SDP gets to
> > > > the other side, it will result in something that works.
> > > The peering
> > > > system doesn't have to even look at the SDP, it just has to
> > > have rules
> > > > that make interoperability work.
> > > >
> > > > The peering system has to, for example, make sure that 
> an address 
> > > > given in the SDP on one side is actually reachable on the
> > > other side.
> > > > Doing that doesn't involve any work, it's just rules the 
> > > > federation agrees to that makes that be true. So, we 
> might need to
> > > specify no NAT
> > > > or conversely, MUST support ICE.  That all speaks to what the 
> > > > peers have to have between their endpoints and their peers.  It 
> > > > doesn't imply the media packets traverse the peering fabric.
> > > >
> > > > Of course, in theory, the peering system doesn't even have to 
> > > > touch the signaling, but we don't have to go there.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Newton [mailto:[email-masked]]
> > > > > Sent: Tuesday, August 01, 2006 3:07 PM
> > > > > To: Brian Rosen
> > > > > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > > > > Subject: Re: [Speermint] Secure RTP
> > > > >
> > > > > Brian Rosen wrote:
> > > > > > I think that we are looking at case 1, and not at case
> > > 2.  I don't
> > > > think
> > > > > we
> > > > > > care about the media.
> > > > >
> > > > > Interesting.  I don't know about you, but I get paid for
> > > getting the
> > > > media
> > > > > right.  Perfect signaling is useless without media.
> > > > >
> > > > > -andy
> > > >
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint