gmane.ietf.mmusic

Re: SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08

Qin Wu — 2013-06-18T03:59:56

From: Ali C. Begen (abegen) [mailto:abegen< at >cisco.com]
Sent: Thursday, June 13, 2013 7:58 PM
To: Qin Wu; draft-ietf-xrblock-rtcp-xr-qoe< at >tools.ietf.org
Cc: xrblock-chairs; mmusic; 'xrblock'
Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08

- I don't agree with the following statement:

   Information is recorded about QoE metric which provides a
   measure that is indicative of the user's view of a service.

The application cannot possibly know a user's view of service unless the user explicitly enters that info in some fashion to the application.

[Qin]:  The application can rely on QoE evaluation model to calculate MoS value and use such MoS value to reflect how end user feel or experience the media quality. That’s what this statement want
to convey.

That is not what the sentence says, though, at least to me. The "user's view of a service" is the troubling part to me. What you do is that you apply an algorithm with some observed values and you try to

WGLC for draft-ietf-mmusic-sdp-g723-g729-03

Ari Keränen — 2013-06-17T23:01:40

This is to start a 2-week Working Group Last Call for

draft-ietf-mmusic-sdp-g723-g729-03

The WGLC ends on July 2nd, 2013.

Please review the document and send your comments both to the authors 
and to the MMUSIC mailing list. If you review the document but do not 
have any comments, please send a note to that effect as well.

The document is available here:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-03


Thanks,
Ari

Re: RFC 6190 Single Session Transport

Jonathan Lennox — 2013-06-17T19:34:12

This was certainly my understanding of RFC 6190 as well, from heavy participation in its standardization in AVT.

I don't understand how single-session multi-source transmission will work without either a) signaling "a=ssrc-group DDP" decoding dependencies, or b) making various implementation-specific assumptions about the structure of the SVC streams.

On Jun 17, 2013, at 2:38 PM, Mo Zanaty (mzanaty) <mzanaty< at >cisco.com<mailto:mzanaty< at >cisco.com>> wrote:

My understanding of 6190 SST is a single SSRC for all layers, not multiple SSRCs (one per layer) within one RTP session. 6190 doesn’t state this clearly, but otherwise SST would need all the same mst-mode stuff as MST, since mst-mode defines how receivers put packets into decoding order from multiple streams based on timestamps or Cross-Session Decoding Order Numbers (CS-DON).

I think you may be referring to the common industry practice of MST using the same port and thus the same RTP session, i.e. Multi-SSRC (rather than Session) Transmission. That is no

Re: RFC 6190 Single Session Transport

Bernard Aboba — 2013-06-17T18:40:10

[BA] Several examples are provided in RFC 6190 Section 7.3. 
Section 7.3.1:  Offer of both H.264/AVC and H.264/SVC on the same m-line.Section 7.3.2:  Offer of H.264/SVC with a single payload type. Section 7.3.5:  Offer of H.264/SVC with multiple payload types, supporting differing levels and packetization modes. 
Note that none of the examples use either a=ssrc or multiple m lines to describe the layers. 

[BA] OK.        _______________________________________________
mmusic mailing list
mmusic< at >ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Re: RFC 6190 Single Session Transport

