Re: [payload] [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 27 October 2011 08:56 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ABC21F86A5; Thu, 27 Oct 2011 01:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.555
X-Spam-Level:
X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 lp9r3TdYBPrw; Thu, 27 Oct 2011 01:56:03 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6121F8672; Thu, 27 Oct 2011 01:55:59 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-c2-4ea91c9e4911
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 56.65.13753.E9C19AE4; Thu, 27 Oct 2011 10:55:58 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 27 Oct 2011 10:55:57 +0200
Message-ID: <4EA91C9C.7010801@ericsson.com>
Date: Thu, 27 Oct 2011 10:55:56 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <4EA13A85.2060506@ericsson.com> <F25CFD88-3ADC-4F74-9E72-9E244C733A2C@acmepacket.com>
In-Reply-To: <F25CFD88-3ADC-4F74-9E72-9E244C733A2C@acmepacket.com>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "mmusic (E-mail)" <mmusic@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2011 08:56:03 -0000

On 2011-10-25 20:01, Hadriel Kaplan wrote:
> 
> On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote:
> 
>> 11. Section 5.3 "    Note: A loopback offer in a given media
>> description MUST NOT contain the standard mode attributes sendonly,
>> recvonly, sendrecv, or inactive. The loopback-mode attributes
>> (loopback-source and loopback-mirror) replace the standard
>> attributes."
>> 
>> This appears to be a strange MUST NOT which I think might
>> encounter issues. Considering that SIP proxies that looks into this
>> SDP requires the direction attribute to be present and adds it,
>> what happens now. And why isn't sendrecv and inactive possible
>> values? sendrecv appears to be requried for loopback to work, and
>> inactive would put media transport in an established session on
>> hold. Isn't that reasonable?
> 
> How about this: Since media loopback requires bidirectional RTP, its
> normal direction mode is "sendrecv"; the "sendrecv" direction
> attribute MAY be encoded in SDP or not, as per section 5.1 of
> [RFC3264], since it is implied by default.  If either the loopback
> source or mirror wish to disable loopback use during a session, the
> direction attribute "inactive" MUST be used as per [RFC3264].  The
> direction mode attributes "recvonly" and "sendonly" are incompatible
> with the loopback mechanism and MUST NOT be indicated when generating
> an SDP Offer or Answer.  When receiving an SDP Offer or Answer, if
> "recvonly" or "sendonly" is indicated for loopback, the SDP-receiving
> agent MAY treat it as a failure of the loopback negotiation or ignore
> the direction attribute.
> 

That is much better. I think the only "controversial" from my
perspective is the "ignore" part. It is clearly an error.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------