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