Hi, Let's also keep in mind that DTMF may not be the only information users want to send to each other during a session. So, you will need to establish subscription dialogs for every type of event that the users may want to send during the session...
Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 11. syyskuuta 2007 12:27 > To: Hadriel Kaplan; Eric Burger > Cc: sip > Subject: RE: [Sip] INFO > > > Hi, > > >>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. > > [Christer] As I've said before, there are environments where some > proxies must (for whatever reason) be passed through. I guess an > outbound proxy is a good example. > > >>KPML and INFO have the same number of messages for a SINGLE digit; > KPML wins > >>hands-down for multiple digits or reports. > > > >Not exactly - for a single digit, KPML would generate a > >Subscribe/200/Notify/200 before the single DTMF was even > >pressed - before the actual Notify with the digits in it. > >And of course there is now also a subscribe dialog involved. > >Assuming a one-shot single digit type, then, we're talking 6 > >SIP messages for KPML vs. 2 for Info. > > [Christer] And, in cases where you need to send DTMFs (or whatever > information) in both directions you actually need 2 > subscription dialogs > - one in each direction, and maintaining dialog state also consumes > resources. And, in some cases you may not even know whether you will > ever have to use the dialog. > > > >>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. > > > >I'm not sure I understand the scenario. The VM learned about > >this call how? > >By being in the signaling path, no? So why wouldn't the CM > >forward INFO along the path? (I mean it is in the same > >dialog, after all) Now I don't doubt it could screw that up, > >and eat the info thinking it was for itself, but lots of > >things can get screwed up - my guess is KPML will not be > >impervious to screw ups. > > [Christer] I also have problems understanding the scenario. INFO is > routed to wherever the INVITE that initiated the dialog was routed... > > Regards, > > Christer > > > _______________________________________________ > 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
