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
