THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#134 - Gentoo ebuild/pkg
User who did this - Henning Westerholt (henningw)
----------
> Would it be complex to make a dedicated ebuild spec for a specific flavor? I'm thinking that might be
> easier not to remember all the pArameters to customize the flavors.
Gentoo users tend to like this use flags, and there is also an easy way to query the available flags of packages: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2#doc_ch…
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=134#comment219
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#134 - Gentoo ebuild/pkg
User who did this - Daniel-Constantin Mierla (miconda)
----------
There are two flavors actually, ser and kamailio. Just at some point sip-router was kind of aliased/alerts the ser flavor, adding some confusion. Perhaps the whole thing needs a bit of review and cleanup.
Is it working with the groups of modules from Makefile? Kamailio uses groups prefixed with k, like standard.
Would it be complex to make a dedicated ebuild spec for a specific flavor? I'm thinking that might be easier not to remember all the pArameters to customize the flavors.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=134#comment218
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#134 - Gentoo ebuild/pkg
User who did this - Claudio Furrer (caio)
----------
Hi Daniel,
You can package any of both flavours just by specifying it in the USE flag when emerging it. It's a whole sip-router package which you can make your preferred flavour.
For example, by doing:
$ USE="flavour_kamailio debug group_standard group_mysql avpops" emerge sip-router
(here you will build kamailio flavours (kamailio as main name for binaries) including avpops module, mysql group and modules of the standard group, with mode debug ON).
$ USE="flavour_ser debug group_standard group_mysql avpops" emerge sip-router
(same as above but with SER as main name of binaries).
If you don't specify the flavour, the main name will be "sip-router", as the Makefile.diff does modify de $MAIN_NAME variable. It used to be "ser" if not flavour were specified, but I did a Makefile.diff by myself just to fix it. Maybe it's wrong, but just for my convenience I did it that way.
Hope it helps its usage.
Regards.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=134#comment217
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#134 - Gentoo ebuild/pkg
User who did this - Daniel-Constantin Mierla (miconda)
----------
Thanks Claudio! At this momonet we package either kamailio or ser. I was looking quickly into the tarball, but since I am not really familiar with ebuild system, I am not sure if one can build the two out of these specs, or it is building one package including everything?
If cannot build ser or kamailio flavours, what it would take to make one per each flavour?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=134#comment216
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Please find attached a patch to increase the size of RLS callid and
contact database fields.
This is the RLS version of the recent presence update by Marius Zbihlei
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hello,
just to let everyone to know that starting with today Peter got
developer access to GIT repository. He sent many patches in the past
months to fix issues or add new features to presence modules (e.g., OMA
extensions to embedded XCAP server) -- some are pending to be committed
and expect more to come, as he is continuing to work with this part of
SIP server.
The user id is 'pd'.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.comhttp://linkedin.com/in/miconda -- http://twitter.com/miconda
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Claudio Furrer (caio)
Attached to Project - sip-router
Summary - Gentoo ebuild/pkg
Task Type - Improvement
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - Linux
Severity - Low
Priority - Normal
Reported Version - 3.1
Due in Version - Undecided
Due Date - Undecided
Details - Added an experimental ebuild to install sip-router 3.1.x under Gentoo Linux.
Also have this ebuild in an external overlay if you want/need to link it.
Test it and I would appreciate any feedback.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=134
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#134 - Gentoo ebuild/pkg
User who did this - Claudio Furrer (caio)
http://sip-router.org/tracker/index.php?do=details&task_id=134
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hello,
I am working with Kamailio RLS which uses PUA as a library to send
SUBSCRIBEs.
Whenever Kamailio receives an RLS subscription it calls
rls_handle_subscribe(). rls_handle_subscribe() calls the function
resource_subscriptions() which in turn calls send_resource_subs() (via
process_list_and_exec()). resource_subscriptions() and
send_resource_subs() fill in a subs_info_t structure that is passed into
the PUA module send_subscribe() function.
The key part is that send_resource_subs() sets the subs_info_t
remote_target field to the pres_uri. The PUA send_subscribe() function
uses the remote_target as the remote_contact (in the ua_pres_t
structure) that is used to lookup the dialog in the PUA hash table.
Unfortunately, this lookup always fails because the PUA module correctly
updates the remote contact in the hash table when it gets a response
back from the (Kamailio) presence server.
The effect that this has is that any re-SUBSCRIBE requests from the RLS
module are treated as new initial SUBSCRIBEs. This causes the pua and
(presence) watchers tables in my Kamailio database to grow rapidly, and
can result in multiple notifications on a presence status change.
I noticed this because I am currently adding a new API to RLS which will
allow me to update my RLS subscriptions whenever my resource list
documents change. This is needed so that subscribers receive an
immediate presence authorisation request when someone adds them to their
contact list. The client I am testing with tends to update the RLS
documents frequently (often for superficial changes) and this combined
with the PUA issue described above means with just two clients on the
system (with only each other in the contact list) I can end up with many
10s of records in pua and watchers within a few minutes.
This issue will also have a lesser effect when RLS re-SUBSCRIBEs from
clients occur. There will be a window (until the original SUBSCRIBE
expires) when there are multiple back-end SUBSCRIBE dialogs for each
contact.
Can anyone advise on this issue and suggest a solution?
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd