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
