Both. How is this degenerate? How is it any different from a watcher updating two subscribers about presence?
On 10/16/07 2:03 AM, "Christer Holmberg" <[EMAIL PROTECTED]> wrote: > > > Hi, > >> No. For subscribe/notify interaction, it is trivial: whomever issues > the subscribe gets the notify. Easy for the stack to figure out. For > INFO >> interaction, everything goes to call control. That works if your model > is pure softswitch/feature server, but not many folks are doing that > anymore. > > Assume two applications are interested of the same event, so they both > subscribe to it. Now, how does the SENDER know to which subscription to > use for a specific application? > > Regards, > > Christer > > > > > > > Hi, > > As I have said before: you have similar problems with > other mechanisms. > > Regards, > > Christer > >> -----Original Message----- >> From: Eric Burger [mailto:[EMAIL PROTECTED] >> Sent: 12. lokakuuta 2007 12:45 >> To: Christer Holmberg >> Cc: [email protected] >> Subject: Re: [Sip] INFO >> >> Routing of the message once it gets to the device >> (application), not route to the device (transport). >> >> -- >> Sent from my wireless e-mail device. Sorry if terse. > We all >> need lemonade: see >> <http://www.standardstrack.com/ietf/lemonade> > <http://www.standardstrack.com/ietf/lemonade> for what lemonade is. >> >> ----- Original Message ----- >> From: Christer Holmberg > <[EMAIL PROTECTED]> >> To: Eric Burger; Hadriel Kaplan > <[EMAIL PROTECTED]> >> Cc: sip <[email protected]> >> Sent: Thu Oct 11 19:38:06 2007 >> Subject: RE: [Sip] INFO >> >> >> Hi Eric, >> >> I am not sure I understand what you mean, but INFOs > are >> routed according to the route set of the invite dialog > they >> are sent within. >> >> If you want to transport information using some other > path >> you can of course not send the information within the > invite dialog. >> >> Regards, >> >> Christer >> >> >>> -----Original Message----- >>> From: Eric Burger [mailto:[EMAIL PROTECTED] >>> Sent: 12. lokakuuta 2007 0:35 >>> To: Christer Holmberg; Hadriel Kaplan >>> Cc: sip >>> Subject: Re: [Sip] INFO >>> >>> 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. >>> >> >> 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. >> > > > > > > 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. > > 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
