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

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 Dec 2013 15:46:37 -0800

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:[email-masked]
m=video 49200 RTP/AVP 100
a=rtpmap:100 H264/90000
a=appID 3
a=recv-appId 20
a=ssrc:20010 CNAME:[email-masked]
 
[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:[email-masked]
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:[email-masked]
 
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:[email-masked]
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:[email-masked]
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:[email-masked]
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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Dec 2013 16:27:55 -0800

> a=appID:1 imageattr:98 send [x=480,y=320]

I don't know, I thought that that was a terrible idea.  It means that
in order to perform the correlation to signaling, you have to start
decoding at least as far as you need to get resolution.

Architecturally, that's going to involve all sorts of contortions to get right.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 Dec 2013 23:01:59 -0800

> Architecturally, that's going to involve all sorts of contortions to get right.
 
[BA] No doubt, given that adding attributes to appID goes back down the road that Unified Plan attempted to avoid. 
 
However, that's what I thought the presentation at IETF 88 was saying. 
 
To my mind, the major benefit was to enable de-multiplexing of media received prior to the Answer, which requires recv-appID. 
 
But most of the existing examples either don't illustrate the use of recv-appID,  or seem like they would work without an a=appID line at all, as long as the PT is unique.   In particular, in the simulcast example it doesn't seem like appID adds value (as long as the SSRCs for the simulcast streams are unique).

---

From: "Roni Even" <[email-masked]>
Date: Wed, 18 Dec 2013 09:52:28 +0200

Hi Bernard,

Thanks for the review, we are currently working on a new revision that will
include the appId, recv-appId and appId-group.

The authors view is that if we have a single RTP stream described by a
single m-line multiplexed using different transport address (not bundled or
unify) as seems to be what RFC3264 is about there is no need for any
identifier, no use also for a=ssrc

When the multiplexing is based on SSRC like in the bundle case or unified if
there is more than one RTP stream from a single source we will need some
identifier to be able to map the RTP stream to a description in SDP or to an
application protocol (CLUE media encoding). This can be done using SSRC but
requires that the SSRC will be known or assigned by the signaling layer. We
prefer to define a token that will be used to map from the SDP to the RTP
layer in the RTP using the SDES and RTP header extensions.

For the early media example in the unified document we also need to allow
the offerer to specify the receive token.

As for your comments see inline

Roni 

From: mmusic [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 18 December, 2013 1:47 AM
To: [email-masked]
Subject: [MMUSIC] Review of draft-even-mmusic-application-token

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:

[Roni Even] We are currently not sure that we will need this type of syntax
where the appId will have attributes. We are looking at the simulcast work
and will see how it relates to the appId.

Some specific comments: 
 
Section 1

 
[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?  

[Roni Even] The offer in the example is for H.264/SVC with two FEC streams
so there are four possible RTP streams available in the m-line. There are
four SSRCs but from the SDP it is not clear how the four SSRCs are mapped to
the pt.

Section 3.1

a=group:SCR 1 2
m=video 49200 RTP/AVP 98
a=rtpmap:98 H264/90000
 
[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:

[Roni Even] I agree and the example was based on a previous version of the
simulcast draft from Magnus. We are taking this example out and will look at
simulcast when we have a better understanding about it from the currently on
going work.  There was a presentation at IETF88 by Bo and Magnus and there
were comments on the direction, Jonathan and I are discussing with them if
and how simulcast may use appId.

 [Roni Even] your examples on the simulcast are correct
Offer
 
a=group:SCR 1 2
m=video 49200 RTP/AVP 98
a=rtpmap:98 H264/90000
 
Answer
 
a=group:SCR 1 2
m=video 28000 RTP/AVP 98
a=rtpmap:98 H264/90000
 
Section 4
 
m=video 49200 RTP/AVP 99
a=rtpmap:99 H264/90000
a=appID 2
a=recv-appId 10

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

[Roni Even] note that the three RTP streams from the three cameras in this
example suing bundle can have the same payload type number if they have the
same parameters according to bundle. In this case the appId will be used to
distinguish between them. There is no need for the a=ssrc in this case.