[MMUSIC] Review of draft-even-mmusic-application-token

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 17 December 2013 23:46 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 C093D1AD937 for <mmusic@ietfa.amsl.com>; Tue, 17 Dec 2013 15:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.636
X-Spam-Level:
X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 dXBF0QEpcY4j for <mmusic@ietfa.amsl.com>; Tue, 17 Dec 2013 15:46:39 -0800 (PST)
Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by ietfa.amsl.com (Postfix) with ESMTP id 091E31A1F5B for <mmusic@ietf.org>; Tue, 17 Dec 2013 15:46:38 -0800 (PST)
Received: from BLU169-W23 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Dec 2013 15:46:38 -0800
X-TMN: [b3/dN0n7SD36aA0zaRoV9WoQ2kb7+jzv]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W23A88E66B5C16DAEEFD26193DB0@phx.gbl>
Content-Type: multipart/alternative; boundary="_c15992a5-97df-4505-928f-10f5b6abd2fe_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Date: Tue, 17 Dec 2013 15:46:37 -0800
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Dec 2013 23:46:38.0274 (UTC) FILETIME=[3A4C9220:01CEFB82]
Subject: [MMUSIC] Review of draft-even-mmusic-application-token
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, 17 Dec 2013 23:46:41 -0000

Overall, the focus of this document seems to be more on appID than on recv-appID.   This puzzles me, because I had assumed that most of the value was in the recv-appID, since that allows the Offerer to demultiplex by appID, even before the Answer is received.  Yet appID is used in many of the Offers in situations where the Answerer would be able to demultiplex by Payload Type.  
 
Perhaps the issue is that the a=recv-appID syntax is not yet expressive enough to provide a solution in situations where the same payload type is used to receive multiple resolutions.   
 
A revised syntax was hinted at during IETF 88 which seems like it would represent an improvement:
 
a=appID:1 imageattr:98 send [x=480,y=320]
 
 
 
 
Some specific comments: 
 
Section 1
 
      a=ssrc-group:DDP 1000 1010

   In this case all video streams are from the same source and can be
   described using a single m-line.  The grouping relations are
   specified using the SSRCs values that need to be available in the
   offer.  It is also not clear based on the offer which SSRC is mapped
   to each of the PT numbers.
 
[BA] Unless I'm mis-reading the SDP, it would appear that distinct SSRCs are being used for the base layer and the extension layer (isn't that what the a=ssrc-group:DDP line is for?).   This would imply that the Offer is for H.264/SVC MST, no?  
 
Section 3.1
 
   The second example is when the application usage of the RTP steam is
   specified using SDP to provide different image resolutions.  The
   media receiver can map the received SSRC to the specific resolution
   based on the appId.

a=group:SCR 1 2
m=video 49200 RTP/AVP 98
a=rtpmap:98 H264/90000
imageattr:98 send [x=640,y=360]  recv[[x=640,y=360] [x=320,y=180]
a=msid:ma ta
a=appID:2
a=mid:1
m=video 49200 RTP/AVP 99
a=rtpmap:99 H264/90000
imageattr:99 send [x=320,y=180]
a=msid:ma ta
a=appID:3
a=mid:2
a=sendonly
 
[BA]  Aside from the syntactic issues (e.g. s/appId/appID/, a=imageattr, [[), I am missing the point of this example. When sending, the resolutions can be distinguished by payload type, but on receiving both 640 by 320 and 320 by 180 resolutions use the same payload type 98, so isn't the problem really on the receiving side?  Perhaps the revised syntax proposed at IETF 88 would help:
 
Offer
 
a=group:SCR 1 2
m=video 49200 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42c01e
a=appID:2 send [x=640,y=360]
a=recv-appID:10 recv [x=640,y=320]
a=recv-appID:20 recv [x=320,y=180]
a=mid:1
m=video 49202 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42c01e
a=imageattr:99 send [x=320,y=180] 
a=appID:3
a=sendonly
a=mid:2
 
Answer
 
a=group:SCR 1 2
m=video 28000 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42c01e
a=recv-appID:2 recv [x=640,y=360]
a=appID:10 send [x=640,y=320]
a=appID:20 send [x=320,y=180]
a=mid:1
m=video 28002 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42c01e
a=imageattr:99 recv [x=320,y=180]
a=recv-appID:3
a=recvonly
a=mid:2
 
Section 4
 
m=video 49200 RTP/AVP 99
a=rtpmap:99 H264/90000
a=appID 2
a=recv-appId 10
a=ssrc:20010 CNAME:v1@example.com
m=video 49200 RTP/AVP 100
a=rtpmap:100 H264/90000
a=appID 3
a=recv-appId 20
a=ssrc:20010 CNAME:v2@example.com
 
[BA] Shouldn't the example look more like this? (for a second BUNDLE offer):
 
a=group:BUNDLE 1 2
m=video 49200 RTP/AVP 99
a=mid:1
a=rtpmap:99 H264/90000
a=appID:2
a=recv-appID:10
a=ssrc:20010 CNAME:v1@example.com
m=video 49200 RTP/AVP 100
a=mid:2
a=rtpmap:100 H264/90000
a=appID:3
a=recv-appID:20
a=ssrc:20010 CNAME:v2@example.com
 
Section 4, second example
 
[BA] The example should look like this, no? (for a first BUNDLE offer)
 
a=group:BUNDLE m1 m2 m3 m4 R1
a=group:FEC-FR m2 m3 m4 R1
m=audio 56600 RTP/SAVPF 109
a=mid:m1
a=msid:ma ta
a=appID:1
a=ssrc:53280
a=rtpmap:109 opus/48000
m=video 56602 RTP/AVPF 100 - left camera
a=mid:m2
a=msid:ma tb
a=appID:2
a=rtpmap:100 H264/90000
a=ssrc:1000 cname:MSTFEC@example.com
m=video 56604 RTP/AVPF 101- Middle camera
a=mid:m3
a=msid:ma tc
a=appID:3
a=rtpmap:101 H264/90000
a=ssrc:1010 cname:MSTFEC@example.com
m=video 56606 RTP/AVPF 102 - Right camera
a=mid:m4
a=msid:ma td
a=appID:4
a=rtpmap:102 H264/90000
a=ssrc:1020 cname:MSTFEC@example.com
m=video 56608 RTP/AVP 110
a=rtpmap:110 1d-interleaved-parityfec/90000
a=fmtp:110 L=5; D=10; repair-window=200000
a=mid:R1
a=appID:5