Re: actpass redux
Roman Shpount <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CAD5OKxtqMRLd8SEm9Pj-yn0X7pV9yijY76CLpEvOrJEn15PRUA@mail.gmail.com> |
On Fri, Jun 9, 2017 at 5:18 PM, Paul Kyzivat <[email protected]> wrote: > On 6/9/17 3:41 PM, Roman Shpount wrote: > >> >> On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat <[email protected] >> <mailto:[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]> >> <mailto:[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]> >> <mailto:[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. >> > > Why is that a problem? If we simply specify that offers MUST contain setup role set to actpass, implementation would legitimately respond to anything with setup role set to active or passive with an error. We want to avoid this since there are existing end points that send active or passive in offers. There are also legacy end points that will only accept actpass. New end points MUST set setup role to actpass to work with them. Finally, setup role MUST be actpass since this allows answering party to determine the setup role. Answering end points typically should be active, since this reduces the call setup time. There is an exception to this for ICE-lite or symmetric UDP, where end points on public IP typically should be passive even when they are answering, since it will require the end point behind NAT to send the first packet to open the NAT pin-hole. > 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. >> > > So is it your intent to make implementation of support for responding to a > non-actpass offer OPTIONAL? This encourages implementations to decide to > not support legacy interop. IMO this is a bad idea because it is rarely > possible to ensure that it won't eventually be required. > You just said that we need to add language about phasing out support for offers with active or passive. We can phase out handling of active and passive setup roles when they are no longer used by existing implementations. This is why it is a SHOULD. We can make handling active and passive offers permanent and put it under a MUST. Regards, _____________ Roman Shpount _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic