Subject: [MMUSIC] 4566bis open issues (from Flemming's review)

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 20 Feb 2018 18:25:01 +0300

All,

The latest and greatest 4566bis draft is here:
https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-25

There are some issues raised by Flemming in his chair review, and I would like to get the list’s opinion on these.

Thanks.
-acbegen

1) Section 5.7:

   A session description MUST contain either at least one "c=" line in
   each media description or a single "c=" line at the session level.
   It MAY contain a single session-level "c=" line and additional "c="
   line(s) per media description, in which case the per-media values
   override the session-level settings for the respective media.

Comment: Multiple c= lines is only allowed for multicast, right? Can we clarify that here? 

   The slash notation for multiple addresses described above MUST NOT be
   used for IP unicast addresses.

Comment: And hence you also cannot specify more than one c= line for a unicast stream, right ?

2) Section 5.8:

   The <bandwidth> is interpreted as kilobits per second by default.

Comment: What about lower layer overhead? RFC 3550 Section 6.2 specifies that we include UDP and IP overhead, etc. but not link layer. I believe this is consistent with (old) discussions on the MMUSIC mailing list as well and think it would be useful to clarity that here.

3) Section 5.9:

   The first and second sub-fields give the start and stop times,
   respectively, for the session.  These values are the decimal
   representation of Network Time Protocol (NTP) time values in seconds
   since 1900 [RFC5905].  To convert these values to UNIX time, subtract
   decimal 2208988800.

Comment: What is the time zone ? RFC 5905 suggests it's UTC (which makes sense), however the subsequent discussion in the "time zone" adjustment field seems to (logically) contradict that, so I'm confused.

4) Section 6.4 and 6.5:

   Syntax:
         ptime-value = non-zero-int-or-real
         maxptime-value = non-zero-int-or-real

Comment: I always thought they were integeres. The text below doesn't make it clear one way or the other, which it needs to.

5) Section 6.15:

   This attribute allows parameters that are specific to a particular
   format to be conveyed in a way that SDP does not have to understand
   them.  The format must be one of the formats specified for the media.
   Format-specific parameters may be any set of parameters required to
   be conveyed by SDP and given unchanged to the media tool that will
   use this format.  At most one instance of this attribute is allowed
   for each format.

Comment: Should we say something about the general convention being a semi-colon separate list of format parameters, as shown in the example ?

6) Section 7:

   One transport that can be used to distribute session descriptions is
   the SAP.  SAP provides both encryption and authentication mechanisms,
   but due to the nature of session announcements it is likely that
   there are many occasions where the originator of a session
   announcement cannot be authenticated because the originator is
   previously unknown to the receiver of the announcement and because no
   common public key infrastructure is available.

Comment: Does SAP provide integrity protection as well?

7) Section 8.2.2:

   The "proto" field describes the transport protocol used.  This SHOULD
   reference a standards-track protocol RFC.  This memo registers three
   values: "RTP/AVP" is a reference to [RFC3550] used under the RTP
   Profile for Audio and Video Conferences with Minimal Control
   [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the
   Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an
   unspecified protocol over UDP.

Comment: Why is the existing registration to RFC3711 not used (i.e. leave out here) ?

   New transport protocols SHOULD be registered with IANA.
   Registrations MUST reference an RFC describing the protocol. Such an
   RFC MAY be Experimental or Informational, although it is preferable
   that it be Standards Track.  Registrations MUST also define the rules
   by which their "fmt" namespace is managed (see below).

Comment: We have an existing registration for udptl which references T.38. It should actually reference RFC 7345 (seems like an IANA mistake, so maybe make a note of that).

8) Section 8.2.3:

Comment: Where are these registrations to be done? The IANA instructions and actual location of the corresponding registries are unclear.

9) Section 8.2.5:

   IANA has registered the bandwidth specifiers "CT" and "AS" with
   definitions as in Section 5.8 of this memo (these definitions update
   those in [RFC4566]).

Comment: The current IANA registration points to RFC4566 and mux-attributes, yet here it says the definition in 4566bis is what matters. Something needs to change here.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2018 11:18:18 -0500

> Comment: I always thought they were integeres. The text below doesn't make it clear one way or the other, which it needs to.

I went back looking for where this came from. It appears that I have 
incomplete history. It came in in late 2015 – early 2016. If you look at 
rfc4566, it doesn’t provide *any* syntax for “packet time”.

My recollection is that somebody felt there was a need for fractional 
ptimes. (And maybe some deployed usage?) Hence we put this in.

