Hadriel, I don't get your example. You would only get a KPML subscription for calls that actually terminate to the voicemail server. And I would imagine that MOST calls to a voicemail server would actually use DTMF and therefore require a subscription.
> -----Original Message----- > From: Stucker, Brian (RICH1:AR00) > Sent: Sunday, September 09, 2007 21:16 > To: Hadriel Kaplan; 'Eric Burger'; Audet, Francois (SC100:3055) > Cc: 'sip' > Subject: RE: [Sip] INFO > > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 07, 2007 3:22 PM > > 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. > > Unless your voicemail users have a severe case of > obsessive-compulsive voicemailbox checking syndrome, and the > users aren't checking their mailboxes when they have no MWI > indication, the number of deposits is guaranteed to at least > equal, and certainly exceed the number of retrievals for any > non-trivial population of subscribers. Otherwise, you'd only > need space for one voicemail in your mailbox. The fact that I > doubt anyone has ever heard of such a ridiculous voicemail > limit seems to confirm my assumptions. > > Regards, > Brian > _______________________________________________ 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
