Re: actpass redux
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <[email protected]> |
On 6/9/17 2:23 PM, Roman Shpount wrote: > On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <[email protected] > <mailto:[email protected]>> wrote: > > On 6/9/17 9:17 AM, Cullen Jennings wrote: > > > On Jun 8, 2017, at 6:49 PM, Roman Shpount <[email protected] > <mailto:[email protected]>> wrote: > > Because of this, I think for the best interop, offerer > MUST specify actpass for both initial and subsequent offers > but answerer MUST be able to handle active and passive setup > roles as well. > > > that works for me > > > I don't understand what this accomplishes. If you must be able to > accept anything in a received offer, then what is gained by > restricting what can be used in an offer? > > > This is all because of legacy interop. There are legacy end points that > send non-actpass, so end point MUST be able to accept active and passive > to interop with such legacy devices. There are also legacy end points > that only expect actass so end point MUST only send actpass to interop > with such devices. I understand that. But if you accept that legacy interop is needed, then there ceases to be any reason to mandate actpass for things that conform to this spec. It would be different if you were proposing a path to deprecating and then dropping the legacy support. If that is the intent then it is worth saying something explicit about it. Thanks, Paul