[asterisk-dev] ast_sip_session

[Kelvin Chua]

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 <kelchy at gmail.com> 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 <mjordan at digium.com>
> wrote:
>
>>
>>
>> On Tue, Nov 15, 2016 at 6:17 AM, Joshua Colp <jcolp at digium.com> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161116/883e6b54/attachment.html>