Subject: Re: [siprec] Multiplexing different participants' streams on the same port

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Mar 2011 13:28:23 +0200

I would like to revive this discussion. I had a chat with a couple of RTP experts (Colin Perkins, Magnus Westerlund), and they felt that the more natural way of sending to an SRS streams of the same medium on behalf of two or more parties would be to send them on the same port with different SSRC values. This means we would need to get from a participant-stream in the metadata model to an SSRC value. There may be different possibilities here (e.g., metadata contains CNAME as well as label, and SDP media description contains CNAME to SSRC mapping). There are SDP extensions that might help here, which I won't try to go in to here.

Multiplexing different parties on the same port, rather than additional ports, has the benefit of port saving, which might be an issue for the SRS (which already has to provide sufficient ports for multiple recording sessions and multiple media on those sessions). It might also be an issue for NATs. Reducing the number of ports would also reduce the amount of ICE processing, if ICE is used.

Likewise RTP-RTCP multiplexing would achieve benefits.

I would like to visit this briefly in the SIPREC session on Thursday, under the protocol discussion.

John (as chair)

> -----Original Message-----
> From: Elwell, John 
> Sent: 18 March 2011 08:11
> To: [email-masked]
> Subject: Multiplexing different participants' streams on the same port
> 
> Something Charles mentioned in another thread triggered me to 
> raise this.
> 
> We consider different participants in the CS as potentially 
> producing separate media streams that the SRC sends to the 
> SRS, where the SRC can send them mixed or unmixed.
> 
> When sending them unmixed, up till now I think we have 
> considered sending them to separate ports on the SRS and 
> identifying them as separate m= lines in the SDP. Another 
> possibility might be to multiplex the different streams on 
> the same port and identify them by different SSRC values. I 
> am not sure whether this would be a correct use of SSRC, and 
> I suspect we would need to check with AVTCORE. Recent 
> discussions in other contexts (telepresence, RTC-Web) have 
> also drawn my attention to such possibilities. See also 
> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/.
> 
> Of course, it would mean that we would have to rethink how we 
> reference the different streams from metadata.
> 
> I am not necessarily proposing such a change - I just want to 
> make sure we have given it due consideration.
> 
> John (as individual)
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Mar 2011 08:26:20 -0400

John,

ISTM that we could *allow* this, but that we should not require that the 
SRC do it this way. (It may not have enough control to do it that way.)

	Thanks,
	Paul

On 3/29/2011 7:28 AM, Elwell, John wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>