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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 16 May 2013 21:33 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 E964711E80CC for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 14:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.313
X-Spam-Level:
X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 Kqo2Dw9SH2Pt for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 14:33:02 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 00F7621F86BB for <mmusic@ietf.org>; Thu, 16 May 2013 14:33:01 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id chCh1l0040Fqzac5DlZ1xn; Thu, 16 May 2013 21:33:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id clZ11l00D3ZTu2S3UlZ1Qg; Thu, 16 May 2013 21:33:01 +0000
Message-ID: <5195508C.6030604@alum.mit.edu>
Date: Thu, 16 May 2013 17:33:00 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
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=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368739981; bh=ThrirLY842Ut9Ggryvz5mswn62CdQem00rsJyGUXxGs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RaPWs8XCy5uxkyawRssaoDFs8I2w4Q5sQZMrUFjVHnig01Nk6+3nAV4zFspZ4Q/5+ 9axUOq9TDmswjSd5Q8wDfRc+VfT41WhtIBVxAPiM2VrBYs2/mxeCJbBRJZB19gJCMd Q2o0WcyGQhLPzVlDWODL/EgFXn8VR7Bnsc07XpMr9bST2EuLFq9GRCFIX2QcExvT8T WHfOj0/+BwZWKluRUntdGPAWo3kLO/ivzT5YQSRuQA5zA1xFXL7bzMfZpltGg7WBkB 4sUY6AU3ew/s5mV3YskUFL9Uffc/hnUvv5oGgV4LNCvEo3nBj22ft6l0+PIzn2dqOo fYXBab16SxmlQ==
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 21:33:08 -0000

On 5/16/13 2:01 PM, 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.  The same has
> to be true when a new SSRC is chosen in the case of a collision.
>
> 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?

This does really get to the essence of the issue doesn't it?
(At least part of it.)

Note that in sip there are two ways to do a transfer:
- REFER, which leads to INVITE/Replaces
- 3pcc, which leads to just a reINVITE.

The INVITE/Replaces is much clearer that a change is required. The 
"Replaces" is a giveaway, and the new SDP should have a different 
session id. (But in cases where there are multiple media streams, mapped 
to distinct windows or devices, it may be hard to decide what to do.)

Its the reinvite case that you are talking about. Its only going to work 
if the handling of new SSRCs by the app is something that makes sense in 
the context of the application. That could be because the app only 
renders to one device, and always renders the most recently received 
SSRC. Or it could be because the app opens a new window for the new SSRC 
and (eventually) closes the old one. Or it could be that extra 
attributes in the SDP tell the application what to do.

	Thanks,
	Paul