Forgot to clarify, I am also trying to pass some headers on response, i.e 180, 183
Kelvin Chua On Wed, Nov 16, 2016 at 12:22 PM, Kelvin Chua <[email protected]> wrote: > thanks for the insights, i'm doing this as a proof of concept. > i relaized there are a lot of things which is a blocker by design. > what i initially tried is to get the bridged channel (of course this could > pose a problem when in multiples) > ast_channel_bridge_peer(session->channel) > then found out that this won't work because during this state, it's not > yet bridged. > looks like there is no way to get the ast_channel of the downstream while > call is not yet established, or is there? > > on earlier versions, there is struct ast_channel *dialed and struct > ast_channel *dialing for this right? > > On Wed, Nov 16, 2016 at 1:40 AM, Matthew Jordan <[email protected]> > wrote: > >> >> >> On Tue, Nov 15, 2016 at 6:17 AM, Joshua Colp <[email protected]> wrote: >> >>> On Mon, Nov 14, 2016, at 03:46 AM, Kelvin Chua wrote: >>> > playing around chan_pjsip/res_pjsip >>> > >>> > i have some data i want to pass from upstream to downstream on reponse >>> > for >>> > example, P-Associated-URI >>> > >>> > i figured that datastore on ast_sip_session only handles either the >>> > upstream channel or the downstream channel. I can already parse the >>> > header >>> > on upstream but stuck on how to write >>> > this to the reply downstream. any pointers? >>> >>> There is no generic mechanism for doing this currently: specifically >>> passing data back on a response or answer. The closest thing would be to >>> add a new frame type (frame.h) to Asterisk, put data on it (in an >>> ast_frame), propagate it through, and have it read/handled on the other >>> side. If you end up with specific questions you can respond back with >>> them, but you are sort of venturing into uncharted territory unless >>> someone else has an idea on how to better do it. >>> >>> >> I'd throw out there as well that this _may_ not be worth doing, >> particularly automatically. As a B2BUA, you're always going to be fighting >> against Asterisk's model of channels and bridges if you want to >> automatically propagate information from an inbound channel to an outbound >> channel. >> >> Things you have to think through: >> (1) What happens when there are Local channels? >> (2) What happens if there are multiple outbound channels (parallel dial)? >> (3) What happens if I'm in a bridge with multiple channels (conference)? >> (4) If the information can be provided in a re-INVITE, what occurs if I >> pass this information along before or after an answer? >> >> One of the safer ways of handling the notion of passing things from an >> inbound to an outbound channel is to have the dialplan do it. You can use >> functions like PJSIP_HEADER to read values off of an inbound channel, store >> them in a channel variable with inheritance, then use a pre-dial handler >> with PJSIP_HEADER (or CHANNEL, etc.) to modify the outbound channel(s) >> prior to dialing. Doing that gives you more control over exactly _when_ you >> pass information along, and helps you avoid the many, many edge cases that >> can occur. >> >> -- >> Matthew Jordan >> Digium, Inc. | CTO >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> Check us out at: http://digium.com & http://asterisk.org >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-dev >> > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
