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. > 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. > 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. _______________________________________________ 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
