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

["Makaraju, Maridi Raju (Raju)" <[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?

<Raju>
IMO, the text does not say subsequent offer must send previously 
negotiated role. In fact there are issues in sending previously 
negotiated role.
The browser or the client is not aware if the sub-sequent offer
could result in an SDP answer which now have a new destination
address (e.g. a new middle box for conf), only the service logic 
in the communications server determines this.
To facilitate this, IMO, sending actpass is the right approach.
If it turns out to be SDP answer has not changed the destination,
fingerprint, and role (i.e. compatible to previous answer) then
previous association will continue to be used. This is per [6].

The above explanation is for DTLS-SRTP without use of ICE.
When ICE is used, if the destination is to be changed then 
per [6] ICE must be restarted. So, restarting ICE must also
set role as actpass instead of previously negotiated role.
When ICE is completed, the SDP answer to a subsequent offer 
can't change the Destination (m/c= lines) to a new 
candidate (it should be the selected candidate) unless ICE 
is restarted.
Please note that ICE restart can't be initiated in an SDP answer.

Unfortunately [7] did not talk about these interactions with ICE.

In conclusion, even for WebRTC use case of DTLS-SRTP, IMHO, it is better
if actpass is offered again for all cases independent of ICE restart.
The peer will simply respond to the previously negotiated role which
will keep the existing association.


[6] https://tools.ietf.org/html/rfc5245#section-9.1.1.1 
[7] https://tools.ietf.org/html/rfc5763#section-6.7.1

</Raju>

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