On Dec 2, 2008, at 3:27 PM, Paul Kyzivat wrote:
Dean Willis wrote:
DRAGE, Keith (Keith) wrote:
INFO must carry a response.
Putting application-level data into an INFO response is problematic
as
this may make the INFO body larger than the transport package size,
and
we have no way to reject large responses.
This is exactly why we stalemated on diagnostic responses.
Given the characteristics of SIP-as-transport, the only reasonable
thing
to do (beside change SIP) is to require all application-layer
responses
use SIP requests in the return direction onstead of piggybacking on
the
SIP response. The SIP response can, in general, tells us only about
the
handling of the request's delivery at a SIP level, not an
application level.
Then I guess we had better stop passing SDP in responses.
Why is it that responses can have a body???
We got lucky with SDP, in that early versions of SDP combined with the
cruft in early versions of SIP actually fit into one UDP packet. One
of the probable issues with SDP-NG is that it might well not enjoy
that characteristic, and as we add countless options, secondary
bodies, and other cruft to SIP we're in danger of crossing the line.
Will UDP work for INFO responses? I dunno. Maybe, if we're lucky.
Do you feel lucky?
SIP's UDP request-response paradigm was at best excessively narrow in
applicability and at worst ill-conceived. We'd have a lot fewer
headaches if we had "offer" requests and "answer" requests at the
application layer, and a clear demarc between that application layer
and SIP's message-transport/rendezvous functions. Or if we'd just used
TCP for everything to start with.
Of course, one might subscribe to the philosophy that since we've so
hopelessly muddled the application and the transport in existing SIP
that we might as well do so for revised-INFO so that we're at least
consist in our mistakes. I find that to be a sensible but depressing
argument.
--
Dean
_______________________________________________
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
