Re: INFO Framework - one pakage per INFO

The gist is...

If one is building request-response type applications, first and  
foremost, why use INFO?  Using INFO says one needs the proxies in the  
path of the messaging.  Sounds like one really needs a rendezvous  
protocol, like SIP, and establish one's own path, e.g., like MSRP.

If one insists on using INFO, one clearly does not care about message  
size, bandwidth utilization, or network element burden. Since 80% of  
the uses of INFO will be for the simple stuff, and the other 20% will  
most likely be over yellow cables (e.g., a media server connected to  
an application server in the same rack), the "extra message" is a tiny  
price to pay to not screw oneself in the future.

On Nov 30, 2008, at 7:30 PM, Anders Kristensen wrote:
> Eric Burger wrote:
>>
[snip]
>> you have a package that is really using INFO for tunneling, then it  
>> is most likely already doing some sort of multiplexing, which means  
>> you already need some way of identifying what the messages are for  
>> and about.
>> PROBLEM 3: Another winner! If you care at all about performance,  
>> you would NEVER use INFO!!!!  Come on guys - let's look at DTMF:  
>> one to sixteen bytes of payload, two thousand bytes of SIP overhead.
>
> I don't think I buy that. If something can be accomplished with one  
> INFO request people are going to wonder why they have to have two.
>
>> Of course, the problems listed below are sort of hyper- 
>> theoretical.  If a UAC cannot get a message as simple as DTMF  
>> right, getting an error message from the UAS saying the UAC got it  
>> wrong is not going to help.  I'll bet my next $100 dollars that a  
>> UAC that needs hints inside of a package to get something as easy  
>> as DTMF right will core dump when it gets an error.
>
> Obviously, DTMF is not the problem. If you're only targeting  
> applications as simple as DTMF then there's no problem. I think we  
> have to expect it'll be used for all sorts of things, though,  
> including request-response type apps.
[snip]

_______________________________________________
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