Re: [MMUSIC] 4566bis outstanding issues - Send, receive asymmetry and port numbers

Fredrik Bergholtz <fredrik.bergholtz@sverigesradio.se> Wed, 06 August 2014 09:49 UTC

Return-Path: <fredrik.bergholtz@sverigesradio.se>
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 87FAC1B2CF7 for <mmusic@ietfa.amsl.com>; Wed, 6 Aug 2014 02:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.15
X-Spam-Level:
X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 JhjV2fsDAgC4 for <mmusic@ietfa.amsl.com>; Wed, 6 Aug 2014 02:49:27 -0700 (PDT)
Received: from mail-2.sr.se (mail-2.sr.se [IPv6:2001:67c:d8:ee80::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B203D1B2CFC for <mmusic@ietf.org>; Wed, 6 Aug 2014 02:49:17 -0700 (PDT)
X-Halon-ID: 7d8b295c-1d4e-11e4-b526-000c2951fa8d
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:from:to:cc:subject:thread-topic:thread-index: date:message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:content-type:mime-version; bh=ujIi1zkQNuasDqiUpw5yqX6xQ4tP1rHUoKD7avFCi4Q=; b=Np3ErGBfB3hLm8zz0M1xDYwIRynwFAc5TjQxfydIJTFtKhNgbLAgeYhpaa2+Pd/G6jmxrqCTYL7hN WLdsaA7lVWptxqbWXX2t8fx3WIo57TS38gcJq3nZ9kET70GhRmx8XVGPm0ajBzmWf3XbvOMwgetZQD oTQUp/52ydIuPX6c=
Received: from STOEXCASHT02.sr.se (unknown [134.25.11.15]) by mail-2.sr.se (Halon Mail Gateway) with ESMTPS; Wed, 6 Aug 2014 11:46:07 +0200 (CEST)
Received: from STOEXMBX01.sr.se ([fe80::3ca4:10d1:e63f:5b7f]) by STOEXCASHT02.sr.se ([fe80::88c7:d3b3:5c76:acd7%13]) with mapi id 14.03.0181.006; Wed, 6 Aug 2014 11:49:10 +0200
From: Fredrik Bergholtz <fredrik.bergholtz@sverigesradio.se>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Thread-Topic: [MMUSIC] 4566bis outstanding issues - Send, receive asymmetry and port numbers
Thread-Index: AQHPsVus4fL0DD3l7kiyoL4ure303w==
Date: Wed, 6 Aug 2014 09:49:10 +0000
Message-ID: <9D8A6737-45D2-44A5-84D1-772754B6E861@sverigesradio.se>
References: <C15918F2FCDA0243A7C919DA7C4BE9940ECF6C11@xmb-aln-x01.cisco.com> <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com> <E851980F-648E-41E1-A200-64BF720D91F5@cisco.com> <53BAA873.6050907@alum.mit.edu> <EE893C03-926F-427C-B4ED-61EF7601130B@cisco.com> <53BAD9A0.6060304@alum.mit.edu> <6A5A8D4EF65AF1439301480747E29F434E42B417@STOEXMBX01.sr.se> <5BF924B8-20CB-4CB2-A152-B49ED07651CD@cisco.com>
In-Reply-To: <5BF924B8-20CB-4CB2-A152-B49ED07651CD@cisco.com>
Accept-Language: en-GB, sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_9D8A673745D244A584D1772754B6E861sverigesradiose_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2FbpBv3TYTikga4Oy257Uv2F0n0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 4566bis outstanding issues - Send, receive asymmetry and port numbers
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: Wed, 06 Aug 2014 09:49:30 -0000

Thanks for the reply, Ali.

The change you referred to is good and helps to further the understanding of the attributes even though it doesn’t explicitly deal with the asymmetry use-case that I have in mind. It does exemplify how to use these attributes on a media level and this is good. It might even be enough. I might want to increase the clarity by changing the paragraph saying:

Within the following SDP example, the "inactive” attribute
applies to audio media and the "recvonly" attribute applies to
video media.

To something like:

Within the following SDP example, the "inactive” attribute
applies to all media. The “recvonly” attribute in the video
media description overrides the session-level “inactive”
attribute. The result is that the audio media is “inactive”
and the video media is “recvonly".
The original text for the “sendonly" attribute mentions that one reason for using this would be if the unicast address was different for send and receive, while this is true, it will be more common to use this when different coding algorithms are to be used for send and receive. When I say more common, I mean in the radio broadcasting business segment, I can not make assumptions on other use-cases.

The change, however, does not address the “same port” issue. Section 5.14 of rfc 4566 states: “The semantics of multiple "m=" lines using the same transport address are undefined.” The text is not perfectly clear on what the “transport address” is, but it is implied that this is, in fact the “port” number(s). My thinking is that this restriction is only valid when the directionality of the media descriptions are the same.

The following is an example of an asymmetrical SDP that might be used in a radio broadcast use-case. From a reporter in the field, a reasonably high audio quality is required but the return from the studio to the reporter only need to be good enough for spoken cues.

v=0
o=mtu-02 3599993974 3599993974 IN IP4 example.com<http://example.com>
s=mtu-02
c=IN IP4 203.0.113.12
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 aptx/32000/1
a=fmtp:96 variant=enhanced; bitresolution=24
a=sendonly
a=ptime:20
m=audio 5004 RTP/AVP 9
a=rtpmap:9 G722/8000
a=recvonly

As I understand it, this SDP example would strictly have undefined semantics even though I think that the semantics are very clear.

I don’t have any concise candidate text that clarifies my points but I could try to think of some if there are no technical issues with the approach that I am unaware of.

Best regards,
Fredrik Bergholtz
Swedish Radio

P.S. I am not a native English speaker, so all my suggested text would have to be validated.



On 05 Aug 2014, at 16:32, Ali C. Begen (abegen) <abegen@cisco.com<mailto:abegen@cisco.com>> wrote:

Hi Fredrik

There were some changes in the bis document regarding these attributes in -08:
http://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rfc4566bis-07&url2=draft-ietf-mmusic-rfc4566bis-08

Do they help with your issue? If not, what else would you like to see?


I remember seeing a discussion regarding the use of the same port at some point but it was another draft (sorry I dont remember which one it was).

-acbegen

On Aug 5, 2014, at 3:35 PM, Fredrik Bergholtz <fredrik.bergholtz@sverigesradio.se> wrote:

Hi. Excellent to see a summarised list of what is considered for 4566bis.

Personally I would like to see ABNF definitions for all the attributes. I do realise the amount of work that is needed but, as someone else mentioned, the 4566 is the base line for all extensions and I think that it is important to make the base as well-defined as possible.

One item that is not in your list that I would like to see is a clarification of how to signal asymmetric sessions. By asymmetric sessions I mean using the a=sendonly and a=recvonly in separate media definitions, specifically addressing the "same port" issue of section 5.14.

I realise that this is a more use-case oriented addition than an improvement of the examples for the various attributes that has been discussed. Perhaps this kind of clarification belong in something like rfc4317 rather than in 4566. Do you have any thoughts on if and how such clarifications could and should be made?

Best regards,
Fredrik Bergholtz
Swedish Radio

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: den 7 juli 2014 19:32
To: mmusic@ietf.org
Subject: Re: [MMUSIC] 4566bis outstanding issues

Trimming again.

On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote:

On Jul 7, 2014, at 11:02 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
Hi Paul,

OK, no one else seems to be paying attention to this. I have some
comments inline and lets see whether we can reach an agreement:

OK.

I've trimmed to a few points to comment on...

On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:

1) 4566bis needs to provide ABNF syntax for all of the attributes 4566
defined.
Comments: This was discussed again in a side meeting in London and
there was not a consensus whether we actually needed this.

IIRC the argument against doing this is that we might get it wrong.

But IMO we should do it because if we can't get it right how can we
expect readers to get it right?

I personally don't wanna take on this task. It is a tedious task and I am not
such an ABNF lover to get these definitions right. If you wanna volunteer, by all
means, please do so.

I'm willing to contribute to this, but won't have time until after the Toronto
meeting.

That is fine.

Also, I'm not intimately familiar with all of the attributes.

Nobody is I am afraid.

There are a lots of people who at least *use* them, and so are familiar with
them at that level. I don't "do" media, so when I'm trying to create examples I
can get as far as "m=audio", and I know there should be an "a=rtpmap", but
beyond that I need to find an example to copy.

OK, this goes back to the issue #1. Personally, I suggest we do not define the
abnfs for every sdp attribute in 4566, but then you have a good point. We can
seek a format and provide a few good examples to show prospective authors.

To do this, obviously as you said, we need to agree on that format. Has
there been a proposal in the past or does anyone have a good proposal to start
with?

Not a formal one. There has been some discussion about this during review
of individual attribute definitions. My take has been that there is not agreement.

If you can recall, can you point us to that proposal and maybe briefly explain
the disagreements as well?

I think it will take a lot of searching to find it. So I can't do so quickly/easily.

One question is whether the definition of a new attribute should:
1) define the full syntax of the line (starting with "a="),
2) should provide additional definitions of <attribute> (via "/=")
3) should provide additional definitions of <att-field> and <att-value>
 (via "/=")
