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

[Eric Burger]

PROBLEM 1: If you want to receive package Foo, and Foo has asymmetric information going the other way, then you want to send Foo-Response. Like you say, Foo is not the same as Foo-Response. Look at KPML as an example of how to do this right.

I feel as if I am swimming upstream with a school of Red Herrings ;-)


On Nov 30, 2008, at 4:44 PM, Anders Kristensen wrote:

PROBLEM 2: You've got it in one! The correlation MUST be at the application layer. If you have a package that has asymmetric information flows, then you have two choices. The first is that you are using a dialog-related application-to-application messaging protocol (INFO) because you want to send messages related to *this* dialog. Any response belongs to the request. Fairly straight forward. Otherwise, if you have a package that is really using INFO for tunneling, then it is most likely already doing some sort of multiplexing, which means you already need some way of identifying what the messages are for and about. PROBLEM 3: Another winner! If you care at all about performance, you would NEVER use INFO!!!! Come on guys - let's look at DTMF: one to sixteen bytes of payload, two thousand bytes of SIP overhead. Of course, the problems listed below are sort of hyper-theoretical. If a UAC cannot get a message as simple as DTMF right, getting an error message from the UAS saying the UAC got it wrong is not going to help. I'll bet my next $100 dollars that a UAC that needs hints inside of a package to get something as easy as DTMF right will core dump when it gets an error.

Eric,











Thanks,
Anders

Eric Burger wrote:

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.

Let us try again.
INFO is a method that *transports* Application-Level "messages".
INFO is NOT a method of Application-Level messaging.

On Nov 29, 2008, at 2:03 AM, Anders Kristensen wrote:

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 :-)

Hadriel Kaplan wrote:

-----Original Message-----
From: Anders Kristensen [mailto:[EMAIL PROTECTED]
Sent: Friday, November 28, 2008 9:44 PM


with the implications of this model. If errors occurring at higher

In any event (no pun intended) I don't think the draft adequately deals 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.

I'll be applying the flame retardant now...

Anders

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.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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