New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "RTP Sending Rules" section #473

Closed
ibc opened this Issue Apr 18, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@ibc
Contributor

ibc commented Apr 18, 2016

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

This comment has been minimized.

Contributor

aboba commented Jan 11, 2017

@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

This comment has been minimized.

Contributor

ibc commented Jan 11, 2017

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?

aboba added a commit that referenced this issue Oct 9, 2017

Checks for send()
Fix for Issues #564 and #473

@aboba aboba referenced this issue Oct 9, 2017

Merged

Checks for send() #784

@aboba

This comment has been minimized.

Contributor

aboba commented Apr 28, 2018

The specification has added some common checks for both send() and receive() in Section 5.4. If additional checks are needed, please file an issue.

@aboba aboba closed this Apr 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment