diff --git a/docs/ng_control_protocol.md b/docs/ng_control_protocol.md index fbf487e5e..1cc497092 100644 --- a/docs/ng_control_protocol.md +++ b/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