Add "RTP Sending Rules" section

[ibc]

The spec already includes a "RTP matching rules" so implementors can follow, step by step, and figure out how to deal with received RTP given receive(parameters). So I suggest the spec should also include a "RTP sending rules" for implementors to figure out what exactly to do when send(parameters) is called, step by step.

After all the rationale given in #471 I do understand what the spec tries to state, but I consider it extremely difficult to be understood by newcomers by just reading the spec. So I mean guidelines such as:

• If there is no encodings create an empty one with codecPayloadType pointing to the first media codec (no DTMF, CN, etc) in the codecs list.
• If no muxId or ssrc is filled into an encoding generate random ones and fill those fields.
• For each encoding with no dependencyEncodingId field a new RTP stream is required, so uniqueness of their ssrc values is required (or fill them following that requirement).
• etc etc etc.

[aboba]

@ibc I'm assuming that one of the things that needs to be covered in the "sending rules" is use of SSRC attributes. For example, when calling receive(), there are reasons why it might make sense to require that if SSRCs are included in parameters.encodings[].ssrc, then they can't be omitted from parameters.encodings[].rtx.ssrc or parameter.encodings[].fec.ssrc (e.g. all or nothing).

Do you think that similar logic applies to the send() method?

[ibc]

I think similar rationale applies. Does it make sense to call send() with encoding[0].ssrc set, encoding[0].rtx set, but encoding[0].rtx.ssrc unset?