Re: [rtcweb] JSEP: Why always offer actpass?

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

> 
> Do you have an opinion on my main "topic": that subsequent offers should
> offer the already negotiated role, rather than always "actpass"?
[Raju]
For non DTLS-SRTP associations, I think the key attribute here is a=connection. If a subsequent offer has an explicit "a=connection:existing" then per the reference[1] a=setup (and other params) are ignored. Per [2] below, the default value for a=connection is "new" in offer and answer. So, if an explicit "a=connection:new" is present or "a=connection" is absent then, per [3],  the existing association is closed and a new association will be opened using new a=setup rules.
Btw, I think section 7.3 of RFC 4145 is just an example showing previously negotiated setup values are used. But section 5.1 is normative and clearly says these attributes must be ignored for a=connection:existing.

Reference [4] and [5] are for DTLS-SRTP which does not allow a=connection attribute and indicates new offer/answer compatibility with old as the criteria to reuse or close/open new one. It also notes that if a=setup changes then a new association is established. This latter part also have to consider the a=setup defaults, which may be different from previously negotiated values, if absent in new offer/answer.

[1] https://tools.ietf.org/html/rfc4145#section-5.1  

   "If the connection value resulting from an offer/answer exchange is
   'existing', the end-points continue using the existing connection.
   Consequently, the port numbers, IP addresses, and 'setup' attributes
   negotiated in the offer/answer exchange are ignored because there is
   no need to establish a new connection."

[2] https://tools.ietf.org/html/rfc4145#section-5.1  
   "The default value of the connection attribute in both offers and
   answers is 'new'. "

[3] https://tools.ietf.org/html/rfc4145#section-5.2 

   "If the connection value for an 'm' line resulting from an offer/
   answer exchange is 'new', the endpoints SHOULD establish a new TCP
   connection as indicated by the 'setup' attribute.  If a previous TCP
   connection is still up, the endpoints SHOULD close it as soon as the
   offer/answer exchange is completed.  It is up to the application to
   ensure proper data synchronization between the two TCP connections."

[4] DTLS SRTP RFC https://tools.ietf.org/html/rfc5763#section-5
	" The endpoint MUST NOT use the connection attribute defined in
      [RFC4145]."

[5] https://tools.ietf.org/html/rfc5763#section-6.6
   "The peers can reuse the existing associations if
   they are compatible (i.e., they have the same key fingerprints and
   transport parameters), or establish a new one following the same
   rules are for initial exchanges, tearing down the existing
   association as soon as the offer/answer exchange is completed.  Note
   that if the active/passive status of the endpoints changes, a new
   connection MUST be established."

BR
Raju