Subject: [MMUSIC] IETF#89: BUNDLE: Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines? - A new take.

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 13:17:45 +0000

Hi,

Based on the discussions, we basically have two alternatives:

Alternative 1: Forbid the usage of the same PT value within multiple m- lines.

Alternative 2: Allow usage of the same PT value within multiple m- lines, and if the answer does not support whatever extensions that are needed for the offerer to distinguish the media, the offer needs to handle that, e.g. by sending a new offer with unique PT values.

IF we choose Alternative 2, we still need to decide whether we let the offerer decide when it's "appropriate" when to use the same PT value, or whether we need to specify some rules (as suggested by Colin). My personal proposal is still to let the offerer decide, and not specify any rules.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 3 Mar 2014 14:00:54 +0000

Hello Christer

  A small twist on your proposal

  I think the recommendation in the BUNDLE document should say 2 points

  1. Reuse of PT is allowed only in the cases where the end-point is able
to uniquely map the incoming RTP Streams to its corresponding m=line. The
specific mechanisms to do so are out of the scope of this document .
Informally, SSRC, AppID or similar stream correlators can be used.

Also using the same PT across multiple m=lines implies the same underlying
codec configuration.

  2. Otherwise, reuse of PT across multiple m=lines MUST NOT be performed
while multiplexing.

We can add example for either if needed

Any thoughts

Thanks
Suhas

On Mon, Mar 3, 2014 at 1:17 PM, Christer Holmberg <
[email-masked]> wrote:

> *Alternative 1*: Forbid the usage of the same PT value within multiple m-
> lines.
>
>
>
> *Alternative 2*: Allow usage of the same PT value within multiple m-
> lines, and if the answer does not support whatever extensions that are
> needed for the offerer to distinguish the media, the offer needs to handle
> that, e.g. by sending a new offer with unique PT values.
>
>
>
> IF we choose Alternative 2, we still need to decide whether we let the
> offerer decide when it's "appropriate" when to use the same PT value, or
> whether we need to specify some rules (as suggested by Colin). My personal
> proposal is still to let the offerer decide, and not specify any rules.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 14:27:13 +0000

Hi,

>  1. Reuse of PT is allowed only in the cases where the end-point is able to uniquely map the >   incoming RTP Streams to its corresponding m=line. The specific mechanisms to do so are >   out of the scope of this document . Informally, SSRC, AppID or similar stream correlators >   can be used.

But, again, when you send the offer, how do you know what "correlators" the answerer supports? Should we say that is out of the scope?

> Also using the same PT across multiple m=lines implies the same underlying codec
> configuration.

So, what is YOUR definition of "codec configuration"? :)

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 3 Mar 2014 14:33:18 +0000

Hello Christer

  Comments Inline.

Cheers
Suhas

On Mon, Mar 3, 2014 at 2:27 PM, Christer Holmberg <
[email-masked]> wrote:

> >  1. Reuse of PT is allowed only in the cases where the end-point is
> able to uniquely map the >   incoming RTP Streams to its corresponding
> m=line. The specific mechanisms to do so are >   out of the scope of this
> document . Informally, SSRC, AppID or similar stream correlators >   can
> be used.
>
>
>
> But, again, when you send the offer, how do you know what "correlators"
> the answerer supports? Should we say that is out of the scope?
>
>
>

[Suhas] I am happy with some text similar to here:
https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.2.

If the Offer/Answer can't prove any mechanism possible, It would imply new
Offer/Answer with unique PTs. I don't see if one can escape the worst-case
scenario though.

> So, what is YOUR definition of "codec configuration"? J
>
>
>
[Suhas] I shall stick with Colin's suggestion.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 14:40:47 +0000

Hi,

[Suhas] I am happy with some text similar to here: https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.2.

If the Offer/Answer can't prove any mechanism possible, It would imply new Offer/Answer with unique PTs. I don't see if one can escape the worst-case scenario though.

If people are ok with that, it works for me.

I guess that means that we would need a flag in the API to indicate whether the same PT value can be used or not.

Regards,

Christer