Re: INFO Framework - one pakage per INFO

I don't follow. The 200 is sent reliably. Why would it get dropped and 
by whom?

Eric Burger wrote:
> The problem with transporting application-level responses in the 200 OK 
> is what happens when the 200 OK gets dropped on the floor?
> 
> 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 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.
>>
>> 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
> 
_______________________________________________
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