Does anyone else have any info or memory of this?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2018 11:25:57 -0500

> Comment: Does SAP provide integrity protection as well?

It appears that this text is carried over directly from rfc4566. But of 
course the expectations for security considerations are much higher than 
they used to be. So perhaps this should be rewritten.

Is SAP still used? Perhaps it would be better to simply remove it. If it 
is still used then can we get someone who knows it to write something?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2018 12:12:51 -0500

> Comment: Where are these registrations to be done? The IANA instructions and actual location of the corresponding registries are unclear.

This does seem to be a mess. The current text is pretty much the same as 
4566. I went back to rfc2327 for clarification. It said:

‘For non-RTP formats, any unregistered format name may be registered 
through the MIME-type registration process [RFC 2048]. The type given 
here is the MIME subtype only (the top-level MIME content type is 
specified by the media parameter).  The MIME type registration SHOULD 
reference a standards-track RFC which describes the transport protocol 
for this media type.  If there is an existing MIME type for this format, 
the MIME registration should be augmented to reference the transport 
specification for this media type.  If there is not an existing MIME 
type for this format, and there exists no appropriate file format, this 
should be noted in the encoding considerations as "no appropriate file 
format".’

That never seemed like a great idea since it overloaded media type 
definitions.

As best I understand, the intent is simply that “fmt” values and usage 
be defined within the document that is referenced in the IANA “proto” 
registration.

I can see being more normative about this, but then we need to have a 
discussion  about that.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 20 Feb 2018 22:23:06 -0500

> Comment: Multiple c= lines is only allowed for multicast, right? Can

The final two paragraphs of the section are:

   Multiple addresses or "c=" lines MAY be specified on a per media
   description basis only if they provide multicast addresses for
   different layers in a hierarchical or layered encoding scheme.  They
   MUST NOT be specified for a session-level "c=" line.

> Comment: What is the time zone ? RFC 5905 suggests it's UTC (which
> makes sense), however the subsequent discussion in the "time zone"
> adjustment field seems to (logically) contradict that, so I'm
> confused.

NTP time values and Unix time values are always time-zone invariant.
NTP counts seconds from 00:00 1 Jan 1900 UTC, whereas Unix counts from
00:00 1 Jan 1970 UTC, so instants designated on those time scales are
independent of any time zone.  (Neither scale counts leap seconds.)
"z=" is only used for repeating events, and specifies corrections for
when the repeats are scheduled according to a civil time system whose
offset from UTC changes.

> Comment: I always thought they were integeres. The text below doesn't
> make it clear one way or the other, which it needs to.

Clearly, the draft intends to allow fractional values.  But why isn't
this "positive-int-or-real"? -- Negative values aren't meaningful.

However, it's not clear to me what the difference between ptime and
maxptime is.

> Comment: Should we say something about the general convention being a
> semi-colon separate list of format parameters, as shown in the example?

Given that the specified syntax is "byte-string", it's probably not
worth it.

> Comment: Why is the existing registration to RFC3711 not used

Looking at the IANA registry, the reason seems to be that RTP/AVP and
udp are registered by RFC 4566, and so have to be refreshed by the -bis
document, the authors mistakenly assumed that RTP/SAVP was also
registered by RFC 4566 and so also needed to be refreshed.  But
actually, RTP/SAVP was registered by RFC 3711 and so does not have to be
refreshed.

Dale

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Feb 2018 23:50:31 +0000

> On 20 Feb 2018, at 16:18, Paul Kyzivat <[email-masked]> wrote:
> 
> I went back looking for where this came from. It appears that I have incomplete history. It came in in late 2015 – early 2016. If you look at rfc4566, it doesn’t provide *any* syntax for “packet time”.
> 
> My recollection is that somebody felt there was a need for fractional ptimes. (And maybe some deployed usage?) Hence we put this in.
> 

It seems to have been added in 4566bis-15. Ali’s presentation at IETF 92 discusses it https://www.ietf.org/proceedings/92/slides/slides-92-mmusic-1.pdf <https://www.ietf.org/proceedings/92/slides/slides-92-mmusic-1.pdf> and the minutes from that meeting say:

a=ptime: and a=maxptime: 
 
Are these always integers?
Paul Kyzivat had made a suggestion to allow the use of decimal fractions only when the fractional part is non-zero. This definition could also be used for framerate; question around whether framerate could be zero. 
 
Jonathan Lennox liked Paul's suggestion. Framerate should not be zero.
 
Roni Even noted that framerate of zero could be a still image.
 
