Hi, >>>maj-3) The document defines an option tag but doesn't say what it means >>>if it shows up in a Require: header. >> >>I think we could say that it means that the UAS must support 199. >>Whether it then actually sends 199 depends on whether it fulfils the >>UAS criteria for sending 199 (see maj-2). > >I think that is bad mojo. You don't want calls failing just because a b2bua or the far-end UAS doesn't support 199. > >What recourse would there be for the UAC? What would the UAC do if it got a 420 response because of it? It would make >the call again without the 199 option tag in Require, or worse it would fail the call and the user will call tech >support - because nothing is going to change when they make another call attempt with that option tag in Require. And >that is basically the definition of when NOT to put something in Require, but rather in Supported.
...which is a good reason to say that the UAC should not use Require: 199. But, we still need to say what it means IF it does so, and I think that was what Robert was thinking about. >IMHO the draft should say a UAC MUST NOT put the option tag in the Require header. If there's some reason some UAC has >to do it, they'll ignore the MUST NOT anyway. But they should think long and hard before making that mistake, and >someone who buys their product should be able to complain to them that they don't comply with the RFC. I don't like must-nots if it doesn't break the protocol. But, I agree we should strongly recommend against it. >I'm almost tempted to say we shouldn't even have an option-tag at all (the Supported lists are getting quite big), but >I'm guessing we'll have interop issues without it because some UAC's will barf on receiving a 199, so the UAS needs to >know if it can send it. :( Yes. And, the solution to long Supported lists is not to stop defining option tags, at least when there are good reasons to define them. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
