Well, that's because you use the worst-case for INFO, and the best case for KPML. Namely:
- Your example uses 1 message per digit for INFO. There is nothing that prevents you from sending *69 in one INFO message. - Your example also uses the pattern mapping feature of KPML to "optimize" the number of message. My best guess is that in common deployment, what people are likely to use is: - INFO with 1 digit per message (as per your example) - KPML with reporting of every digit pressed (unlike your example) So in this case INFO actually wins in all cases. Now, don't get me wrong: I'm not advocating the use of INFO for digit mapping. I just think this analysis is more theoretical than real. And I'm quite unconvinced that digit pressing is a big factor in "computing power requirement" for the servers providing those services. In short, I don't think "efficiency" is the main factor here. > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 04, 2007 13:23 > To: Hadriel Kaplan > Cc: sip > Subject: Re: [Sip] INFO > > I have not checked, but I think IEEE journal papers run about > US $5. You can get a monthly subscription that makes the > rate way lower. Your company probably has a corporate > subscription, or someone there most likely has an IEEE > Digital Library subscription, so again, the papers should be paid for. > > Since the IEEE has a serious self-plagiarism policy, here is > a *different* way for seeing how KPML wins. > > The vast bulk of a SIP message in a non-trivial network > (i.e., with one or more proxies) is the routing information > (URI's, Via's, Route's, etc.). > Sure, a Zebarth INFO (the absolute smallest encoding for a > DTMF digit) of 2 bytes is much smaller than a KPML NOTIFY, > which can easily be 70 bytes. > However, when you have 1000 bytes of headers, 1002 and 1070 > are pretty much the same. > > Given that, let us look at the counts. > > KPML: > SUBSCRIBE (SIP Message) > Immediate NOTIFY (SIP Message) > Digit NOTIFY's... > > DTMF: > Digit INFO's... > > What does this mean? It means that if you are on a shared > media network (wireless or 5BaseT), where each direction > counts, we have: > > DTMF KPML > # digits # packets # packets > 1 1 3 > 2 2 3 > 3 3 3 Common Star Codes (e.g., *69) > 4 4 3 Common PINs > 5 5 3 > 6 6 3 Also common PINs > 7 7 3 > 8 8 3 > 9 9 3 > 10 10 3 Common Supplementary > Phone Number > 11 11 3 Common Supplementary > Phone Number > > One can quibble as to whether the cross over is at 3 or 4 > digits, since KPML packets are slightly larger than INFO > packets. However, at 3 digits the argument goes in favor of > a mechanism with negotiation, content security, dialog > security, works for HERFP, etc., etc. > > At 4 digits, KPML unquestionably uses less bandwidth. > > Of course, the numbers are even better for KPML on non-shared > media networks. > > > On 8/31/07 1:41 AM, "Hadriel Kaplan" <[EMAIL PROTECTED]> wrote: > > > Hey Eric, > > I read the draft and was especially interested in the claim > that KPML > > consumed less bandwidth than INFO for DTMF. You cite an > IEEE paper, > > but I don't think that's freely available. Can you > summarize how you > > came to such a conclusion? When I do the numbers, KPML > often loses... > > in some scenarios by a LOT. And it's not even just the extra > > bandwidth/messages, but also the state and processing horsepower. > > There is one scenario where KPML wins, for some SIP boxes > but not others. > > Although that could all be because I either don't correctly > understand > > the actual way KPML would be used, or because the use cases I am > > concerned with are not the same as those in your paper's analysis. > > > > -hadriel > > > > > >> -----Original Message----- > >> From: Eric Burger [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, August 21, 2007 5:37 PM > >> To: 'sip' > >> Subject: [Sip] INFO > >> > >> Since list traffic is down, how about something to spice things up? > >> > >> > >> Any thoughts on > >> > >> http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt > >> > >> ??? > >> > >> If you like it, say so. If you hate it, say so. > >> > >> Text welcome. > >> > >> > >> Notice: This email message, together with any attachments, may > >> contain information of BEA Systems, Inc., its > subsidiaries and > >> affiliated entities, that may be confidential, proprietary, > >> copyrighted and/or legally privileged, and is intended solely for > >> the use of the individual or entity named in this message. > If you are > >> not the intended recipient, and have received this message > in error, > >> please immediately return this by email and then delete it. > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.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 > > > > > > > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.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 > _______________________________________________ Sip mailing list https://www1.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
