Re: [Sip] INFO Framework - one pakage per INFO

["DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>]

See below 

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip