Inline Keith
> -----Original Message----- > From: Anders Kristensen [mailto:[EMAIL PROTECTED] > Sent: Monday, December 01, 2008 8:32 PM > To: DRAGE, Keith (Keith) > Cc: Eric Burger; SIP List > Subject: Re: [Sip] INFO Framework - one pakage per INFO > > inline > > DRAGE, Keith (Keith) wrote: > > See below > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of > >> Anders Kristensen > >> Sent: Sunday, November 30, 2008 9:44 PM > >> To: Eric Burger > >> Cc: SIP List > >> Subject: Re: [Sip] INFO Framework - one pakage per INFO > >> > >> Eric, > >> > >> I understand what you're saying but as I said I think it's > >> problematic or at least warrants some discussion in terms > of where it > >> leads. My worry is that it makes it significantly more tedious to > >> build on the info-events work and hence invites people to either > >> ignore the whole thing or the parts with which they disagree. > >> > >> So let's take the ubiquitous DTMF example. Someone defines a DTMF > >> info event package and they want the recipient of DTMF > events to be > >> able to indicate to the sender that a particular event > could not be > >> decoded. If I understand you correctly, the error indication would > >> have to be carried in an INFO going in the opposite > direction of the > >> DTMF itself. > >> > >> PROBLEM 1: If errors are to be returned this way it means > that both > >> parties must signal both "Send-Info: dtmf" and > >> "Recv-Info: dtmf". Hence there's no distinction between > the sender of > >> DTMF events and the sender of responses to DTMF events. Unless the > >> dtmf package is modeled as two separate INFO event packages. > >> > > The answer is, yes if that is what the application demands. > > > > I would note that on the analogue network DTMF is > unacknowledged. The > > only way I know that my digits have been sucessfully > received is when > > call control advances a state. I don't know it has missed a digit > > until the wrong person answers the call, or I get number > unobtainable. > > I have to go to MFC to get any form of acknowledged tone > signalling, > > and as yet I have not seen INFOs carrying R2 signalling packages. > > > > So in this case, a SIP state change could well be an implicit > > acknowledgement generated by the application, but that is not one > > implied by any response to the INFO request. > > The implementations of DTMF-over-INFO I'm familiar with will > respond with 4xx error codes to malformed payload. My guess > is that's extremely common. This is arguably a layer > violation but, I think, a fairly benign one. Depends what you mean by a malformed payload. If it is the syntax of the body itself, I would argue that it is reusing a lower layer mechanism because it just happens to do the right thing, rather than something that is correct from a layering point of view. > > Either we allow error responses in such cases or else we say > just don't return an error (which I think rather limits the > scope of this work) or else we say the error indication needs > to be sent in an INFO in the opposite direction. OR we allow > INFO responses to carry an app-level response in the payload. > INFO must carry a response. > > > >> PROBLEM 2: In some cases (most likely more often than not) > it will be > >> necessary to correlate responses to requests. In your model this > >> correlation has to be done at the app level, that is, in the INFO > >> payload. However, that will make it difficult to use > existing formats > >> that don't have a convenient place to put such an ID. My > employer's > >> INFO DTMF payload doesn't have a place to put it. Another > frequently > >> used example is the exchange of JPG images for whatever purpose. > >> Again, no place to put an app level ID in the INFO > payload. You could > >> put it in the INFO header put that would be a layer > violation, right? > >> > > Correct. And I see even more problems if you try and do it > at the SIP > > level. > > Do you see any problems in carrying an app-level payload in > 200 responses to INFO? > Yes. Because distinguishing real application responses from application functions that themselves require a response is almost impossible. So you end up putting payload in a 200 (OK) response to info for which you now need to generate an application level response. What next? Well you need to use an INFO to reject it. Which leads one directly to say that application level responses should go in an INFO in the first place. > > > >> PROBLEM 3: If all events require a response you end up > with twice as > >> many INFO transactions as is really necessary. > >> That's difficult to swallow without a really good reason. We could > >> allow 200 respones to INFO to carry INFO package responses with no > >> adverse affects to layering so that's not it. > > > > Well as I said before, not all info packages require a > direct response. > > > > No but those that do will IMHO not be served well by the info > framework as it stands. > > Anders > _______________________________________________ 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
