Hi All,
I’m trying to understand the proper way to negotiate RFC4568 crypto attribute
session parameters such as UNENCRYPTED_SRTP. In section 5.1.2,
Generating the Initial Answer –Unicast Streams, the RFC says
When the answerer receives the initial offer with one or more crypto
attributes for a given unicast media stream, the answerer MUST either
accept exactly one of the offered crypto attributes, or the offered
stream MUST be rejected.
and
Furthermore, any session parameters that are negotiated MUST be
included in the answer. Declarative session parameters provided by
the offerer are not included in the answer; however, the answerer may
provide its own set of declarative session parameters.
So this seems like maybe the answerer can insert its own declarative
session parameters into the crypto attribute in the answer, along with
its keying material, but I’m not clear if it is proper to insert a negotiated
parameters such as UNENCRYPTED_SRTP, into a crypto attribute in the
response.
For example, suppose one receives an SDP offer like the following:
v=0
o=bob at biloxi.com 52342343 9239423 IN IP4 10.248.0.251
s=Session123
i=A test session
c=IN IP4 10.248.0.239
t=0 0
m=audio 5004 RTP/SAVP 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ljsdk1ksjld32368klksDSDkddKDKFsDskdldKKd|2^20|1:4
and the receiver of this offer is willing to support SRTP but not SRTP encryption. Then since
the offer does not include the UNENCRYPTED_SRTP session parameter should
the offer be rejected outright and the call terminated, or is it OK (not in violation of the
RFC) to respond with an answer that inserts the UNENCRYPTED_SRTP parameter
inserted into the answer crypto attribute as follows:
v=0
o=mtaylor at biloxi.com 52342343 9239423 IN IP4 10.248.0.251
s=Session323
i=A test session
c=IN IP4 10.248.0.240
t=0 0
m=audio 5004 RTP/SAVP 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline: Ukdkw1gfjslkeUvksjelKKkdjwekslkejLKE11dk|2^20|1:4 UNENCRYPTED_SRTP
In other words, per the RFC is it incumbent upon the offerer to explicitly indicate
a willingness to do unencrypted SRTP, but a preference for encrypted SRTP, by including
two crypto attriubutes as in
v=0
o=bob at biloxi.com 52342343 9239423 IN IP4 10.248.0.251
s=Session123
i=A test session
c=IN IP4 10.248.0.239
t=0 0
m=audio 5004 RTP/SAVP 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ljsdk1ksjld32368klksDSDkddKDKFsDskdldKKd|2^20|1:4
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:ya3k283klkWWdkjwFek2932ckdejlklkelksl233|2^20|1:4 UNENCRYPTED_SRTP
So then if such a parameter is not present in the offer the answerer can assume that the offerer
is not willing to support it.
This seems better since it forces offerers to explicitly indicate what they’re willing to negotiate, but
I wanted to make sure whether or not inserting a negotiated session parameter like UNENCRYPTED_SRTP
into a response is valid per RFC4568 or if the fact that it is a “negotiated” parameter means
that it is not valid to insert it.
Regards,
Mike Taylor
_______________________________________________ mmusic mailing list mmusic at ietf.org https://www.ietf.org/mailman/listinfo/mmusic