RFC 4733 requires a media path to the application. As a former Media Server vendor, I think that is a great idea. However, as a current Application Server vendor, I am not looking to raise the cost of deployment.
-----Original Message----- From: Jackson, James [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 4:54 PM To: Hadriel Kaplan; Eric Burger; Francois Audet Cc: sip Subject: RE: [Sip] INFO For the majority of call flows, I would expect RFC2833/4733 to be sufficient, especially for applications like voicemail. However, it is insufficient when you get into more complex scenarios like attended call transfers where the media is ideally released but the App must still process DTMF (ex. transferee hits key to disconnect transfer target and return to menu). It seems that the best solution would be to use RFC2833 and only subscribe to KPML as needed. James -----Original Message----- From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 3: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 _______________________________________________ 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
