Re: Review: draft-ietf-mmusic-sdp-simulcast

Thanks Bo !

Please see inline.

On May 3, 2017, at 12:14 PM, Bo Burman <[email protected]<mailto:[email protected]>> wrote:

Hi Arun,

Thank you for the comments! Please see my responses inline below.

Cheers,
/Bo

From: Arun Arunachalam (carunach) [mailto:[email protected]]
Sent: den 9 april 2017 13:04
To: Bo Burman <[email protected]<mailto:[email protected]>>
Cc: Flemming Andreasen (fandreas) <[email protected]<mailto:[email protected]>>; Arun Arunachalam (carunach) <[email protected]<mailto:[email protected]>>
Subject: Re: Review: draft-ietf-mmusic-sdp-simulcast

Hi Bo,

Reviewed the draft and have a few comments and questions (shown below).

Thanks!
Arun

Comments / Questions:

(1) Section 1<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-1>

   transport over RTP.  The media transport topologies considered are
   point to point RTP sessions as well as centralized multi-party RTP
   sessions, where a media sender will provide the simulcasted streams
   to an RTP middlebox or endpoint, and middleboxes may further
   distribute the simulcast streams to other middleboxes or endpoints.

Several places in the doc use the term “RTP Session” and “RTP streams” hence it would be useful to provide a reference so that readers can know the difference.

RTP Session —> https://tools.ietf.org/html/rfc3550#section-1.1
[BoB] As said at the start of section 2.1 “Terminology”, the draft generally uses terms from RTP Taxonomy (RFC 7656). Both RTP stream and RTP session are terms described there. RTP session is, as you say, also defined by RFRC 3550, but there has been significant confusion around what the term really means, so additional clarification was added in RFC 7656. I have no problem adding them as explicit terms in section 2.1, but will then more or less just reference RFC 3550 and RFC 7656 from there.

Good. The reference in the terminology section should be sufficient.




(2) Section 3.1<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-3.1>


   Bitrate:  This relates to the amount of bits spent per second to

      transmit the media source as an RTP stream, which typically also

      affects the Quality of Experience (QoE) for the receiving user.


I think the authors may have intended to use “sent” instead of “spent".
[BoB] I think a sender can “spend” bits it “has available” to send, but I agree that it would be better to change to “sent”.

(3) Section 6.1<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-6.1>

   directionality is reversed.  This example answer has removed all
   offered alternative formats for the first simulcast stream (keeping
   only SCID 1), but kept alternative formats for the second simulcast
   stream in receive direction (4, 5).  The answer thus accepts to send
   two simulcast streams, without alternatives.  The answer does not
   accept initial pause of any simulcast streams, in either direction.
   More examples can be found in Section 6.6.

Please remove the word “thus” since there is no reason provided prior to this sentence.
[BoB] OK.


(4) Section 6.2<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-6.2>

   instead of making it equivalent to implicitly sending a pause
   request, is because the pausing RTP sender cannot know which
   receiving SSRC owns the restriction when TMMBR/TMMBN are used for
   pause/resume signaling since the RTP receiver's SSRC in send
   direction is sometimes not yet known.

It would be good to a give reference for TMMBR/TMMBN pointing to https://tools.ietf.org/html/rfc7728#section-2.1 or https://tools.ietf.org/html/rfc7728#section-5.6.
[BoB] OK. Prefer section 5.6 of RFC 7728. However, the draft source is XML and I don’t think xml2rfc <xref> supports referencing a particular section, so I’m not sure how to achieve that.


I think we can use "Section 5.6 of <xref target="RFC7728”/>” in the XML version of the doc.

Reference: https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18

Working example:

XML:

<section title="Intermediary">
<t>The term "intermediary" is defined in Section 2 of <xref target="RFC7989"/>; it refers to any entity along the call signaling path.</t>
</section>

RFC:
https://tools.ietf.org/html/rfc8123#section-3.3



(5) Section 6.3.2<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-6.3.2>

   An answerer that receives indication in an offer of an SCID being
   initially paused SHOULD mark that SCID as initially paused also in
   the answer, regardless of direction, unless it has good reason for
   the SCID not being initially paused.  One such reason could, for
   example, be that the answerer would otherwise initially not receive
   any media of that type at all.

