> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 29, 2008 12:42 AM > > Hadriel Kaplan wrote: > > I just reviewed 3428, and I don't read it as saying that a 200 should be > returned of the message is *received*. It says that the the message > should be processed according to the rules of sip, and then a final > response should be returned immediately. It just says the message need > not be *rendered* immediately (or ever). > It doesn't say that you can't, or shouldn't, check the validity of the > message and return an error if it is invalid.
Oh no of course you *can* check its validity and respond negatively - the question is if you must, or if you can instead return 200 ok even if you couldn't process the content. I think it was implied in Sub/Not and Message that you could respond with 200 even if you (later) could not actually process the body content successfully. So for INFO, if we allow you to send 200 even if you can't process the body content, then the packages have to specify what to do in that case (which obviously the package can just say "ignore it, do nothing"). Take DTMF for example - would we require processing before responding? Or would we allow post-processing? If the latter, would we need to send an error indication back upstream? I think we would allow post-processing, but ignore it. And definitely allow an integrated processing model to return 4xx as well, since that can happen anyway for other reasons. -hadriel _______________________________________________ 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
