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

Emil Ivov <emcho@jitsi.org> Fri, 24 May 2013 07:08 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA5A21F9434 for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 00:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level:
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biEf1vkZxtv3 for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 00:08:07 -0700 (PDT)
Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA2621F9408 for <mmusic@ietf.org>; Fri, 24 May 2013 00:08:06 -0700 (PDT)
Received: by mail-bk0-f53.google.com with SMTP id mx1so2282400bkb.26 for <mmusic@ietf.org>; Fri, 24 May 2013 00:08:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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 10.204.108.196 with SMTP id g4mr8480059bkp.26.1369379285688; Fri, 24 May 2013 00:08:05 -0700 (PDT)
Received: from [192.168.43.3] ([212.5.158.176]) by mx.google.com with ESMTPSA id fz10sm4010804bkc.9.2013.05.24.00.08.02 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 00:08:04 -0700 (PDT)
Message-ID: <519F11D0.504@jitsi.org>
Date: Fri, 24 May 2013 10:08:00 +0300
From: Emil Ivov <emcho@jitsi.org>
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)" <fluffy@cisco.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com> <519E80E4.6010904@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB11351027A@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11351027A@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnsGyT9PktY03oFVMuEXdVrVXrSeaeS2EaL/i2PW3YvAIBzCw7YtEX+MjV15/ONHD5E3emB
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=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.

Exactly.

> 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.

OK.

> 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.

Emil

-- 
https://jitsi.org