On Tue, Dec 6, 2011 at 3:35 PM, Paul Kyzivat <[email protected]> wrote:
> The examples below look like some sort of conformance test, rather than > cases that would actually be encountered in practice. If so, I suppose > either you are implementing the tester and looking for what response to > expect, or else you have failed a conformance test and are looking for > an argument about why the tester is wrong. > > For the most part 3261 does not mandate behavior for non-conforming > cases. So in general for the cases you describe almost any behavior > would be ok. It then becomes a "quality of implementation" issue, not a > conformance issue. > > Also, you have two kinds of cases below: > - repetition of headers that are only permitted to occur once > (e.g. To, From, Call-ID) > - repetition of headers that can appear more than once, but in a > form that makes little sense. (E.g. Via) > > In the former case, the recipient might notice the duplication and > object to it. Or it might not notice, and just process one of the > instances of the header. Either is ok. > > In the latter case, you need to look into the details. E.g. for Via, as > long as the vias get cleaned up while routing the response, and the > response gets where it should, then all is well. > > A very good reasoning. I also think such behaviour should not occur in SIP elements, even if restriction to do so is not described anywhere in the docs. I would respond with 400 where Reason-Phrase describing first encountered failure in the request (i.e. first duplicated header). I probably wouldn't bother about duplicated Via headers much, as these have to be dealt with by the upstream elements only. But other headers mentioned, are the concern of the downstream elements, and I wouldn't allow pass this junk through because, as Paul mentioned there, depending on the implementation the receiver might, or might not, process the request. And sending request downstream with the uncertainty of it being handled is beneficial for nobody, and is irresponsible at the very least. Regards, Brez _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
