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

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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: den 26 oktober 2011 19:19
To: avt@ietf.org
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.

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

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt