Draft: draft-ietf-rtcweb-jsep

Commentary: I think this is close enough to merge it , put it out in a draft , and see what the WG things 
 This LGTM . 
 overall , this looks like it 's on the right track . Main question ( for really ) is whether this should be turned more into prose rather than a W3C - style algorithm . ( i.e. " First , check this . Then , do that . Next , do this other thing . Finally , drop the packet . " ) 
  , if there is anything I can do to help on this one today . Ping me and I will make it top priority . 
 A response to  's comment about when the tables are constructed : I think it 's clear that the tables need to be constructed after the transport exists , but before the first packet is routed . But an implementation could choose whether to construct it right after the transport is created or right before the first packet is routed . I do n't think we need to specify that . You do bring up a really good point about updating the table over time . We know entries can be by setLocalDescription / setRemoteDescription and removed by setLocalDescription / setRemoteDescription and But that 's not covered at all by the text written so far . 
 FYI , I updated this to address  's comment about updating the tables over time . I a paragraph saying what the results of updates should be , but leaves the when and how up to the implementation . 
 Cover MID , RID , unsignaled SSRCs , and RTCP . Related to and . 
 Suggest doing this in a new Section 5.10 on demux . 
 Actually , now that I think about it , we do n't need to specify how to handle RID at all . We could just way " receive all the source RTP streams that come in and use RtpStreamID and RepairedRtpStreamID to correlate source RTP streams and repair RTP streams " . In other words , the RIDs do n't need to be signalled to the receiver . If I 'm correct about this , we can have a simplified version : When an RtpReceiver is , removed , or has its parameters modified , the following is done : 
 We had discussion during IETF that there is a need for a RTP media plane specification related to simulcast and the different types of RTP middleboxes to clarify where the various SDES items need to occur and which types of SSRC , MID and RID switching behavior that can occur on the various legs . This will clearly spark discussion as there was diverse views between Emil Ivov ,   , and   .   had observed I think 4 different behaviours . 
 Need to not forget the case where there are multiple ports that help disambiguate . 
 For the case of multiple ports : I think all we need to do is point out that the algorithm applies to each of the RtpReceivers listening on a given port . In other words , demux is per - port . And obviously if you have only one RtpReceiver per port , there 's nothing to do except check that the PT is known , which I think the algorithm I posted covers . 
 This looks reasonable except that the style is a bit inconsistent . specifically : for each encoding e in r.getParameters().encodings : receiverbyssrc [ ] = r 
 Here 's some possible text , with slightly tweaked pseudo - code to match : When an RTP packet is received by a transport ( typically a DtlsTransport ) , that packet MUST be routed to the correct RtpReceiver . For each transport , the following steps MUST be followed to prepare to route packets : a table mapping MID to RtpReceiver . For each RtpReceiver configured to receive from this transport , let the key be the RtpReceiver 's MID , and the value be the RtpReceiver . a table mapping SSRC to RtpReceiver . For each RtpReceiver configured to receive from this transport , and for each SSRC that RtpReceiver is configured to receive , let the key be the SSRC and the value be the RtpReceiver . a table mapping Payload Type to RtpReceiver . For each RtpReceiver configured to receive from this transport , and for each Payload Type that RtpReceiver is configured to receive , let the key be the Payload Type and the value be the RtpReceiver . For each RTP packet received , the following steps MUST be followed to route the packet : the packet has a MID and that MID is not in the table mapping MID to RtpReceiver , drop the packet and stop . the packet has a MID and that MID is in the table mapping MID to RtpReceiver , update the SSRC mapping table to include an entry mapping the packet 's SSRC to the RtpReceiver . the packet 's SSRC is in the SSRC mapping table , route the packet to the mapped RtpReceiver and stop . the packet 's Payload Type is in the Payload Type table , update the the SSRC mapping table to include an entry mapping the packet ’s SSRC to the RtpReceiver . Deliver the packet to the RtpReceiver and stop . the packet . Note : When designing these steps , a troubling possible use case was if the MIDs were lost in signaling , but still sent in RTP packets . But a packet would only be sent with MIDs if an answer were sent with MIDs in it . If there are no MIDs in the answer , then MIDs would not be present in the RTP . And if MIDs are in the answer , they were n't lost from the signaling . In other words , this case will not happen . This would correspond to pseudocode something like this : 
 PR : 
 Resolved by 
 Submitted some thoughts . As usual , the devil is the details . This overall LGTM . A handful of editorial comments . LGTM
Paragraph (version B):
Note: The following algorithm does not yet have WG consensus but is
included here as something concrete for the working group to discuss.
Paragraph (version B):
Construct a table mapping MID to RtpReceiver for each RtpReceiver
configured to receive from this transport.
Paragraph (version B):
Construct a table mapping SSRC to RtpReceiver for each RtpReceiver
configured to receive from this transport and for each SSRC that
RtpReceiver is configured to receive.  Some of the SSRCs may be
presesnt in the m= section corresponding to that RtpReceiver in
the remote description.
Paragraph (version B):
Construct a table mapping payload type to RtpReceiver for each
RtpReceiver configured to receive from this transport and for each
payload type that RtpReceiver is configured to receive.  The
payload types of a given RtpReceiver are found in the m= section
corresponding to that RtpReceiver in the local description.  If
any payload type could map to more than one RtpReceiver, map to
the RtpReceiver whose m= section appears earliest in the local
description.
Paragraph (version B):
If the packet has a MID and that MID is not in the table mapping
MID to RtpReceiver, drop the packet and stop.
Paragraph (version B):
If the packet has a MID and that MID is in the table mapping MID
to RtpReceiver, update the SSRC mapping table to include an entry
mapping the packet's SSRC to the RtpReceiver.
Paragraph (version B):
If the packet's SSRC is in the SSRC mapping table, route the
packet to the mapped RtpReceiver and stop.
Paragraph (version B):
If the packet's payload type is in the payload type table, update
the the SSRC mapping table to include an entry mapping the
packet's SSRC to the RtpReceiver.  Deliver the packet to the
RtpReceiver and stop.
Paragraph (version B):
Otherwise, drop the packet.
Paragraph (version B):
After packets are routed to the RtpReceiver, further processing of
the RTP packets is done at the RtpReceiver level.  This includes
using I-D.ietf-mmusic-rid to determine which RTP streams depend on or
repair other RTP streams.
Paragraph (version B):
As RtpTransceivers (and, thus, RtpReceivers) are added, removed,
stopped, or reconfigured, the tables above must also be updated.