Michael, IIRC, an earlier draft said that, but there were requests that the keepalive method be left up to the application using it, as that consumer may have its own keepalive method and it might even be hard to convert that application (and its implementation) to work on such a link, so it was changed to the current wording. Basically, any draft that specifies how an application would use a connection established via AppAttach needs to specify its keepalive method.
Bruce On Tue, Feb 14, 2012 at 8:56 PM, Michael Chen <[email protected]> wrote: > Hi, > > In base draft, section 5.5.2.1 (about AppAttach), it states, > > "The application using connection set up with this request is > responsible for providing sufficiently frequent keep traffic for NAT > and Firewall keep alive and for deciding when to close the > connection." > > When such a connection is established by ICE, it means that it is > capable of multiplexing STUN bind and indication messages with other > messages (application). Wouldn't it be natural for the RELOAD layer that > completed the ICE check and DTLS to also use STUN indication message to > keep everything alive (firewall, connection, UDP session, etc.)? which > is identical to that of a connection created from the Attach message. > > This is an inter-op issue that must be approved or disapproved by this > draft, so I would like to hear comments from the authors. > > Thank you > > --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
