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

Emil Ivov <emcho@jitsi.org> Thu, 16 May 2013 19:03 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 B403221F86CA for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 12:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 rraLs4h6ho+L for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 12:03:19 -0700 (PDT)
Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3C511E80A6 for <mmusic@ietf.org>; Thu, 16 May 2013 12:03:10 -0700 (PDT)
Received: by mail-bk0-f44.google.com with SMTP id jk14so277954bkc.17 for <mmusic@ietf.org>; Thu, 16 May 2013 12:03:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=RdIlg1HbiaRgZUvVS20ktpwZTWEN4lQbwOlnKqO8DQ8=; b=gPEe+fR5GGiBcCIFtahPSFAzeIDHRuUDBFnNew8TtLV/LA0K9o+6u2SnheYGb/GGTT LG8jQiFtBMPCA2x6Frbej/QjFk3m8rP2dpGOwD7HRVRRkJAz/ig51V4QqTxCy3YE1ODH j/49wj60611ypWQYRkpasC3wOOD+jV/8z0iqjdi7r+P25c8S2Q+X1h3C9a7xNdACFdcw lZpluR+2Z8terEPVJD11J4gmlqugahY03OqUCR3nTVFEDKE6SQc6DM0J+aT6LJ/gXZq3 rqbVVBxk7Ho6ZnyBG86Pz5i8umtSyp6h32qEPz6RN2OAC/hZs6Pyzx1IJQoXE1F70cS9 Q6BA==
X-Received: by 10.204.71.77 with SMTP id g13mr14078634bkj.50.1368730989573; Thu, 16 May 2013 12:03:09 -0700 (PDT)
Received: from camionet.local ([79.100.215.70]) by mx.google.com with ESMTPSA id jm15sm2394137bkb.13.2013.05.16.12.03.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 12:03:08 -0700 (PDT)
Message-ID: <51952D6C.1000904@jitsi.org>
Date: Thu, 16 May 2013 22:03:08 +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/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1134E782F@xmb-aln-x02.cisco.com> <5193B1DB.2070308@alum.mit.edu> <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <BLU169-W119163BAE68316B331EE12193A20@phx.gbl> <5193EA5C.7050905@alvestrand.no> <BLU169-W743682718AEA906C0F3C2A93A20@phx.gbl> <CABkgnnULK4Af+G4sg8Nnsa27v8wtB3fF3Ei2=x9Q7vDf+5Ak9Q@mail.gmail.com> <51950CED.6020305@jitsi.org> <CABkgnnUiWZnbC1vbs2qAUOB-HEr-CQYynS4wrzwpMFA5PB=Q3Q@mail.gmail.com> <CAPvvaaL_Gw4XWOO=VGThp6kyq-NJpB+0EFjXyWHNamfOtDfHrg@mail.gmail.com> <CABkgnnUb+sxidkGT4aoVB4aRGPxAaUm89DePQ0wPjyUsxdN2dg@mail.gmail.com>
In-Reply-To: <CABkgnnUb+sxidkGT4aoVB4aRGPxAaUm89DePQ0wPjyUsxdN2dg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlX3nbTivQUyxtMvaXYlS6Q5eKwAkVyGeKpEsSOK+qsTmXA72UvbUziCPmIKHKSPr1v0cB8
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: Thu, 16 May 2013 19:03:21 -0000

On 16.05.13, 21:01, Martin Thomson wrote:
> On 16 May 2013 10:52, Emil Ivov <emcho@jitsi.org> wrote:
>> Could you please be more specific about the sorts of problems you
>> expect and how they are caused by adhering to the basics of RTP?
> 
> I'm not a strong proponent of these things, and I expect those
> proponents to stand up and say something.  However, it is my
> understanding that in a call transfer case, the arrival of a new SSRC
> is treated as though the remote source has been switched out, not as
> though a new participant has been added to the session. 

Correct, however this happens after prior signalling which pretty much
destroys the existing RTP session.

> The same has
> to be true when a new SSRC is chosen in the case of a collision.

Indeed and it seems to me the above also applies here since sources that
choose a new identifier would first end their existing session with a BYE.

> This is clearer when you talk about video.  Does the video from the
> new SSRC go in the same window (/frame/<video> tag) as the existing
> SSRC, or does it go in a new window?

Given that in both cases we have one session ending and another
commencing, I'd say that the natural way to handle this would be to have
one video component removed and another added.

Cheers,
Emil

-- 
https://jitsi.org