> -----Original Message----- > From: Anders Kristensen [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 30, 2008 7:30 PM > > Hadriel Kaplan wrote: > > But we can't _require_ a fully-layered model. In other words, all > packages have to gracefully handle failure responses to their INFO request > which were caused by processing failure. And if a package really cares > about processing failure, then it could also define a way to indicate it > in a subsequent separate INFO transaction. > > Either it's legal or it isn't. It's no good saying it's not legal but do > what you gotta do. Are you saying the info-events draft should allow UAs > to return INFO level errors in response to app-level problems?
The info-events draft has no choice but to allow an INFO request to fail with a failure response code. ISTM every SIP request type that can succeed can also fail with a failure response code. I don't think we need a *new* response code. One could use 415 or 400, or Paul suggested 488. I would do whatever Subscribe/Notify/Message does in such cases. And to be clear, I don't think ANY of this needs to be in the base draft. If someone wants to define a package that has a body which can contain error information, and sends that in an INFO request after getting an INFO request it can't process, why should we say a package can't do that? And I don't mean that in the sense of "let's be flexible" - I mean it's actually illogical to constrain what a package puts in its INFO message or why, at layer above SIP. I don't even know how to word such language. "You MUST NOT define a package which contains error information about your application"? And I don't think we can reasonably mandate that the original INFO request only be responded to with 200 ok if the entire application processed it successfully. For example, let's say INFO-DTMF actually cared about an error condition. (I don't think it does, but just for argument's sake) You couldn't mandate it send that error in the response to the INFO, because there are cases where that would be impossible. For example, a SIP-H.323 gateway would get the INFO and convert it to H.245-UII. If we mandate sending back the error for the INFO, it would require waiting for the H.245 message to be successfully received on the H.323 side before sending back any response to the INFO, which can be quite long. Not only would you get a bunch of retransmissions (if over UDP), but it may exceed the overall transaction timer itself. I think that's why Subscribe had to send a Notify after subscription, as well. The processing time for something at a layer above SIP is just not controllable at a SIP transaction layer. But even given that - it can't stop a INFO-DTMF receiver from sending back a 4xx. The real question is whether it would be allowed to send back application-layer information such as bodies in the response. And I have no clue on that. There's pro's/con's, as usual. > So a UA would look at both Send-Info, Recv-Info and Accept in order to > find out what are the info pkg capabilities of the peer? I guess that > could work. Actually I think we had consensus there would be no Send-Info defined in the draft. But anyway no I don't think I meant that. :) -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
