Right: "DTMF may not be the only information users want to send to each other during a session." This is why one MUST establish multiple subscription dialogs. How else would one keep track of the different elements / local routing decisions? If you are proposing application routing a'la P-Asserted-Service...
On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" <[EMAIL PROTECTED]> wrote: > > > 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 >> > 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
