Subject: [MMUSIC] Simulcast draft feedback

From: Byron Campen <[email-masked]>
Date: Mon, 19 Oct 2015 15:22:17 -0500

**** Identification type shenanigans ****

     The draft currently allows the following:

a=simulcast: send rid=foo;bar;baz recv pt=96;97;98

     Here we have different identification types for each direction. Is 
this something the spec should allow? Also, things get really 
interesting when you add sendrecv:

a=simulcast: send rid=foo;bar;baz recv pt=96;97;98 sendrecv pt=100

     Now we have three simulcast streams that use rid, and a fourth that 
uses pt, for the send direction. This strikes me as a bad idea. Removing 
sendrecv is something that sounds like a good idea, for this and other 
reasons.

     (I would also point out that this would be a complete non-issue if 
we just used rid)

**** Payload type asymmetry confusion ****

     Consider the following simulcast offer/answer exchange, where the 
answerer removes a simulcast version and changes payload types:

offer:
a=rtpmap:96 VP8/90000
a=rtpmap:97 VP8/90000
a=rtpmap:98 VP8/90000
// a=fmtp that differ for the above three
a=simulcast: send pt=96;97;98

answer:
a=simulcast: recv pt=42;101

     What did the answerer just accept? We cannot infer from rtpmap, 
since those are all the same, and we probably cannot infer from fmtp 
either, since that isn't symmetric. Perhaps if imageattr were used, the 
offerer could attempt to determine which of the imageattrs in the answer 
matched what was placed in the offer, but this is a bit of a stretch.

     We could work around this with syntax like the following, perhaps:

answer:
a=simulcast: recv pt=42;;101

     (Again, I would point out that this would be a non-issue if we just 
used rid)

**** Requirements for support of PT-based simulcast ***

*    My understanding of the draft is that support for PT-based 
simulcast is mandatory, while RID-based simulcast is optional to 
implement. Is this correct? If so, how is negotiation supposed to look 
between an offerer that offers to use rid, and an answerer that does not 
support rid? Is the simulcast attribute simply removed? Is changing the 
identification type in an answer permitted under any circumstances?

**** Renegotiation questions ****

     This draft does not mention renegotiation at all. I'm assuming 
adding/removing simulcast versions and alternatives is ok. What about 
switching from PT-based to RID-based simulcast (or vice versa) in a reoffer?

Best regards,
Byron Campen

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2015 18:07:42 -0400

> a=simulcast: recv pt=42;101

I don't understand. I think you need to provide more info. Did it change 
PTs in the m-line of the answer for codec configs the offerer called 
96,97,98? Did it add more PTs not mentioned in the offer?

Without knowing that I can't figure out what the above might mean.

I agree this is murky.

	Thanks,
	Paul

---

From: Byron Campen <[email-masked]>
Date: Mon, 19 Oct 2015 17:09:54 -0500

On 10/19/15 5:07 PM, Paul Kyzivat wrote:
> I don't understand. I think you need to provide more info. Did it 
> change PTs in the m-line of the answer for codec configs the offerer 
> called 96,97,98? Did it add more PTs not mentioned in the offer?
>
     It changed the payload types that were present in the offer (same 
m-section).

Best regards,
Byron Campen

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 19 Oct 2015 22:40:04 +0000

The convention for existing SDP attributes is to refer to local media formats (PT for RTP media sections). If the answer uses different PTs for the same format, this can lead to complex format matching rules for local vs remote SDP. While I think everyone dislikes this complexity for the limited benefit of supporting asymmetry in PTs, I think simulcast and rid should just stick with the convention. It would be even greater complexity to have an SDP body refer to local PTs in most areas but remote PTs in a few others (rid and simulcast attributes). 

If we really want to avoid this complexity we need a new attribute like a=symmetric-pt-only independent of simulcast or rid. The complexity is unavoidable without this, because it is a basic thing even in single stream cases which obviously must be supported. There is no way simulcast or rid can avoid this complexity within their own specs. 

Mo

On Oct 19, 2015, at 6:10 PM, Byron Campen <[email-masked]> wrote:

> I don't understand. I think you need to provide more info. Did it change PTs in the m-line of the answer for codec configs the offerer called 96,97,98? Did it add more PTs not mentioned in the offer?
   It changed the payload types that were present in the offer (same m-section).

Best regards,
Byron Campen

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