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

[Stefan Håkansson LK <[e-mail]>]

Thanks for a good overview!

On 25/11/14 19:30, Makaraju, Maridi Raju (Raju) wrote:
>>
>> 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.

In this context we're dealing only with DTLS-SRTP I guess.

I read [5] as that subsequent offers should offer the negotiated role 
for existing connections (and not actpass), but I'm not sure. What is 
your interpretation?

>
> [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
>