Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching

Roman Shpount <> Thu, 04 June 2015 21:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 73FF21AC3B2 for <>; Thu, 4 Jun 2015 14:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uZNz70TNFcg0 for <>; Thu, 4 Jun 2015 14:02:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A66C1AC3B0 for <>; Thu, 4 Jun 2015 14:02:47 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so1346889igb.0 for <>; Thu, 04 Jun 2015 14:02:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ii6GtkWTLWVscoLzovrfunXTK4N2fm2jLyLIzS2u270=; b=KjDO87PBFmHuIrB2TEuERq4n+A6z130hNUj+gy+xRHSQVUwWXutDP0ya6/S7cBuQaO Q3XoKd+go0NHQ49MgegIE1jUvbh429wt6AuOG77llLuuAwBtdybEFmtSp7lodSkDXDXq o6EtOAdoGo5ZqMRFF/HLZuhnDk2mpJCIUVdwuV812zMLwbLj1aacFxlr9ihx1ndKM+fb fIdVkIs6wxB1mxwPsw2au86tlDuvN3ll0Zh4k5SpJwORximpiwQqRfmjDBwI9oFoVkJY RIre2lknATxpKiZVNr0KEjyBr18Lg+dcT8CTxY+AQsrAR8XhcybmRXjGXw5JAKdZTJhX UrFw==
X-Gm-Message-State: ALoCoQkczHRMpws7Rz0eggwZorrs2pL/U9hmcGBXUa6j9OLHan/6ahWjEggA9zF+g46J2CCyT5gd
X-Received: by with SMTP id m140mr5945137ioe.85.1433451766526; Thu, 04 Jun 2015 14:02:46 -0700 (PDT)
Received: from ( []) by with ESMTPSA id j5sm1924344ioo.8.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2015 14:02:45 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so1324358igb.1 for <>; Thu, 04 Jun 2015 14:02:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id d71mr30363294ioe.29.1433451764219; Thu, 04 Jun 2015 14:02:44 -0700 (PDT)
Received: by with HTTP; Thu, 4 Jun 2015 14:02:44 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 04 Jun 2015 17:02:44 -0400
Message-ID: <>
From: Roman Shpount <>
To: Harald Alvestrand <>
Content-Type: multipart/alternative; boundary="001a1140eada359a950517b77f3a"
Archived-At: <>
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jun 2015 21:02:48 -0000

On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand <>

> If we want to have a mechanism that:
> a) allows PT switching
> b) uses different clock rates (and therefore different SSRCs)
> c) doesn't need renegotiation on SSRC change
> I would think that the initial SDP would have to contain a=ssrc fields for
> *all* the possible SSRCs - that is, one "a=ssrc:<nnnn> cname:<cname>" line
> per payload type.
> Section 5.2.1 already specifies that there will be multiple a=ssrc lines
> (and a=ssrc-group lines) in the case of RTX data. So it's not exactly a
> novel solution.
I agree with one small correction -- it is not a separate SSRC per payload
type, but separate SSRC per clock rate. For instance, if you have G.711
audio, RFC 4733 tones and CN at 8KHz, there is going to be a payload type
for each of them, but all this media should use the same SSRC. Opus, RFC
4733 tones and CN at 48Khz (and you will need to specify to different
payloads for tones and CN for different clock rates), will use second SSRC.

The reason for separate SSRCs is to have RTCP reports to work correctly,
which requires to use the same time units for all the media under
particular SSRC. Multiple payloads running with the same clock rate can
re-use the same SSRC without any issues. It actually is beneficial to use
the same SSRC since they can be synchronized based on the RTP time stamps
which would be more precise then ntp time.
Roman Shpount