Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type

Gunnar Hellström <> Thu, 23 April 2020 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7686B3A0CDE for <>; Thu, 23 Apr 2020 09:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SUVCghvbzf5U for <>; Thu, 23 Apr 2020 09:59:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F26C3A0C41 for <>; Thu, 23 Apr 2020 09:59:36 -0700 (PDT)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 8DBF620052; Thu, 23 Apr 2020 18:59:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1587661174; bh=d2yoZv9JbkVhy5kBi+eiRV/61zTP3IBzI+FmKtRFWtE=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=pyLjcwf+LJWaHMvGgyFf3zJzFbDiitZg5p+kqAl3iwA78tE48oY+Berq4wAanUiZA VJZsS22BEw00rwdA94tYTJSeFIuN+AvRJ1LUh53NMvrcgQMHYg8B/xZ2xmu1z6efIc 0EVUHe9HdMix5Ow1L7W7f1KRWn6IMb6wqpW96aJ0=
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
To: "Dale R. Worley" <>
References: <> <>
Message-ID: <>
Date: Thu, 23 Apr 2020 18:59:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F114FA113883D24FC5935F17"
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Apr 2020 16:59:43 -0000

Hi Dale,

Here is a bit more on the use of multiple SSRC:s in an RTP session.

In that old discussion, there was no idea proposed for how to signal a 
new participant in the conference. But there were multiple people 
preferring a solution with multiple SSRCs in the same RTP session. 
Similarly in this new discussion.

There is a possibility to signal a new SSRC for the case that the RFC 
4535 - 4575 - 4579 family for SIP centralised conference is used.  Then 
the RFC 4575 SIP Notify sent by the focus can be specified to contain a 
text media member, with a src-id element containing the SSRC of the 
added participant. So, if current RTP implementations have an API that 
tells it to accept a new stream with SSRC=x then a mechanism with 
multiple SSRCs might be used. Do they have that?

For simplicitly, the Payload Type numbers should be the same for all 
streams, otherwise there would need to be reInvites for every new 
participant, adding PT numbers to the m-line.

I am afraid that we get into too many uncertain areas just as we did 
when discussing the same topic in 2011, so that we should return to the 
single stream solution.



Den 2020-04-23 kl. 10:36, skrev Gunnar Hellström:
> Hi Dale,
> Thanks, a good question. It is the right time to consider which source 
> multiplexing and reliability method to select, now when we need to 
> introduce a new negotiation.
> More below
> Den 2020-04-23 kl. 04:27, skrev Dale R. Worley:
>> I assume that there's a good reason why the case of redundant
>> transmission of multi-party text isn't done by suitably interleaving the
>> redundant packets of the serveral text sources (which can be separated
>> by their SSRC values).  I can't remember if this is a violation of the
>> RTP rules, or perhaps it's just inefficient.  But a quick read of the
>> draft didn't mention why this approach doesn't work, and it seems like
>> it would be a useful note to the reader.
> Draft-hellstrom-avtcore-multi-party-rtt-source is intended to contain 
> the solution for the type of bridge used in NG9-1-1 and 3GPP IMS, 
> which seems to be based on the RFC4535 SIP centralised conference 
> framework.
> Backgrounds and discussions of possible methods with a wider scope are 
> collected in
> draft-hellstrom-avtcore-multi-party-rtt-solutions
> <>
> where section 4.2.1 is similar to what you propose with separate 
> ssrc:s per source. Each discussed method also has pros and cons 
> briefly documented. Having separate SSRC per source is what RTP calls 
> using a RTP translator.
> Yes, I would have liked to use that method. But we have an urgency in 
> implementing the selected method in NG9-1-1 systems and in 3GPP IMS. 
> And it is said that many current RTP implementations do not support 
> multiple SSRCs in the same RTP session and even that RFC 3264 says 
> that one m-section in sdp can only support one SSRC. However, RFC 4588 
> (FEC) section 8.8 shows an SSRC-multiplexing sdp example where the 
> original media stream has one SSRC and the redundancy another within 
> the same m-section. But that is of course no evidence that current RTP 
> implementations support it.
> RFC 8108 clarifies in section 3.3 that one of its applications is for 
> combining multiple media sources of the same kind in the same RTP 
> session. But it has the total goal of multiplexing also multiple media 
> in the same RTP session. The corresponding sdp specification (with a 
> much wider scope than we need) is 
> draft-ietf-mmusic-sdp-bundle-negotiation and it is not supported by 
> many current RTP implementations ( but maybe soon is because of its 
> use in WebRTC).
> Methods that could be considered but are not yet documented in 
> draft-hellstrom-avtcore-multi-party-rtt-solutions 
> <> 
> are (excuse me if some look far fetched):
> RFC 4588 FEC, using SSRC multiplexing if that works or session 
> multiplexing if needed. In this case plain T.140 RTP would be sent 
> from the mixer in one stream, with the ssrc of the mixer and csrc of 
> the source, and in the redundancy stream the packets would be repeated 
> (twice) with another ssrc in a small redundancy header.
> RFC 8122 Comedia to improve reliability, but then I have not studied 
> how to arrange for multi-party use.
> draft-ietf-mmusic-t140-usage-data-channel using one WebRTC data 
> channel per source.
> RFC 8108 section 3.3 and draft-ietf-mmusic-sdp-bundle-negotiation
> Avoiding solutions because of imagined limitations in current 
> implementations may be a bad design criterium, so do you suggest that 
> we rapidly look further into any of these or other options?
> Thanks
> Gunnar
>> Dale
> -- 
> Gunnar Hellström
> GHAccess
> _______________________________________________
> Audio/Video Transport Core Maintenance

Gunnar Hellström