Mo Zanaty (mzanaty — 2013-06-17T18:38:54

My understanding of 6190 SST is a single SSRC for all layers, not multiple SSRCs (one per layer) within one RTP session. 6190 doesn't state this clearly, but otherwise SST would need all the same mst-mode stuff as MST, since mst-mode defines how receivers put packets into decoding order from multiple streams based on timestamps or Cross-Session Decoding Order Numbers (CS-DON).

I think you may be referring to the common industry practice of MST using the same port and thus the same RTP session, i.e. Multi-SSRC (rather than Session) Transmission. That is not standardized in 6190, but often used in practice. This often uses a single m-line, so it has no BUNDLE dependency. If it used multiple m-lines, your argument would be true for that case. BUNDLE (or some similar mechanism to mux m-lines onto one port) would be required for that type of MST to use the same port. But that does not seem to be a limitation of Plan A, since some mux mechanism is always required to do that type of MST regardless of Plan A.

Mo

Re: RFC 6190 Single Session Transport

Adam Roach — 2013-06-17T17:32:46

I don't think that assertion has a basis in reality, but I could simply 
be misunderstanding what you're trying to say.

English is imprecise, and it's clear that we're not having a meeting of 
minds here. Let's try a different language. You send an e-mail to the 
list containing the SDP currently exchanged by SIP endpoints for SST. 
I'll send SDP in an e-mail reply that shows how it works under Plan A.

Sound good?

/a

I-D Action: draft-ietf-mmusic-sdp-g723-g729-03.txt

2013-06-17T17:29:52

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

Title           : Offer/Answer Considerations for G723 Annex A and G729 Annex B
Author(s)       : Muthu Arul Mozhi Perumal
                          Parthasarathi Ravindran
Filename        : draft-ietf-mmusic-sdp-g723-g729-03.txt
Pages           : 8
Date            : 2013-06-17

Abstract:
   RFC4856 describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the Session Description
   protocol(SDP) offer and answer.  This document provides the offer/
   answer considerations for these parameters and updates RFC4856.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729

There's

RFC 6190 Single Session Transport

Bernard Aboba — 2013-06-17T17:20:21

At the virtual interim, a question arose about RFC 6190 Single Session Transport. 
Here is what RFC 6190 Section 1 says:
   This memo defines two basic modes for transmission of SVC data,
   single-session transmission (SST) and multi-session transmission
   (MST).  In SST, a single RTP session is used for the transmission of
   all scalability layers comprising an SVC bitstream; in MST, the
   scalability layers are transported on different RTP sessions. Section 1.2.2 clarifies the usage scenarios of SST and MST: 
   SST should be used in point-to-point unicast applications and, in
   general, whenever the potential benefit of using multiple RTP
   sessions does not justify the added complexity...  

   MST should be used in a multicast session when different receivers
   may request different layers of the scalable bitstream.  Since SST implies (by definition), use of a single RTP session to transport multiple layers, were plan A to be used for signaling, negotiation of SST would only be possible if both p

Re: BUNDLE: SDP O/A Open Issue: Allowed for Offerer to assign same address to multiple m- lines before Answerer has indicated BUNDLE support in SDP Answer?

Martin Thomson — 2013-06-17T16:26:49

I have no problem with allowing this, though I think that it requires
a reasonable amount of text to ensure that the risks are known.

Virtual interim meeting material

Ari Keränen — 2013-06-17T14:18:16

Virtual interim meeting material available here:
http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/proceedings.html

Chair slides with agenda proposal(s): 
http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-0.ppt


Cheers,
Ari

Re: MMUSIC WG June 17th virtual interim agenda

Randell Jesup — 2013-06-17T11:30:16

+1

Try to make progress towards a decision (or, gasp, an actual decision)

On 6/17/2013 3:40 AM, Harald Alvestrand wrote:

Re: MMUSIC WG June 17th virtual interim agenda

Harald Alvestrand — 2013-06-17T07:40:32

If the purpose is to inform people about the plans, that's a fine agenda.

If the purpose is to find out whether there's a chance we can find 
consensus around one plan, another plan or a third plan, I think the 
agenda is not suited for that purpose.

Since the point of having an IETF process is to get to decisions, and 
the point of having interims is to further the IETF process, I still 
think we could allocate more time to what's important.

This issue's been festering for a year at least. We need to stop 
informing ourselves and find a consensus.

BUNDLE: SDP O/A Open Issue: Allowed for Offerer to assign same address to multiple m- lines before Answerer has indicated BUNDLE support in SDP Answer?

Christer Holmberg — 2013-06-17T07:20:16

Hi,

In BUNDLE-04, there are a couple of open issues associated with assigning the same address to multiple m= lines in a BUNDLE group.

The main technical issue is whether it should be allowed to do it *before* the Answerer has, in the SDP Answer, indicated support of BUNDLE.

I.e. should it be allowed to, in the *initial* SDP Offer, assign the same address to multiple m= lines in a BUNDLE group?

Paul has indicated that it should be allowed, if the Offerer e.g. "knows" that the environment where it is operating in supports BUNDLE.

Now, as that is very similar to my original BUNDLE proposal, I would like to hear what others (especially Cullen) thinks about it.

Regards,

Christer
_______________________________________________
mmusic mailing list
mmusic< at >ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Re: MMUSIC WG June 17th virtual interim agenda

Flemming Andreasen — 2013-06-17T02:47:03

Our expectation is that there will be many questions and comments on 
each of the plan presentations as we go through them, hence the 1 hour 
allocation for each suggested. Furthermore, we wanted to ensure that 
each plan got it's fair share of time allocated to discussion. The 
remaining 40 mins were intended to be more open-ended discussion based 
on what we have heard and discussed for each plan by then.

Based on the above, please let us know if folks still feel the agenda 
should be modified.

Thanks

Re: MMUSIC WG June 17th virtual interim agenda

Mary Barnes — 2013-06-15T18:22:43

An excellent suggestion.  I had been putting together an email on just
this topic as it wasn't all clear to me what the objectives were and
who was really leading the meeting and discussions.

Mary.

On Sat, Jun 15, 2013 at 4:39 AM, Harald Alvestrand <harald< at >alvestrand.no> wrote:

Re: MMUSIC WG June 17th virtual interim agenda

Stefan Håkansson LK — 2013-06-15T16:51:26


+1

_______________________________________________
mmusic mailing list
mmusic< at >ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Re: MMUSIC WG June 17th virtual interim agenda

Bernard Aboba — 2013-06-15T15:16:43

+1

On Jun 15, 2013, at 7:11 AM, "Paul Kyzivat" <pkyzivat< at >alum.mit.edu> wrote:

_______________________________________________
mmusic mailing list
mmusic< at >ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Re: MMUSIC WG June 17th virtual interim agenda

Paul Kyzivat — 2013-06-15T14:11:09

+1

On 6/15/13 5:39 AM, Harald Alvestrand wrote:

Re: MMUSIC WG June 17th virtual interim agenda

Harald Alvestrand — 2013-06-15T09:39:45

Not on A vs B, but on the agenda:

This time allocation is:

- 20 mins administrativia
- 120 mins presentation
- 40 mins discussion

I do not think this is a wise allocation. It maximizes the time given to 
plan "owners" to present their viewpoints, and minimizes the time 
avaliable for people who do not "own a plan" to present a viewpoint.
People who come to the meeting SHOULD have read the drafts beforehand. 
If not, listening to 60 mins of presentation won't make them understand 
the issues.

I would suggest instead:

- 10 min administrativia (agenda bash)
- 15 min Plan A presentation
- 15 min Plan A clarification questions
- 15 min Plan B presentation
- 15 min Plan B clarification questions
- 10 min presentaton on "what questions do we need to answer" (by the 
chairs)
- 90 min discussion on answering the questions (structured by the chairs)
- 10 min administrativia (wrapup)

(and yes, this is enough time that one could fit in a slot for "no plan" 
too)

(I'm HOPING that the draft agenda is intended to sh

When commenting on BUNDLE-04

Christer Holmberg — 2013-06-15T08:58:12

Hi,

When giving comments on BUNDLE-04, I would appreciate if you could separate your comments into different e-mails, e.g. one mail per main topic (SDP O/A procedures, ICE usage, SDP Attribute procedures, etc etc etc).

It will be much easier to follow the discussion, and we'll avoid ultralong e-mails :)

It would also be good if you could indicate whether any given comment is editorial or technical.

Thanks!

Christer
_______________________________________________
mmusic mailing list
mmusic< at >ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

Re: BUNDLE TEXT: Offerer procedures (June 12th)

Christer Holmberg — 2013-06-15T08:55:16

Hi,


I think the only technical issue is whether it's allowed to:

1) Assign an address to multiple m- line before it has been selected as a bundle address; and

2) Whether it's allowed to assign an address to multiple m- line before the Answerer has indicated *in the SDP Answer* whether it supports BUNDLE.

The two are of course related, because in order to allow 2) we also need to allow 1) :)

I personally don't have any problems with you suggestion (it will require some editorial work, but technically there should be no issues). 

However, it does sound very much like my original BUNDLE proposal (where the Offerer ALWAYS assigned the bundle address to all m- lines), so I'd like to hear what others - especially Cullen - thinks about it.

Regards,

Christer