Trying to understand the example. Can you please explain a scenario in which the example applies?
[BoB] Say that you have a simulcast with several different media quality levels being offered. The offerer expects most receivers to accept the highest quality level, and that they are then uninterested to receive the lower quality levels. The offerer has therefore set the lower quality simulcast streams to initially paused. Further assume a somewhat restricted answerer that cannot cope with the highest quality level. It therefore wants to accept a lower quality level simulcast stream and would not receive anything at the beginning of the session (until issuing an RFC 7728 RESUME) if it accepts this lower quality simulcast stream as initially paused. Without including such fairly extensive example text, I don’t know how to best make a clarification. Do you have a proposal?

Got it. Nice example.

How about following:

   One such reason could, for example, be that the answerer doesn’t have the ability to
   process any unpaused simulcast streams offered for a given media source. It chooses
   one of the paused simulcast stream in the offer and marks it as not paused in the answer.





(6) Section 7.2.1<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-7.2.1>

   This will result in a single RTP stream being used for a particular
   of the RTP mixer’s media sources.


This sentence seems to be missing a word - “…tor a particular _______ of the RTP mixer’s….”
[BoB] What about replacing “a particular of” with “each one of”?

We can use “each of”:

   This will result in a single RTP stream being used for each
   of the RTP mixer's media sources.





(7) Section 7.2.1<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-7.2.1>

    This as there is nothing in the signalling between the mixer and the receiver that is structured around the originating media sources, only the mixer’s media sources.

 I think “This as” needs to be changed to “That is”.
[BoB] OK. I assume “That is, “ (with a comma)?



Yes.


(8) Section 7.2.1<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08#section-7.2.1>

   If RtpStreamIds are used in this scenario, it should be noted that
   the RtpStreamId on a particular SSRC will change based on the actual
   simulcast stream selected for switching.  These RtpStreamId
   identifiers will be local to this leg’s signalling context.  In
   addition, the defined RtpStreamIds and their parameters need to cover
   all the media sources and simulcast streams that can be switched into
   this media source.

In the above paragraph what does “this scenario” refer to? Is it the scenario of using media source’s rtp stream SSRC in the CSRC of the rtp mixer’s rtp stream (or) is it referring to “RTP Mixer - Receiver” scenarios in general?
[BoB] “This scenario” means to refer to this section (7.2.1). Will clarify.

Does “this leg’s signaling context” refer to the “RTP mixer - Receiver” call leg?
[BoB] Not necessarily just RTP stream receiver, it could also be RTP stream sender, otherwise yes. It is the context of a single SDP offer/answer between two participants (RTP mixer and whatever endpoint is the counterpart – possibly even another RTP mixer).

The sentence “In addition, the defined RtpStreamIds….that can be switched into this media source" is not clear to me. Specifically why would we switching an RTP stream into a media source. Was it intended to be “switched from this media source” or “switched to a RTP receiver”? Please explain.
[BoB] The RTP mixer receives (potentially simulcast) RTP streams from originating media sources and switches those RTP packets internally to provide data for the RTP mixer’s own media sources and RTP streams, as seen by the final receiver of the RTP streams from the RTP mixer. What about re-formulating to “In addition, the defined RtpStreamIds and their parameters need to cover all the media sources and simulcast streamsreceived by the RTP mixer that can be switched into this media source, sent by the RTP mixer”?

Yes! this gives more clarity.

Thanks!
Arun













On Mar 30, 2017, at 5:42 PM, Arun Arunachalam (carunach) <[email protected]<mailto:[email protected]>> wrote:

Hi Flemming,

I think in about a week i.e by EOB 4/7.

Thanks!
Arun
Sent from my iPhone

On Mar 30, 2017, at 4:33 PM, Flemming Andreasen (fandreas) <[email protected]<mailto:[email protected]>> wrote:
Thanks Arun - when do you think you will have the review ready ?

-- Flemming
On 3/30/17 4:30 PM, Arun Arunachalam (carunach) wrote:
Hi Flemming,

As discussed, i would be glad to review draft-ietf-mmusic-sdp-simulcast<https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-simulcast> draft.

Thanks!
Arun


.

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic