MT#55283 amend publish docs

and fix typoes

Change-Id: Ia7b03b14c6a0dd879f3815cf8c3d5611c74ed0dd

docs/ng_control_protocol.md

@@ -2533,9 +2533,16 @@ Similar to an `offer` message except that it is used outside of an offer/answer
 scenario. The media described by the SDP is published to *rtpengine* directly,
 and other peer can then subscribe to the published media to receive a copy.
 
-The message must include the key `sdp` which should describe `sendonly` media;
-and the key `call-id` and `from-tag` to identify the publisher. Most other keys
-and options supported by `offer` are also supported for `publish`.
+The message must include the key `sdp` which should describe `sendonly` media
+(but see below).
+
+The keys `call-id` and `from-tag` may be included to identify the publisher,
+and may refer to an existing publisher or participant to a call. If these keys
+are absent, random strings will be generated to create a new call and/or
+publisher, and they will be returned in the response message.
+
+Most other keys and options supported by `offer` are also supported for
+`publish`.
 
 The reply message will contain an answer SDP in `sdp`, but unlike with `offer`
 this is not a rewritten version of the received SDP, but rather a `recvonly`
@@ -2544,6 +2551,9 @@ section will be listed, and by default this will be the first supported codec
 from the published media. This can be influenced with the `codec` options
 described above, in particular the `accept` option.
 
+The flag `bidirectional` may be included to support `sendrecv` media instead of
+forcing a `recvonly` and `sendonly` pair.
+
 The list of codecs given in the `accept` option is treated as a list of codec
 preferences, with the first codec listed being the most preferred codec to be
 accepted, and so on. It is allowable to list codecs that are not supported for
@@ -2664,11 +2674,11 @@ Example:
 
 ## `connect` Message
 
-This message makes it posible to directly connect the media of two call parties
+This message makes it possible to directly connect the media of two call parties
 without the need for a full offer/answer exchange. The required keys are
 `call-id` to identify the call, and `from-tag and `to-tag` to identify the two
 call parties to connect. The media will be connected in the same way as it
-would through an offer/answer exchange. Transcoding will automaticaly be
+would through an offer/answer exchange. Transcoding will automatically be
 engaged if needed.
 
 It's also possible to connect two call parties from two different calls