Re: INFO Framework - one pakage per INFO

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