Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 01.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 31 Oct 2006 08:20:36 +0000

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 31 October 2006 02:03
> To: 'Hadriel Kaplan'; Elwell, John; 'Francois Audet'; [email-masked]
> Subject: RE: [MMUSIC] RE: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt
> 
> > > Security Descriptions probably doesn't need it, either -- it can't
> > > do early media unless we resurrect
> > > draft-wing-mmusic-sdes-early-media-00.txt or some idea like it.
> >
> > Sure, but you may need to know that you can't do it.  I.e., when you
> > make a best-effort offer, you may need to know that the answerer has
> > chosen srtp instead of rtp before the SDP answer comes back, so
> > payload-mapping is the way.  (Sorry, I said port-mapping originally
> > but meant payload-mapping)
> 
> Ok, but what can you do with that new knowledge?  Maybe there 
> is something
> useful you can do with the various early media things described in
> draft-stucker-sipping-early-media-coping (stop playing the 
> RTP that's being
> streamed to you), but I'm not sure I know what it is.
[JRE] If SDescriptions has a different payload type, then you know that if
you receive this payload type before the SDP answer you cannot render it,
whereas if you receive a payload type for RTP or for SRTP using certain
MIKEY options you can indeed render the payload.

> -d

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 31 Oct 2006 13:08:14 -0500

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 3:21 AM
>

Exactly.  

And if you make a new offer later, or your original offer got forked, you
can decide when/what can be rendered or not.  So it also helps if you get
both RTP and SRTP at the same time during a transition period. (ie, the item
for further study in your draft-wing-media-security-requirements-00.txt,
labeled "A solution SHOULD allow to start with RTP and then upgrade to
SRTP")

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 10:47:26 -0800

> > whereas if you receive a payload type for RTP or for SRTP 
> > using certain MIKEY options you can indeed render the 
> > payload.
> 
> Exactly.  

Ok, thanks.  Makes sense to me now.

> And if you make a new offer later, or your original offer got 
> forked, you can decide when/what can be rendered or not.  So 
> it also helps if you get both RTP and SRTP at the same 
> time during a transition period. (ie, the item for further 
> study in your draft-wing-media-security-requirements-00.txt,
> labeled "A solution SHOULD allow to start with RTP and then 
> upgrade to SRTP")

Yeah, there are two cases hidden there, I believe:  one is
what ZRTP does today ('upgrading' a connection), and another
is handling RTP early media as described by 
draft-stucker-sipping-early-media-coping-03.txt, where the
RTP is coming from RTP endpoints that aren't the final 
endpoint.

-d