Re: [Sipbrandy] WGLC: draft-ietf-sipbrandy-osrtp-04 - Christer's review

[Christer Holmberg <[e-mail]>]

Hi Andy,

Below is a suggestion for an "SDP Offer/Answer Considerations" section.

Feel free to use, modify or throw in the trash bin :)

Regards,

Christer

---------------

X. SDP Offer/Answer Considerations

This section defines the SDP offer/answer considerations for opportunistic security. 

The procedures are for a specific m- section describing RTP-based media. If an SDP offer or answer 
contains multiple such m- sections, the procedures are applied to each m- section individually.

"Initial OPSRTP offer" refers to the offer in which oportunistic security is offered for 
an m- section for the first time within an SDP session.

X.1. Generating the Initial OPSRTP Offer

When an offerer sends an initial offer, in order to offer opportunistic security for a m- section descrbing
RTP-based media, the offerer MUST:

- indicate the RTP/AVP profile [RFC3551] (or the RTP/AVPF profile [RFCXXXX]) in the proto sub-field of the m- section; and
- include the SRTP keying attributes associated with one or more SRTP key managmenebt mechanism in the m- section:
-- In case of DTLS-SRTP key agreement [RFC5763], the keying attributes are provided using the SDP Fingerprint attribute.
-- In case of SDP Security Descriptions key agreement [RFC4568], the keying attributes are provided using the SDP Crypto attribute.
-- In case of ZRTP key agreement [RFC6189], the keying attributes are provided using the SDP zrtp-hash attribute.

X.2 Generating the Answer

When an answerer generates an answer to an offer which offers opportunistic security for an m- description 
[Section X.1], if the answerer accepts usage of SRTP and the indicated key management mechanism, the answerer generates
an answer and MUST:
- indicate one SRTP/AVP profile (or the SRTP/AVPF profile) in the proto sub-field of the corresponding m- section in the answer; and
- indicate the SRTP keying attributes associated with the chosen key management mechanism;

If the answerer does not accept the offered security for an m- section, but does accept the m- section, the answerer MUST 
indicate the RTP/AVP profile (or the RTP/AVPF) in the proto sub-field of the corresponding m- section in the answer, 
using normal procedures for negotiating non-secured RTP media. The answerer MUST NOT include any keying attributes in the m- section.  

If an m- section of the offer indicates previously negotiated SRTP, if the answerer accepts to continue using SRTP, 
the answerer will generate the corresponding m- section in the answer using the normal offer/answer procedures 
for SRTP and the used key management mechanism.

If SRTP has previously been negotiated, if a subsequent offer offers opportunistic security, the answerer
can choose to continue using SRTP (and generate the answer as described in the first paragraph above), or disable SRTP 
(and generate the answer as described in the second paragraph above).

Once the answerer has sent an answer, in which it indicates usage of SRTP for an m- section, the answerer will trigger normal procedures
associated with SRTP and the negotiated key management mechanism.


X.3 Offerer Processing the Answer

When the offerer receives an answer, if the answerer accepts the usage of SRTP, the answerer will trigger normal procedures associated
with SRTP and the negotiated key management mechanism.


X.4 Modifying the Session

When an offerer sends a subsequent offer, if SRTP has previously been negotiated for an m- section in the offer, the offerer MUST either:
- indicate the SRTP/AVP profile (or the SRTP/AVPF profile), indicating that the offerer wants to continue using SRTP; or
- re-offer opportunistic security, using the procedures in section X.1. As described in Section X.2, the answerer can choose to 
continue using SRTP, or switch to non-secure RTP.