On Tue, Nov 15, 2022 at 7:12 PM <aster...@phreaknet.org> wrote:

> On 11/15/2022 9:56 AM, Joshua C. Colp wrote:
> > On Tue, Nov 15, 2022 at 10:50 AM <aster...@phreaknet.org
> > <mailto:aster...@phreaknet.org>> wrote:
> >
> >
> >     If res_pjsip_pubsub would need to be extended to support this,
> >     would it
> >     reasonable to add a callback to a pubsub module that allows it
> >     access to
> >     the pjsip_tx_data, so it can do whatever it needs to with it,
> >     before the
> >     response gets sent? Or another preferred method of allowing
> >     modules to
> >     add headers?
> >
> >
> > At a surface it is probably fine.
> Thanks, doing that allowed just what I needed to do.
> Next limitation... the new_subscribe callback is supposed to return 200
> (or some other code) to accept or reject the subscription. The only
> arguments are the endpoint name and resource name.
> This is not really always sufficient; it may be necessary to approve or
> reject the subscription using some information present in the
> subscription itself (for example, a header). I think this is all
> consequent of the very narrow range of scenarios that res_pjsip_pubsub
> was written for originally.
> The subscription_established callback is actually perfectly set up for
> this. We have a handle on the ast_sip_subscription, and can call
> ast_sip_subscription_get_header if needed to get the header.
> However, this requires approving all subscriptions with a 200 in the
> new_subscribe callback, only to potentially realize it should be
> rejected in the subscription_established callback. This is too late
> because the 200 OK already gets sent to the endpoint before
> subscription_established gets called.
> So, the only good solution is to extend new_subscribe to accept a third
> argument: rdata, since a subscription hasn't yet been created at that
> point so we could not use ast_sip_subscription_get_header to fetch
> headers. Yuck, since it's a public API... there could also be a
> new_subscribe_with_rdata callback that gets executed instead if a module
> defines one. Or maybe we can break ABI and go master only here if that
> would be too inelegant.

Even adding a new callback will break the ABI. I think fundamentally this
work should only occur in master where changing ABI is fine. I have
concerns that it will cause unintended consequences in some way and I've
had enough of those in the past year in release branches.

Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to