Subject: [MMUSIC] Issue with RID draft: support for "pt=" should be optional

From: Peter Thatcher <[email-masked]>
Date: Thu, 22 Oct 2015 14:18:41 -0700

Currently, all attributes/constraints on an a=rid line are optional.  For
example, if the offer contains this:

a=rid:A send
a=rid:B send
a=simulcast rids:A,B

and the answer contains this:

a=RID:A recv max-fs=15
b=RID:B recv max-fs=15
a=simulcast rids:A,B

That's an error because the offer indicated no support for max-fs.

However, currently in the draft (if I'm reading it correctly), the answer
can contain this:

a=RID:A recv pt=1,2
b=RID:B recv pt=3,4
a=simulcast rids:A,B

This is problematic for two reasons:

1.  It's not consistent with all of the other attributes/constraints.

2.  Like many of the other attributes/constraints (which are optional), pt
doesn't map well to the WebRTC API, which means it will make sense to not
support pt constraints in WebRTC 1.0.  But if it remains mandatory in this
draft, then the draft may end up being incompatible with WebRTC 1.0.

I propose we treat pt= just like max-fs= and max-width=, etc, and make it
optional.  Otherwise we risk ending up with a draft that we can't use for
WebRTC 1.0 anyway.   Plus, it would be more consistent with all the other
attributes/constraints on an a=rid line.

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 16:25:16 -0500

On 10/22/15 4:18 PM, Peter Thatcher wrote:
> Currently, all attributes/constraints on an a=rid line are optional.  
> For example, if the offer contains this:
>
> a=rid:A send
> a=rid:B send
> a=simulcast rids:A,B
>
> However, currently in the draft (if I'm reading it correctly), the 
> answer can contain this:
>
> a=RID:A recv pt=1,2
> b=RID:B recv pt=3,4
> a=simulcast rids:A,B
>
>
> 2. Like many of the other attributes/constraints (which are optional), 
> pt doesn't map well to the WebRTC API, which means it will make sense 
> to not support pt constraints in WebRTC 1.0.  But if it remains 
> mandatory in this draft, then the draft may end up being incompatible 
> with WebRTC 1.0.

There's no reason this would have to be exposed at the API level, 
though. There are lots of things in SDP that don't bubble all the way up 
to the application, simply because they're not likely to care. That 
said, I have no serious objection to what you propose below...

> I propose we treat pt= just like max-fs= and max-width=, etc, and make 
> it optional.  Otherwise we risk ending up with a draft that we can't 
> use for WebRTC 1.0 anyway. Plus, it would be more consistent with all 
> the other attributes/constraints on an a=rid line.

I'm okay with that -- if an implementation didn't want to bind to PTs in 
its offer, but wanted to let the answerer indicate PTs, it could include 
a "pt" parameter with no value, just like the other parameters. Anyone 
object to such an approach?

/a