Serdar51 left a comment (kamailio/kamailio#4537)
Firstly, thanks for the reviews.
> I don't see that we have used "peer" anywhere in Kamailio before. aorstate
> would be more in line with the docs of USRLOC, or even userstate.
Actually, I initially considered the terms `aor` and `user`, but wanted to use
a more generic concept. These terms, however, are primarily associated with
`usrloc`.
```
modparam("peerstate", "use_avps", 1)
modparam("peerstate", "caller_avp", "$avp(caller_xxx)")
modparam("peerstate", "callee_avp", "$avp(callee_xxx)")
$avp(caller_xxx) = $_s($fU@$fd);
$avp(callee_xxx) = $_s($rU@$rd);
```
This approach enables tracking and modifying state for multiple custom `peers`
on both caller and callee sides at the `dialog` level, even for non-local
entities.
> * Why does this module implement its own hash table? Using the htable module
> would enable replication and much more. There may be good reasons, but I
> would like to see them :-) Having this module without being able to run
> multiple servers will be a problem.
I considered using the `htable` api, but I would have needed to structure the
data to be stored for peer as json etc. I thought this could create extra load
for update and build processes. I wanted to provide peer access with O(1)
complexity this way.
Finally, while the content differs, using "realtime peer state" as a title
could cause confusion with Asterisk's realtime concept. Can be changed, it's
not a must-have. As @miconda mentioned, what's realtime is the "state of peer",
not the "peer" itself.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4537#issuecomment-3718978900
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4537/[email protected]>_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
