Re: actpass redux
Roman Shpount <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CAD5OKxucsrZvCP4v5tm_DSA5kGA4GwKRsFvS0tfu9M_FG_6WoQ@mail.gmail.com> |
On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat <[email protected]> wrote: > 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. > The situation right now is that there are implementations that send offers with setup role set to active or passive. So, my suggestion for the language (subject to future wordsmithing) is: End points MUST set setup role to actpass in all offers. End points SHOULD accept setup role active or passive in an offer if interoperability with legacy end points is desired. Does this work? _____________ Roman Shpount _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic