Inline... > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Friday, September 07, 2007 5:00 PM > > 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.
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. > 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. > 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. The VM will probably NOT *directly* subscribe to the UAC. It will need to go through the UAC's outbound proxy. And if the VM is outside the UAC's enterprise or service provider domain, my guess is the VM will need to go through some other boxes too. A stand-alone UAC has virtually no way to verify the identity of a subscribing VM, so I hope they don't just accept direct subscriptions. Also, this only works if the UAC supports multiple KPML subscribes, right? Which were only optional in the spec, no? > By the way, I am deliberately using the provocative "softswitch" term > :-) Well, I'm not sure how the "softswitch" term makes a difference - I would think a "softswitch" would need to be in the path for all signaling, and will not be bypassed even by KPML. But then "softswitch" is an ambiguous term. :) -hadriel _______________________________________________ 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
