Re: [rtcweb] draft-roach-mmusic-unified-plan-00 expired

Iñaki Baz Castillo <> Wed, 22 January 2014 14:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DA3FB1A0236 for <>; Wed, 22 Jan 2014 06:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GlKiwHP3dQuh for <>; Wed, 22 Jan 2014 06:35:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 608BE1A00EC for <>; Wed, 22 Jan 2014 06:35:06 -0800 (PST)
Received: by with SMTP id f11so489823qae.38 for <>; Wed, 22 Jan 2014 06:35:05 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=TVTW6jZbIq76hTAfS8gw42s3nYsXEgwZTiLlvszuKQc=; b=FZ1hrkwFIA5dEpRp6r9fpBiK2maom/hEsUCV/p1jzbBXvdvoYuAqEaG2lcBJ9voq2f IH1TfFIhG/xu9xQyc53nD7a26/WZPgykgNCE3Ziqh9BCAf9Lsshdxlt6i8XchZZ7utHJ w0c9XIolX991jg1/FeUb3SJL6IrMxgJU4hB+X8ELof07K/zKpr6CjP0QItZtIdg+iIjB PaWUkDMmvM3VNn+BdFL2xUAwZbp7ZIO3GYiYZtKHjdPmxEs/qpu207hdkY5tzVg9PPm5 Wkt3qu9RGLm4ZWBgz07zP5Kl0biovj/xvX7h52jvUvQAgPvvxxUO65FVPWe22vrlF+pM lGhA==
X-Gm-Message-State: ALoCoQnkIEsRGKBsZAUumFuweKiCwNYf8TgMBSNWcUhU43zQCG7zN2p34cJuJXDPGtWhsLAaYwqm
X-Received: by with SMTP id s103mr2634677qgd.47.1390401305553; Wed, 22 Jan 2014 06:35:05 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Jan 2014 06:34:45 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Wed, 22 Jan 2014 15:34:45 +0100
Message-ID: <>
To: Paul Kyzivat <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] draft-roach-mmusic-unified-plan-00 expired
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: Wed, 22 Jan 2014 14:35:08 -0000

2014/1/20 Paul Kyzivat <>:
> What is it that troubles you about this.
> I guess from prior comment that you want to add more m-lines in the answer?
> But O/A is a negotiation/handshake. If you include extra m-lines in the
> answer then there is no completion to the negotiation of those.

Having two endpoints establshing a media session, the only they need is:

- To decide a transport or transports for sending media one to each other.
- To tell one to each other what it is sending.

SDP is good (enough) in classic and simple communications in which
both endpoints send and receive something similar (i.e. one single
audio track in both directions).

But nowadays we want that endpoint-A can send just one audio track and
one video track and receive 8 audio tracks and 8 video tracks from
endpoint-B. If endpoint-A makes the SDP offer, it "should" include 16
m lines:

- 1 audio line for sending its single audio track and receive *one* of
the remote tracks (a=sendrecv).
- 7 audio tracks just for receiving the rest of the remote audio
tracks (a=recvonly).
- Same for video.

This is completely unnecessary if we skip the SDP tradition. There is
no need at all for endpoint-A to tell endpoint-B "you can send me up
to 8 audio tracks since I have added 8 m audio lines in my SDP offer,
otherwise you can only send me a single audio track, but you can send
me later a re-offer".

This is something that ORTC "fixes".


Iñaki Baz Castillo