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

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Anders Kristensen
> Sent: Monday, December 01, 2008 10:33 PM
>
> Dean Willis wrote:
> >
> > It means that the stack can't send a 200 response to INFO until it has
> > been directed to by the application. That seems like a layering problem
> > to me, not to mention a major stack rewrite.
>
> Right, I'm sure that's a total stack rewrite. It's a wonder how people
> manage to send DTMF in INFO today. With app-generated error codes.

I don't think he means it would be a stack re-write for you (or most people using info-dtmf or that matter).  He just means that as it stands right now per the INFO RFC, one could build a SIP Stack that uses INFO in a completely layered approach.  It would interoperate with an integrated stack for info-dtmf, because DTMF as an application doesn't really care about failed remote processing, so neither side would care and they'd both interoperate.  And for info-dtmf there is no application data returned on error, afaik.

Why don't we just compromise and do what other similar methods do: let the base draft say the package decides its own needs, but that it is RECOMMENDED to handle application-level errors in a separate transaction?  This still provides interoperability, because we negotiate supported packages to begin with and if you don't want to support a direct response you don't have to support that package; and if we find packages that really need/benefit from a direct response, they can argue their case.

BTW, when we talk about application-layer error, I hope we're not talking about content errors like XML formatting errors.  Because a Firewall could process that and decide to reject malformed XML, and the Firewall will have no application-layer for the package.
Even in a "layered" approach, delivery failure due to a 400 response is still sent up to the application caller I assume?

-hadriel
_______________________________________________
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