Exactly. Or almost any Enteprise scenario.
> -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: Friday, September 07, 2007 13:22 > To: 'Eric Burger'; Audet, Francois (SC100:3055) > Cc: 'sip' > Subject: RE: [Sip] INFO > > But there are cases where the KPML model is vastly greater overhead. > > Consider a typical voicemail server. For calls to the > voicemail server to retrieve messages, KPML is probably good > because you can define a digit map for the mailbox number and > password which would reduce overall message counts. But for > calls to leave a voicemail (which I assume greatly outnumber > those to retrieve them, but you would know more about that > than I), KPML has to create a subscription for every single > call, just in case the caller happens to press some optional > dtmf that the voicemail app supports. For each and every > call, a subscription has to be routed and its state saved by > stateful proxies along the path to the UAs, even though only > a small fraction of the calls ever press a DTMF button. > > But of course that voicemail server could just do 2833/4733 > instead, if the UA's supported it. So then consider a SIP to > PSTN or H.323 gateway. The PSTN or H.323 gateway has no > knowledge that one call needs DTMF vs. another > - it has to send and receive them for all calls. It could > use 2833/4733, but very few H.323 devices support 2833, and > for whatever reason some PSTN gateways don't either. > (MGCP-controlled ones I think) So the gateway or its > controller would have to KPML-subscribe for every single call > from SIP to the PSTN or H.323 side, with no real digit map > possible. The amount of dialog state and messaging for DTMF > would actually get somewhere near that required for the > actual call signaling, and yet only a fraction of the calls > would ever send a single DTMF tone! > > And that's the basic issue. For applications where the > probability of DTMF actually being sent is very high, and for > which digit mapping can save messages, KPML makes sense (if > everyone supported it). But those are the kind of > applications where the extra cost of additional messaging > caused by INFO is actually warranted - you have an app that > needs a lot of messaging, then you pay the price for it. But > conversely for other apps, ones which don't need much dtmf, > expecting them to pay the overhead penalty for a KPML model > makes no sense. > > -hadriel > > > -----Original Message----- > > From: Eric Burger [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 05, 2007 1:17 AM > > To: Francois Audet > > Cc: sip > > Subject: Re: [Sip] INFO > > > > I would offer this is "apples-to-apples": > > > > If INFO is buffering digits, you have to tell it to, e.g., > register a > > digit map. In that case, INFO loses a packet round-trip, > KPML is all > > of one extra round trip. Small price to pay for interoperability. > > > > If one uses the pattern <regex>.</regex>, then KPML is all of two > > extra round trips. I agree, that could be "bad" if you have a VERY > > large volume of instances where one is polling for a single digit. > > However, if you do not have a large volume of instances of a single > > digit, the overhead is insignificant. On the contrary, if you have > > any decent number of digits being collected one-by-one, > then I would > > offer the two subscription round-trips get swamped by the number of > > digit reports, and the fact a KPML digit report is 7% > larger than the > > most ideal INFO message (which, by the way, I don't think > anyone has > > implemented), that is noise, as well. > > > > > > On 9/4/07 5:30 PM, "Francois Audet" <[EMAIL PROTECTED]> wrote: > > > > > 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 > > >> > > > > > > > > > > > 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
