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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 06 August 2014 13:47 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 C5FF61B2D42 for <mmusic@ietfa.amsl.com>; Wed, 6 Aug 2014 06:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.265
X-Spam-Level: **
X-Spam-Status: No, score=2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, MANGLED_TOOL=2.3, SPF_SOFTFAIL=0.665] 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 LQ8KDKqWYXVu for <mmusic@ietfa.amsl.com>; Wed, 6 Aug 2014 06:47:37 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9E81B2D37 for <mmusic@ietf.org>; Wed, 6 Aug 2014 06:47:37 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id bPRV1o0060mv7h058Rnd9m; Wed, 06 Aug 2014 13:47:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id bRnc1o00l3ZTu2S3XRnczq; Wed, 06 Aug 2014 13:47:37 +0000
Message-ID: <53E231F8.5080604@alum.mit.edu>
Date: Wed, 06 Aug 2014 09:47:36 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
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> <9D8A6737-45D2-44A5-84D1-772754B6E861@sverigesradio.se>
In-Reply-To: <9D8A6737-45D2-44A5-84D1-772754B6E861@sverigesradio.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407332857; bh=mrCvHK7zjZE6M5RvY2k+DvXIiSE2XVis30C//VEmBVg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UyOLc2Wtnr84XzAAmGIThkn5LdGB4beoBRTdoiBWP8ndjfCbIaD2Grs1UOttwHqZU hbPpRHBMs0ghpMNrI2zomaIcxTQ6gGxDP4lfGELy3OyKhCmtfhmIRNYOtqyTRqK6RA ki8zLAUVhRwED+HVQNinhFro7DyfJrMoUwNye4vnUoMywXYXIrnb7/CQ7NzUXZnbPZ VjDjZ/fLvNzRrey6lpemt1hTvHMK2jAYfOhuhjF42FGbpZTUY2r1Byh+yAocVJGShX maQZajZGFvrbyXhTuRNl9hRw0K+XGOPTKhBx2mhjBHC7tbRzi7654Wi/XzYu3ZuVuV wLRMpfjVwq+CQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FP8NUfZow8N_SLDdQhNCv3ipkg4
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 13:47:39 -0000

Fredrik,

There is now a solution to your asymmetric use case, using the BUNDLE 
draft: draft-ietf-mmusic-sdp-bundle-negotiation-07.

	Thanks,
	Paul

On 8/6/14 5:49 AM, Fredrik Bergholtz wrote:

> 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
>>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>