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

[Anders Kristensen <andersk at cisco.com>]

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.

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?

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.

Thanks,
Anders

Eric Burger wrote:
> Let us try again.
>
> INFO is a method that *transports* Application-Level "messages".
>
> INFO is NOT a method of Application-Level messaging.
>
> What is the difference?  In TCP, if I send a message, "SIP/2.blah blech" 
> to port 5060, TCP will acknowledge delivery of that packet.  That is 
> like a "200 OK" in SIP.  The process monitoring port 5060, on the other 
> hand, will hopefully come back with some sort of "4xx you suck" message, 
> encapsulated over TCP, which TCP will acknowledge delivery of.
>
> It is bad enough that we are proving Oran's Law: any well-deployed 
> protocol becomes a transport protocol. Let us not make it worse and make 
> SIP look like Bluetooth with its dozens of profiles for whether you are 
> a data device, a speaker, a microphone, a headset (yes, which is 
> different than a speaker and a microphone), and so on.
>
> Let INFO be INFO: something that *transports* messages through a SIP 
> Proxy network.  Note I say "through a SIP Proxy network."  If you do not 
> want to traverse Proxies, use TCP :-)
>
>
> On Nov 29, 2008, at 2:03 AM, Anders Kristensen wrote:
>
> > Hadriel Kaplan wrote:
> > > > -----Original Message-----
> > > > From: Anders Kristensen [mailto:andersk at cisco.com]
> > > > Sent: Friday, November 28, 2008 9:44 PM
> > > >
> > > > In any event (no pun intended) I don't think the draft adequately deals
> > > > with the implications of this model. If errors occurring at higher
> > > > layers aren't reported as failure of the INFO request itself, it pretty
> > > > much follows that the 200 response to the INFO must include a payload
> > > > that carries info (sorry, pun not intended here either) on the error.
> > > No I think the logic that Eric's arguing for is "you asked for 
> > > delivery of this package, and I'm responding with 200 ok because it 
> > > was delivered".  In other words treat INFO as a delivery vehicle, 
> > > like MESSAGE, and as long as the package was delivered you send a 200 
> > > ok, with no correlation to if/when the package was opened and read 
> > > successfully or not by a higher-layer info-package "consumer".
> > > > The alternatives would be:
> > > > 1) Don't report app-level errors. Perhaps OK for simple packages.
> > > > 2) Report outcome in separate INFO requests going in the opposite
> > > > direction. Seems wasteful and requires additional app-level 
> > > > correlation.
> > > Yeah, I think Eric's argument is for (2).  If they need it, they pay 
> > > for it.
> >
> > Well, in the case of (2) I'd say they'd be overpaying. In my view it's 
> > a non-starter. People will want to be able to send app-level responses 
> > and they won't want to go through a lot of extra trouble to do it. And 
> > why should they? I'm thinking we should allow app-level errors to be 
> > signalled with INFO error codes and/or allow INFO responses to carry 
> > responses along the lines of what CSTA does.
> >
> > I'll be applying the flame retardant now...
> >
> > Anders
_______________________________________________
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