Re: INFO Framework - one pakage per INFO
Hadriel Kaplan <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <E6C2E8958BA59A4FB960963D475F7AC3137A7E2E7A@mail> |
> -----Original Message----- > From: [email protected] [mailto:[email protected]] 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 [email protected] for questions on current sip Use [email protected] for new developments on the application of sip