Re: [MMUSIC] What is an m-line?

Martin Thomson <martin.thomson@gmail.com> Wed, 15 May 2013 18:53 UTC

Return-Path: <martin.thomson@gmail.com>
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 7DEC721F9080 for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 11:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 m+SZKI5eJpGA for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 11:53:37 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BB28021F9092 for <mmusic@ietf.org>; Wed, 15 May 2013 11:53:34 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u54so2039347wes.1 for <mmusic@ietf.org>; Wed, 15 May 2013 11:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=pwj+7Dy4jq7O9v6UXD5CZLU/QmW90c+59tVlYAjyMRE=; b=RO9hlblsHLcl/rQFz7ybBK0LIp0VOjwzk41mHQGqV28sOIsCSZWu1akTUTfh+TgpMa x3Vlj/KzdM4/eIEFNaHCWe6G9oUS3KyW4g7FCtQ2AK4Thly8QlU96jHm4O59E1M3V4os cRI+sTnwLrET4MziWf50AlfvWYUG9Rn8NFZyFja0nHVPCfOoYHEt+wFGT6Q4kWFB5seq 8UEQ43laH2/IzbvCerRfxkCL41iRpEOt9cFTgrnJmxTN2X2eWXwBPWuVHvxKmD9Oy8ac WfQcMSF65w/OoUa8o0T1n3TtsjdKoAxz0bVD0Uc0TMskQWI1cFwjrY2Voe2vqXTrIhyl ZY+w==
MIME-Version: 1.0
X-Received: by 10.180.20.148 with SMTP id n20mr16996523wie.8.1368644009999; Wed, 15 May 2013 11:53:29 -0700 (PDT)
Received: by 10.194.20.135 with HTTP; Wed, 15 May 2013 11:53:29 -0700 (PDT)
In-Reply-To: <2BB39401-29DC-4648-BB7F-51F0FE934082@csperkins.org>
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com> <2BB39401-29DC-4648-BB7F-51F0FE934082@csperkins.org>
Date: Wed, 15 May 2013 11:53:29 -0700
Message-ID: <CABkgnnV8gzpCcb4Frvq+X_oMRfJEko5WJKTH7LNZngp0Vd9uSg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] What is an m-line?
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: Wed, 15 May 2013 18:53:38 -0000

On 15 May 2013 04:02, Colin Perkins <csp@csperkins.org> wrote:
>> 1. an m-line represents a single RTP session
>>    (or at least the part of the session that touches the client)
>>    This appears to be consistent with the Plan B approach
>
> This is closest to my understanding, although an RTP session is defined by a shared SSRC space that can span multiple transport connections, so I don't think it's quite right. Perhaps "an m-line refers to one transport endpoint of a single RTP session"?

That's why I said "at least the part of the session that touches the
client", but this is probably more correct given that the same session
can have multiple transport endpoints on the same endpoint, described
in the same SDP as different m-lines.

> (For example, in a simple two-party voice-only call with RTCP there are distinct m-lines, with different transport endpoints, in the offer and the answer. But, since there is a shared SSRC space across the sending and receiving RTP flows - which there has to be for RTCP to work - you have one RTP session.)

This is a good point.  In offer/answer, this can clearly be two things
(as dictated by a=sendrecv).

I'd like to know how well this offer/answer usage scales.  Does this
extend to a three-party RTP session with the same characteristics?