I second this amendment because without prior knowledge of RELOAD I can see implementors wondering about this ICE /TCP scenario.
Julian On Jan 20, 2010, at 11:21 PM, Michael Chen wrote: > Hi, > > Regarding the value for AttachReqAns.role: > > /* > * RELOAD 5.5.1.8. Role Determination > * > * "The roles of controlling and controlled as described in Section 5.2 > * of ICE are still utilized with RELOAD. However, the offerer (the > * entity sending the Attach request) will always be controlling, and > * the answerer (the entity sending the Attach response) will always be > * controlled." > * > * RELOAD 5.5.1.13. Sending Media > * > * "Consequently, once ICE processing completes, the agent will begin > * TLS or DTLS procedures to establish a secure connection. The node > * which sent the Attach request MUST be the TLS server. The other > * node MUST be the TLS client." > * > * Therefore, according to RFC-4145, the offerer (ICE controlling) > * MUST take the 'passive' role and the answerer (ICE controlled) > * MUST take the 'active' role. > */ > > I want the group to confirm this, because it seems counter-intuitive. If this > is true, then I suggest the following change to the definition of 'role' in > section 5.5.1.1 to help implementers avoid a critical mistake: > > role > An active/passive/actpass attribute from RFC 4145 [RFC4145]. > This value MUST be 'passive' for the offerer (the peer sending > the Attach request) and 'active' for the answerer (the peer > sending the Attach response). > > Thanks > > --Michael > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