Conclusion: 
●      Nobody objects to Ali’s/Paul's suggestion, so move forward with fractional values.

See also https://trac.ietf.org/trac/mmusic/ticket/21 <https://trac.ietf.org/trac/mmusic/ticket/21>

(I’m fairly sure there were some earlier comments that triggered this discussion, but I can’t find them)

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Feb 2018 23:54:47 +0000

> On 20 Feb 2018, at 16:25, Paul Kyzivat <[email-masked]> wrote:
> It appears that this text is carried over directly from rfc4566. But of course the expectations for security considerations are much higher than they used to be. So perhaps this should be rewritten.
> 
> Is SAP still used? Perhaps it would be better to simply remove it. If it is still used then can we get someone who knows it to write something?

I’m unconvinced SAP is still used, but in principle it provided integrity protection via a PGP signature. This almost certainly doesn’t meet current standards.

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Fri, 23 Feb 2018 00:03:04 +0000

> On 20 Feb 2018, at 17:12, Paul Kyzivat <[email-masked]> wrote:
> 
> This does seem to be a mess. The current text is pretty much the same as 4566. I went back to rfc2327 for clarification. It said:
> 
> ‘For non-RTP formats, any unregistered format name may be registered through the MIME-type registration process [RFC 2048]. The type given here is the MIME subtype only (the top-level MIME content type is specified by the media parameter).  The MIME type registration SHOULD reference a standards-track RFC which describes the transport protocol for this media type.  If there is an existing MIME type for this format, the MIME registration should be augmented to reference the transport specification for this media type.  If there is not an existing MIME type for this format, and there exists no appropriate file format, this should be noted in the encoding considerations as "no appropriate file format".’
> 
> That never seemed like a great idea since it overloaded media type definitions.
> 
> As best I understand, the intent is simply that “fmt” values and usage be defined within the document that is referenced in the IANA “proto” registration.
> 
> I can see being more normative about this, but then we need to have a discussion  about that.

As I recall, the “fmt” namespace was intended to be the MIME media types namespace. There was a lot of discussion about this at the time, although I think mostly between the AVT chairs (since this related to how RTP payload types were registered), the ADs, and the MIME people.

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Fri, 23 Feb 2018 00:17:11 +0000

> On 20 Feb 2018, at 15:25, Ali C. Begen <[email-masked]> wrote:
> 
> All,
> 

That matches my understanding.

> Comment: What is the time zone ? RFC 5905 suggests it’s UTC (which makes sense), however the subsequent discussion in the "time zone" adjustment field seems to (logically) contradict that, so I'm confused.

They’re NTP timestamps. If I understand correctly, NTP is tied to UTC.

> Comment: Should we say something about the general convention being a semi-colon separate list of format parameters, as shown in the example ?

They’re MIME media type parameters, and therefore my definition semicolon separated. If that’s not clear, we should specify it.

> Comment: Does SAP provide integrity protection as well?

Yes.

> Comment: Where are these registrations to be done? The IANA instructions and actual location of the corresponding registries are unclear.

For RTP, they don’t need to be registered since the fmt value is the RTP payload type (see also RFC 3555).

For udp, you register the MIME media type following RFC 4288.

For anything else, you do as specified in the RFC that defines that “proto” value. 

This seems clearly specified.

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

-- 
Colin Perkins
https://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 24 Feb 2018 15:04:07 +0100

Hi,

I very split about this change. From the point of an RTP payload format 
that defines the packetization time, using fraction would be very nice. 
And also on that level it is an minor interoperability issue to allow 
these, the main problem is if the basic SDP parser throws a fit.

However, from my perspective the issue with ptime is that this is an 
payload format specific parameter that got overloaded onto a single per 
media stream instance. This becomes problematic as soon as one have 
multiple codes with none matching values, like if one like single frame 
audio payloads but have one 20 ms codec and one 30 ms one, what do one 
use, and how is it interpreted. And what happens if one would state 
ptime=22.5 when one have also a 22.5 frame length codec.

I wished we faced this issue earlier and changed the recommendation to 
leave the ptime and maxptime values in that a=ftmp lines and deprecated 
the use on media stream level.

I think both ptime and maxptime needs text on the fact that the value 
may not be matching the possible values for all of the payload formats. 
Especially if the value is a fractional one.

Cheers

Magnus Westerlund

