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]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
