Subject: RE: [MMUSIC] Question on sdp-new

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Oct 2005 16:18:32 +0100

Paul,

S/MIME isn't the only way of doing key management for SRTP - the use of
MIKEY doesn't require S/MIME. The example I gave in my original message on
this thread was with a=key-mgmt.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 13 October 2005 16:08
> To: Elwell, John
> Cc: Mark Baugher; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] Question on sdp-new
> 
> 
> 
> Elwell, John wrote:
> > Mark,
> > 
> > Thanks, but if I remember correctly, Cullen's document was 
> to do with
> > different body types in a SIP message, e.g., S/MIME or MIME 
> versions of the
> > same body or SDP and SDPng. I don't think it extended to 
> different options
> > within the same body type.
> 
> No, it didn't. But the proposal was to have two different SDP bodies, 
> one offering RTP and the other offering SRTP. We came to the 
> conclusion 
> that two bodies are needed because the SRPT offer/answer needs to be 
> protected with S/MIME, and one can probably expect a UA that supports 
> SRTP to support S/MIME. But you probably shouldn't expect all UAs to 
> support S/MIME.
> 
> 	Paul
> 
> > John 
> > 
> > 
> >>-----Original Message-----
> >>From: Mark Baugher [mailto:[email-masked]] 
> >>Sent: 13 October 2005 14:00
> >>To: Elwell, John
> >>Cc: [email-masked]; [email-masked]; 
> >>[email-masked]; [email-masked]
> >>Subject: Re: [MMUSIC] Question on sdp-new
> >>
> >>We should consider whether we want to standardize SRTP 
> >>inter-operation 
> >>with legacy RTP systems.  I recall reading a draft from 
> >>Cullen Jennings 
> >>that addressed this problem in SIP signaling using a 
> >>multipart/alternative MIME encoding of a SIP message.  This 
> >>reduces the 
> >>problem to the legacy RTP systems that also don't recognize 
> >>mulitipart-alternative SIP messages.  Cullen should correct 
> me if my 
> >>summary is wrong.
> >>
> >>Mark
> >>On Oct 13, 2005, at 4:10 AM, Elwell, John wrote:
> >>
> >>
> >>>Would the following SDP be legal?
> >>>
> >>>   v=...
> >>>   o=...
> >>>   s=...
> >>>   c=...
> >>>   t=...
> >>>   m=audio 62986 RTP/SAVP 0 4 18
> >>>   a=rtpmap:0 PCMU/8000
> >>>   a=rtpmap:4 G723/8000
> >>>   a=rtpmap:18 G729/8000
> >>>   a=key-mgmt:.....
> >>>   m=audio 62986 RTP/AVP 0 4 18
> >>>   a=rtpmap:0 PCMU/8000
> >>>   a=rtpmap:4 G723/8000
> >>>   a=rtpmap:18 G729/8000
> >>>
> >>>Note that the two media have the same port and thus the 
> >>
> >>same transport
> >>
> >>>address. In 6.15 of sdp-new there is a list of conditions 
> >>
> >>in which two 
> >>
> >>>media
> >>>may use the same transport address. It is not clear to me whether 
> >>>condition
> >>>3 is violated: "If two media sessions have the same 
> >>
> >>transport address, 
> >>
> >>>they
> >>>SHOULD operate under the same RTP profile.  The sessions 
> MAY use two
> >>>different RTP profiles only if those profiles are specifically 
> >>>designed to
> >>>be compatible."
> >>>
> >>>Do the different transports (RTP/SAVP and RTP/AVP) constitute 
> >>>different RTP
> >>>profiles? If so, can we regard the two protocols as "designed to be
> >>>compatible"? Note that in a SIP context, if an SDP offer 
> >>
> >>contains the 
> >>
> >>>code
> >>>above, the offerer would need to be prepared to receive 
> >>
> >>either SRTP or 
> >>
> >>>RTP
> >>>on the same port until the SDP answer arrives, perhaps using the
> >>>authentication tag to distinguish SRTP from RTP.
> >>>
> >>>This form of SDP seems to be useful where the offerer is 
> >>
> >>prepared to 
> >>
> >>>accept
> >>>either SRTP or RTP (perhaps indicating to the user whether the 
> >>>resulting
> >>>audio is secure). By using the same transport address the answerer 
> >>>should
> >>>treat the two media as alternatives and presumably should 
> >>
> >>reject one of
> >>
> >>>them. By using two different transport addresses the media 
> would be 
> >>>treated
> >>>separately and the answerer might accept both, which might 
> >>
> >>not be what 
> >>
> >>>is
> >>>wanted.
> >>>
> >>>Some clarification on this in the next version might be 
> >>
> >>useful (I note 
> >>
> >>>that
> >>>some comments have been raised so presumably a next 
> version will be 
> >>>produced
> >>>at some stage).
> >>>
> >>>The problem of distinguishing between RTP and SRTP on the 
> same port 
> >>>(or even
> >>>between different SRTP streams on the same port that use different 
> >>>keys as a
> >>>result of using different key management methods) could 
> possibly be 
> >>>worked
> >>>around by assigning different payload type numbers, e.g.:
> >>>
> >>>   v=...
> >>>   o=...
> >>>   s=...
> >>>   c=...
> >>>   t=...
> >>>   m=audio 62986 RTP/SAVP 0 4 18
> >>>   a=rtpmap:0 PCMU/8000
> >>>   a=rtpmap:4 G723/8000
> >>>   a=rtpmap:18 G729/8000
> >>>   a=key-mgmt:.....
> >>>   m=audio 62986 RTP/AVP 97 98 99
> >>>   a=rtpmap:97 PCMU/8000
> >>>   a=rtpmap:98 G723/8000
> >>>   a=rtpmap:99 G729/8000
> >>>
> >>>However, I am not sure whether this would violate the 
> >>
> >>conditions for 
> >>
> >>>using
> >>>the same transport address. Also I am not sure of the 
> >>
> >>legality of using
> >>
> >>>dynamic payload numbers for encodings for which static 
> >>
> >>payload numbers 
> >>
> >>>exist
> >>>or whether this would be supported by products in the field.
> >>>
> >>>John
> >>>
> >>>_______________________________________________
> >>>mmusic mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/mmusic
> >>>
> >>
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2005 13:16:02 -0400

> this thread was with a=key-mgmt.

OK, sorry - I missed that.

The multipart approach would still work, but it might not be the best 
choice.

	Paul