4) provide definitions of the name and value that are consistent with
 <att-field> and <att-value> without formally extending the
 definitions of those.

Note that 4566 loosely follows (4) but gives the definitions informally rather
than via ABNF. So it gives no guidance on how to use ABNF for this. A number of
drafts have chosen to follow (2). Some have started to do (1) but I don't know of
any that ended up that way.

A question I have raised is: if (2) or (3) is followed, does that mean that the
draft doing so must be considered as "updating" 4566?

I dont see why it should. Personally most of the attributes I defined followed
(4). That seemed the easiest option.

I've been outnumbered on the discussions of this. ISTM that whenever I write

attribute =/ something new

then I have at least extended the rfc that defines <attribute> and arguably have
updated it. The reason it might be considered an update is that what I am
defining implicitly includes the definition of <attribute> and thus probably all the
abnf that includes the definition of <attribute>. To verify my new abnf, or to
generate a parser, I need to create a combined abnf. And abnf doesn't have
namespaces. So all the rulenames I newly define must be distinct from those
defined with <attribute>.

And that is true for *every* extension. And for them to be compatible with one
another they all must define rulenames that are unique among them all.

So effectively each one is an update.

It is subtly different if I follow (4), even if I use abnf to define the syntax for my
new attribute, and even if I reuse rule definitions (like
<token>) from the base sdp definition.

One thing that people sometimes forget when defining new attributes is that
the syntax of the new attribute MUST also be valid when parsed by the "generic"
attribute syntax. AFAIK there is no way in ABNF to specify that. I think that (4)
comes closest.

Yes, but this must be checked during the last call by actual humans not some
abnf parser.

For now that is true. I have found such errors while doing SDP directorate
reviews.

Thanks,
Paul

-acbegen


Thanks,
Paul


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic