Re: INFO Framework - one pakage per INFO

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