Den 2018-02-23 kl. 00:50, skrev Colin Perkins:
>
>> On 20 Feb 2018, at 16:18, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> Comment: I always thought they were integeres. The text below 
>>> doesn't make it clear one way or the other, which it needs to.
>>
>> incomplete history. It came in in late 2015 – early 2016. If you look 
>> at rfc4566, it doesn’t provide *any* syntax for “packet time”.
>>
> It seems to have been added in 4566bis-15. Ali’s presentation at IETF 
> 92 discusses it 
> https://www.ietf.org/proceedings/92/slides/slides-92-mmusic-1.pdf and 
> the minutes from that meeting say:
>
>
>         a=ptime: and a=maxptime:
>
> Paul Kyzivat had made a suggestion to allow the use of decimal 
> fractions only when the fractional part is non-zero. This definition 
> could also be used for framerate; question around whether framerate 
> could be zero.
>
> *Conclusion*:
> ●Nobody objects to Ali’s/Paul's suggestion, so move forward with 
> fractional values.
>
>
> See also https://trac.ietf.org/trac/mmusic/ticket/21
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 24 Feb 2018 15:09:07 +0100

> That matches my understanding.

Yes, I concur with Colin here, the default includes everything to IP 
level. And clearly one can override that default by being explicit, like 
in the case of TIAS (RFC 3890). That RFC also have guiding 
interpretation on the default, by actually stating the following on AS:

1.1.2. Application Specific Maximum

    The Application Specific maximum bandwidth is indicated by the
    modifier "AS".  The interpretation of this attribute is dependent on
    the application's notion of maximum bandwidth.  For an RTP
    application, this attribute is the RTP session bandwidth as defined
    in RFC 3550 [4].  The session bandwidth includes the bandwidth that
    the RTP data traffic will consume, including the lower layers, down
    to the IP layer.  Therefore, the bandwidth is in most cases
    calculated over RTP payload, RTP header, UDP, and IP, defined in RFC
    2327 [1].

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Feb 2018 13:50:31 -0500

> these, the main problem is if the basic SDP parser throws a fit.

Having the general syntax support fractional values is only an enabler. 
Presumably each individual format also needs to specify what range of 
values it supports, and if that includes fractions. Presumably backward 
compatibility will mean that fractions can't be used in all cases. It 
might take more text to clarify this. (It isn't clear to me what that 
text ought to say.)

> Especially if the value is a fractional one.

I guess what you are saying here is roughly what I was trying to say above?

I guess the existing definitions of formats won't say anything about 
this. Do we need language that says fractional (and zero) values may 
only be used if the format explicitly defines their use?

	Thanks,
	Paul

> SE-164 80 Stockholm, Sweden | mailto:[email-masked]

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 25 Feb 2018 06:50:41 +0000

+1
Roni

