On Dec 1, 2008, at 3:31 PM, Anders Kristensen wrote:
inline DRAGE, Keith (Keith) wrote:See below-----Original Message-----From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders KristensenSent: 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 whencall 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 yetI 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.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.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?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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
