Ding, ding, ding!!! KPML is NOT for IVR. INFO and KMPL lose terribly to VoiceXML (or MSCML or MSML).
However, if you really want to recreate the PSTN... Consider a PSTN call. The call goes from the gateway to softswitch / Proxy. Proxy routes to VM App Server. INFO has to pass through softswitch / Proxy. In KPML-land, VM App Server *directly* subscribes to UAC key press state, bypassing the softswitch. KPML and INFO have the same number of messages for a SINGLE digit; KPML wins hands-down for multiple digits or reports. More importantly, let's take a Call Management (CM) application that calls a VM application when they cannot find the subscriber. INFO has to pass through the softswitch / Proxy to the CM application. Cool - it is a proxy, so it knows to relay. But OOPS! The CM application has to proxy the INFOs to the VM application. Yes - you could be a good programmer and remember to do that EVERYWHERE you place an outbound call, but it is really easy to get wrong. In KPML-land, the VM application server not only *directly* subscribes to the UAC key press state, but it will NOT get the key presses (like the ubiquitous long-#) that are for the CM application. Likewise, the CM application, which is ONLY looking for long-#, won't get all of the VM key presses. That scenario is where KPML really kicks-butt. By the way, I am deliberately using the provocative "softswitch" term :-) -----Original Message----- From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 4:22 PM To: Eric Burger; 'Francois Audet' 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 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
