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> 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. > _______________________________________________ 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
