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

[Paul Kyzivat <[e-mail]>]

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) <[e-mail]
> <mailto:[e-mail]>> 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
>> <[e-mail]> 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:[e-mail]] On Behalf Of Paul Kyzivat
>>>> Sent: den 7 juli 2014 19:32
>>>> To: [e-mail]
>>>> 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 <[e-mail]>
>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>