2 min read
In CWMP, the CPE is always the initiator of sessions. It begins each session with a call to the Inform RPC, which contains EVENT codes that specify to the ACS the reason for the session.
One way the that ACS can entice a CPE to begin a session is with the Connection Request mechanism. In TR-069 Amendment 4 and earlier, this was done exclusively with HTTP, though an option for XMPP Connection Requests was added in Amendment 5.
In either case, the Connection Request is a stateful mechanism where the ACS sends the request to a URL specified by the CPE. The CPE authenticates that request to make sure it’s coming from the ACS it is assigned to. It then responds with a 200 OK or 204 No Content message to the ACS, and then initates a CWMP session with the ACS using the "6 CONNECTION REQUEST" event code.
The problem arises when the the CPE tries to initiate the new session before it has responded to the Connection Request. While the ACS should expect the CPE to initiate a session for any reason, many ACS will try to keep track of (or cut down on) sessions by matching each session to a particular connection request. Starting a session before the Connection Request is confirmed may also trigger the ACS to think that it was not completed and initiate another Connection Request.
This functionality is also spelled out in a requirement in TR-069:
The CPE’s response to a successfully authenticated Connection Request MUST use either a ―200 (OK) or a ―204 (No Content) HTTP status code. The CPE MUST send this response immediately upon successful authentication, prior to it initiating the resulting Session. The length of the message-body in the HTTP response MUST be zero.
Thus, the CPE is expected to respond to the Connection Request before initiating a CWMP session based on that Connection Request.
