Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 03 December 2013 02:17 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD461AE00A for <mmusic@ietfa.amsl.com>; Mon, 2 Dec 2013 18:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.5
X-Spam-Level: **
X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t1jaMbqPW1U for <mmusic@ietfa.amsl.com>; Mon, 2 Dec 2013 18:17:20 -0800 (PST)
Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id 922301ADFAD for <mmusic@ietf.org>; Mon, 2 Dec 2013 18:17:20 -0800 (PST)
Received: from BLU169-W72 ([65.55.116.73]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 18:17:18 -0800
X-TMN: [R2z7qRM1HIsK5sZSoAjjWRIKpX7Lya6HJaiyYrHSZR8=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W724F5CA422C24BCB7FD9AB93D50@phx.gbl>
Content-Type: multipart/alternative; boundary="_b4a68e6f-80d7-4dbd-a249-63124a34aa4f_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Mon, 02 Dec 2013 18:17:17 -0800
Importance: Normal
In-Reply-To: <BLU169-W1333DD46BD52F4550CC8DB993D50@phx.gbl>
References: <BLU169-W11468829F05B411E43D51E693EE0@phx.gbl>, , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, <BLU169-W119ED7AA7ACE6A2FC53A4CE93E80@phx.gbl>, <BBE9739C2C302046BD34B42713A1E2A22E061AB2@ESESSMB105.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se>, <BLU169-W1333DD46BD52F4550CC8DB993D50@phx.gbl>
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Dec 2013 02:17:18.0274 (UTC) FILETIME=[CA5CDA20:01CEEFCD]
Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 03 Dec 2013 02:17:22 -0000

Christer said: 
 
"If the answerer does NOT support simulcast, it will see an Offer with multiple uni-directional streams. The behavior is difficult to predict. So, even with a mechanism based on grouping, the question is still: should the support of the simulcast feature be negotiated between the endpoints first, before it is enabled? Most likely it would require 2 O/A transactions."
 
[BA] If the answerer does NOT support simulcast, it would not respond with an a=group:SC line, so the Offerer will know that simulcast is not supported.  If the Answerer accepted more than one of the m= lines offered by the Offerer, but didn't include an a=group:SC line, then the Offerer could send a modified offer in order to avoid confusion on the part of the Answerer.   A similar scenario can occur in draft-westerlund-avtcore-rtp-simulcast, since the Answerer may not understand the a=sim-send-cap or a=sim-recv-cap lines.  
 
In an O/A exchange where both the Offerer and Answerer support simulcast, the exchange would look like this: 
 
Offer: 
 
v=0
o=alice 2362969037 2362969040 IN IP4 192.0.2.156
s=Simulcast Enabled Client
t=0 0
c=IN IP4 192.0.2.156
b=AS:665
a=group:SC S1 S2
m=video 49300 RTP/AVP 97
a=sendonly
b=AS:520
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42c01e
a=imageattr:97 send [x=640,y=360]
a=mid:S1
m=video 49302 RTP/AVP 98
a=sendonly
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42c01e
a=imageattr:98 send [x=320,y=180]
a=mid:S2
m=video 49304 RTP/AVP 100 99
a=recvonly
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42c01e
a=imageattr:100 recv [x=640,y=360] 
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42c01e
a=imageattr:99 recv [x=320,y=180]
a=mid:S3
 
Answer: 
 
v=0
o=server 823479283 1209384938 IN IP4 192.0.2.2
s=Answer to Simulcast Enabled Client
t=0 0
c=IN IP4 192.0.2.43
b=AS:665
a=group:SC S1 S2
m=video 48000 RTP/AVP 97
a=recvonly
b=AS:520
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42c01e
a=imageattr:97 recv [x=640,y=360]
a=mid:S1 
m=video 48002 RTP/AVP 98
a=recvonly
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42c01e
a=imageattr:98 recv [x=320,y=180]
a=mid:S2
m=video 48004 RTP/AVP 100 99
a=sendonly
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42c01e
a=imageattr:100 send [x=640,y=360] 
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42c01e
a=imageattr:99 send [x=320,y=180]
a=mid:S3