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

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 24 Nov 2014 15:36:36 +0000

Hi,

I'm looking into the JSEP draft. One thing that seems strange is that in 
every offer the role offered is "actpass", also for existing 
connections. As I read section 7.3 of 
https://www.rfc-editor.org/rfc/rfc4145.txt the established roles should 
be maintained in such situations.

What is the reason for the always offering "actpass" also for 
established roles/connections?

Stefan

---

From: Justin Uberti <[email-masked]>
Date: Mon, 24 Nov 2014 17:11:21 -0800

Quoth RFC5763, Section 5:

   o  The endpoint MUST use the setup attribute defined in [RFC4145
<https://tools.ietf.org/html/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).

However I concur that the existing roles should be maintained, e.g. the
answerer must choose active or passive appropriately. Chrome will fail upon
an attempted role change.

On Mon, Nov 24, 2014 at 7:36 AM, Stefan Håkansson LK <
[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 25 Nov 2014 07:08:30 +0000

On 25/11/14 02:11, Justin Uberti wrote:
>     o  The endpoint MUST use the setup attribute defined in [RFC4145  <https://tools.ietf.org/html/rfc4145>].

The section quoted seem to refer to the initial offer/answer, later in 
that document (section 6.6, with heading "Session Modification") there 
is wording that (to me at least) hints at keeping the established roles 
in subsequent offers.

A different question is the value of initially offering actpass when ICE 
is mandatory to use. ICE connectivity checks will happen before the DTLS 
handshake, so perhaps initially offering passive would make sense. 
(actpass is a MUST according to 5763, OTOH 5763 is only an informal ref 
to JSEP.)

> answerer must choose active or passive appropriately.

Agreed.

> Chrome will fail
> upon an attempted role change.
>
> On Mon, Nov 24, 2014 at 7:36 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 16:28:22 +0000

> (actpass is a MUST according to 5763, OTOH 5763 is only an informal ref

<Raju>
Limiting it to "passive" would force the peer and/or intermediaries to support DTLS client functionality as well. IMHO, this may limit the success rate. If a peer or middlebox does not support DTLS client functionality then it can always return "passive", which may involve bit more delay in DTLS setup. But it is not that bad as the SDP offerer must wait for SDP answer (a=fingerprint is needed) before the DTLS can be setup successfully anyway.
</Raju>

BR
Raju

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 25 Nov 2014 17:38:32 +0000

On 25/11/14 17:28, Makaraju, Maridi Raju (Raju) wrote:
>>> 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
>>>
>> The section quoted seem to refer to the initial offer/answer, later
>> in that document (section 6.6, with heading "Session Modification")
>> there is wording that (to me at least) hints at keeping the
>> established roles in subsequent offers.
>>
>> A different question is the value of initially offering actpass
>> when ICE is mandatory to use. ICE connectivity checks will happen
>> before the DTLS handshake, so perhaps initially offering passive
>> would make sense. (actpass is a MUST according to 5763, OTOH 5763
>> is only an informal ref to JSEP.)
>
> <Raju> Limiting it to "passive" would force the peer and/or
> intermediaries to support DTLS client functionality as well. IMHO,
> this may limit the success rate. If a peer or middlebox does not
> support DTLS client functionality then it can always return
> "passive", which may involve bit more delay in DTLS setup. But it is
> not that bad as the SDP offerer must wait for SDP answer
> (a=fingerprint is needed) before the DTLS can be setup successfully
> anyway. </Raju>

Thanks Raju, seems this was a bad proposal - forget you heard it!

Do you have an opinion on my main "topic": that subsequent offers should 
offer the already negotiated role, rather than always "actpass"?

Br,
Stefan

> BR Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 18:30:02 +0000

> 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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 28 Nov 2014 13:44:30 +0000

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?

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Nov 2014 09:34:41 -0500

> for existing connections (and not actpass), but I'm not sure. What is
I actually have a more generic question: In what circumstances would new
DTLS connection handshake be initiated if transport parameters and
fingerprint did not change?

I assume new negotiation is required if subsequent offer contains active or
passive role that does not match the current connection state. What about
actpass? Is getting an actpass in the subsequent offer should mean that the
roles did not change and existing connection should continue to be re-used
or does it mean new negotiation should be started?

Should DTLS-SRTP endpoints be able to handle new DTLS handshake at any
time, without any associated signaling exchange? I do not think any of the
current browser implementations support that, even though such support
would be required for DTLS-SRTP rekey. If DTLS handshake handling at any
time is required, then end-points should only be forced to do a new
handshake by signaling if their roles change. If one of the end-points
turns out to be overzealous and starts an unexpected handshake, it would be
handled no differently then DTLS rekey, as long as roles stayed the same.

There is also a consideration, that the newly generated offer is intended
to be send to a completely new end-point and not to the existing
connection. This would most likely be known in advance for webrtc end
points, since they will need to collect a new set of ICE candidates, but
this can affect SIP end-points.

Since we would probably want to avoid extra handshakes, and that we want to
accommodate both offers intended for the existing and the new destinations,
we can state that in the subsequent offers, the end point should include
the actpass setup attribute. In the answer, if DTLS connection is already
setup, the end point should respond with the currently negotiated role. If
an end-point receives an offer with the non actpass setup attribute, it
should only initiate a new DTLS handshake if the specified attribute does
not match the currently negotiated setup state.
_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 28 Nov 2014 14:59:04 +0000

> for existing connections (and not actpass), but I'm not sure. What is

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Nov 2014 15:00:29 +0000

Hi,

You may want to take a look at the new version of the SCTP-SDP draft, where I have added procedures (and some open issues) regarding the usage of a=setup and a=connection.

> I actually have a more generic question: In what circumstances would new DTLS connection handshake be initiated if transport parameters and fingerprint did not change? 
>
> I assume new negotiation is required if subsequent offer contains active or passive role that does not match the current connection state. 
>
> What about actpass? Is getting an actpass in the subsequent offer should mean that the roles did not change and existing connection should continue to be re-used or does it mean new negotiation should be started?
>
> Should DTLS-SRTP endpoints be able to handle new DTLS handshake at any time, without any associated signaling exchange? I do not think any of the 
> current browser implementations support that, even though such support would be required for DTLS-SRTP rekey. If DTLS handshake 
> handling at any time is required, then end-points should only be forced to do a new handshake by signaling if their roles change. If one of the end-points 
> turns out to be overzealous and starts an unexpected handshake, it would be handled no differently then DTLS rekey, as long as roles stayed the same.
>
> There is also a consideration, that the newly generated offer is intended to be send to a completely new end-point and not to the existing connection. This would 
> most likely be known in advance for webrtc end points, since they will need to collect a new set of ICE candidates, but this can affect SIP end-points.
>
> Since we would probably want to avoid extra handshakes, and that we want to accommodate both offers intended for the existing and the new destinations, we can 
> state that in the subsequent offers, the end point should include the actpass setup attribute. In the answer, if DTLS connection is already setup, the end point should 
> respond with the currently negotiated role. If an end-point receives an offer with the non actpass setup attribute, it should only initiate a new DTLS handshake if the 
> specified attribute does not match the currently negotiated setup state.

RFC 7345 (UDPTL-DTLS) says the following:

	"Once an offer/answer exchange has been completed, either endpoint MAY
   	send a new offer in order to modify the session.  The endpoints can
   	reuse the existing DTLS association if the key fingerprint values and
   	transport parameters indicated by each endpoint are unchanged.
   	Otherwise, following the rules for the initial offer/answer exchange,
   	the endpoints can negotiate and create a new DTLS association and,
   	once created, delete the previous DTLS association, following the
   	same rules for the initial offer/answer exchange.  Each endpoint
   	needs to be prepared to receive data on both the new and old DTLS
   	associations as long as both are alive."

So, I guess that can be read in a way that the setup attribute as such does not impact previously negotiated TLS roles - unless the key fingerprint values and/or transport parameters are modified.

The SCTP-SDP draft currently says that a subsequent offer must not change the previously negotiated roles. But, I guess we could say something similar as in RFC 7345.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Nov 2014 18:22:56 -0500

On Fri, Nov 28, 2014 at 10:00 AM, Christer Holmberg <
[email-masked]> wrote:

> So, I guess that can be read in a way that the setup attribute as such
> does not impact previously negotiated TLS roles - unless the key
> fingerprint values and/or transport parameters are modified.
>
> The SCTP-SDP draft currently says that a subsequent offer must not change
> the previously negotiated roles. But, I guess we could say something
> similar as in RFC 7345.
>

I have struggled with this language quite a bit from the implementation
perspective. I think we need to explicitly state that endpoints MUST reuse
the existing association if the key fingerprint values and transport
parameters indicated by each endpoint are unchanged. The way this language
reads to me is that endpoints can reuse the existing association if they
want to, but they can create a new one if they don't. Also, when this new
association is created, it is unclear if old setup roles MUST be preserved
or if they MUST be selected based on the current offer/answer exchange. It
seems the current specification language is not strong or clear enough on
this topic.

Another implementation issue, unless I am greatly mistaken, is that the web
browsers will not currently handle creating a new DTLS association unless
they expect it to be created. I believe this to be a very critical issue
with DTLS implementations which will not only affect DTLS association
setup, but will also break re-key. I think, we should state that webrtc
end-point should expect new DTLS association with exiting setup roles and
key fingerprint to be created at any time.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Nov 2014 05:01:20 +0000

Hi,

>> So, I guess that can be read in a way that the setup attribute as such does not impact previously 
>> negotiated TLS roles - unless the key fingerprint values and/or transport parameters are modified.
>>
>> The SCTP-SDP draft currently says that a subsequent offer must not change the previously negotiated roles. But, I guess 
>> we could say something similar as in RFC 7345.
>
> I have struggled with this language quite a bit from the implementation perspective. I think we need to explicitly state 
> that endpoints MUST reuse the existing association if the key fingerprint values and transport parameters indicated 
> by each endpoint are unchanged.

We could take such general approach.

However, for ‘SCTP/DTLS’ (DTLS over SCTP), I assume that the DTLS connection will also be re-established if the underlying SCTP association is re-established - even if no transport parameters etc are changed.

Also, RFC 6083 says:

                “Each DTLS connection MUST be established and terminated within the same SCTP association.”

> The way this language reads to me is that endpoints can reuse the existing association if they want to, but they can create a new one if they don't. Also, when this new 
> association is created, it is unclear if old setup roles MUST be preserved or if they MUST be selected based on the current offer/answer exchange. It seems the current 
> specification language is not strong or clear enough on this topic.

In my opinion, IF a new DTLS connection needs to be established (for whatever reasons), the current roles should be used.

BTW, I think this whole discussion belongs to MMUSIC, as it is Offer/Answer related :)

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 30 Nov 2014 13:50:54 +0000

> does not impact previously
> the previously negotiated roles. But, I guess
> perspective. I think we need to explicitly state
> > that endpoints MUST reuse the existing association if the key fingerprint
> values and transport parameters indicated
> However, for ‘SCTP/DTLS’ (DTLS over SCTP), I assume that the DTLS connection
> will also be re-established if the underlying SCTP association is re-
> established - even if no transport parameters etc are changed.
> 
> Also, RFC 6083 says:
> 
> > The way this language reads to me is that endpoints can reuse the existing
> association if they want to, but they can create a new one if they don't.
> Also, when this new
> seems the current
> In my opinion, IF a new DTLS connection needs to be established (for
> whatever reasons), the current roles should be used.

<Raju>
When ICE is NOT used, how does the offerer know that the answerer does not change the fingerprint and/or transport parameters? I guess it does not know. So, offerer has to be prepared for new DTLS association by offering actpass.
When ICE is used, the answerer can't change transport parameter unless offerer does ICE restart (which changes offerer transport parameters); Ref [1] is very clear on this indicating "DTLS handshake procedure is repeated". However, even when ICE is used, I do not find any restriction about answerer not changing fingerprint. So, even without ICE restart answerer can trigger a DTLS renegotiation by changing its fingerprint.

To conclude all this, IMO whether ICE is used or not, sending actpass for all new offers may be cover all possible scenarios.

[1] http://tools.ietf.org/html/rfc7345#page-8
   In the case of an ICE restart, the DTLS
   handshake procedure is repeated, and a new DTLS association is
   created.  Once the DTLS handshake is completed and the new DTLS
   association has been created, the previous DTLS association is
   deleted.

</Raju>

BR
Raju

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 30 Nov 2014 14:20:56 +0000

On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote:
>>>> "Once an offer/answer exchange has been completed, either
>>>> endpoint
>> MAY
>>>> send a new offer in order to modify the session.  The
>>>> endpoints
>> can
>>>> reuse the existing DTLS association if the key fingerprint
>>>> values
>> and
>>>> the endpoints can negotiate and create a new DTLS association
>>>> and, once created, delete the previous DTLS association,
>>>> following the same rules for the initial offer/answer exchange.
>>>> Each endpoint needs to be prepared to receive data on both the
>>>> new and old DTLS associations as long as both are alive."
>>>>
>>>> negotiated TLS roles - unless the key fingerprint values and/or
>>>> transport
>> parameters are modified.
>>>>
>> However, for ‘SCTP/DTLS’ (DTLS over SCTP), I assume that the DTLS
>> connection will also be re-established if the underlying SCTP
>> association is re- established - even if no transport parameters
>> etc are changed.
>>
>> Also, RFC 6083 says:
>>
>> association if they want to, but they can create a new one if they
>> don't. Also, when this new
>> or if they MUST be selected based on the current offer/answer
>> exchange. It seems the current
>> In my opinion, IF a new DTLS connection needs to be established
>> (for whatever reasons), the current roles should be used.
>
> <Raju> When ICE is NOT used, how does the offerer know that the
> answerer does not change the fingerprint and/or transport parameters?
> I guess it does not know. So, offerer has to be prepared for new DTLS
> association by offering actpass. When ICE is used, the answerer can't
> change transport parameter unless offerer does ICE restart (which
> changes offerer transport parameters); Ref [1] is very clear on this
> indicating "DTLS handshake procedure is repeated". However, even when
> ICE is used, I do not find any restriction about answerer not
> changing fingerprint. So, even without ICE restart answerer can
> trigger a DTLS renegotiation by changing its fingerprint.
>
> To conclude all this, IMO whether ICE is used or not, sending actpass
> for all new offers may be cover all possible scenarios.

That is also my conclusion based on the discussion so far.

I also think the JSEP draft as far as detailed out is correct, but info 
about how the implementation should behave for Subsequent answers is 
missing. Text saying that the role must be maintained (unless there is 
an ICE restart) should be put in there.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 30 Nov 2014 15:06:20 +0000

> >> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the DTLS
> >> "Each DTLS connection MUST be established and terminated within the
> >> same SCTP association."
> >>
> >>

<Raju>
Hi Stefan,
Looks like, there is some misunderstanding here. My conclusion is to include
actpass, but not the previously negotiated role, in all subsequent offers, 
not just during ICE-restarts.
This is to handle the scenario of answerer changing fingerprint, which
is allowed (i.e. not explicitly disallowed), in a more
natural way by renegotiating the roles. Entity which wants to change fingerprint
may also want to renegotiate the role even when transport parameters are not changed.

Also, when ICE is not used answerer can change transport parameters which needs 
renegotiation of roles.

So, to have uniform rules for ICE (restart or not) and no ICE it is better to
send the role in subsequent offer as if it is an initial offer (i.e. actpass).
</Raju>

BR
Raju

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 30 Nov 2014 15:26:45 +0000

On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote:
> Looks like, there is some misunderstanding here.

Probably my fault in that case :)

> My conclusion is to include

I think that is what the JSEP draft says - and my conclusion is that it 
_is_ correct.

My point was that the _answer_ should (when it is a subsequent answer) 
should say the same role as in previous answers (unless there is an ICE 
restart).

> send the role in subsequent offer as if it is an initial offer (i.e. actpass).

That is also my understanding (and what the JSEP draft says).

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Nov 2014 15:29:05 +0000

Hi,

If some clarification regarding this is needed, I don't think it should be in the JSEP draft.

If it's related to SDP Offer/Answer in general, it should be in an MMUSIC spec, referenced by JSEP.

Regards,

Christer

-----Original Message-----
From: Stefan Håkansson LK 
Sent: 30 November 2014 17:27
To: Makaraju, Maridi Raju (Raju); Christer Holmberg; Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote:
>>> I guess it does not know. So, offerer has to be prepared for new 
>>> DTLS association by offering actpass. When ICE is used, the answerer 
>>> can't change transport parameter unless offerer does ICE restart 
>>> (which changes offerer transport parameters); Ref [1] is very clear 
>>> on this indicating "DTLS handshake procedure is repeated". However, 
>>> even when ICE is used, I do not find any restriction about answerer 
>>> not changing fingerprint. So, even without ICE restart answerer can 
>>> To conclude all this, IMO whether ICE is used or not, sending 
>>> actpass for all new offers may be cover all possible scenarios.
>>
>> I also think the JSEP draft as far as detailed out is correct, but 
>> info about how the implementation should behave for Subsequent 
>> answers is missing. Text saying that the role must be maintained 
>> (unless there is an ICE restart) should be put in there.
>
> <Raju>
> Hi Stefan,

> actpass, but not the previously negotiated role, in all subsequent 
> offers, not just during ICE-restarts.

I think that is what the JSEP draft says - and my conclusion is that it _is_ correct.

My point was that the _answer_ should (when it is a subsequent answer) should say the same role as in previous answers (unless there is an ICE restart).

> is allowed (i.e. not explicitly disallowed), in a more natural way by 
> renegotiating the roles. Entity which wants to change fingerprint may 
> also want to renegotiate the role even when transport parameters are not changed.
>
> Also, when ICE is not used answerer can change transport parameters 
> which needs renegotiation of roles.
>
> So, to have uniform rules for ICE (restart or not) and no ICE it is 
> better to send the role in subsequent offer as if it is an initial offer (i.e. actpass).

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 30 Nov 2014 17:18:02 +0000

> should say the same role as in previous answers (unless there is an ICE

<Raju>
Hi Stefan,
Sorry, it was my misunderstanding in not reading your text correctly.
I did not pay attention to "_answer_" part.
I agree with you that subsequent answers SHOULD (not MUST) keep 
previously negotiated role (except for ICE restarts).
However, as Christer pointed out such clarification belong to SCTP 
SDP draft though.
</Raju>

BR
Raju