Hi Vivek, It's perfectly alright for the B2BUA to use this mechanism as well. As it seems you already know it, for a B2BUA, a call are two different call legs.. so it can treat individual leg with its own preferences/configuration. Depending on the methods supported, codec negotiation , etc by either legs of the call with the B2BUA, anything's possible.
- Ben. --- On Wed, 10/15/08, Vivek Batra <[EMAIL PROTECTED]> wrote: > From: Vivek Batra <[EMAIL PROTECTED]> > Subject: [Sip-implementors] Implementation of INFO in B2BUA > To: [email protected] > Date: Wednesday, October 15, 2008, 4:17 AM > Hi Folks, > > I have a doubt regarding implementation of INFO in B2BUA. > > INFO is used to transport DTMF digit however other > information (wireless > signal strength etc) can also be carried over INFO. > > > > In B2BUA, if INFO (with DTMF) is received on first call > leg, I need to block > the INFO and generate the DTMF in Inband/ RFC2833 on other > call leg (since > SIP client on other call leg might not support INFO OR > RFC2833/ Inband is > programmed in local configuration of B2BUA for other call > leg). > > > > Is it true implementation in B2BUA to block INFO on first > call leg and > generate the DTMF in other type if SIP client on other call > leg does not > support INFO? > > > > I was afraid by blocking the INFO since it can also be used > to transport > other information. > > > > Best Regards, > > Vivek Batra > > > > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
