Subject: [AVTCORE] Max SSRC declaration: Objection to retrofitting rules

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Oct 2011 10:19:06 -0700

Hello,
I have read through draft-westerlund-avtcore-max-ssrc, and generally I 
find it a fine specification, which allows us to be explicit about an 
aspect of RTP usage that was not previously explicit.

However, I do have one strong objection to two specific paragraph:

    When max-send-ssrc or max-recv-ssrc are not included in the SDP, it
    MUST be interpreted as equivalent to a limit of one, unless sendonly
    or recvonly attributes are specified, in which case the limit is
    implicitly zero for the corresponding unused direction.
.....
    In case an answer fails to include any of the limitation attributes,
    the agent SHOULD be interpreted as capable of supporting only a
    single stream in the direction for which attributes are missing.

If I read this correctly:

  - There is no way to tell from SDP whether or not the sender or 
recipient intends to conform
    to the max-ssrc draft: The extension itself is not signalled.
  - Therefore, it seems that the intent of the paragraph is to change 
the rules about how to interpret
    SDP messages that do NOT contain any hint that their sender is 
conforming to max-ssrc
  - Therefore, the draft, if taken literally as written, would 
retroactively declare all usage
    of multiple SSRCs in a single RTP session to be noncompliant with 
its SDP declaration.

That seems to me to be an entirely unreasonable thing to do, given that 
implementations are using multiple SSRCs on single RTP sessions every 
minute of every day.

I would not object to a section that instead said:

    When max-send-ssrc or max-recv-ssrc are not included in the SDP, no
    information about the supported number of SSRCs is available, unless 
sendonly
    or recvonly attributes are specified, in which case the limit is
    implicitly zero for the corresponding unused direction.

    If a specific deployment is protected by gateways that modify SDP, 
and have
   knowledge of a specific limit active within that deployment, those 
gateways
   MAY choose to add max-*-ssrc attributes to the SDP exchanged with the
   outside world, to indicate the limited capacity of those devices.
.....
    In case an answer fails to include any of the limitation attributes,
    local heuristics SHOULD be applied to produce a reasonable guess at the
    capacity of the responding agent.

Declaring a class of deployments non-conformant by IETF fiat is not, in 
my opinion, a reasonable option.
Encouraging the deployers of limited-function devices to be explicit 
about those limitations is a reasonable option.

                        Harald

---

From: Bo Burman <[email-masked]>
Date: Fri, 28 Oct 2011 17:45:22 +0200

Hello Harald,

I think your objection as well as your proposed replacement text are both very reasonable, and we will update the document accordingly.

Do you think that the proposed "local heuristics" approach will be a generally acceptable method to apply when the proposed attributes are not present? I am aware that it is most likely what will have to be done, but is it acceptable to refer to it in an Internet Draft, or need it somehow be more elaborate?

Best Regards
/Bo B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: den 26 oktober 2011 19:19
To: [email-masked]
Subject: [AVTCORE] Max SSRC declaration: Objection to retrofitting rules

Hello,
I have read through draft-westerlund-avtcore-max-ssrc, and generally I find it a fine specification, which allows us to be explicit about an aspect of RTP usage that was not previously explicit.

  - There is no way to tell from SDP whether or not the sender or recipient intends to conform
    to the max-ssrc draft: The extension itself is not signalled.
  - Therefore, it seems that the intent of the paragraph is to change the rules about how to interpret
    SDP messages that do NOT contain any hint that their sender is conforming to max-ssrc
  - Therefore, the draft, if taken literally as written, would retroactively declare all usage
    of multiple SSRCs in a single RTP session to be noncompliant with its SDP declaration.

That seems to me to be an entirely unreasonable thing to do, given that implementations are using multiple SSRCs on single RTP sessions every minute of every day.

    When max-send-ssrc or max-recv-ssrc are not included in the SDP, no
    information about the supported number of SSRCs is available, unless sendonly
    or recvonly attributes are specified, in which case the limit is
    implicitly zero for the corresponding unused direction.

    If a specific deployment is protected by gateways that modify SDP, and have
   knowledge of a specific limit active within that deployment, those gateways
   MAY choose to add max-*-ssrc attributes to the SDP exchanged with the
   outside world, to indicate the limited capacity of those devices.
.....
    In case an answer fails to include any of the limitation attributes,
    local heuristics SHOULD be applied to produce a reasonable guess at the
    capacity of the responding agent.

Declaring a class of deployments non-conformant by IETF fiat is not, in my opinion, a reasonable option.
Encouraging the deployers of limited-function devices to be explicit about those limitations is a reasonable option.

                        Harald

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2011 10:25:42 -0700

> I think your objection as well as your proposed replacement text are both very reasonable, and we will update the document accordingly.
Thanks!
> Do you think that the proposed "local heuristics" approach will be a generally acceptable method to apply when the proposed attributes are not present? I am aware that it is most likely what will h…
My personal opinion is that the more our internet-drafts reflect 
reality, the better off we are....

It is not an area in which I am expert, but I would think that people 
who do SBCs for a living are the best people to turn to for advice on 
how to describe what needs to be done here - and whether it is at all 
helpful to have these local heuristics described in an I-D.

                    Harald