[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