[asterisk-dev] PJSIP CLI and AMI organization thoughts
Kevin Harwell
kharwell at digium.com
Mon Dec 9 09:49:55 CST 2013
On Sat, 2013-12-07 at 09:20 -0700, George Joseph wrote:
>
<snip>
> It would be nice if endpoint stored all its object relationships the
> same way but it doesn't. It stores its related aors as a comma
> separated string, its auths in 2 different auth arrays, channels you
> have to get through a snapshot, etc. Endpoint formatter code is going
> to have to be modified anyway because presumably if someone added a
> new module then endpoint would need to be modified to store the
> relationship. In the case of a reverse relationship like identify,
> it's 2 lines of code in endpoint formatter. One to look up the
> identify formatter and another to call ast_sip_for_each_identify.
>
auths, aors, and transports can also register with the endpoint
formatting object so it shouldn't need to be modified. Also, if it did
need to change for those particular cases I would be okay with since
those are part of the res_pjsip api.
The problem is identify (or some future module) is not part of the core
res_pjsip api and is a loadable module. The api should not have to
change for a loadable module.
> What concerns me about lists is that they have to be traversed and
> tested for every call. It's flexible but it has overhead especially
> for high volume requests like the AMI. The hashtable does require some
> developer foreknowledge but I think the speed tradeoff is worth it.
>
I am not sure there would be a huge gain in performance as you still
have to do the hash calculation and then a NULL check. Even so,
unfortunately, I can't see away around this.
>
>
More information about the asterisk-dev
mailing list