Re: [MMUSIC] Proposal for what bundle should say about demux

Emil Ivov <> Fri, 24 May 2013 07:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EA5A21F9434 for <>; Fri, 24 May 2013 00:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id biEf1vkZxtv3 for <>; Fri, 24 May 2013 00:08:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4008:c01::235]) by (Postfix) with ESMTP id 2FA2621F9408 for <>; Fri, 24 May 2013 00:08:06 -0700 (PDT)
Received: by with SMTP id mx1so2282400bkb.26 for <>; Fri, 24 May 2013 00:08:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=WfPvuV2+ls+t7lDUd6Pt8fo6THyQZxFw64gGxZ1+4Uo=; b=MgwB4gcWgmxVrnEl/9dBeINl7gWHbU4ETN+fOMRPp2J5EaPg2kfWyaAQ9U/yRQy4TU mzwRsMeWClD9fMnRinrWRl+OLx70o4dpwTLF9z32iyzOTyr8DgU0HJFfOHSepotMxpSb kqjbOzOGjHKxWYhrSdjwQG5pPlzawNhr4ITrC0qaCf4fD8zaPXNrvFR09xkYAWxTUxKc h1Iv7bcjnlY93vh0ErvjlpUBUbvaKx8q8ls7vx7taBgetvg6XxePiaYLRqBMy4gv5JtE cNG8jfgc5/6Gz/HO13xXBCRuzDHuKSnMM/kGF669g5lvAxwRlAuosUSJ3Y9rLdjpzRd5 bYNw==
X-Received: by with SMTP id g4mr8480059bkp.26.1369379285688; Fri, 24 May 2013 00:08:05 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id fz10sm4010804bkc.9.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 00:08:04 -0700 (PDT)
Message-ID: <>
Date: Fri, 24 May 2013 10:08:00 +0300
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnsGyT9PktY03oFVMuEXdVrVXrSeaeS2EaL/i2PW3YvAIBzCw7YtEX+MjV15/ONHD5E3emB
Cc: mmusic WG <>
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 May 2013 07:08:08 -0000

Hey Cullen,

On 24.05.13, 01:22, Cullen Jennings (fluffy) wrote:
> <snip>
> What I had in mind was something along the lines of the following
> A is sending an offer that forks to B and C. A and B support the new
> mechanisms but C does not. A has no idea if the things it is talking
> to support the new thing.


> A constructs an offer that in the SDP has an indication it can
> receive the header extension. Perhaps something like
> "a=new-hdr-ext=123456". The new header extension allows one to embed
> an identifer in the RTP packets and this SDP indicates that the
> identifier should be 123456 for RTP with this mapping.


> A sends the offer and it arrives at both B and C. C does not
> understand it and just ignores it. B understands it and inserts a TP
> header extension with the identifier 123456.
> Imagine the RTP packets from B and C arrive at A before any SDP
> answer. A looks at the RTP packet from B, and see the header exertion
> and reads out the identifier 123456 and now knows the mapping. A
> looks at the RTP packet from C and does not see the RTP header
> extension so it carries on to try other things.

That's it. This is the point that I am talking about. In order for A to
be able to fall back to something, it needs to have attributed PTs such
that they could be used for demuxing.

So in other words: when constructing your offer, whatever you do, you
MUST make sure that your PTs would be enough for you to match to m=
lines, UNLESS you are certain that the other party would support some
other mechanism for doing the same.

Does this make sense?

> So yes, as you point out, for the packets from C where it can't use
> PT, it needs to fall back to SSRC 

SSRC is also a non-guaranteed approach because you don't know if C is
going to pre-announce them in SDP.