Issue 187: Behavior when encodings are not set

Is it possible for receiver.receive(parameters) or sender.send(parameters) to be called with parameter.encodings not set?  If so, what happens then?

Looking at the RTCRtpEncodingParameters dictionary, if the developer doesn't need fec or rtx, isn't doing simulcast or layered coding, can live with a default assumption that active=true, and doesn't want to choose the ssrc (for a sender) or specify an ssrc for incoming packets (receiver) then it should be ok for the developer not to set parameter.encodings.

dictionary RTCRtpEncodingParameters {
    unsigned long       ssrc;
    payloadtype         codecPayloadType;
    RTCRtpFecParameters fec;
    RTCRtpRtxParameters rtx;
    double              priority = 1.0;
    unsigned long long  maxBitrate;
    double              minQuality = 0;
    double              framerateBias = 0.5;
    double              resolutionScale;
    double              framerateScale;
    boolean             active = true;
    DOMString           encodingId;
    sequence<DOMString> dependencyEncodingIds;
};

The trickier question is what this means for Section 8.2, RTP packet routing. Here are some ideas:

When parameters.encodings is not set when calling receiver.receive(parameters), then when an incoming packet matches a pt_table[packet.pt] entry,
then an ssrc_table[] entry is added, but the pt_table[] entry is not removed.

When parameters.encodings is not set when calling sender.send(parameters), then the browser chooses an SSRC for the sender,
and default values of RTCRtpEncodingParameters are assumed.