dtls-srtp setup attribute

[Bryan]

rfc5763 talks about a setup attribute that is required in both offer and answer, but I do not see this attribute in the offer generated by Chrome 27.  Is this setup attribute required or not?  Thanks

from http://tools.ietf.org/html/rfc5763

   The offer and answer MUST conform to the following requirements.

   o  The endpoint MUST use the setup attribute defined in [RFC4145].
      The endpoint that is the offerer MUST use the setup attribute
      value of setup:actpass and be prepared to receive a client_hello
      before it receives the answer.  The answerer MUST use either a
      setup attribute value of setup:active or setup:passive.  Note that
      if the answerer uses setup:passive, then the DTLS handshake will
      not begin until the answerer is received, which adds additional
      latency. setup:active allows the answer and the DTLS handshake to
      occur in parallel.  Thus, setup:active is RECOMMENDED.  Whichever
      party is active MUST initiate a DTLS handshake by sending a
      ClientHello over each flow (host/port quartet).

JS to create offer:

(new webkitRTCPeerConnection(null,{mandatory:{DtlsSrtpKeyAgreement:true}})).createOffer(function(o){console.log(o.sdp)},function(e){console.log(e)},{mandatory:{OfferToReceiveVideo:true}});

generated offer:

v=0
o=- 2897947437 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS
m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:GUXuWhzUmfVX4G86
a=ice-pwd:o3L8JeotG+l/sN2EoYyUI4Hu
a=ice-options:google-ice
a=fingerprint:sha-256 21:F7:BD:A7:4C:97:6F:7C:A6:DB:1B:42:96:A2:B9:38:9B:8B:94:5A:51:70:CD:21:F0:20:D2:24:FE:F2:14:FE
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3PHyAynZM9d3FVlemtQrCRgmQDGmFFv9ukawK7Fl
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=video 1 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:GUXuWhzUmfVX4G86
a=ice-pwd:o3L8JeotG+l/sN2EoYyUI4Hu
a=ice-options:google-ice
a=fingerprint:sha-256 21:F7:BD:A7:4C:97:6F:7C:A6:DB:1B:42:96:A2:B9:38:9B:8B:94:5A:51:70:CD:21:F0:20:D2:24:FE:F2:14:FE
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=recvonly
a=mid:video
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3PHyAynZM9d3FVlemtQrCRgmQDGmFFv9ukawK7Fl
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack 
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000

[Justin Uberti]

Chrome uses the ICE roles to determine active vs passive; the CONTROLLED party takes the active role.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[SteveG]

Just to clarify, so in the case of webRTC client to ice-lite endpoint the ice-lite endpoint would be the active role for DTLS establishment?  

Also is there any intention to implement the setup attribute in chrome and allow dynamic control through an api?

Cheers,

Steve