diff --git a/docs/ng_control_protocol.md b/docs/ng_control_protocol.md
index 902168f3d..30b39adef 100644
--- a/docs/ng_control_protocol.md
+++ b/docs/ng_control_protocol.md
@@ -100,6 +100,32 @@ Of course the agent controlling *rtpengine* using the *NG* protocol does not hav
 to be a SIP proxy (e.g. kamailio). Any process that involves SDP can potentially talk to
 *rtpengine* using this protocol.
 
+As mentioned already, each NG-protocol message can include optional flags in order
+to cause specific behavior for this particular SDP offer/answer
+(e.g. transport, transcoding, preferred encryption parameters etc.)
+
+The parsing of option flags (sometimes also called *rtpp flags*) can be done:
+* by remote SIP proxy (e.g. kamailio)
+* by rtpengine itself
+
+*NOTE: currently parsing on the daemon side is implemented, but not all control agents
+*may support it. As of the time of writing only the kamailio module uses it.*
+
+The difference between two approaches is that in the first case, the parsing of flags
+is done with help of module, meanwhile in the second case a list of flags is passed
+to rtpengine using bencode string format and is then parsed here.
+The benefit of the second approach is that any new flags supported by rtpengine
+will automatically be supported without having to worry about support in the control module.
+
+When the flags are passed to rtpengine, they are formated as following:
+
+	{ "rtpp_flags": "replace-origin replace-session-connection via-branch=auto-next strict-source label=callee OSRTP-accept transport-protocol=RTP/AVP address-family=IP4" }
+
+Regardless whether the flags parsing is done by the module or daemon,
+a functional behavior remains the same and has no difference in terms of SDP processing.
+
+## Messages description
+
 ## `ping` Message
 
 The request dictionary contains no other keys and the reply dictionary also contains no other keys. The