From: mmusic [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Saturday, February 24, 2018 4:09 PM
To: Colin Perkins; Ali C. Begen
Cc: [email-masked]
Subject: Re: [MMUSIC] 4566bis open issues (from Flemming's review): Bandwidth values

2) Section 5.8:

Yes, I concur with Colin here, the default includes everything to IP level. And clearly one can override that default by being explicit, like in the case of TIAS (RFC 3890). That RFC also have guiding interpretation on the default, by actually stating the following on AS:

   2327 [1].

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 27 Feb 2018 12:45:10 +0300

On Fri, Feb 23, 2018 at 2:54 AM, Colin Perkins <[email-masked]> wrote:

> I’m unconvinced SAP is still used, but in principle it provided integrity
> protection via a PGP signature. This almost certainly doesn’t meet current
> standards.
>

Proposed text:

One transport that was used to distribute session descriptions is the SAP,
which is currently not much used any more. SAP provided both encryption and
authentication mechanisms, but due to the nature of session announcements
it is likely that there were many occasions where the originator of a
session announcement could not be authenticated because the originator was
previously unknown to the receiver of the announcement and because no
common public key infrastructure was available. In principle, SAP provided
integrity protection via a PGP signature, however, this almost certainly
does not meet the current standards.

Let me know if this works for you.

-acbegen

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Feb 2018 09:36:06 -0500

On 2/27/18 4:45 AM, Ali C. Begen wrote:
> 
> 
> On Fri, Feb 23, 2018 at 2:54 AM, Colin Perkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     > On 20 Feb 2018, at 16:25, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>     I’m unconvinced SAP is still used, but in principle it provided
>     integrity protection via a PGP signature. This almost certainly
>     doesn’t meet current standards.
> 
> 
> Proposed text:
> 
> One transport that was used to distribute session descriptions is the 
> SAP, which is currently not much used any more. SAP provided both 
> encryption and authentication mechanisms, but due to the nature of 
> session announcements it is likely that there were many occasions where 
> the originator of a session announcement could not be authenticated 
> because the originator was previously unknown to the receiver of the 
> announcement and because no common public key infrastructure was 
> available. In principle, SAP provided integrity protection via a PGP 
> signature, however, this almost certainly does not meet the current 
> standards.
> 

I don't find this helpful. Rather it just seems odd for security 
considerations to be talking about a protocol that isn't used.

I think we could just drop the paragraph in question without losing 
anything.

Or, we could pick another protocol (e.g., SIP) as an example and discuss 
how security works there.

	Thanks,
	Paul

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 28 Feb 2018 18:09:08 +0300

On Wed, Feb 28, 2018 at 5:36 PM, Paul Kyzivat <[email-masked]> wrote:

>>     > It appears that this text is carried over directly from rfc4566.
>> But of course the expectations for security considerations are much higher
>> than they used to be. So perhaps this should be rewritten.
>>     >
>>     > Is SAP still used? Perhaps it would be better to simply remove it.
>> If it is still used then can we get someone who knows it to write something?
>>
>> encryption and authentication mechanisms, but due to the nature of session
>> announcements it is likely that there were many occasions where the
>> originator of a session announcement could not be authenticated because the
>> originator was previously unknown to the receiver of the announcement and
>> because no common public key infrastructure was available. In principle,
>> SAP provided integrity protection via a PGP signature, however, this almost
>> certainly does not meet the current standards.
>>

I am ok with removing the entire paragraph.

-acbegen

---

From: Peter Stevens <[email-masked]>
Date: Wed, 28 Feb 2018 15:30:30 +0000

I've just seen some of this discussion regarding whether SAP is still being used.

I haven't investigated the details of how it is used within their devices, but SAP is used within Dante products, of which there are many from different manufacturers.
It might be worth contacting one or more of them for comments.

Peter Stevens

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: 28 February 2018 14:36
To: [email-masked]
Subject: Re: [MMUSIC] 4566bis open issues (from Flemming's review): SAP

        Thanks,
        Paul

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Feb 2018 12:39:20 -0500

> It might be worth contacting one or more of them for comments.

In any case, in this context it was only being used as an example. At 
the time it was first written it may well have been the only example. 
But today it is clearly not the the most common, or well known, use. So 
it is kind of a weird thing to include.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Feb 2018 17:56:14 +0000

Hi,

I agree: there is no need to say anything about SAP in the Security Considerations. 

I also don't think we need the first sentence in section 4.4, because what does it have to do with SDP? If SAP wants to filter, SAP should describe how to filter.

I'm ok mentioning SAP in Sections 1 and 3.4 - elsewhere I think we should remove it.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 28 February 2018 19:39
To: Peter Stevens <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] 4566bis open issues (from Flemming's review): SAP

> It might be worth contacting one or more of them for comments.

In any case, in this context it was only being used as an example. At the time it was first written it may well have been the only example. 
But today it is clearly not the the most common, or well known, use. So it is kind of a weird thing to include.

	Thanks,
	Paul

>>      I'm unconvinced SAP is still used, but in principle it provided
>>      doesn't meet current standards.
>>
>>
>> Proposed text:
>>
>> session announcements it is likely that there were many occasions 
>> where the originator of a session announcement could not be 
>> authenticated because the originator was previously unknown to the 
>> receiver of the announcement and because no common public key 
>> infrastructure was available. In principle, SAP provided integrity 
>> protection via a PGP signature, however, this almost certainly does 
>> not meet the current standards.
>>
> Or, we could pick another protocol (e.g., SIP) as an example and 
> discuss how security works there.
> 
>          Thanks,
>          Paul
> 
> 
> 
> 
> This e-mail (and any attachments) is confidential and may contain 
> personal views which are not the views of the BBC unless specifically stated.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 28 Feb 2018 21:51:05 +0300

Works for me. I implemented the changes.

-acbegen

On Wed, Feb 28, 2018 at 8:56 PM, Christer Holmberg <
[email-masked]> wrote:

> I also don't think we need the first sentence in section 4.4, because what
> does it have to do with SDP? If SAP wants to filter, SAP should describe
> how to filter.
>
> > I haven't investigated the details of how it is used within their
> devices, but SAP is used within Dante products, of which there are many
> from different manufacturers.
> In any case, in this context it was only being used as an example. At the
> time it was first written it may well have been the only example.
> >>      > Is SAP still used? Perhaps it would be better to simply remove
> it. If it is still used then can we get someone who knows it to write
> something?
> >>