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.
INFO-DTMF is a good example of one that *won't care*. There's no real point in indicating errors back. That doesn't mean you can't send back a 4xx immediately in response to the INFO request - you can always do that - it just means we do NOT have to define a way to indicate error after that in an upstream INFO request. And BTW, any package could define different content-type or body content or whatever for both the normal use and the error indication, so it won't need separate package names for each. But anyway that's really up to the specific package to handle, not the main draft methinks. -hadriel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric > Burger > Sent: Sunday, November 30, 2008 5:28 PM > > PROBLEM 1: If you want to receive package Foo, and Foo has asymmetric > information going the other way, then you want to send Foo-Response. > Like you say, Foo is not the same as Foo-Response. Look at KPML as an > example of how to do this right. > > PROBLEM 2: You've got it in one! The correlation MUST be at the > application layer. If you have a package that has asymmetric > information flows, then you have two choices. The first is that you > are using a dialog-related application-to-application messaging > protocol (INFO) because you want to send messages related to *this* > dialog. Any response belongs to the request. Fairly straight forward. > Otherwise, if you have a package that is really using INFO for > tunneling, then it is most likely already doing some sort of > multiplexing, which means you already need some way of identifying > what the messages are for and about. > > PROBLEM 3: Another winner! If you care at all about performance, you > would NEVER use INFO!!!! Come on guys - let's look at DTMF: one to > sixteen bytes of payload, two thousand bytes of SIP overhead. > > Of course, the problems listed below are sort of hyper-theoretical. > If a UAC cannot get a message as simple as DTMF right, getting an > error message from the UAS saying the UAC got it wrong is not going to > help. I'll bet my next $100 dollars that a UAC that needs hints > inside of a package to get something as easy as DTMF right will core > dump when it gets an error. > > I feel as if I am swimming upstream with a school of Red Herrings ;-) > > _______________________________________________ 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
